User Story Capture
Derive structured user stories and acceptance criteria from exploration session captures.
Usage
python ./scripts/execute.py \
--input <file> [<file2>...] \
--format <standard|gherkin> \
--output <output_file.md>
Formats:
standard (default): As a [user type], I want [goal], so that [benefit] — with priority table and gaps.
gherkin: Standard + Given / When / Then Acceptance Criteria blocks per story.
Flags:
--input PATH [PATH ...] : Session brief, BRD draft, prototype notes, or prior captures
--output PATH : Destination file (default: exploration/captures/user-stories-draft.md)
--format FORMAT : Output format (default: standard)
Interactive Co-Authoring Workflow
When invoked interactively, follow this 3-stage pattern. Do not dump a full story list at once.
Stage 1: Context Gathering
Ask all three questions in a single message before generating anything:
- Input files: Which source documents should I work from? (Check
exploration/ — list what you find: session brief, BRD draft, prototype notes.) If no files exist, stop and ask for input before proceeding.
- Primary actor: Which user role, system actor, or job-to-be-done is the highest priority for the first implementation slice? (Use role-neutral language — e.g., "the person approving requests", "the agent running evals", not just "the user".)
- Out-of-scope: Are there any actors or workflows we should explicitly exclude from this story set?
- Format: Should acceptance criteria use standard format (
As a / I want / So that) or Gherkin (Given / When / Then)? Default to standard unless Gherkin is requested.
After the user responds: read each input file they identify.
Stage 2: Iterative Refinement
Build the backlog in layers — do not jump straight to full Gherkin blocks.
Outline first: Based on the input files and primary actor, present a numbered list of lightweight story titles (one line each, no ACs yet). Ask: "Which of these should we keep, cut, or merge for the first slice?"
Curate: Apply changes. Mark any story derived from unclear or inferred source material as [UNCONFIRMED].
Draft approved stories: For each kept story, write the full format:
- Standard:
As a [actor], I want [goal], so that [benefit].
- Gherkin: Add
Given / When / Then AC blocks after the story statement.
Gherkin format rules:
Given = precondition or system state before the action (what is already true)
When = the single action or event the actor performs
Then = the observable, testable outcome (what changes or appears)
- One
When per scenario. Use And for additional Given or Then clauses.
Present each story and ask: "Accurate? Anything to add or change?" Apply edits before the next story.
Stage 3: Reader Testing (Test-Driven ACs)
After all approved stories are drafted:
- For each priority story (top 3 if there are many), predict exactly 2 edge cases or failure modes that a QA engineer would test but that the current ACs do not cover. An edge case must be specific and testable — not generic ("what if it fails?") but concrete ("what if the file is missing at sync time?").
- Present the gaps: "Story [N] doesn't handle: [edge case 1], [edge case 2]. Should we add scenarios for these?"
- If yes: add
Given / When / Then blocks for the confirmed edge cases. Mark inferred edge cases [UNCONFIRMED] until the user confirms they are real scenarios.
- Collect all unresolved questions in a
## Story Gaps section at the end.
Anti-Hallucination Rules
- Do NOT invent user types, goals, or benefits not described in source captures.
- Do NOT fabricate edge cases in Gherkin AC without evidence from input files or explicit user confirmation.
- Mark inferred stories and scenarios
[UNCONFIRMED] — only promote to [CONFIRMED] after human sign-off.
- Do NOT proceed without input files — stories generated from nothing are pure hallucination.
- Source citations required: each story must note which input file it derives from (e.g.,
(source: brd-draft.md, Functional Requirements)). Stories with no traceable source must be marked [UNCONFIRMED — inferred, not in source].
## Story Gaps section is mandatory — list every open decision or missing actor definition exactly once.
1---2name: user-story-capture3description: Derives, groups, and refines user stories from exploration work, prototype behavior, and business context, with prioritization for the first implementation slice. Supports standard "As a / I want / So that" format and Gherkin "Given / When / Then" Acceptance Criteria format. Trigger with "generate user stories", "write acceptance criteria", "create Gherkin scenarios", "derive stories from requirements", or "create a backlog".4---56# User Story Capture78Derive structured user stories and acceptance criteria from exploration session captures.910## Usage1112```bash13python ./scripts/execute.py \14 --input <file> [<file2>...] \15 --format <standard|gherkin> \16 --output <output_file.md>17```1819**Formats:**20- `standard` *(default)*: `As a [user type], I want [goal], so that [benefit]` — with priority table and gaps.21- `gherkin`: Standard + `Given / When / Then` Acceptance Criteria blocks per story.2223**Flags:**24- `--input PATH [PATH ...]` : Session brief, BRD draft, prototype notes, or prior captures25- `--output PATH` : Destination file (default: `exploration/captures/user-stories-draft.md`)26- `--format FORMAT` : Output format (default: `standard`)2728## Interactive Co-Authoring Workflow2930When invoked interactively, follow this 3-stage pattern. Do not dump a full story list at once.3132### Stage 1: Context Gathering33Ask all three questions in a single message before generating anything:34351. **Input files:** Which source documents should I work from? (Check `exploration/` — list what you find: session brief, BRD draft, prototype notes.) If no files exist, stop and ask for input before proceeding.362. **Primary actor:** Which user role, system actor, or job-to-be-done is the highest priority for the first implementation slice? (Use role-neutral language — e.g., "the person approving requests", "the agent running evals", not just "the user".)373. **Out-of-scope:** Are there any actors or workflows we should explicitly exclude from this story set?384. **Format:** Should acceptance criteria use standard format (`As a / I want / So that`) or Gherkin (`Given / When / Then`)? Default to standard unless Gherkin is requested.3940After the user responds: read each input file they identify.4142### Stage 2: Iterative Refinement43Build the backlog in layers — do not jump straight to full Gherkin blocks.44451. **Outline first:** Based on the input files and primary actor, present a numbered list of lightweight story titles (one line each, no ACs yet). Ask: *"Which of these should we keep, cut, or merge for the first slice?"*462. **Curate:** Apply changes. Mark any story derived from unclear or inferred source material as `[UNCONFIRMED]`.473. **Draft approved stories:** For each kept story, write the full format:48 - Standard: `As a [actor], I want [goal], so that [benefit].`49 - Gherkin: Add `Given / When / Then` AC blocks after the story statement.5051 **Gherkin format rules:**52 - `Given` = precondition or system state before the action (what is already true)53 - `When` = the single action or event the actor performs54 - `Then` = the observable, testable outcome (what changes or appears)55 - One `When` per scenario. Use `And` for additional `Given` or `Then` clauses.5657 Present each story and ask: *"Accurate? Anything to add or change?"* Apply edits before the next story.5859### Stage 3: Reader Testing (Test-Driven ACs)60After all approved stories are drafted:61621. For each priority story (top 3 if there are many), predict exactly 2 edge cases or failure modes that a QA engineer would test but that the current ACs do not cover. An edge case must be specific and testable — not generic ("what if it fails?") but concrete ("what if the file is missing at sync time?").632. Present the gaps: *"Story [N] doesn't handle: [edge case 1], [edge case 2]. Should we add scenarios for these?"*643. If yes: add `Given / When / Then` blocks for the confirmed edge cases. Mark inferred edge cases `[UNCONFIRMED]` until the user confirms they are real scenarios.654. Collect all unresolved questions in a `## Story Gaps` section at the end.6667## Anti-Hallucination Rules6869- Do NOT invent user types, goals, or benefits not described in source captures.70- Do NOT fabricate edge cases in Gherkin AC without evidence from input files or explicit user confirmation.71- Mark inferred stories and scenarios `[UNCONFIRMED]` — only promote to `[CONFIRMED]` after human sign-off.72- Do NOT proceed without input files — stories generated from nothing are pure hallucination.73- **Source citations required:** each story must note which input file it derives from (e.g., `(source: brd-draft.md, Functional Requirements)`). Stories with no traceable source must be marked `[UNCONFIRMED — inferred, not in source]`.74- **`## Story Gaps` section is mandatory** — list every open decision or missing actor definition exactly once.7576<example>77Context: BRD draft is complete, user wants a core story set.78user: "Generate user stories from our BRD."79assistant: "I'll run `user-story-capture` in standard format to derive a prioritised story set."80</example>8182<example>83Context: User wants stories with ready-to-use Acceptance Criteria.84user: "Create Gherkin acceptance criteria for these requirements."85assistant: "I'll run `user-story-capture --format gherkin` to produce stories with Given/When/Then AC blocks."86</example>8788<example>89Context: Pre-sprint refinement.90user: "Write acceptance criteria for the checkout flow stories."91assistant: "I'll use `user-story-capture --format gherkin` with the checkout BRD sections as input."92</example>