Skip to content
Skills Library
Programming · Building & coding

implement-tasks

/implement-tasks

Use to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task. Triggers on "/sdlc:implement-tasks {slug}", "implement {slug}", "build {slug}", "TDD {slug}", "code up the tasks for {slug}", "імплементуй {slug}", "реалізуй фічу {slug}", "напиши код за задачами {slug}". Reads docs/features/{slug}/tasks/tasks.json + the upstream artifacts, detects the repo's test/lint/vet commands stack-agnostically, builds a dependency DAG, and runs one of three modes — sequential single-agent TDD, an agent team (Te

Repository
sdlc ↗
Licence
MIT
Last repository change
25.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
9
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 25.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Use to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task. Triggers on "/sdlc:implement-tasks {slug}", "implement {slug}", "build {slug}", "TDD {slug}", "code up the tasks for {slug}", "імплементуй {slug}", "реалізуй фічу {slug}", "напиши код за задачами {slug}". Reads docs/features/{slug}/tasks/tasks.json + the upstream artifacts, detects the repo's test/lint/vet commands stack-agnostically, builds a dependency DAG, and runs one of three modes — sequential single-agent TDD, an agent team (Te

Triggers from the description

implement {slug}build {slug}TDD {slug}code up the tasks for {slug}імплементуй {slug}реалізуй фічу {slug}напиши код за задачами {slug}
Original author description

Use to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task. Triggers on "/sdlc:implement-tasks {slug}", "implement {slug}", "build {slug}", "TDD {slug}", "code up the tasks for {slug}", "імплементуй {slug}", "реалізуй фічу {slug}", "напиши код за задачами {slug}". Reads docs/features/{slug}/tasks/tasks.json + the upstream artifacts, detects the repo's test/lint/vet commands stack-agnostically, builds a dependency DAG, and runs one of three modes — sequential single-agent TDD, an agent team (Te

How it works

  1. Owner
  2. Inputs
  3. Protocol
  4. Decision tree (compact)
  5. TDD cycle (per task)
  6. Definition of Done
  7. Anti-patterns
  8. References & template
Original SKILL.md headings · 69 lines, 1,206 words
SKILL.md preview
---
name: implement-tasks
model: inherit
effort: medium
agents: [test-author, implementer, refactor, reviewer]
description: >
  Use to implement a feature from its tasks.json with test-driven development — writes a failing
  test first, makes it pass, refactors, gates, and commits per task. Triggers on
  "/sdlc:implement-tasks {slug}", "implement {slug}", "build {slug}", "TDD {slug}",
  "code up the tasks for {slug}", "імплементуй {slug}", "реалізуй фічу {slug}",
  "напиши код за задачами {slug}". Reads docs/features/{slug}/tasks/tasks.json + the upstream
  artifacts, detects the repo's test/lint/vet commands stack-agnostically, builds a dependency
  DAG, and runs one of three modes — sequential single-agent TDD, an agent team (TeamCreate), or
  a dynamic Workflow — chosen from settings + DAG shape with graceful fallback. Output: committed,
  tested code + updated tasks/tracker.md. Hard-refuses if docs/features/{slug}/tasks/tasks.json is
  missing (the legacy docs/features/{slug}/tasks.json is accepted as a fallback) → run
  `/sdlc:break-tasks {slug}` first.
triggers:
  - /sdlc:implement-tasks
stage: "17"
---

# Skill: implement-tasks (SDLC stage 17 — Code)

The implementation engine — the keystone that closes the cycle. It turns `tasks.json` into committed, tested code through a strict TDD cycle per task — `SELECT → RED → GREEN → REFACTOR → GATE → COMMIT` — and orchestrates that cycle in one of three modes (sequential / agent-team / dynamic-workflow) picked by an unambiguous decision tree. Everything is stack-agnostic: the test, lint, and vet commands are **detected**, never hard-coded.

This file is the spine. Each step delegates to a file in `references/`.

## Owner

Tech Lead drives; the engine runs the cycle. Four subagents ship with the plugin: [`test-author`](../../agents/test-author.md) (`sdlc:test-author`, RED), [`implementer`](../../agents/implementer.md) (`sdlc:implementer`, GREEN), [`refactor`](../../agents/refactor.md) (`sdlc:refactor`, REFACTOR — isolated, tidies while green), [`reviewer`](../../agents/reviewer.md) (`sdlc:reviewer`, read-only review). GATE + COMMIT stay on the engine, which owns the settings and the `require_integration` policy.

## Inputs

