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

dev-code

/dev-code

Pisze kod w każdym zadaniu programistycznym, wykonując zadania z planu w kolejności zależności i commitując każde osobno.

Repozytorium
tejit-plugin ↗
Licencja
MIT
Ostatnia zmiana repozytorium
10.11.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
2
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 10.11.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

Pisze kod w każdym zadaniu programistycznym, wykonując zadania z planu w kolejności zależności i commitując każde osobno.

Wyzwalacze z opisu

add Xfix Ychange Zimplement thiswrite the codecode this out
Oryginalny opis (EN)

Use for ALL coding work, with or without a PRD. With an approved design+tasks folder (PRD.md + TASKS.md from dev-design/dev-tasks), executes the tasks via coding sub-agents in dependency order, one commit per task, with the orchestrator tracking each task Status in TASKS.md. With no PRD (plain request such as "add X", "fix Y", "change Z", "implement this", "write the code"), runs in light mode where the request itself is the task. Always test-first, runs only the tests for the change, then invokes dev-review and offers dev-ship. Triggers include "implement this", "code this out", "build the ta

Jak działa

  1. Overview
  2. When to Use
  3. Input & Scope Modes
  4. Light mode
  5. Preconditions (main thread, before dispatching)
  6. Execution Loop (everything via agents — nothing coded on the main thread)
  7. Finish
  8. Common Mistakes
Sekcje z nagłówków SKILL.md, w oryginale · 203 linii, 1 850 słów
Podgląd SKILL.md
---
name: dev-code
description: Use for ALL coding work, with or without a PRD. With an approved design+tasks folder (PRD.md + TASKS.md from dev-design/dev-tasks), executes the tasks via coding sub-agents in dependency order, one commit per task, with the orchestrator tracking each task Status in TASKS.md. With no PRD (plain request such as "add X", "fix Y", "change Z", "implement this", "write the code"), runs in light mode where the request itself is the task. Always test-first, runs only the tests for the change, then invokes dev-review and offers dev-ship. Triggers include "implement this", "code this out", "build the tasks", "implement SP3 / task 5 only", "add a feature", "make this change".
metadata:
  version: "0.1.0"
---

# dev-code — Execute PRD+TASKS into Code

Before anything else, follow `../_shared/update-check.md`.

## Overview

All code changes go through this skill, with or without a PRD. It **orchestrates coding
sub-agents** — the main thread plans order, dispatches agents, verifies their evidence,
tracks each task's Status (full mode), and never writes code itself. Core principle:
**one verified commit per task, in dependency order, test-first.**

Two modes:
- **Full mode** — an approved folder with `PRD.md` + `TASKS.md` exists. Each coding agent
  grounds itself in the PRD's Architecture/Decisions and explores the repo itself for the
  actual files (`TASKS.md` carries no code or file lists, see `dev-tasks`).
- **Light mode** — no PRD or TASKS. The guidance the user gave is the task. See below.

Shared conventions live in `../_shared/dev-common.md`; this file uses its section names
(Workspace guard, Test policy, CI default, Question rules, Plain explanation, Auto mode,
Handoff, Review cadence) rather than restating them.

**Method every task agent follows** (written out in the agent prompt):
- Test first: write a test that fails for the right reason, watch it fail, write the
  minimum code to pass, watch it pass, then tidy.
- Evidence before claims: run the tests for this change and paste the real command and
  output. No "should work".
- When something fails: reproduce it, read the actual error, form one hypothesis at a
  time and test it, fix the cause rather than the symptom. After 3 failed attempts, stop
  and report instead of guessing further.

## When to Use

- Any request to write or change code: a feature, a fix, a refactor, "implement this".
- A folder with `PRD.md` + `TASKS.md` exists and the human wants it built (full mode).
- "Implement the whole branch folder", a single sub-project, or a single task.
- **Not for:** designing/decomposing (`dev-design`) or generating tasks (`dev-tasks`).
  In full mode, a sub-project whose PRD still has `[OPEN]` items waits (see the gate).

## Input & Scope Modes

Full mode input is a **folder path**:
- **Branch folder** (`…/agent_files/<branch-slug>-<timestamp>/`) → all sub-projects, order
  from `README.md`.
- **Single sub-project folder** (`…/<NN-name>/`) → that one's tasks, in `TASKS.md` table order.
- **"only SP&lt;N&gt;" / "only task N"** → just that sub-project/task.

Light mode input is the request itself. No folder is needed.

**Fix-only** (used by `dev-ship` for test or CI failures): light mode with the failure as
the task, but no CI default and no Finish steps 2-5. Make the fix test-first, commit, and
return to the caller. The caller owns review rounds and the ship step, so their 3-round
caps do not reset.

## Light mode

Used when there is no PRD or `TASKS.md`. The user's guidance is the single task.
- No PRD, no `TASKS.md`, no Status tracking, no settled-design gate.
- If the request is too vague to act on, ask per Question rules (with a default); never
  ask for facts you can find in the repo.
