requirements

Files (2)

• SKILL.md
• template.md · references/

SKILL.md (first lines)

# Requirements Skill

A skill for creating, updating, improving, and reverse-engineering software requirements documents following a
standardized template format.

## Template Format

All requirements documents follow this structure (see full template in `references/template.md`):

**Flat format** (simple, single-component documents):

```markdown
# _Project / Component Name_ – Requirements

## Overview

_Brief description of purpose, scope, and objectives._

## Functional Requirements

- [ ] **FR-1**: [Requirement description]
    - Additional details or sub-requirements as bullet points

## Non-Functional Requirements

- [ ] **NFR-1**: [Non-functional requirement]
    - Specific metrics or benchmarks

## Technical Constraints and Requirements

- [ ] **TR-1**: [Technical constraint or requirement]
    - Context or reasoning
```

**Grouped format** (recommended for multi-component systems):

```markdown
# _Project / Component Name_ – Requirements

## Overview

_Brief description of purpose, scope, and objectives._

## Functional Requirements

### 1. _Component or Feature Group_

- [ ] **1.1**: [Requirement description]
    - Additional details or sub-requirements as bullet points

- [ ] **1.2**: [Another requirement in this group]

### 2. _Another Component_

- [ ] **2.1**: [Requirement description]

## Non-Functional Requirements

### 1. _Category (e.g. Performance)_

- [ ] **1.1**: [Non-functional requirement]
    - Specific metrics or benchmarks

## Technical Constraints and Requirements

### 1. _Category (e.g. Platform)_

- [ ] **1.1**: [Technical constraint or requirement]
    - Context or reasoning
```

**Key rules**:

- **Flat format**: IDs use `FR-N`, `NFR-N`, `TR-N` (incrementing integers)
- **Grouped format**: H3 headings (`### N. Name`) group requirements by component or category within each H2 section;
  numbering restarts at 1 per H2 section; requirement IDs are `N.M` (e.g., `1.1`, `2.3`)
- Use flat for simple single-component docs; use grouped when requirements span multiple distinct components
- Each requirement is a checkbox `- [ ]`
- Sub-details are indented bullet points under the requirement
- File is named `requirements.md` (or `prd.md` if that already exists in the project)
- Multiple requirements files per project are fine (e.g., per component) — identify the right one

**Hard rule — no implementation details**:

Requirements describe _what_ the system must do from the user's perspective, never _how_ the code implements it. Class
names, function names, method names, variable names, type names, constants, and file names are implementation details —
their presence in a requirement is a **red flag** signalling a violation. This rule applies to all workflows, not only
reverse-engineering.

- Test: "Could a non-developer stakeholder understand this requirement?" If not, rewrite it.
- Bad: `"The ConfigParser::load() method must accept a file path parameter."`
- Good: `"The system must load its configuration from a file path supplied at startup."`

## Workflows

Choose the appropriate workflow based on the user's situation:

---

### A. Create New Requirements (from idea or description)

Use when: User has a vague idea, feature description, or verbal concept with no existing docs.

1. **Parse the initial description** — extract what you can about the goal, users, and scope
2. **Identify gaps** — list what's unclear: Who are the users? What are the boundaries? What does success look like?
3. **Ask clarifying questions iteratively** using the 5W1H framework:
    - **WHO**: Target users, personas, stakeholders
    - **WHAT**: Exact functionality, data handled, system behavior
    - **WHY**: Business value, problem being solved
    - **WHEN**: Timeline constraints, dependencies
    - **WHERE**: System boundaries, integration points, environments
    - **HOW**: Technical constraints, performance needs, existing systems
4. **Never settle for vague answers** — probe with: "Can you give a specific example?", "How would you measure that?",
   "What happens if we don't include this?"
5. **Draft the requirements document** following the template
6. **Present for review** and iterate until confirmed

**Important**: Focus on _what_ the system should do, not _how_ it does it. Avoid prescribing technical solutions unless
explicitly requested. If a class name, function name, or variable name appears in a requirement you are drafting, stop

From kubasejdak-org/dotfiles-ai, MIT.

More from kubasejdak-org/dotfiles-ai