wicked-garden-product-requirements-analysis git:20260914.d73e4ddA

Immutable. This exact content never changes and is served at /api/v1/blob/21e1a95269c7343a.

---
name: wicked-garden-product-requirements-analysis
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).
metadata:
  role: module
  phases: "clarify,design,review"
  archetypes: "*"
---

# 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


**Hand-off** — open the `wicked-garden-mem` skill and run its `recall` action with `user story` as the query to find similar requirements (FTS5 over indexed docs + wiki), and again with `requirements for {feature_type}` to recall past patterns; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.

Store the requirements by appending `## Requirements` + the user stories to the active clarify task's description — the harness's task list where it has one (the `wicked-garden-workflow` skill's `refs/integration.md` carries the field list and the harness-specific Hand-off), else your working notes.

## Output Format

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