| name | requirements-gathering |
| description | Extracts structured requirements from vague or underspecified requests. Produces acceptance criteria, explicit scope boundaries, constraints, and open questions. Use after brainstorming or when the user gives a fuzzy goal ("make it better", "add X", "support Y") and before planning or implementation. Bridges ideation to execution-ready specs. |
On-demand loading: Read this skill only when the task clearly matches the description above. Do not load for unrelated work.
Requirements Gathering
Purpose
Turn ambiguous requests into a structured requirements brief that planning and implementation can follow without guesswork. This skill is not open-ended design exploration—that is brainstorming. Here the focus is clarity, boundaries, and testable outcomes.
Pipeline: requirements-gathering → prd → spec-driven-development → writing-plans
When to use
- The user's ask lacks concrete success criteria, scope, or constraints.
- You are about to plan, estimate, or implement but critical facts are missing or assumed.
- Brainstorming produced ideas but nothing is yet captured as requirements.
- The request mixes multiple goals; you need to separate and prioritize them.
When to Skip or Defer
- The request is already specific (clear inputs, outputs, files, and done-when).
- Pure creative exploration is still needed—run
brainstorming first, then return here.
- Only trivial, one-line behavior is requested and repo context already defines the contract.
Process
1. Classify the gap
Silently note what is missing:
- Problem / outcome — What problem is solved? For whom?
- Scope — What is in vs out?
- Constraints — Time, tech, compliance, performance, compatibility.
- Evidence — What exists in the repo or docs that already answers part of this?
Use repository inspection and /docs when available; do not invent project facts.
2. Ask only what blocks a good brief
Prefer one focused question per turn when interacting with the user. If you can infer a reasonable default from the codebase, state the assumption in the brief instead of blocking.
3. Resolve conflicts
If goals conflict (e.g. speed vs full refactor), surface the tradeoff and record the decision or mark as open with options.
4. Produce the brief
Output the full template from references/requirements-brief-template.md in the assistant message (and optionally save under the project's docs/ tree if the user or project convention expects it—never invent paths for global/dotfiles-only workspaces).
Handoff
- To planning: Pass the brief as the source of truth; plans should reference requirement IDs or headings.
- After brainstorming: Condense dialogue into this template; drop exploratory options that were rejected.
- If still ambiguous: Ship the brief with a prominent Open Questions section and do not pretend gaps are closed.
Relationship to Other Skills
| Skill | Role |
|---|
brainstorming | Explores options and design collaboratively before requirements stabilize. |
requirements-gathering | Locks down what "done" means and what is excluded. |
prd | Formalizes requirements into a PRD with user stories and metrics. |
| Planning / ticket rules | Use the Acceptance Criteria and In/Out Scope as the backbone of tasks and verification. |
References
| File | Contents |
|---|
references/requirements-brief-template.md | Full brief template, quality bar, traceability table |
