Auto-Requirement

Create a concise, evidence-grounded requirement document that explains why the change is needed, what behavior is required, what is outside scope, and how success will be judged.

Scope Boundary

This skill owns:

• problem framing and desired outcomes
• target users and important scenarios
• functional requirements and acceptance criteria
• non-functional requirements and constraints
• business rules, states, and decision tables when they clarify behavior
• priorities, dependencies, assumptions, risks, and open questions

This skill does not:

• generate todolist.md or implementation tasks
• design file-by-file code changes unless needed to document an existing constraint
• implement, test, deploy, commit, or publish anything
• require another skill before or after it

Operating Principles

1. Single-agent by default. Analyze product, UX, technical feasibility, and risk in one coherent pass. Use additional agents only when the user explicitly requests delegation or the work contains genuinely independent research domains.
2. Evidence before invention. When a repository or source documents are available, inspect them before defining behavior that may already exist.
3. Ask only material questions. Ask the user when an answer would materially change scope, irreversible architecture, compliance, safety, cost, or external behavior. Do not block on details that can be handled with a clearly labeled assumption.
4. Draft early. Open questions may remain in a draft. A useful requirement document is better than withholding the entire artifact until every detail is known.
5. Adaptive depth. Small changes get short specifications. Complex stateful or regulated features get the additional rules, state models, examples, and risk analysis they need.
6. Preserve ownership. Do not overwrite unrelated user content, commit the document, or change code unless the user separately asks for those actions.
7. Protect secrets. Never read or reproduce .env, credentials, tokens, private keys, or secret files.

Workflow

1. Resolve the Input and Output

• If the user supplies text, files, links, or repository paths, treat them as source material.
• If the user supplies an output path, use it.
• Otherwise, in a repository use docs/requirements/YYYY-MM-DD-<topic>-requirement.md.
• If no repository convention exists, choose a clear local Markdown filename and report it.
• If revising an existing requirement, preserve confirmed decisions and explicitly identify changed assumptions or scope.

2. Gather Relevant Context

Inspect only what is needed:

• applicable AGENTS.md, README, product docs, prior requirements, and ADRs
• current behavior in relevant source and tests when the requirement changes an existing system
• recent related history when it clarifies intent or compatibility constraints
• user-provided research, examples, screenshots, tickets, or feedback

Record source paths or links in the document. Distinguish observed facts from inference.

3. Frame the Decision

Extract and reconcile:

• the problem and why it matters now
• desired outcomes and measurable success
• target users and primary scenarios
• in-scope and explicitly out-of-scope behavior
• constraints, dependencies, and compatibility expectations
• contradictions, hidden trade-offs, and failure scenarios

Do not turn requested implementation details into product requirements unless they are genuine system constraints. When the user has already made a technical decision, record it as a constraint or decision rather than silently reopening it.

4. Handle Ambiguity

Classify uncertainty:

• Blocking decision: different answers change product scope, public contracts, data safety, compliance, irreversible architecture, or substantial cost. Ask a concise question before finalizing the affected section.
• Non-blocking assumption: a conservative default can be reversed cheaply. Continue and record it in Assumptions with its impact if wrong.
• Future decision: not required for the current scope. Record it in Open Questions with an owner or decision point when known.

Batch related blocking questions. Do not run a fixed number of question rounds.

5. Write the Requirement

Use references/requirement-template.md, adapting it to the task. Required sections are:

1. document status and source context
2. problem and desired outcomes
3. users and scenarios
4. scope and non-goals
5. functional requirements with testable acceptance criteria
6. non-functional requirements and constraints
7. assumptions, dependencies, risks, and open questions

Use stable identifiers where they improve traceability:

• FR-001 for functional requirements
• NFR-001 for non-functional requirements
• BR-001 for business rules
• DEC-001 for decisions
• OQ-001 for open questions

Do not introduce goal/domain hierarchies merely to satisfy a template. For a small requirement, a flat list of well-written FR items is sufficient.

6. Validate Before Delivery

Check all of the following:

• every in-scope outcome maps to at least one functional requirement
• every Must requirement has concrete, observable acceptance criteria
• terms such as "fast", "simple", "secure", and "real-time" have measurable or operational meanings
• requirements describe behavior, not vague implementation activity
• non-goals do not contradict requirements
• IDs and cross-references are unique and valid
• assumptions are not presented as confirmed facts
• unresolved questions are visible and do not invalidate unrelated completed sections
• stateful behavior has valid states, transitions, failure handling, and recovery where applicable
• calculations or classification rules include at least one concrete example where applicable
• no implementation task list, code change, commit, or deployment instruction has leaked into the output

7. Write and Report

When the user asked to create or revise the requirement, write the file without an additional approval round unless a blocking product decision remains. Then report:

• output path
• status: Draft or Ready for Review
• number of functional and non-functional requirements
• assumptions and blocking open questions, if any
• important evidence boundaries or unverified areas

Do not commit the file automatically.

Depth Guide

Light

Use for a small, well-understood change. Include problem, scope, requirements, acceptance criteria, constraints, and open questions. Avoid personas and diagrams unless they add real information.

Standard

Use for a feature spanning multiple behaviors or components. Add scenarios, dependencies, risks, priorities, and compatibility expectations.

Deep

Use for complex business rules, stateful workflows, money, permissions, migrations, safety, or regulated domains. Add decision tables, state transitions, computation examples, failure recovery, data lifecycle, and explicit evidence gaps.

Quality Standard

A requirement is ready for review when a product owner can decide whether it should exist and an engineer can understand the required observable behavior without the document pretending that every implementation detail is already known.