git:20260506.9dce6ee to git:20260711.6a4c633

---

description: |

Use when turning a vague idea or stakeholder ask into structured user stories with acceptance criteria

and a requirements graph. For complexity >= 3 or compliance projects, defaults to graph mode.

NOT for navigating an existing requirements graph (use requirements-navigate) or stakeholder alignment (use product:align).

phase_relevance: ["clarify", "design", "review"]

archetype_relevance: ["*"]

---

# Requirements Analysis Skill

Structured requirements elicitation from discovery through documentation.

> **Default: Graph mode.** For complexity >= 3 or compliance projects, produce

> a `requirements/` graph (see `requirements-graph` skill) instead of a

> monolithic document. Use `--monolith` to force the legacy single-file format.

> See: `requirements-graph/SKILL.md` for graph layout and schema.

> See: `requirements-navigate/SKILL.md` for querying and maintaining the graph.

## Process

### 1. Context Gathering

- Read project brief, outcome.md, or requirements

- Identify existing documentation

- Note assumptions and constraints

### 2. Stakeholder Identification

- Who are the users/personas?

- Who are secondary stakeholders?

- Who has decision authority?

### 3. Requirements Elicitation

Ask the 5 W's:

- **Who**: Which users/personas?

- **What**: What capabilities needed?

- **When**: What triggers the need?

- **Where**: What context/environment?

- **Why**: What value/benefit?

### 4. User Story Definition

Format: **As a [persona], I want [capability], so that [benefit]**

Quality criteria:

- Specific persona identified

- Capability clearly stated

- Benefit/value articulated

- Testable outcome

### 5. Acceptance Criteria

For each story:

```

Given [context/precondition]

When [action/event]

Then [expected outcome]

```

Include:

- Happy path scenarios

- Error conditions

- Edge cases

- Non-functional requirements

### 6. Validation

Check:

- [ ] All stories have persona, capability, benefit

- [ ] Acceptance criteria are testable

- [ ] Edge cases identified

- [ ] Dependencies mapped

- [ ] Ambiguities flagged

## User Story Template

```markdown

### US{N}: {Story Title}

**As a** {specific persona}

**I want** {specific capability}

**So that** {specific benefit}

**Priority**: {P0/P1/P2}

**Complexity**: {S/M/L/XL}

**Acceptance Criteria**:

1. Given {context}, When {action}, Then {outcome}

2. Given {error condition}, When {action}, Then {error handling}

3. Given {edge case}, When {action}, Then {graceful handling}

**Non-Functional**:

- Performance: {requirement}

- Security: {requirement}

- Usability: {requirement}

**Dependencies**: {Other stories or systems}

**Assumptions**: {What we're assuming}

**Open Questions**: {What needs clarification}

```

## Common Patterns

**CRUD Operations**:

- Create: As a user, I want to create X, so that I can track Y

- Read: As a user, I want to view X, so that I can understand Y

- Update: As a user, I want to edit X, so that I can correct Y

- Delete: As a user, I want to remove X, so that I can clean up Y

**Authentication/Authorization**:

- Login, logout, password reset

- Role-based access control

- Session management

**Data Validation**:

- Input validation

- Error messaging

- Constraint enforcement

## Integration with Tools

```bash

# Search for similar requirements (FTS5 over indexed docs + wiki)

wicked-brain:search "user story"

# Store requirements on the active clarify task via native TaskUpdate

# TaskUpdate(taskId="{task_id}", description="{previous}\n\n## Requirements\n{user_stories}")

# Recall past patterns

Skill(skill="wicked-brain:memory", args="recall \"requirements for {feature_type}\"")

```

## Output Format

See: `refs/requirements-output-format-template.md`, `refs/requirements-example-auth.md`, and `refs/requirements-example-export-integration.md`