Requirements Extract
Turn supplied source material into a traceable requirements/v1 JSON model without silently filling gaps. JSON is the source of truth; Markdown is generated from it.
Output language
- Produce all natural-language output in Ukrainian.
- Preserve exact source quotations in their original language when needed for provenance.
- Preserve code, identifiers, API names, file names, commands, and machine-readable values.
Artifacts
Use the project-defined location. Otherwise use:
docs/requirements/requirements.json — editable source of truth;docs/requirements/requirements.md — generated view.
Read references/contracts/requirements.schema.json before creating or editing the JSON. Treat schema_version: requirements/v1 as an exact compatibility boundary.
Workflow
Inventory every supplied source and choose the narrowest available locator: file, section, heading, paragraph, use case, cell range, or quoted fragment.
Extract requirements separately from background, examples, rationale, and optional solutions.
Build a staged UTF-8 JSON file that conforms to requirements/v1.
Validate the staged file:
python "<skill-dir>/scripts/pipeline_artifacts.py" validate requirements "<staged-json>"
Write it safely:
python "<skill-dir>/scripts/pipeline_artifacts.py" safe-write requirements "<staged-json>" "<output-dir>/requirements.json"
When the primary JSON exists, the command creates requirements.candidate.json or the next numbered candidate. Replace the primary file only after an explicit user request, using --replace.
Render the JSON path reported by safe-write. Use the matching Markdown name; a candidate JSON produces a candidate Markdown view and leaves the primary view unchanged.
python "<skill-dir>/scripts/pipeline_artifacts.py" render requirements "<written-json>" --output "<matching-markdown>"
The renderer groups requirements by type in contract order and sorts each group by numeric ID. Open items are ordered by importance: blocker before risk before note, then open before accepted-risk before resolved, then by numeric ID. Rendering never changes JSON array order.
Report processed and skipped sources, the actual written paths, requirement and open-item counts, and whether the result is primary or candidate.
For an existing requirements.json supplied for manual maintenance, validate it first. Regenerate requirements.md from the validated JSON; never parse Markdown back into JSON.
Extraction rules
- Preserve source meaning. Mark each requirement as
explicit or derived.
- Use stable IDs:
BG-*, BR-*, FR-*, NFR-*, and CON-*. Use OPEN-* for unresolved questions.
- Every requirement needs a concise normative statement and at least one valid source locator.
UNKNOWN -> OPEN: missing facts, undefined terms, conflicts, and behavior-changing assumptions become open items.- Preserve actors, conditions, thresholds, time limits, ownership, permissions, states, and constraints.
- Keep distinct requirements separate. Record a proposed solution as a constraint only when the source makes it mandatory.
- A derived requirement must list its supporting references and explain the necessary logical inference. If the inference needs an unstated business premise, create an open item instead.
- Give every open item a severity, status, reason, minimal resolution question, and affected requirement IDs.
Completion criteria
Finish only when the written JSON validates, every requirement traces to a known source, unresolved uncertainty is visible as OPEN-*, and the matching Markdown view exists.
Do not approve requirements, close open items, create acceptance criteria, choose architecture, or implement the system.
1---2name: requirements-extract3description: Extract a source-grounded requirements model from raw briefs, specifications, meeting notes, or process descriptions into editable requirements.json and generated requirements.md. Use as the first stage of a controlled requirements pipeline before critique, approval, design, or implementation.4---56# Requirements Extract78Turn supplied source material into a traceable `requirements/v1` JSON model without silently filling gaps. JSON is the source of truth; Markdown is generated from it.910## Output language1112- Produce all natural-language output in Ukrainian.13- Preserve exact source quotations in their original language when needed for provenance.14- Preserve code, identifiers, API names, file names, commands, and machine-readable values.1516## Artifacts1718Use the project-defined location. Otherwise use:1920- `docs/requirements/requirements.json` — editable source of truth;21- `docs/requirements/requirements.md` — generated view.2223Read [references/contracts/requirements.schema.json](references/contracts/requirements.schema.json) before creating or editing the JSON. Treat `schema_version: requirements/v1` as an exact compatibility boundary.2425## Workflow26271. Inventory every supplied source and choose the narrowest available locator: file, section, heading, paragraph, use case, cell range, or quoted fragment.282. Extract requirements separately from background, examples, rationale, and optional solutions.293. Build a staged UTF-8 JSON file that conforms to `requirements/v1`.304. Validate the staged file:3132 ```text33 python "<skill-dir>/scripts/pipeline_artifacts.py" validate requirements "<staged-json>"34 ```35365. Write it safely:3738 ```text39 python "<skill-dir>/scripts/pipeline_artifacts.py" safe-write requirements "<staged-json>" "<output-dir>/requirements.json"40 ```4142 When the primary JSON exists, the command creates `requirements.candidate.json` or the next numbered candidate. Replace the primary file only after an explicit user request, using `--replace`.43446. Render the JSON path reported by `safe-write`. Use the matching Markdown name; a candidate JSON produces a candidate Markdown view and leaves the primary view unchanged.4546 ```text47 python "<skill-dir>/scripts/pipeline_artifacts.py" render requirements "<written-json>" --output "<matching-markdown>"48 ```4950 The renderer groups requirements by `type` in contract order and sorts each group by numeric ID. Open items are ordered by importance: `blocker` before `risk` before `note`, then `open` before `accepted-risk` before `resolved`, then by numeric ID. Rendering never changes JSON array order.51527. Report processed and skipped sources, the actual written paths, requirement and open-item counts, and whether the result is primary or candidate.5354For an existing `requirements.json` supplied for manual maintenance, validate it first. Regenerate `requirements.md` from the validated JSON; never parse Markdown back into JSON.5556## Extraction rules5758- Preserve source meaning. Mark each requirement as `explicit` or `derived`.59- Use stable IDs: `BG-*`, `BR-*`, `FR-*`, `NFR-*`, and `CON-*`. Use `OPEN-*` for unresolved questions.60- Every requirement needs a concise normative statement and at least one valid source locator.61- `UNKNOWN -> OPEN`: missing facts, undefined terms, conflicts, and behavior-changing assumptions become open items.62- Preserve actors, conditions, thresholds, time limits, ownership, permissions, states, and constraints.63- Keep distinct requirements separate. Record a proposed solution as a constraint only when the source makes it mandatory.64- A derived requirement must list its supporting references and explain the necessary logical inference. If the inference needs an unstated business premise, create an open item instead.65- Give every open item a severity, status, reason, minimal resolution question, and affected requirement IDs.6667## Completion criteria6869Finish only when the written JSON validates, every requirement traces to a known source, unresolved uncertainty is visible as `OPEN-*`, and the matching Markdown view exists.7071Do not approve requirements, close open items, create acceptance criteria, choose architecture, or implement the system.
maximsamokhval