Codd Greenfield

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-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

1. Read .codd/greenfield_session.yaml: result.failed_stage, result.failed_unit, result.error.
2. 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.
3. Transient failure (AI timeout, network): codd greenfield --resume.
4. 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

1. Never interrupt a running autopilot — inspect the session file instead.
2. Never hand-edit generated files mid-run. After the run, changes go through codd-evolve / codd fix, not direct edits.
3. Never re-init over an existing project without gate-3 confirmation.
4. Never report success without codd check passing (the autopilot's own exit code already encodes this — trust it, don't re-judge).
5. 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.