Teams building an API or developer platform have an unusual relationship to their own specs: the requirements document isn't just internal process, it's the closest artifact to what the product actually is, since external developers experience the platform entirely through the contract it exposes.
Why EARS-format requirements fit API work especially well
The EARS format's precision — ubiquitous, event-driven, state-driven, unwanted-behavior, optional-feature statements — maps almost directly onto the kind of behavior an API contract has to specify anyway: what happens on a given request, what happens on an invalid one, what a flag changes, what's guaranteed versus what's implementation detail. Teams building APIs often find requirements.md reads less like new overhead and more like a formalized version of the API-behavior notes they were already half-writing in a design doc.
Full tier for anything that's a breaking or additive contract change
A new endpoint that extends existing patterns is usually light tier. A change to authentication, versioning strategy, rate-limiting behavior, or any modification that could break existing integrations is squarely full-tier territory — this is externally-facing architectural risk in the most literal sense, since a mistake here doesn't just cost you internally, it breaks other people's production systems.
Approval gates as the thing that actually prevents contract drift
The discipline against silently editing an approved requirements document mid-implementation matters more for a public API than almost anywhere else, because the requirements document is, in effect, the contract. An agent quietly "improving" an approved endpoint behavior mid-build isn't a documentation problem — it's a shipped breaking change nobody explicitly reviewed as one.
Investigation for issues reported by external developers
When a bug report comes from an external developer integrating against your API rather than from your own team, you often can't easily reproduce their exact environment — which makes the Investigate skill's insistence on verifying actual behavior, not just reasoning from code, and citing a specific root cause, the difference between a support reply that says "should be fixed now" and one that actually is.
For a platform team, the workflow isn't just development process — it's the mechanism that keeps the contract you're asking other developers to trust from drifting away from what you actually documented and reviewed.