--- 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/.md`. `` 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): ``` ``` ## 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.