| name | codd-greenfield |
| description | Run the CoDD greenfield autopilot: a requirements document in, a working system out, unattended. Use when the user wants to build a NEW system from a requirements doc ("greenfield", "build from requirements", "要件定義から自動構築", "write requirements and walk away") or to resume/inspect an interrupted autopilot run. Greenfield generation, NOT brownfield modification (use codd-evolve), NOT pure bug fix (use codd fix).
|
CoDD Greenfield — Unattended Autopilot
Take a requirements document and build the entire system: init → elicit →
plan → generate → implement → verify (auto-repair) → propagate → check, with
every gate auto-approved. The user writes requirements and walks away; this
skill drives codd greenfield and watches the result.
Works identically whether this skill is installed for Claude Code
(~/.claude/skills/) or Codex CLI (~/.agents/skills/): the skill only runs
codd commands, and the AI CLI that CoDD itself invokes per stage comes from
the project's codd.yaml ai_command — never from this skill.
When to Use
- The user has (or is about to write) a requirements document and wants a
system built from it without supervising each stage
- Trigger phrases:
- "Build this from the requirements doc"
- "Greenfield this project"
- "要件定義から自動構築して"
- "Write requirements, walk away — make it happen"
- "Resume the greenfield run" / "What happened to the autopilot?"
- The project is empty or freshly initialized (no meaningful source yet)
Do NOT use this for:
- Evolving an existing CoDD project — use
codd-evolve
- Pure bug fix on an existing system — use
codd fix / codd fix [PHENOMENON]
- Reverse-engineering an undocumented codebase — use
codd extract / codd brownfield
Decision Tree
1. Does a requirements file exist?
├─ yes → continue
└─ no → STOP-AND-ASK gate 1: ask the user for the path, or offer to
draft docs/requirements/requirements.md from their description
(they approve the draft before the autopilot starts)
2. Is the project already codd-initialized (codd/codd.yaml or .codd/codd.yaml)?
├─ no → need --project-name and --language for codd init
│ ambiguous? → STOP-AND-ASK gate 2
└─ yes → does .codd/greenfield_session.yaml exist with a non-success result?
├─ yes → this is a RESUME: codd greenfield --resume
└─ no → fresh run; if source files already exist that a fresh
run could overwrite → STOP-AND-ASK gate 3
3. Run the canonical flow (below). Walk away.
Canonical Flow (preferred)
One command. Prefer this over stage-by-stage unless recovering:
codd greenfield --requirements docs/requirements/requirements.md \
[--project-name NAME --language LANG] \
[--ntfy-topic TOPIC] [--max-repair-attempts 10]
- All gates are auto-approved (elicit findings applied, derived tasks and
implementation steps approved, repair runs in automatic mode).
--ntfy-topic posts progress notifications — notify-only, never blocking.--dry-run first when the user wants to preview the plan without spending
AI calls.- Checkpoints land in
.codd/greenfield_session.yaml after every unit
(every wave, every implement task), so interruption is cheap.
- Exit 0 = success and
codd check passed. Non-zero = a stage failed; the
report names the failed stage and the resume command.
Stage-by-Stage Fallback (partial / recovery runs)
Use only when the one-command form is unsuitable: re-running a single failed
stage, splicing into CI, or debugging. The CLI sequence is the exact
equivalent of the autopilot (also available as a heavily-commented script at
examples/greenfield_autopilot.sh in the CoDD repository):
codd init NAME --language LANG --requirements FILE --auto-approve
codd elicit && codd elicit apply findings.md
codd plan --init --force
codd generate --all-waves --force
codd implement list-tasks --format json
codd implement plan --task T
codd implement steps --task T --approve --all
codd implement run --task T
codd verify --auto-repair --max-attempts 10 --repair-mode automatic
codd propagate --verify && codd propagate --commit
codd check
Resume and session inspection
codd greenfield --resume
cat .codd/greenfield_session.yaml
Stages are idempotent (generate skips existing files, implement re-runs are
safe), so resuming is always safe.
Stop-and-Ask Gates
Ask the user only when one of these fires. Everything else is
auto-approved — that is the point of the autopilot.
- Missing requirements file. No file at the given (or default) path.
Ask for the path or offer to draft one from the user's description.
- Ambiguous project name / language. Project is not initialized and the
user gave neither. Ask once: "Project name and primary language?"
- Destructive re-init. The directory already contains source files or a
CoDD config that a fresh run could overwrite, and the session file does
not indicate a resumable run. Confirm before proceeding (or steer to
codd greenfield --resume / codd-evolve as appropriate).
Do not ask the user about: which lexicons to pick, whether to apply
elicit findings, task or step approval, repair proposals, wave order, or
commit messages for propagate. The autopilot auto-approves all of these.
While the Autopilot Runs
Do not interrupt the autopilot mid-run. Do not kill the process, do not
run additional codd commands in the same project, and do not edit the
generated files while it is running — concurrent mutation corrupts the run.
To observe progress, inspect the checkpoint file (read-only):
cat .codd/greenfield_session.yaml
If the user wants progress pings, prefer --ntfy-topic over polling.
If the run looks stuck, let the stage time out and fail; then report the
failed stage from the session file and offer codd greenfield --resume.
Failure Handling
- Read
.codd/greenfield_session.yaml: result.failed_stage,
result.failed_unit, result.error.
- The result report also prints an inspect command for the failed stage
(e.g.
codd generate --wave 2, codd implement run --task T) — run it
for detail only if needed.
- Transient failure (AI timeout, network):
codd greenfield --resume.
- Structural failure (requirements contradiction, unrepairable verify red):
surface the error verbatim to the user; suggest fixing the requirements
doc and resuming. Do not loop resume more than 2 times on the same error.
Report
Greenfield autopilot: SUCCESS
requirements: docs/requirements/requirements.md
stages: init ✅ elicit ✅ plan ✅ (3 waves) generate ✅
implement ✅ (5 tasks) verify ✅ (red 0) propagate ⚠ (advisory)
check ✅
resume file: .codd/greenfield_session.yaml
On failure, name the failed stage/unit, the error, and the resume command.
Absolute Constraints
- Never interrupt a running autopilot — inspect the session file instead.
- Never hand-edit generated files mid-run. After the run, changes go
through
codd-evolve / codd fix, not direct edits.
- Never re-init over an existing project without gate-3 confirmation.
- Never report success without
codd check passing (the autopilot's
own exit code already encodes this — trust it, don't re-judge).
- Never commit without user approval. The autopilot builds; the user
reviews and commits.
Guardrails
- Use the
codd command, not python -m codd.cli
- Run from the project root
- Prefer
codd greenfield over the stage-by-stage fallback; the fallback is
for recovery and CI splicing, not the default path
- One requirements doc per run; if the user has several, they import into the
same project (
codd init --requirements accepts one file; further docs go
to docs/requirements/ before running)
Why This Skill Exists
CoDD's greenfield philosophy is "write only functional requirements and
constraints — the system builds itself." codd greenfield is that philosophy
as one command. This skill is the conversational front: it picks the right
entry (fresh run / resume / dry-run), enforces the three stop-and-ask gates,
and keeps humans from babysitting a pipeline that was designed to run
unattended. The CLI remains the engine; the skill decides when to start it
and how to read what it left behind.
