requirements

Formalize resolved designs into numbered, testable FR/NFR specifications in docs/REQUIREMENTS.md.

3|Updated Oct 28, 2020
One-click install
npx skills add https://github.com/k0d3x8its/dotfiles --skill requirements-k0d3x8its
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: requirements
Source: https://github.com/k0d3x8its/dotfiles/tree/main/claude/.claude/skills/requirements
Command: npx skills add https://github.com/k0d3x8its/dotfiles --skill requirements-k0d3x8its

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It turns a resolved design or brainstorm into a formal, numbered requirements specification with observable verification criteria, preventing vague or untestable requirements from reaching architecture and planning stages. ## Core Features & Use Cases - Gap-only interview: Reads prior brainstorm and grill-me findings first, then asks only about unresolved sections instead of re-asking settled questions. - Append-only FR/NFR numbering: Continues from the highest existing FR-NN/NFR-NN number, never renumbering or reusing retired identifiers so downstream citations stay valid. - Encryption gate: Checks .gitattributes for a git-crypt filter before writing docs/REQUIREMENTS.md, stopping plaintext writes by default. - Use Case: After running /grill-me to resolve open design questions for a new feature, invoke /requirements to produce a testable spec that /architecture can trace every requirement back to a component. ## Quick Start Run /requirements with a feature note after your design questions are resolved to generate a numbered FR/NFR spec at docs/REQUIREMENTS.md.

Frequently Asked Questions about requirements

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write testable functional requirements for a feature?▼

Phrase every requirement observably, with a verify clause naming a command or concrete check someone can run. This skill enforces that rule during its interview and refuses to number a requirement until it can be verified.

What comes after brainstorming in a spec-driven development pipeline?▼

After brainstorm and grill-me resolve open questions, the requirements step formalizes decisions into a numbered FR/NFR spec at docs/REQUIREMENTS.md. Architecture then designs the system and traces each requirement to a component.

Can I run a requirements spec without prior brainstorm documents?▼

Yes, the skill runs cold when no brainstorm or grill-me outputs exist. It conducts a longer interview to build the Overview, Problem Statement, and Users sections from scratch instead of reading prior artifacts.

Why does the skill stop before writing docs/REQUIREMENTS.md?▼

It enforces an encryption gate: the file is written encrypted by convention, so it checks .gitattributes for a git-crypt filter pattern first. If absent, it stops and recommends running /encrypt or explicitly confirming a plaintext exception.

What are the limitations of a requirements specification skill?▼

It only formalizes what must be true, never how: component design belongs to /architecture and task breakdown to /write-plan. It also never renumbers or reuses retired FR/NFR numbers, since downstream files cite them directly.