agile-story
Story
Use this skill to create a clear execution plan, ready to implement.
Initial context received via slash: $ARGUMENTS
If $ARGUMENTS is filled (e.g., story reference, description, issue), use as starting point.
If empty, ask what will be planned.
Language
Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters. If the user's language is unclear, ask before generating output. Templates are in English — translate headers and content to match.
Objective
- Create a clear and proportionally simple execution plan
- Map impacted files
- Define verifiable tasks
- Produce artifact ready for immediate implementation
When to use
- Small and localized work — few files, low risk, single-cycle delivery
- A story from an epic that needs an operational execution plan
- Story already detailed in an epic that needs tasks mapped to files
- The problem is already clear and you just need to map out what to change
When NOT to use
- Large work needing decomposition — use
/agile-epic - Problem not yet clear — use
/agile-intake - Multiple dependent deliveries — use
/agile-epic - Need strategic direction — use
/agile-roadmap
Process
1. Understand what will be done
If coming from an epic story file, read the story and extract:
- Objective
- Impacted files
- Acceptance criteria
- Prototype routes/screens involved
- Business rule IDs/files involved
If standalone, ask the user and explore the code to understand context.
2. Build the plan
Fill in the required sections:
- Context: problem, objective, constraints
- Traceability: prototype routes/screens, business rule IDs/files, source docs
- Files: exact paths with action (read/alter/create)
- Detail: AS-IS, TO-BE, scope, approach
- Test-first plan: behavior to prove, first failing test, test level, and low-value tests to avoid
- Tasks: verifiable checklist
- Verification: commands and validations
3. Present and wait for confirmation
Use ExitPlanMode to present the plan. Wait for explicit confirmation before implementing.
Where to save
- If part of an initiative:
planning/<initiative>/epics/NN-<epic>/NN-story-name.md- When the story file from the epic already exists, add/update the Tasks and Verification sections in place.
- If standalone:
.agents/plans/<name>.md(for items without an epic)
Task plans are execution artifacts. They reference their parent story or epic via the Origin field. When part of an initiative, the story file already contains context — the task adds execution detail.
Cross-reference
If the plan comes from an epic, include at the top:
**Origin:** `planning/<initiative>/epics/NN-<epic>/00-overview.md`
Chaining
After plan confirmation:
- Implement following the checklist
- At the end, suggest
/agile-status(closure mode) to close the delivery
Reference template
Use templates/story.md from this skill as base.
Required sections
Every plan must contain:
- Context (problem, objective, constraints, references)
- Traceability (prototype routes/screens, business rule IDs/files, source docs)
- Files (exact paths, action, reason)
- Detail (AS-IS, TO-BE, scope, approach, risks)
- Test-first plan (behavior, first failing test, preferred level, and front-end value check when applicable)
- Tasks (verifiable checklist)
- Verification (lint, typecheck, tests, manual validation, acceptance)
Rules
- Every plan must be presented before implementation (ExitPlanMode).
- Only implement after explicit user confirmation.
- Don't create a task plan for work that needs an epic (large scope with several stories).
- Files must have exact paths.
- Reference business rule IDs when the story implements domain behavior, permissions, sync, conflict handling, AI approvals, or audit/versioning.
- Front-end plans should cite the prototype route/screen when the change is user-facing.
- Tasks must be verifiable, not vague.
- When completed, update
[ ]to[x]according to actual progress.
Relationship with the flow
flowchart LR
A["/agile-intake"] --> B["/agile-epic"]
B --> C["/agile-story"]
C --> D[execution]
D --> E["/agile-status"]
E --> F["/agile-retro"]
This skill is the last step before execution. For larger problems, use /agile-epic. To close the delivery, use /agile-status (closure mode).
More from djalmajr/essential-skills
agile-proto
Create interactive UI prototypes with a CDN-only stack (z-proto + Tailwind v4 + shadcn-style components + Preact/htm + preact-iso), including faithful send-to-Figma captures when requested. Use when asked to "prototype", "create proto", "mockup screens", "interactive prototype", "send to Figma", or when exploring UI flows before implementation.
17agile-metrics
Consolidates objective metrics of a sprint. Use when you need quantitative data about deliveries, blockers, deviations, and velocity to feed retro, sprint review, or capacity decisions.
17agile-retro
Conducts retrospective with learnings and improvement actions. Use when a cycle, sprint, or delivery has ended and the team needs to reflect on what worked and what needs to change. Also absorbs post-implementation reflection aspects.
16agile-intake
Structures new and vague problems into clear intake documents. Use when the problem is not yet mature enough for the backlog, when someone brings an idea or need without defined scope, or when you need to decide what the next artifact in the flow should be.
16agile-roadmap
Maps multi-phase trajectories with dependencies into clear, sequenced roadmaps. Use when work has multiple phases that need sequencing, when decisions today affect future decisions, when stakeholders need to see the whole journey, or when external dependencies exist. Applicable regardless of total duration — a 4-week multi-phase initiative benefits as much as a quarterly roadmap.
16agile-epic
Structures large initiatives into a decomposed backlog with roadmap, dependencies, and verification. Generates an overview file plus individual story files with tasks. Use when work requires several coordinated stories, has dependencies between deliveries, or needs a roadmap.
16