- `<slug>` — feature slug.
- **Gate (hard refuse):** `docs/features/<slug>/tasks/tasks.json` (legacy fallback: `docs/features/<slug>/tasks.json`, used only when the first is absent). Both missing → «run `/sdlc:break-tasks <slug>` first». Greenfield skeleton: `<slug>` = `_scaffold` (written by `map-architecture`).
- Read for context (the agents read these directly, not via paraphrase): `PRD.md` (AC), `data-model.md` + the **staged** migrations under `docs/features/<slug>/migrations/` (a `layer: migration` task **promotes** these into the live migrations tree — see [`./references/inputs.md`](./references/inputs.md)), `contracts/openapi.yaml`, `test-plan.md`, `sad.md`, Accepted `adr/`.
- Settings: `.claude/sdlc.local.md` (auto-created with documented defaults if absent — normally by `write-prd` at the backbone start; `implement-tasks` creates it too if you jump straight here) → [`./references/settings.md`](./references/settings.md).

## Protocol

1. **Preconditions.** Resolve the plan path — `docs/features/<slug>/tasks/tasks.json`, else the legacy `docs/features/<slug>/tasks.json` (warn that it's legacy) — verify it parses; load the upstream artifacts list. Detail → [`./references/inputs.md`](./references/inputs.md).
2. **Settings.** Read `.claude/sdlc.local.md`; if absent, auto-create it with the documented defaults (frontmatter + the «What each key does» body, self-documenting) and patch `.gitignore` (`.claude/*.local.md`, `.worktrees/`) — the same template `write-prd` writes. → [`./references/settings.md`](./references/settings.md).
3. **Detect commands.** Run the stack-agnostic cascade (settings override → Makefile → package scripts → language manifests → Docker probe for the integration tier) to resolve unit / integration / lint / vet commands. Print what was detected. → [`./references/command-detection.md`](./references/command-detection.md).
4. **Build the DAG.** Parse `tasks.json`, validate `deps` is acyclic, topologically sort into phases (Kahn). Compute `task_count`, `longest_chain`, `parallel_width`. Mark serialization lanes (`layer: migration`; tasks with overlapping `files_hint`). `layer: ui` is **not** auto-serialized — UI tasks parallelize unless their `files_hint` overlaps.
5. **Pick the mode.** Run the decision tree (below; full form → [`./references/decision-tree.md`](./references/decision-tree.md)). Apply the guards.
6. **Generate the run-plan.** Sequential → an ordered task list. Team → a shared TaskList with the full task text in each body. Workflow → a generated `Workflow` script (DAG → Kahn phases → fan-out pipeline). → [`./references/team-exec.md`](./references/team-exec.md) / [`./references/workflow-exec.md`](./references/workflow-exec.md).
7. **Banner.** Print the active mode and the settings that drove it: `mode=<…> tdd=<…> isolation=<…> parallel=<n> integration=<…>`. The user sees exactly how the engine will behave before it acts.
8. **Execute** in the chosen mode. Every task runs the TDD cycle → [`./references/tdd-loop.md`](./references/tdd-loop.md). A `layer: migration` task first **promotes** its staged migration(s) (`docs/features/<slug>/migrations/<NN>_*`) into the live migrations tree — assigning the real sequence number / timestamp per the repo's convention, in ordinal order — *then* applies + reverts them; detail → [`./references/inputs.md`](./references/inputs.md).
9. **Per-task gate + commit.** RED runs in `sdlc:test-author`, GREEN in `sdlc:implementer`, REFACTOR in the isolated `sdlc:refactor` agent. After GREEN+REFACTOR the **engine** runs the gate — unit + (integration if available) + lint + vet must be clean — then commits task-scoped with trailers `SDLC-Task: <id>` and `SDLC-AC: <id>` (one per satisfied AC). GATE + COMMIT are the engine's, not any agent's. Update `tasks/tracker.md` → `done`.
10. **Summary + hand off.** Report covered AC, commits made (with `SDLC-Task` trailers), any task dropped/blocked, and the per-task gate results. Then **emit the stage-handoff block** per [`../_shared/handoff.md`](../_shared/handoff.md) — *What I did* (covered AC, commits with `SDLC-Task` trailers, gate results) + *Review* (the committed diff + `tasks/tracker.md`) + *Run next* (`/clear`, then `/sdlc:review-feature <slug>` — a clean-context pass over the whole diff), then `/sdlc:ship-feature <slug>`. In team mode the [`reviewer`](../../agents/reviewer.md) may also run per-task, but the authoritative independent review of the whole change lives in the `review-feature` skill — `implement-tasks` does not self-certify.

## Decision tree (compact)

```
parallel_eligible := isolation==worktree AND max_parallel>1 AND parallel_width>=2
                     AND (size in {M,L,XL} OR task_count>=4)

if team_mode AND parallel_eligible:                          → AGENT TEAM (TeamCreate) over the DAG
elif workflow_mode=="auto" AND parallel_eligible AND Workflow-available: → DYNAMIC WORKFLOW
else:                                                        → SEQUENTIAL single-agent TDD (topo order)
```

**Guards (apply before dispatch):** `team_mode` but not eligible → warn + downgrade to the next mode. `max_parallel>1` with `isolation: inplace` → clamp parallel to 1 (no two agents edit one tree). `workflow_mode: off` → never generate a Workflow. `tdd: false` → skip RED (warn loudly — you lose the safety net). `require_integration: always` but Docker absent → **BLOCK** before dispatch; `auto` → run unit-only and mark integration NON-red; `never` → skip the integration tier. Full table → [`./references/decision-tree.md`](./references/decision-tree.md). Graceful degrade: if `Workflow`/`TeamCreate` is unavailable at runtime, fall through to sequential.

## TDD cycle (per task)

`SELECT → RED → GREEN → REFACTOR → GATE → COMMIT` — RED in `sdlc:test-author`, GREEN in `sdlc:implementer`, REFACTOR in the isolated `sdlc:refactor`, GATE + COMMIT on the engine. The RED step is load-bearing: write the test first, run it, and **classify the first run** — GOOD red (assertion fails / unimplemented) vs BAD red (the test itself won't compile → fix the test) vs false-pass (green immediately → the test is too weak, strengthen it) vs NON-red (skipped because Docker is absent → governed by `require_integration`, counts as neither red nor green). Quote the failing line before writing any production code. Escalation on persistent red → [`./references/escalation.md`](./references/escalation.md): more-capable model → retry → split the task → if the test encodes a wrong AC, **ask a human** (never weaken the test) → rollback to the last green. `stop_on_red` decides halt vs drop-and-continue (dependents auto-block).

## Definition of Done

- Every task in `docs/features/<slug>/tasks/tasks.json` is either committed (test-first, gate-clean, `SDLC-Task`/`SDLC-AC` trailers) or explicitly reported as dropped/blocked with the reason.
- Unit gate green; integration green where available (or NON-red recorded with the policy reason); lint + vet clean per the detected commands.
- The active mode + settings were printed in the banner before execution.
- `tasks/tracker.md` reflects final status; the summary reports the gate results and hands off to `review-feature` (the independent review gate) — `implement-tasks` does not self-certify the whole change.

## Anti-patterns

- **Code before the test.** RED first, always (unless `tdd: false`, which warns).
- **Weakening a test to make it pass.** If the AC is wrong, ask a human and fix the AC; never edit the test to be less strict.
- **Skipping the RED classification.** A false-pass that looks green hides a useless test.
- **Parallel agents editing one working tree.** Parallelism requires worktree isolation — the guard clamps it.
- **Committing with a red or skipped gate** and calling it done. A NON-red integration tier must be labelled, not hidden.
- **Spawning a team for <4 tasks** — coordination overhead exceeds the gain; the eligibility check forbids it.
- **Claiming integration passed when Docker was absent.** Report NON-red honestly.

## References & template

`inputs.md` · `settings.md` · `command-detection.md` · `decision-tree.md` · `tdd-loop.md` · `team-exec.md` · `workflow-exec.md` · `escalation.md` — all in [`./references/`](./references/).
Files in this package (9)
  • SKILL.md 10 KB
  • references/command-detection.md 3 KB
  • references/decision-tree.md 3 KB
  • references/escalation.md 2 KB
  • references/inputs.md 7 KB
  • references/settings.md 7 KB
  • references/tdd-loop.md 5 KB
  • references/team-exec.md 4 KB
  • references/workflow-exec.md 4 KB

Versions

RepositoryScoreLicence
This page · genkovich/sdlc100MIT
grixu/cc-toolkit100MIT

Database snapshot: 13.11.2026 · package version 401307aadc6d (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100implement
    Use to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task. Triggers on "implement {slug}", "build {slug}", "TDD {slug}", "code up the tasks for {slug}", "/sdd:implement…
  • 100break-tasks
    Use to break a designed feature into atomic, ≤1-day tasks with a dependency graph, a per-task Definition of Done, and a machine-readable tasks.json that the implement-tasks engine consumes. Triggers on "task breakdown for {slug}", "break down tasks for {slug}", "tasks for…
  • 100implement
    Implements a single task from the plan using TDD discipline. Reads the task spec, writes tests first, writes minimal passing code, refactors, and commits. Use when executing a planned task, writing code for a feature, or when the user says "implement this", "write the code",…
  • 100tasks
    Use to break a designed feature into atomic, ≤1-day tasks with a dependency graph, a per-task Definition of Done, and a machine-readable tasks.json that the implement engine consumes. Triggers on "task breakdown for {slug}", "break down tasks for {slug}", "tasks for {slug}",…
  • 90ship-feature
    Use to close the loop after review — verify the feature actually works, write the changelog, and open the pull request. Triggers on "ship {slug}", "open a PR for {slug}", "changelog for {slug}", "prepare {slug} for merge", "/sdlc:ship-feature {slug}", "відправ фічу {slug}",…
  • 100red-green-refactor
    Guides the red-green-refactor TDD workflow: write a failing test first, implement the minimum code to make it pass, then refactor while keeping tests green. Use when a user asks to practice TDD, write tests first, follow red-green-refactor, do test-driven development, write…

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.