Init

Set up this project for the CID loop. The output is a CID context pack at .cid/ — the committed working memory that lets four fresh-context roles advance the project autonomously. The single most load-bearing artifact is target.md: the loop can only be as good as the target's Verify criteria, because they are its fitness signal. Spend your effort there.

All file templates are in references/templates.md — read it before scaffolding.

Step 1 — Detect the situation

• .cid/target.md already exists → this project is already initialized. Say so,

show /long-horizon:status, and offer to revise the target instead of re-scaffolding. Never overwrite an existing pack without explicit confirmation. Note the scaffolded .claude/settings.json denies Claude edits to .cid/target.md (deliberate — target edits are a human act): to revise, draft the change for the human to apply, or ask them to lift the deny rule for the edit and restore it after.

• The directory has source code → brownfield: explore it first (structure, language, existing

tests/gates/CI, docs) so the interview and the drafted target build on reality. Run git status --short and note any uncommitted work — it is the user's, and must stay out of the init commit (Step 4).

• Otherwise → greenfield.

Step 2 — Interview

$ARGUMENTS may carry a one-line goal; use it to seed the interview. Ask what you cannot infer, using AskUserQuestion for the discrete choices — in batches, not one long form. Cover:

1. Goal — what the project does when it is done, for whom. This becomes the frozen core of

target.md: it never drifts without the human.

1. Riskiest assumption — the one thing most likely to sink the project (an algorithm works, an

API is usable, a latency bound holds). This seeds the PoC exit criteria: the poc phase exists to prove exactly this, end-to-end, before anything else gets built.

1. Stack — language, key libraries/services, platform constraints. Brownfield: confirm what you

detected rather than asking cold.

1. Quality gate — the one command that must be green for every increment (build + lint + test).

Brownfield: use the existing gate. Greenfield: propose a stack-appropriate command and scaffold whatever it needs (task runner config, a first trivial test) so it can run green from iteration one. A gate that cannot run yet is the first thing the new phase fixes.

1. Milestones — draft 3–7 v1 milestones yourself from the goal, each with a Verify block,

and present them for correction. Do not ask the user to write milestones from scratch.

1. Branch model — recommend: loop works on develop, pushes on PASS, human merges to main

via a gated PR. Simpler alternative for personal projects: loop commits directly to main, no push. Let the user pick.

1. Second opinion (optional) — a command for an independent external reviewer the review

role launches each iteration (e.g. codex review --commit HEAD). Default to none if the user has no external reviewer — the loop runs fine without one.

Step 3 — Draft target.md and get sign-off

Write the draft target.md (template in references/templates.md) and show it to the user. Every Verify criterion must be runnable — a command that exits 0 or an assertion checkable mechanically. Push back on vague criteria ("works well", "is fast"): convert each to a measurable form or move it to a human sign-off note. Extract every verifiable constraint latent in the goal — whatever judgment residue remains should be small and explicitly routed to the human.

Iterate until the user approves. The target is human-owned from here on: the loop verifies against it but never edits it.

Alongside the target, present the phase policy table (from the policy.md template) for explicit ratification — in particular the Tests required row: the new/poc cells deliberately relax testing to smoke/golden level, which may override stricter standing norms in the project's or the user's own instructions. That relaxation applies only because the user approves it here, per project — adjust any row the user objects to before scaffolding.

Step 4 — Scaffold

Create, from the templates:

1. .cid/README.md — a one-paragraph orientation note
2. .cid/target.md — the approved target
3. .cid/policy.md — gate command, branch model, push policy, second-opinion

command (set it to none unless the user names an external reviewer), phase policy table, empty role-adjustment sections

1. .cid/state.md, next.md, handoff.md, learnings.md, issues.md,

journal.md — initial stubs

1. .cid/bin/ — copy scripts/cid-metrics.py → .cid/bin/metrics.py and

scripts/cid-driver.py → .cid/bin/driver.py from this skill's directory (paths relative to this SKILL.md). Committed with the pack so the roles — and a CI runner, which sees only the checkout — can run them: metrics.py is the journal-analytics digest the roles read each iteration; driver.py is the unattended reference driver (the build skill's references/automation.md documents it). Requires uv on PATH — if the user does not have it, say so; the roles fall back to reading the journal directly.

1. .claude/loop.md — points a bare /loop at /long-horizon:build (tell the user this changes

what a bare /loop does in this project)

1. .claude/settings.json — merge in (never clobber an existing file) the permission rules

from the template: allow rules so driver-run iterations proceed without per-command prompts, deny rules backing two loop invariants (no edits to .cid/target.md, no push to the protected branch). The template's commentary in references/templates.md is authoritative for the rules' rationale — in particular the compound-gate rule (one allow rule per quality-gate subcommand) and why the pack lives at .cid/, not under .claude/.

1. Greenfield only: git init if needed, the stack scaffold the gate needs, and a CLAUDE.md

noting the project is built by the CID loop (conventions, glossary seed)

Then: create the loop branch per the chosen branch model, and commit only the files this init created or modified as cid(init): scaffold CID context pack — add them by explicit path, never git add -A/git add ., so pre-existing uncommitted work stays out of the commit (tell the user what was left unstaged). Explicit paths do not protect a file init modifies: if a file you must edit (typically .claude/settings.json) already carried uncommitted user changes per the Step 1 git status, staging it would sweep those hunks in too — ask the user to commit or stash that file before you edit it. Run the quality gate once to confirm it is green (fix the scaffold until it is — a red gate at init poisons every later iteration).

Step 5 — Hand off

Report what was created and end with next steps:

1. /long-horizon:build — run the first iteration by hand and watch the four roles.
2. Drive it: /goal … Loop: IDLE or STOP … or /loop 20m /long-horizon:build (details in the

build skill's references/automation.md).

1. /long-horizon:status any time; /long-horizon:retro after ~10 iterations.
2. To steer the loop later: edit target.md / file issues — never edit code mid-loop without

committing, and prefer a cid(steer): commit for out-of-band interventions.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: titusz
• Source: titusz/skills
• License: MIT

Install and usage instructions live in the source repository linked above.