/ca-init
Opt this repo into codeArbiter — scaffold the root-level .codearbiter/ state store.
$ npx -y skills add arbiterForge/codeArbiter --skill ca-init --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/ca-init
Context preview
The summary Claude sees to decide when to auto-load this skill.
Opt this repo into codeArbiter — scaffold the root-level .codearbiter/ state store.
SKILL.md
ca-init.SKILL.mdname: ca-init
description: Opt this repo into codeArbiter — scaffold the root-level .codearbiter/ state store.
argument-hint: "(none) | --stage N | --check"
$ca-init — first-run scaffold
Stand up the root-level `.codearbiter/` project-state store that opts a repo into arbiter management. This is the v2 replacement for vendoring/`init-vendor`: no symlinks, no shims, no dual root. It writes the activation flag and the empty state files, then hands off to the populator.
`.codearbiter/CONTEXT.md` frontmatter `arbiter: enabled` is the single activation flag — it gates the SessionStart persona injection. The scaffolded `CONTEXT.md` is a **stub** (no initialization sentinel), so after scaffolding the project still needs populating before normal operation.
Procedure
1. Run the scaffolder against the repo's git toplevel (resolved by the script):
python "${CLAUDE_PLUGIN_ROOT}/hooks/init-codearbiter.py"It is idempotent and refuses if `.codearbiter/CONTEXT.md` already exists — it never overwrites state. Pass `--stage N` to set the initial maturity value (default `1`). Use `--check` to report state without creating anything.
2. It creates `.codearbiter/` with: `CONTEXT.md` (`arbiter: enabled`, `stage: N`, stub body), `open-tasks.md`, `open-questions.md`, `overrides.log` (audit header), and `last-checkpoint` (`0`).
3. **Then route to the populator** — the stub is not yet usable:
- **Source code already exists** in the repo → route to `$ca-create-context` (brownfield: scouts
read the codebase and synthesize the full context, writing the initialization sentinel).
- **Greenfield** (no meaningful source) → route to `$ca-decompose` (layered interview).
The populator is **mandatory, not optional**: it authors `tech-stack.md`, `coding-standards.md`, and `security-controls.md` (and writes the initialization sentinel). The pipeline gates BLOCK on reading those files — `writing-plans` and `tdd` need `tech-stack.md`, the security gates need `security-controls.md` — so `$ca-feature` run on a freshly-scaffolded stub will STOP at pre-flight until the populator has run. `session-start` surfaces this as `NOT INITIALIZED` every session.
4. Report what was created and which populator you are routing to.
When NOT to use
- `.codearbiter/` already scaffolded → the scaffolder refuses; run `$ca-create-context` or
`$ca-decompose` to populate, or `$ca-status` to see state.
- You only want to re-check detection state → run the scaffolder with `--check`.
Hard gate
MUST NOT hand-author `.codearbiter/CONTEXT.md` frontmatter — the scaffolder is the sanctioned path so the activation flag and state-file shapes match what the hook parses. MUST NOT mark a stub initialized; only the populator writes the initialization sentinel.
Read more
name: ca-init description: Opt this repo into codeArbiter — scaffold the root-level .codearbiter/ state store. argument-hint: "(none) | --stage N | --check"
$ca-init — first-run scaffold
Stand up the root-level `.codearbiter/` project-state store that opts a repo into arbiter management. This is the v2 replacement for vendoring/`init-vendor`: no symlinks, no shims, no dual root. It writes the activation flag and the empty state files, then hands off to the populator.
`.codearbiter/CONTEXT.md` frontmatter `arbiter: enabled` is the single activation flag — it gates the SessionStart persona injection. The scaffolded `CONTEXT.md` is a **stub** (no initialization sentinel), so after scaffolding the project still needs populating before normal operation.
Procedure
1. Run the scaffolder against the repo's git toplevel (resolved by the script):
python "${CLAUDE_PLUGIN_ROOT}/hooks/init-codearbiter.py"It is idempotent and refuses if `.codearbiter/CONTEXT.md` already exists — it never overwrites state. Pass `--stage N` to set the initial maturity value (default `1`). Use `--check` to report state without creating anything.
2. It creates `.codearbiter/` with: `CONTEXT.md` (`arbiter: enabled`, `stage: N`, stub body), `open-tasks.md`, `open-questions.md`, `overrides.log` (audit header), and `last-checkpoint` (`0`).
3. **Then route to the populator** — the stub is not yet usable:
- **Source code already exists** in the repo → route to `$ca-create-context` (brownfield: scouts
read the codebase and synthesize the full context, writing the initialization sentinel).
- **Greenfield** (no meaningful source) → route to `$ca-decompose` (layered interview).
The populator is **mandatory, not optional**: it authors `tech-stack.md`, `coding-standards.md`, and `security-controls.md` (and writes the initialization sentinel). The pipeline gates BLOCK on reading those files — `writing-plans` and `tdd` need `tech-stack.md`, the security gates need `security-controls.md` — so `$ca-feature` run on a freshly-scaffolded stub will STOP at pre-flight until the populator has run. `session-start` surfaces this as `NOT INITIALIZED` every session.
4. Report what was created and which populator you are routing to.
When NOT to use
- `.codearbiter/` already scaffolded → the scaffolder refuses; run `$ca-create-context` or
`$ca-decompose` to populate, or `$ca-status` to see state.
- You only want to re-check detection state → run the scaffolder with `--check`.
Hard gate
MUST NOT hand-author `.codearbiter/CONTEXT.md` frontmatter — the scaffolder is the sanctioned path so the activation flag and state-file shapes match what the hook parses. MUST NOT mark a stub initialized; only the populator writes the initialization sentinel.
When you can't trust yourself with your code base, trust Arbiter.
Repo: arbiterForge/codeArbiter
Other skills on codearbiter.
- /brainstorming
The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it takes a one-line idea and drives it to an approved, concrete spec with testable acceptance criteria. Four gated phases — frame, refine, write, approve. No
Open skill - /commit-gate
The only path to a commit. Routed to when the user invokes /commit or otherwise instructs codeArbiter to persist staged changes. Nine gated phases — permission, branch, classification, verification (test/lint/secrets), behavioral proof, diff review, selective stage, message,
Open skill - /context-check
Optional manual drift audit — report stale provenance-tracked docs (via _provenancelib drift detection across .codearbiter/.provenance/), then per stale doc offer re-scout / re-baseline / defer. Not the daily loop; commit-gate auto-heal owns routine maintenance.
Open skill - /context-creation
The brownfield back-fill. Routed to by /create-context, and by startup when .codearbiter/CONTEXT.md lacks the <!--INITIALIZED--> body marker but source code exists. Six gated phases — pre-flight, scout dispatch, synthesis, gap interview, write, lock. Reads the existing codebase
Open skill - /crypto-compliance
The banned-primitive gate. Routed to when changed code hashes, signs, encrypts, derives keys, generates security-relevant randomness, configures TLS, or imports a crypto library. Rejects broken primitives, disabled TLS verification, and home-rolled crypto; the approved-primitive
Open skill - /debug
Investigate-then-decide root-cause analysis for a defect whose cause is unknown (distinct from /fix, which assumes a known bug). Five gated phases: capture, hypothesize, gather, decide, hand off. Investigation only, no code changes; exits to /fix, /adr, or a no-action close.
Open skill

