# Implement > Generate production code and tests for a story group using agent teams for parallel execution. - Skill: `cwijayasundara/implement-3` (Agent Skill) - Install (CLI): `npx skillmds@latest add cwijayasundara/implement-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/cwijayasundara/implement-3/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: cwijayasundara (https://skillmd.com/u/cwijayasundara) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/cwijayasundara/implement-3 --- # Implement Skill Generate production-quality code and tests for all stories in a dependency group, using a Claude Code agent team for parallel execution. --- ## Usage ``` /implement C ``` Implements all stories in group C. The group ID corresponds to a node in `specs/stories/dependency-graph.md`. --- ## Prerequisites Before running `/implement`, verify: - `specs/stories/dependency-graph.md` exists and lists groups with story assignments. - `specs/design/component-map.md` exists and maps each story to the files it owns. - All stories in the target group have acceptance criteria written. - All upstream groups are already implemented and passing evaluation. If any prerequisite is missing, stop and report what is absent. Do not proceed with partial context. --- ## Execution Steps ### Step 1 — Load Quality Principles Read `.claude/skills/code-gen/SKILL.md` in full. These six principles (small modules, static typing, functions under 50 lines, explicit error handling, no dead code, self-documenting names) apply to every line of code produced. Inject the full text into every teammate prompt. ### Step 2 — Load Dependency Graph Read `specs/stories/dependency-graph.md`. Identify: - Which stories belong to the requested group. - Which groups must be complete before this group (upstream dependencies). - The total story count for this group. Abort if upstream groups are not yet evaluated as PASS. ### Step 3 — Load Component Map Read `specs/design/component-map.md`. For each story in the group, extract: - The list of files the story owns (may create or modify). - Any shared interface or type files that multiple stories reference. This ownership map is the single source of truth for file assignments during parallel execution. ### Step 4 — Load Learned Rules Read `.claude/state/learned-rules.md`. Inject ALL rules verbatim into every teammate spawn prompt. Learned rules represent project-specific decisions made during previous sprints (naming conventions, library choices, API patterns). Skipping this step causes regressions. ### Step 5 — Spawn Agent Team (Multiple Stories) If the group contains **2 or more stories**, spawn a Claude Code agent team: - Create **1 teammate per story**, up to a maximum of **5 concurrent teammates**. - If the group has more than 5 stories, batch them: first 5 stories run, then the remainder after all complete. - Each teammate spawn prompt must include: - The story's acceptance criteria (full text). - The file ownership list from component-map.md for that story. - All learned rules from `.claude/state/learned-rules.md`. - All six quality principles from `.claude/skills/code-gen/SKILL.md`. - Instruction to **message teammates** before modifying any shared type or interface file. - Instruction to **await plan approval** before writing any code (present the plan, wait for confirmation). - Teammates must coordinate on shared types: - Before editing a type definition used by another story's files, send a message to the affected teammate describing the change. - Teammate receiving the message must acknowledge before the edit proceeds. - If two teammates claim ownership of the same file, escalate to the orchestrator (this agent). Do not merge partial changes. Resolve ownership, then continue. ### Step 6 — Use Generator Directly (Single Story) If the group contains exactly **1 story**, do not spawn a team. Execute the story using the generator agent directly: - Present a plan (files to create/modify, type definitions, test strategy). - Await approval. - Implement code, then write tests. ### Step 7 — Validation Gate After all teammates (or the generator) complete: 1. Run the full test suite: `npm test` or `pytest` (whichever applies to the project). 2. Run the linter: `npm run lint` or `ruff check .`. 3. Run the type checker: `tsc --noEmit` or `mypy .`. All three must pass with zero errors before proceeding. If any fails, return the failure output to the responsible teammate for a fix, then re-run the validation gate. ### Step 8 — Code Review Spawn the `code-reviewer` agent on the set of changed files: - Pass the list of modified files and the story acceptance criteria. - The reviewer emits findings at three severity levels: **BLOCK**, **WARN**, **INFO**. - **BLOCK** findings must be fixed. Spawn the responsible teammate to address the finding, re-run tests, re-run the reviewer. Maximum **3 retry cycles**. - **WARN** findings are logged but do not block merge. - **INFO** findings are optional improvements. If the reviewer still emits BLOCK findings after 3 retries, escalate to the user with a summary of the unresolved issues. --- ## Rules - Every file produced must trace to a story in the current group. No story, no code. - Code is written first; tests are written after, against the public interface. - No speculative code ("might need later"). If it is not in an acceptance criterion, it does not exist. - Teammates may not edit files outside their ownership assignment without coordinator approval. - Plan approval is mandatory before any teammate begins coding. Skipping this step is not a time-saver — it causes conflicts and rework. --- ## Gotchas - **Teammates editing the same file:** Prevent this with the ownership map. If it happens anyway, stop both teammates, resolve ownership, reconcile changes manually. - **Skipping plan approval:** Leads to scope creep, missed acceptance criteria, and merge conflicts. Always require the plan step. - **Deferring test coverage:** Tests are written in the same sprint cycle, not later. "I'll add tests in the next sprint" is not acceptable. - **Vibe coding without acceptance criteria:** Every function must trace to an acceptance criterion. If the criterion does not exist, do not write the code — write the criterion first. - **Ignoring learned rules:** Failing to inject `.claude/state/learned-rules.md` recreates decisions the team has already made, causing style and pattern drift.