/codd-greenfield

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  # skip if initialized
codd elicit && codd elicit apply findings.md                       # advisory
codd plan --init --force
codd generate --all-waves --force
codd implement list-tasks --format json                            # then per task T:
codd implement plan  --task T                                      #   advisory
codd implement steps --task T --approve --all                      #   advisory
codd implement run   --task T                                      #   blocking
codd verify --auto-repair --max-attempts 10 --repair-mode automatic
codd propagate --verify && codd propagate --commit                 # advisory
codd check                                                         # final gate

Resume and session inspection

codd greenfield --resume          # re-runs the first incomplete stage,
                                  # skipping units already marked done
cat .codd/greenfield_session.yaml # per-stage / per-unit status, failed_stage,
                                  # failed_unit, error

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.

1. **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. 2. **Ambiguous project name / language.** Project is not initialized and the user gave neither. Ask once: "Project name and primary language?" 3. **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