/init

name: completely:init
description: Scaffold the completely thin layer into the current repository — Definition of Done, the harness rules snippet in CLAUDE.md, and an optional project-specific quality command. Use when setting up claude-harness in a new project, or when the user says "harness init", "set up the harness", or "wire up the quality gates here".
version: 0.1.0
user-invocable: true
argument-hint: "[--force]"

You are scaffolding the **claude-harness** project thin layer into the current repo. The heavy logic (hooks, evaluator agent) ships with the plugin/global install; this only adds the small per-project pieces. **Never overwrite an existing file without asking** (unless the user passed `--force`).

Steps

1. **Locate the repo root** (`git rev-parse --show-toplevel`, else cwd) and **detect the stack**:

• `pyproject.toml` / `setup.cfg` → Python (commands: `ruff check`, `mypy`, `pytest`)
• `package.json` → JS/TS (read its `scripts`; commands likely `eslint .`, `tsc --noEmit`, `vitest run` / `jest`)
• `go.mod` → Go; `Cargo.toml` → Rust. Record the real lint/typecheck/test commands.

2. **Create `.claude/` and `.claude/harness/`** if missing.

3. **Write `.claude/DEFINITION_OF_DONE.md`.** Copy the harness template. Locate it under the installed plugin (try `${CLAUDE_PLUGIN_ROOT}/templates/DEFINITION_OF_DONE.md`, then `~/.claude/harness/core/`); if you can't find it, regenerate it from the canonical content you know (default-FAIL checklist). Fill in the detected stack's commands.

4. **Merge the harness rules into the project `CLAUDE.md`.** If `CLAUDE.md` exists, append the `CLAUDE.harness.md` snippet (between its `<!-- claude-harness -->` markers) — do not duplicate if already present. If no `CLAUDE.md`, create a minimal one with the snippet. Fill in the real project commands you detected in step 1.

5. **Project quality command (optional).** If the repo already has an aggregate check script (e.g. `scripts/check.sh`, a `Makefile` `check` target, or a `package.json` `check` script), create `.claude/harness/quality-gate.local.sh` that delegates to it — this makes the harness `quality-gate` hook reuse the project's own gate instead of guessing. Make it executable. If there is no such script, skip this (the hook's built-in stack detection handles it).

6. **Confirm hook activation.** If the plugin is installed, the gates are already active globally — say so. Otherwise tell the user to run `install.sh --project <repo>` (manual path).

7. **Report** exactly what you created/changed and what you skipped (and why). Suggest a one-line verification: `echo '{"tool_input":{"command":"rm -rf /"}}' | bash <guard-dangerous.sh>; echo exit=$?` (expect exit=2)

Guardrails

• Idempotent: re-running must not duplicate the CLAUDE.md snippet or clobber edits.
• Do not invent commands — read them from the project's real config.
• This is a self-tooling task: scaffold the FULL thin layer; if something blocks it, return

`blocked` with the reason — do not silently skip a piece.

Compose with the user's own skills/rules (never override)

DETECT and LAYER — do not clobber:

• If the repo has a `CLAUDE.md`, APPEND the harness rules between `<!-- claude-harness -->`

markers (idempotent). Keep the user's content; harness hard-invariants on top, project rules below. Never replace the file.

• Leave the user's existing `~/.claude` skills/agents untouched; compose via `core/routing.md`,

treating user skills as first-class for their intents.

• If a user skill already covers an intent (e.g. their own `/review`), PREFER it over the

harness default and record the choice in routing. Hierarchy, not replacement.

Discovery (new vs existing) — do this FIRST

1. **Ask what it is** — one question: what are we building / what is this repo? 2. **New vs existing:**

• **NEW** (empty repo / no source) → scaffold from zero: CLAUDE.md, `completely.toml`, pick

stack + architecture (offer presets, recommend a default), set up quality (`cmpl quality`), reference the rules. Confirm, then write.

• **EXISTING** → STUDY first: read CLAUDE.md/AGENTS.md, package.json/pyproject, the dir shape;

infer stack + architecture; then ask ONLY the gaps — don't re-ask what you can see. Reconcile with the existing CLAUDE.md — APPEND harness rules, never overwrite the user's content. 3. **Ask architecture** (see `core/architectures.md`). If unsure → choose the recommended for the stack and state the one-line trade-off. 4. Record in `completely.toml` (`[project][stack][architecture]`) and the CLAUDE.md snippet. One question at a time; idempotent; never interrogate or clobber.