User story
Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.
npx -y skills add tmj-90/gaffer --skill user-storyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when generating user stories with acceptance criteria, or planning sprint capacity against a set of stories. Triggers on "write user stories", "create stories for this feature", "break this into stories", "sprint planning", or "story points".
SKILL.md
3.3 KB, as published. Nobody here has run it
Generate structured user stories with acceptance criteria
A user story is not a task list — it's a unit of user value that can be independently delivered and tested.
Story format
As a [specific user role],
I want to [action / capability]
so that [outcome / value].
Acceptance criteria:
- Given [context], when [action], then [observable outcome].
- Given [context], when [error condition], then [error handling].
Anti-patterns to reject:
- "As a user" (too vague — which user?)
- Stories without AC ("it should work")
- Stories that describe implementation ("add a button") instead of value ("so that I can...")
- Stories > 8 story points (split them)
Story sizing heuristic (Fibonacci)
| Points | Scope |
|---|---|
| 1 | Trivial — confident implementation; no unknowns |
| 2 | Small — clear implementation; minor unknowns |
| 3 | Medium — clear approach; some complexity |
| 5 | Large — approach known; meaningful unknowns or cross-cutting |
| 8 | Extra large — approach uncertain; split if possible |
| 13+ | Epic — must be split before sprint planning |
INVEST principles (every story should satisfy all six)
- Independent — can be delivered without depending on another in-progress story.
- Negotiable — the how is open; the what and why are fixed.
- Valuable — delivers value to a real user, not just to engineering.
- Estimable — the team can size it; unknowns are identified.
- Small — fits in a sprint; ≤ 8 points.
- Testable — ACs allow a tester to confirm done from not-done.
Sprint planning
Given a capacity (in story points) and a prioritised backlog:
- Sort stories by priority (impact × confidence / effort).
- Take from the top until capacity is consumed.
- Flag any story ≥ 8 points — must be split before it enters the sprint.
- Confirm each story in the sprint satisfies INVEST.
Steps
- Gather context. Feature or epic description; user personas available; any existing requirements or PRD.
- Identify the user roles involved. For each distinct role, generate stories independently.
- Write stories in standard format. One value unit per story; INVEST check for each.
- Write at least two ACs per story. Happy path + at least one error/edge case.
- Size each story. Flag 8+ for splitting.
- For sprint planning — sort by priority; fill to capacity; confirm no 13+ point stories in the sprint.
Review checklist
- Specific user role — not "user" or "admin" (if there's only one admin role, "admin" is specific enough).
- Value stated explicitly — the "so that" is not "I can do X" but "I get [outcome]".
- ACs are testable — Given/When/Then format; observable outcomes.
- No story > 8 points without a split plan.
- INVEST satisfied — all six principles met for each story.
Rules
- A story without testable ACs cannot enter a sprint.
- Stories describe value, not implementation — if the "I want" clause describes code, rewrite it.
- Split at 8 points: a story that can't be done in a sprint is a planning risk.