- Dispatch one coding agent with the request as the task. Same method: test first, tests
  for this change only, one commit.
- **CI default:** if the repo has no CI workflow that runs the tests on push/PR, include
  wiring one in (e.g. `.github/workflows/ci.yml`) as part of the work (not in fix-only).
- Then `dev-review` (one review covers everything), then the ship question, same as full
  mode (see Finish).
- The artifact and handoff still apply; the branch folder is created per the Output
  convention.

**Step 0.** If `auto` is in the request, print the Auto mode text from `../_shared/dev-common.md` first thing, if it has not been printed yet.

## Preconditions (main thread, before dispatching)

1. **Workspace guard:** apply the Workspace guard in `../_shared/dev-common.md` first. It
   pulls and creates a worktree off the latest default branch for new work, or continues
   in the existing worktree with `git pull --ff-only`. Install dependencies before running
   anything. Do the rest of the run there.
2. **Auto check:** if the first message contains `auto` (see Auto mode), turn it on and
   print its explanation first, before any work. **Auto reminder:** at the first dev-code command of this piece of work, show once: "Say
   `auto` any time to run all remaining stages without stopping." Follow Auto mode if on.
3. **Read context:** project `AGENTS.md`, `README.md` index, each target `PRD.md` (esp.
   Architecture, Decisions, Manual steps, Risks / Open Questions), and `TASKS.md`. **Read
   `TASKS.md` once and hold it** — you own it for the rest of the run; sub-agents never
   read it to make decisions, only you dispatch from it. (Full mode only.)
4. **Settled-design gate (full mode only):** target `TASKS.md` missing → stop, send to
   `dev-tasks`. Target PRD's Risks / Open Questions has any `[OPEN]` item → stop, list
   them, route to the human. Do not implement unsettled design. In auto mode, OPEN items
   take the recommended default and are logged in the PRD as
   `[RESOLVED: auto default - <choice>]` instead of stopping.
5. **Git safety:** working tree clean, ignoring `docs/agent_files/` (bookkeeping edits to
   `TASKS.md` and artifacts are committed at stage end, see Finish).
6. **Order (full mode):** execution order = `TASKS.md`'s tracking table (`Depends on`
   column) within each sub-project, sub-projects ordered by the README's phases/deps.
7. **Resume (full mode):** the tracking table's `Status` column is the resume source — skip
   tasks already `done`; cross-check against `git log` if anything looks stale.
8. **Status:** no narration while working. If asked "status", answer in at most five
   lines from the `TASKS.md` Status column.

## Execution Loop (everything via agents — nothing coded on the main thread)

For each task, in order (sequential by default):

1. **Mark it `in-progress`** (full mode). Main thread edits `TASKS.md`'s tracking table —
   only the Status cell for this task — before dispatching. This is bookkeeping, not code.
