# Requirements

> This skill should be used when clarifying a feature, writing a requirements spec, running a structured discovery session, or when users mention requirements-start, requirements-status, requirements-current, requirements-list, requirements-remind, or requirements-end.

- Skill: `blogic-cz/requirements` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add blogic-cz/requirements`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blogic-cz/requirements/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: blogic-cz (https://skillmd.com/u/blogic-cz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/blogic-cz/requirements

---


# Requirements Skill

Run a structured 5-phase requirements workflow that turns a feature request into an implementation-ready specification.

Keep SKILL.md as the workflow source of truth. Load detailed templates and canned output text from `references/templates.md`.

## Purpose

- Clarify product and technical expectations before implementation.
- Capture assumptions explicitly.
- Produce a requirements spec that references real codebase patterns when available.

## When to Use

Use this skill when:

- A user asks to clarify scope for a new feature.
- A user asks to write or refine a requirements document/spec.
- A requirements command workflow is active (`requirements-start`, `requirements-status`, `requirements-current`, `requirements-list`, `requirements-remind`, `requirements-end`).

## Core Rules

1. Ask one question per message.
2. Keep each question closed-form:
   - yes/no, or
   - bounded multiple choice (2-5 options), with a default.
3. Generate all questions for the current phase first, then ask sequentially.
4. Keep product language primary; add technical notes only when they help decision quality.
5. During requirements gathering, do not implement code.
6. Use real repository paths once discovered. Use placeholders only in reusable templates/examples.
7. Keep phase question count bounded (target 5; allow 4-7 when justified).

## 5-Phase Workflow

### Phase 1 — Initialize Session

1. Create a requirement folder: `requirements/[timestamp]-[slug]/`.
2. Create initial artifacts:
   - `00-initial-request.md`
   - `metadata.json`
3. Update `requirements/.current-requirement` with the active folder.
4. Scan the codebase to identify relevant modules, data models, routes, and APIs.

If the repository structure differs, adapt paths and naming to that repository.

### Phase 2 — Discovery Questions (Product Scope)

1. Draft discovery questions focused on user outcomes, scope boundaries, permissions, data impact, and external integrations.
2. Write all phase questions to `01-discovery-questions.md` before asking any.
3. Ask questions sequentially, each with a proposed default.
4. Accept concise answers:
   - yes/no
   - one option from a bounded list
   - unknown/default
5. Store responses in temporary working notes while the phase is in progress.
6. After all questions are asked, persist finalized responses to `02-discovery-answers.md` and update `metadata.json`.

### Phase 3 — Context Gathering (Autonomous)

1. Search code for similar features and reusable patterns.
2. Review relevant backend/frontend/data files and integration points.
3. Record findings in `03-context-findings.md`:
   - similar features
   - candidate files to modify
   - constraints and risks
   - recommended patterns
4. Perform this phase without user questioning unless critical ambiguity blocks progress.

Use whichever search/read/navigation tools are available in the current agent runtime.

### Phase 4 — Detail Questions (Behavior & Design Decisions)

1. Derive follow-up questions from Phase 3 findings.
2. Write all phase questions to `04-detail-questions.md` before asking.
3. Ask one at a time with defaults.
4. Keep wording PM-friendly first, then include optional technical anchor when useful.
   - Good: “Should users edit this from the existing Project Settings screen?”
   - Optional anchor: “(Likely in `apps/web/src/routes/project-settings.tsx`)”
5. Store answers in temporary notes during the phase.
6. After all questions are asked, persist finalized responses to `05-detail-answers.md` and update `metadata.json`.

### Phase 5 — Generate Requirements Spec

1. Create `06-requirements-spec.md`.
2. Include:
   - overview
   - functional requirements and acceptance criteria
   - technical requirements
   - files/systems impacted
   - assumptions and open questions
3. Mark unresolved items as `ASSUMED:` with rationale.
4. Update metadata status to complete (or incomplete if explicitly paused).
5. Clear `.current-requirement` when the session ends.

Use spec templates from `references/templates.md`.

## Command Behaviors

### requirements-start

- Initialize the folder and metadata.
- Run Phase 1, then begin Phase 2.

### requirements-status

- Show current phase, progress, recent answers, and next question.
- Resume from the next unanswered question.

### requirements-current

- Show full read-only snapshot of the active requirement (all artifacts).
- Do not continue questioning unless explicitly asked.

### requirements-list

- List all requirement folders with status, sorted by:
  1. active,
  2. complete/incomplete,
  3. newest first.

### requirements-remind

- Show concise rule reminders based on current phase.
- Correct process drift (for example: open-ended questions, implementation drift, missing defaults).

### requirements-end

- If active requirement exists, offer:
  1. generate spec now,
  2. mark incomplete,
  3. cancel.
- Confirm destructive actions before deleting artifacts.

## Portability Rules

1. Treat project-specific paths as examples, not constants.
2. Treat companion skills as optional accelerators, not dependencies.
3. Prefer generic wording unless repository context confirms specific frameworks/tools.
4. Keep artifacts and process identical across agent runtimes.

## Quality Checklist

- Question sets are complete before asking begins.
- Every asked question has a default and rationale.
- Temporary notes are consolidated into phase answer files.
- Spec clearly separates confirmed decisions vs assumptions.
- Output stays requirements-focused (no implementation).

## Reference Files

- `references/templates.md` — canonical templates for:
  - question files
  - answer files
  - context findings
  - metadata
  - requirements spec
  - status/list/reminder output snippets