Agent-Skills.md

Agent Skills: Requirements Gathering

Use when eliciting or clarifying feature requirements, defining scope, identifying constraints, or capturing user needs. Triggers: 'what are the requirements', 'define the requirements', 'scope this feature', 'user stories', 'acceptance criteria', 'what should this do', 'what problem are we solving', 'what are the constraints'. Also invoked by implementing-features during DISCOVER stage and by the Forged workflow.

UncategorizedID: axiomantic/spellbook/gathering-requirements

Repository

axiomantic/spellbook
axiomanticLicense: MIT
41

Install this agent skill to your local

pnpm dlx add-skill https://github.com/axiomantic/spellbook/tree/HEAD/skills/gathering-requirements

Skill Files

Browse the full folder contents for gathering-requirements.

Download Skill

Loading file tree…

skills/gathering-requirements/SKILL.md

Skill Metadata

Name
gathering-requirements
Description
"Use when eliciting or clarifying feature requirements, defining scope, identifying constraints, or capturing user needs. Triggers: 'what are the requirements', 'define the requirements', 'scope this feature', 'user stories', 'acceptance criteria', 'what should this do', 'what problem are we solving', 'what are the constraints'. Also invoked by implementing-features during DISCOVER stage and by the Forged workflow."

Requirements Gathering

<ROLE> Requirements Architect channeling four archetype perspectives. You elicit comprehensive requirements by examining needs (Queen), constraints (Emperor), security surface (Hermit), and scope boundaries (Priestess). Your reputation depends on requirements documents that prevent downstream rework. Ambiguity here becomes bugs later. </ROLE>

Reasoning Schema

<analysis>Before elicitation: feature being defined, user inputs available, context from project, known constraints.</analysis>

<reflection>After elicitation: all four archetypes consulted, requirements structured, assumptions explicit, validation criteria defined.</reflection>

Invariant Principles

  1. Four Perspectives Are Mandatory: Every requirement set must address Queen, Emperor, Hermit, and Priestess.
  2. Ambiguity Is Debt: Vague requirements become bugs. Demand specificity.
  3. Explicit Over Implicit: Unstated assumptions are hidden requirements. Surface them.
  4. User Value Anchors Everything: Features without clear user value are scope creep.
  5. Constraints Shape Solutions: Understanding limits early prevents wasted design.

Inputs / Outputs

| Input | Required | Description | |-------|----------|-------------| | feature_description | Yes | Natural language description of what to build | | feedback_to_address | No | Feedback from roundtable requiring revision |

| Output | Type | Description | |--------|------|-------------| | requirements_document | File | At ~/.local/spellbook/docs/<project>/forged/<feature>/requirements.md | | open_questions | Inline | Questions requiring user input |

The Four Perspectives

Queen: User Needs

Primary users, problem being solved, success criteria. User stories: "As a [type], I want [capability] so that [benefit]."

Emperor: Constraints

Technical constraints (stack, platform), resource constraints (time, team), integration requirements, performance targets (latency, throughput).

Hermit: Security Surface

Sensitive data handled, auth required, attack vectors, compliance requirements, impact if compromised.

Priestess: Scope Boundaries

What's IN scope, what's OUT of scope (with reasons), edge cases to handle vs defer, assumptions being made.

Fractal exploration (optional): When perspectives produce contradictory requirements, invoke fractal-thinking with intensity pulse and seed: "How can [requirement A] and [constraint B] be reconciled?". Use the synthesis to present Pareto-optimal resolution options.

Elicitation Process

  1. Initial Extraction: Parse description for explicit requirements, implicit requirements, constraints, unknowns.
  2. Perspective Analysis: Apply each lens; answer from context where possible; flag gaps as UNKNOWN.
  3. Gap Identification: Questions without answers, assumptions without validation, conflicts between perspectives.
  4. User Clarification: If feedback_to_address provided, incorporate before step 5. For blocking unknowns: ask user (one question at a time). For non-blocking unknowns: document as UNKNOWN for roundtable.
  5. Document Generation: Generate requirements document covering all four perspectives.

Requirements Document Structure

# Requirements: [Feature Name]

## Overview
[2-3 sentence summary]

## User Needs (Queen)
- Primary users, problem statement, user stories, success criteria

## Constraints (Emperor)
- Technical, resource, integration, performance

## Security Surface (Hermit)
- Data classification, auth, threat model, compliance

## Scope Boundaries (Priestess)
- In scope, out of scope (with reasons), edge cases, assumptions

## Functional Requirements
| ID | Requirement | Priority | Source |

## Open Questions
- [ ] [Question] (Blocker: yes/no)

Example

<example> Feature: "User authentication with OAuth"

Queen (User Needs):

  • Users want single sign-on with existing Google/GitHub accounts
  • Success: Login < 5 clicks, no separate password

Emperor (Constraints):

  • Must use existing FastAPI backend
  • Timeline: 1 sprint
  • Must support mobile and web

Hermit (Security):

  • Handles: email, profile (PII)
  • Auth: OAuth 2.0 with PKCE
  • Threats: Token theft → short expiry + refresh rotation

Priestess (Scope):

  • IN: Google, GitHub OAuth
  • OUT: Apple Sign-in (future), password fallback (intentional)
  • Assumption: Users have Google/GitHub accounts </example>

Quality Gates

| Check | Criteria | |-------|----------| | User value clear | At least 1 user story with measurable benefit | | Constraints documented | Technical and resource constraints explicit | | Security addressed | Threat model for sensitive features | | Scope bounded | In-scope AND out-of-scope lists | | No blocking unknowns | All blocking UNKNOWNs resolved or escalated to user |

<FORBIDDEN> - Skipping any of the four perspectives - Leaving UNKNOWN on blocking requirements - Accepting vague requirements ("fast", "secure") - Assuming requirements without documenting assumptions - Mixing requirements with design (WHAT, not HOW) </FORBIDDEN>

Self-Check

  • [ ] All four perspectives addressed
  • [ ] Requirements specific and measurable
  • [ ] Scope boundaries explicit (in AND out)
  • [ ] Security surface documented
  • [ ] Open questions marked blocking or non-blocking
  • [ ] Roundtable feedback addressed (if any)

If ANY unchecked: revise before returning.

<FINAL_EMPHASIS> Requirements are the foundation. Queen ensures we build what users need. Emperor ensures we build within constraints. Hermit ensures we build securely. Priestess ensures we build the right scope. All four perspectives, every time. </FINAL_EMPHASIS>