Przejdź do treści
Biblioteka skilli
Programowanie · Budowanie i kod

implement-tasks

/implement-tasks

Wdraża funkcję z tasks.json metodą TDD: test najpierw, potem kod przechodzący, refaktoryzacja, bramki i commit dla każdego zadania, z wykryciem poleceń test, lint i vet repozytorium.

Repozytorium
sdlc ↗
Licencja
MIT
Ostatnia zmiana repozytorium
25.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
9
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 25.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Wdraża funkcję z tasks.json metodą TDD: test najpierw, potem kod przechodzący, refaktoryzacja, bramki i commit dla każdego zadania, z wykryciem poleceń test, lint i vet repozytorium.

Wyzwalacze z opisu

implement {slug}build {slug}TDD {slug}code up the tasks for {slug}імплементуй {slug}реалізуй фічу {slug}напиши код за задачами {slug}
Oryginalny opis (EN)

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

Jak działa

  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
Sekcje z nagłówków SKILL.md, w oryginale · 69 linii, 1 206 słów
Podgląd SKILL.md
---
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/).
Pliki w paczce (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

Wersje

RepozytoriumWynikLicencja
Ta strona · genkovich/sdlc100MIT
grixu/cc-toolkit100MIT

Migawka bazy z 13.11.2026 · wersja paczki 401307aadc6d (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100implement
    Implementuje funkcję z pliku tasks.json metodą TDD: najpierw nieprzechodzący test, potem kod, refaktoryzacja, bramki jakości i commit dla każdego zadania.
  • 100break-tasks
    Dzieli zaprojektowaną funkcję na atomowe zadania do jednego dnia z grafem zależności, Definition of Done i plikiem tasks.json, który czyta silnik implement-tasks.
  • 100implement
    Realizuje pojedyncze zadanie z planu w dyscyplinie TDD: czyta specyfikację, pisze testy, minimalny kod przechodzący, refaktoryzuje i robi commit.
  • 100tasks
    Rozbija zaprojektowaną funkcję na niepodzielne zadania na jeden dzień i graf zależności oraz plik tasks.json dla silnika implementacji.
  • 90ship-feature
    Sprawdza działanie funkcji po przeglądzie, pisze changelog i otwiera pull request, a bez zaliczonego przeglądu odmawia.
  • 100red-green-refactor
    Prowadzi przez cykl TDD red-green-refactor: najpierw test, który pada, potem minimalny kod przechodzący test i refaktoryzacja przy zielonych testach.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.