| name | story-execution |
| description | Facilitate the execution and review of a single user story through implementation, testing, and acceptance. Invoke when a developer or team is ready to begin work on a specific backlog story that has a code-producing component. |
Adapted from bmad-method:bmad-dev-story (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.
When to use
Use this skill when a team member is beginning active work on a single user story that involves software implementation. Typical triggers include:
- A story has been selected from the Sprint Backlog and assigned to a developer or pair.
- The team's project has a code-producing component (application, script, integration, data pipeline, etc.).
- The developer needs a structured record of implementation decisions, tests, and review notes tied to the story's acceptance criteria.
This skill is optional for v1 installs. Teams whose semester project produces no code — a pure planning or research project — should skip this skill. The skill acknowledges that PM-only teams can omit story-level technical execution from their artifact set without losing any other phase-3 capability.
Do not invoke for sprint planning, standup preparation, or sprint review; those are separate skills with distinct purposes.
Summon the SME
Before facilitating, load the user-story reference to ground execution in established practice.
Reading the config. Check .pm-kit.config.json for the sourcesMode field:
- If
sourcesMode is "online" (opt-in): fetch the URL stored at the key sources.storyExecution in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers.
- If
sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of user stories as described by Mike Cohn and the agile community — covering the "As a / I want / So that" format, acceptance criteria, and the definition of done. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.storyExecution in the output. Do not fabricate quotations or page numbers.
In both cases, the URL to cite is https://en.wikipedia.org/wiki/User_story.
Facilitation script
Walk the user through these steps in sequence. Do not skip steps or combine them.
Step 1 — Story summary. Ask the user to state the story ID, title, the user-story sentence ("As a … I want … so that …"), and the full list of acceptance criteria. Confirm all acceptance criteria are measurable and agreed upon before proceeding.
Step 2 — Implementation plan. Guide the developer in breaking the story into discrete technical steps. Each step should be completable in a single working session or less. Ask: "What are the technical sub-tasks needed to satisfy each acceptance criterion?"
Step 3 — Tests. Ask the developer to state what tests will verify the acceptance criteria. Record the test names or descriptions. Confirm at least one test exists per acceptance criterion.
Step 4 — Implementation execution. The developer performs the implementation work outside this skill. When implementation is complete, ask: "Is each acceptance criterion satisfied? Are all listed tests passing?"
Step 5 — Review notes. Capture the outcomes of the code or PM review: who reviewed, what was flagged, what was resolved, and what (if anything) was deferred.
Step 6 — Definition of Done verification. Walk through the team's Definition of Done item by item. Confirm each item is met. Record the outcome as a checklist in the artifact.
Step 7 — Lessons learned. Ask the developer for one or two short observations from this story: what went well, what would they do differently, or what process insight emerged.
Step 8 — Produce the artifact. Assemble the completed story execution record using the structure in TEMPLATE.md (sibling file). Fill every section. Leave no placeholder unfilled.
Step 9 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/story-execution/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 chars) derived from the story ID and title (e.g., us-42-user-login). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):
<!-- Generated by agentic-pm-kit:story-execution on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->
Languages
The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.
Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.
Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.
Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given.
Acceptance gate
When the story execution record is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.
