メニュー
Implement a bounded code change from a request, spec, or implementation plan. Use when executing implementation work and choosing between quick, bounded, and tracked modes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | implementation-workflow |
| description | Implement a bounded code change from a request, spec, or implementation plan. Use when executing implementation work and choosing between quick, bounded, and tracked modes. |
Use for code delivery. Optimize for evidence and signal density, not ceremony.
| Mode | Use when | Default shape |
|---|---|---|
| Quick Task | Small/local, obvious scope | Direct work; no artifacts/subagents |
| Bounded Delivery | Clear change across ~1-3 areas | Direct, or 0-1 scout -> 1 worker -> optional review |
| Tracked Project | Multi-session, expensive restart/handoff, or explicitly requested | Phase contracts + .ai/current-work.md pointer |
Default Quick/Bounded. Do not inherit a stale/completed/unrelated anchor.
Before work, collect only: objective, acceptance criteria, exact paths/symbols, constraints/non-goals, and test commands. Extract this once into a handoff packet. Do not make every child reread full plan/spec/current-work files.
Use a scout only to answer a real uncertainty. Good output: exact paths, symbols, line ranges, tests, and one start point. Bad output: file dumps or generic architecture prose.
Give one worker a coherent vertical slice with owned acceptance tests. A plan bullet, file, type error, or local repair is not automatically another delegation.
The worker should implement, run relevant evals, and fix in-scope implementation/type/test failures before returning. It returns: status, changed paths, eval evidence, one decision/blocker, and one next action.
Parallelize only read-only or isolated work. Never share a mutable checkout between concurrent workers unless the caller explicitly provides safe isolation.
For each phase state: objective, acceptance evidence, child shape, and escalation condition.
0-1 scout -> 1 worker -> optional 1 reviewer.current-work.md is a restart pointer, not a transcript. Keep it under 500 tokens when possible and point to detail.
Update it only at material phase boundary, blocker, decision, handoff, or closeout. Do not update/read it after routine child completions. Keep Todo Tracker at major-phase granularity; detailed work stays in the plan.
At a phase handoff, record only: completed phase and acceptance evidence, active artifacts, one decision/blocker, exact next phase/action, and budget used. On resume, use a fresh parent session when practical; read the anchor plus only the artifact section needed next, never prior tool history.
Report: mode, phase/status, changed paths, eval/test results, one decision/blocker, exact next action, current-work path if used, and review result/recommendation.
Manage tracked feature work with `.ai/current-work.md`, handoffs, and archive rules.
Turn a bounded functional spec into an implementation plan. Use when architecture, code structure, sequencing, migration, and verification must be decided before implementation.
Turn current context into a concise implementation spec. Use when a user wants to define what to build, capture requirements, or create a bounded technical/product spec before implementation.
Map a large or unclear initiative into facts, decisions, open frontier, and next work without writing a spec or implementation plan. Use when scope, architecture, dependencies, or sequencing are still genuinely uncertain before creating a spec.
Collapses deterministic multi-step repository research, aggregation, indexing, validation, and transformation into one small purpose-built local script and one Bash run. Use when a task would otherwise require 6+ related read/search/tool calls, iterates over many files or records, cross-references results, or requests batch analysis; do not use for small exploration or broad mutations.
Create a concise ADR for a durable, consequential architectural decision.