Requirements Engineering

Why this skill exists. Good architecture is a byproduct of good requirements — you do not design it directly, you clarify the requirements until the modules, boundaries, and contracts they imply become obvious. This skill produces the WHAT (the specification and the contracts to honor); the ios-architecture-expert skill turns it into the HOW. Every artifact here starts from a conversation that eliminates assumptions — see references/clarifying-questions.md.

Agent Behavior Contract

When this skill is active, follow these rules strictly:

1. Include the artifacts the feature warrants — the full set (BDD Narrative, Acceptance Criteria, Use Cases, Model Specs, Payload Contract, Flowchart, Architecture Diagram) for a non-trivial networked feature, but omit ones that don't apply: an online-only feature needs no offline narrative, cache use case, or Cancel course; a feature reusing a model needs no new Model Spec. The architecture diagram is one shared app-level graph, not one per feature.
2. Never accept vague requirements without asking clarifying questions first — Who are the user types? What happens offline? What are the error cases?
3. Use domain-specific language consistently across all artifacts — if the domain says "image feed" not "feed items", use "image feed" everywhere.
4. Every use case must have a Data section listing ALL inputs, a Primary course, at least one Error course, and a Cancel course where applicable.
5. Model Specs must use Property/Type tables — not prose descriptions.
6. Payload Contracts must show HTTP method, path, status code, and example JSON — including optional fields demonstrated by omission.
7. Requirements are living specifications — iterate and refine as understanding evolves, do not treat as one-time documents.

Requirements Diagnostic Table