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.