initlisted

# init — Install the harness into a project Runs **inside** the target project. It interviews the repository first and the user second, because most of what varies is discoverable and asking about it wastes the one resource the user actually spends: attention. Migration is the common case. **Treat a greenfield repo as the special case, not the default.** ## Step 1 — Detect, don't ask Read before asking anything: | Signal | Tells you | | :-- | :-- | | lockfiles, `package.json`, `pyproject.toml`, `pubspec.yaml`, `go.mod`, `Cargo.toml`, `Gemfile` | language and package manager | | scripts/tasks in those files, CI workflow files | the real validator commands — the ones that already pass | | existing test directories and naming | the test runner and where tests live | | `git log --format=%s -50` | the commit convention actually in use, not the one in CONTRIBUTING | | `.github/ISSUE_TEMPLATE/`, existing labels | the issue taxonomy already in use — adopt it rather than imposing one | | `git remote -v`, existing PR templates | the tracker and default branch | | existing `.claude/`, `.agents/`, `CLAUDE.md`, `AGENTS.md`, `.specs/` | what is already installed, and what you must not overwrite | **Run each candidate validator before adopting it.** A command copied from a README that fails on a clean checkout will make the quality gate block every turn from day one, and the user will disable the gate rather than debug it. If a validator fails on a clean tree, say so and ask whether t