2. **Dispatch one coding agent** (a sub-agent) using
   `code-agent-prompt-template.md`: repo path, the task text verbatim (from `TASKS.md`, or
   the user's request in light mode), the PRD path with instruction to read its
   Architecture + Decisions (full mode), and the mandate to explore the repo itself to
   find the files, then implement test-first. **Tell it explicitly: do not edit
   `TASKS.md`.**
3. **The agent** implements ONLY that task, test-first, runs **only the tests it created
   or that the change impacts** (Test policy: never the whole suite), makes **exactly one
   commit** (message/trailer per `../_shared/dev-common.md`). It reports: commit SHA,
   files changed, the test command + real output, acceptance criteria met, deviations.
4. **Orchestrator verifies** before advancing: commit exists, tests actually passed
   (spot-check the diff/output, don't trust prose alone). There is no per-task review;
   review happens per sub-project (see Finish).
5. **Flip Status** (full mode). Success + criteria met → main thread sets `done`. Failure
   (impl fails, tests red, criteria unmet) → main thread sets `blocked`, **stops the run**
   (don't pile broken commits or skip ahead), diagnoses (reproduce, read the error, one
   hypothesis at a time) or reports the blocker to the human, and records it in the
   artifact.

**Parallelism:** tasks with shared files or sequential deps stay serial. Independent
sub-projects in the same phase MAY run in parallel — each gets its own git worktree
nested under `<repo>/.worktrees/<sub-project-branch>`, branched from the feature
worktree's branch (install dependencies there first) and merged back into it per
sub-project (not into main).

**Commits:** one per task by default; combine only when genuinely inseparable (say so in
the artifact). Never mix unrelated changes.

**Scope discipline:** agents implement only what the task specifies. New issues/ideas
discovered mid-task go into the artifact's follow-ups (and back to the PRD via
`dev-design`), never silent scope creep.

## Finish

1. **Write the artifact** `code-<YYYY-MM-DD-HHMM>.md` in the target folder. Multiple runs
   → multiple artifacts (history). Commit the artifact and any `TASKS.md`/PRD changes
   (`docs: code artifacts`, per `../_shared/dev-common.md`). Do not run the full test
   suite here; that is `dev-ship`'s job.
2. **Review** per Review cadence in `../_shared/dev-common.md`: invoke `dev-review`
   automatically once when a sub-project's tasks are all done (never per task). When all
   sub-projects are finished, a full review of the whole branch diff runs automatically,
   without asking. One sub-project, or light mode: one review covers both. `dev-review`
   writes its file and returns here with no message; this run continues.
3. **Fix loop:** `dev-review` returning NEEDS_CHANGES comes back here with the must-fix
   list as the next task (light-mode style, one agent), then re-review. Max 3 rounds,
   then stop and report. BLOCK or a PRD gap goes to `dev-design`.
4. **Handoff (mandatory, never skip, both modes):** write the Handoff section (stage,
   done, next, open decisions, `Mode: auto` if on) to `_next-context_.md` per
   `../_shared/dev-common.md` at the end of each sub-project and before the ship ask. The
   stage is not finished until the file exists. Print "Continue here" (with the `read
   <path> and continue` block) whenever the run stops; not mid-loop, not in auto mode.
5. **Ship ask** once the final review passes: invoke `dev-ship`. If no PR is open for the
   branch, ask exactly one yes/no, "Ship?". If a PR is already open, ship directly. In
   auto mode never ask. Ask nothing else about push, PR, title or base branch. If
   `dev-ship` succeeds it removes the Handoff section (no stale section may remain); skip any further handoff message.
   If the answer is no or it stops, print the "Continue here" message.

### Artifact format (`code-<timestamp>.md`)

```
# Code Run — <date time> — <scope: all sub-projects | SP3 | SP3/Task 5>
Branch: <branch>   Base: <default branch>   Mode: full | light

## Tasks completed
| Sub-project | Task | Status | Commit | Files | Tests |
|---|---|---|---|---|---|
| 01-... | Task 1 — ... | done | <sha> | a.py, b.py | 12 passed |
| ...    | ...          | blocked | — | — | 1 failed (see below) |

## Deviations from the PRD/TASKS
- <task> — <what changed and why>

## Follow-ups / new issues discovered
- <issue> → <where it should go: PRD update, new task, bug>

## Still requires you (from PRD Manual steps + this run)
- <human-only step>
```

## Common Mistakes

- **Coding on the main thread.** Orchestrate only; all code is written by agents.
- **Implementing past the gate (full mode).** Missing TASKS or `[OPEN]` PRD items = stop
  (auto mode takes defaults and logs them).
- **Running the whole test suite.** Only tests for the change; the full suite is `dev-ship`.
- **Reviewing per task.** Review is per sub-project, plus one full review at the end.
- **Trusting "tests pass" without evidence.** Verify the diff + real test output.
- **Letting a coding agent edit `TASKS.md`.** Status is main-thread-only; a sub-agent
  editing it (even the description) breaks the tracking contract.
- **Barreling past a failure.** Stop, mark `blocked`, diagnose, report.
- **Giant catch-all commits.** One task per commit unless genuinely inseparable.
- **Scope creep.** Build the task; route new ideas to the artifact/PRD.
- **Committing to `main`, or working outside the feature worktree.** Apply the Workspace
  guard first.
- **Skipping dev-code because "it is small".** All coding goes through here; use light mode.
- **Skipping the handoff.** No `_next-context_.md` or "Continue here" = the stage is not
  finished, in light mode too (Finish step 4).
- **Skipping the artifact.** The run log is the deliverable that closes the loop.
Pliki w paczce (2)
  • SKILL.md 12 KB
  • code-agent-prompt-template.md 5 KB

Wersje

RepozytoriumWynikLicencja
Ta strona · tejitpabari99/tejit-plugin100MIT
FOURTEEN1416/academic-agent-toolkit96CC-BY-4.0

Migawka bazy z 13.11.2026 · wersja paczki a7eb68c3d417 (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

  • 100dev-tasks
    Generuje lub odświeża plik TASKS.md z zatwierdzonych PRD, z tabelą śledzenia i krótką specyfikacją każdego zadania.
  • 100dx-agent-dev
    Wdraża kod na podstawie specyfikacji agenta RE: implementacja, samokontrola (build, testy, lint), naprawa błędów i commit.
  • 82implement-spec
    Wykonuje zadania zatwierdzonej specyfikacji test-first, po jednym zadaniu na commit, z subagentami recenzji.
  • 95tl-dev-fe
    Prowadzi frontendowy cykl TDD według specyfikacji zadania UC: komponenty, strony i kod interfejsu.
  • 90dev-build
    Buduje zatwierdzony plan zadanie po zadaniu, z nowym wykonawcą i recenzentem przy każdym, dziennikiem i limitem poprawek.
  • 100building-from-prds
    Implementuje zatwierdzoną zmianę w repozytorium z katalogiem docs/prd: najpierw testy jednostkowe, potem kod, aż testy przejdą.

Uwagi i zgłoszenia

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