Implement Story Markdown

---
name: Implement a story according to the requirements and tasks
description: Implement story.md requirements and tasks.
user-invocable: false
---

# Implement a story according to the requirements and tasks

## Instructions

- The story should have tasks grouped by dependencies using the format from `story-flow:analyze-task-dependencies` skill.
  - Launch every group whose prerequisites are complete concurrently in a single message, without waiting for the other groups to finish. Group order in the file is not execution order — all groups headed "no prerequisites" start together.
  - Dispatch one task at a time within a `**Sequential ...**` group; dispatch every task of a `**Parallel ...**` group concurrently in a single message. Start each subagent prompt with `Task <N>:`, N being the task's number in the story.
- You are an **orchestrator**, not an implementer.
  - **REQUIRED:** Immediately delegate ALL tasks to subagents using the **Task tool** to run them in isolated context.
  - **FORBIDDEN tools for orchestrator (NEVER use directly):**
    - Glob, Grep, Read
    - Write, Edit, MultiEdit
    - WebSearch, WebFetch
    - TaskCreate, TaskUpdate, TaskGet, TaskList
    - Task with Explore subagent
- Instruct each subagent:
  - When installing dependencies, use the latest stable version, or a higher patch version within the existing minor if the project pins one.
  - After implementing UI according to UI design HTML files, verify by taking screenshots of both the UI and the design using `mcp__plugin_story-flow_chrome-devtools__navigate_page` and `mcp__plugin_story-flow_chrome-devtools__take_screenshot`.
  - For every source file created or modified, update the corresponding test file to achieve 100% coverage and ensure all linting warnings and errors are resolved.
    - One test case per scenario/behavior, not one test per assertion.
    - Combine test assertions for basic rendering into a single test - only separate tests when testing different states, behaviors, or edge cases.
    - Every test must have assertions that verify the behavior described in its test name — not just that the code runs without crashing.
      - No missing assertions: every test must contain at least one `expect()` that checks a meaningful outcome.
      - Assertions must be correct: expected values must match the actual business logic, not be copied from implementation output without verification.
  - Report back to the orchestrator just "completed" or "failed". On success, strictly nothing else. On failure, include a brief summary of the issues encountered.
- When a story references the qa-tester subagent for planning BDD scenarios, use the qa-tester subagent and instruct it to load skills in this order using the Skill tool:
  1. First: `story-flow:plan-bdd-scenarios` (plugin - general BDD planning protocol)
  2. Then: `plan-bdd-scenarios` if it exists (project-level - overrides/extends the plugin)
  3. Confirm which skills are loaded before continuing with BDD planning.

## Example Inputs

- Implement story according to @path/to/story.md
- Implement story markdown @path/to/story.md
- Implement story @path/to/story.md
- Implement @path/to/story.md
- Implement the following plan
- Implement this plan
- Execute this plan
- Proceed with implementation