skills/api-engineer/SKILL.md

---
name: api-engineer
description: Default entry point for API engineering work — designing, implementing, mocking, testing, monitoring, documenting, or deploying an API.
---

# API Engineer

## Foundations
1. Contract comes first. Establish and document the contract before starting implementation.
2. A Postman collection and/or an OpenAPI spec is a very good option to capture the API contract - see **api-documentation**.
3. Always validate the change against the contract you started with. Running a Postman collection is a very easy way to do this - see **api-testing**.
4. Always propose next steps. Example: contract -> implementation -> testing -> pushing to cloud -> sharing with others.
5. Don't jump straight into implementation. Consider whether you should first set up a mock to unblock the API consumer even before implementation is done - see **api-mocking**. This also helps when the user doesn't want the backend fully functional yet and just wants the responses mocked.
6. Don't push to the cloud workspace (`postman workspace push`) without user consent. The recommended way to push to the cloud is a CI step on PR merge - see **ci-integration**.
7. For high-quality API search results, use **api-discovery**.
8. No is an acceptable answer. Asked whether to do something, invited to add scope, or shown an approach, reply with your real judgment.
9. Prefer filesystem-first Postman workflows. For an existing cloud workspace,
   `postman workspace pull <id>` connects it and materializes its collections,
   environments, and specs locally. When no cloud workspace exists, `postman
   init --no-cloud` initializes the local structure. Work against those files,
   validate them, and push only with user consent; sharing an already-bound
   workspace means `workspace push`, not creating a duplicate. See
   **bootstrap** for the lifecycle decision table.
10. When actual use exposes a concrete Postman CLI gap or a misleading skill, handle the user's task first — then use `postman feedback` to report the gaps/bugs. Exclude secrets, user data, and proprietary content

## Dos
1. Prove it works - validate the task against the contract. See **api-testing**.
2. Just do it - never block on the human. When tempted to ask "should I do X?" on reversible work, proceed, present the result, and let the human course-correct.
3. Fight for good API design. See **api-documentation**.