claude-forge: Instructions file for Claude Code

Claude Forge

Maintainer: Arie Goldkin Plugins: ctk (formerly continuity-toolkit), dtk (formerly devops-toolkit), atk (formerly ai-toolkit), ftk (formerly frontend-toolkit), etk (formerly engineering-toolkit) Versioning: Independent per plugin CC Alignment: v2.1.221 (triaged 2026-08-04) — docs/reviews/2026-08-04_cc-v2.1.221-alignment-audit.md. That pass closed the 28-version gap by triage, not by behavioural probing: it measured what this repo ships and declares against the v2.1.194→221 CHANGELOG, and fixed the two claims found stale — the subagent nesting depth (5 → 3, having passed through 1) and context: fork skills now running in the background by default. ⚠ Its Tier-2/3 items are explicitly labelled hypotheses, not findings, because the previous audit's false floor note came from treating a CHANGELOG line as a conclusion. The auto-mode settings-path question (v2.1.207) is the one most likely to bite and is deliberately left unresolved pending a probe. Prior: v2.1.193 (audited 2026-06-26); the v2.1.174→193 gap analysis (model-governance enforcement via enforceAvailableModels, the hook if-condition file-path fix, auto-mode native git-blocking + classifyAllShell, nested-subagent 5-deep (superseded — the live default is 3, see the Subagent section), /plugin Skills tab) is in docs/reviews/2026-06-26_cc-v2.1.193-alignment-gaps.md. Floor note — RETRACTED 2026-08-01, it was wrong (issue #98). It previously read that ctk's hooks.json file-path if conditions depend on the v2.1.176 fix "to gate correctly," making that the effective minimum CC version for our security/permission hooks. Measured on v2.1.220: 4 of the 6 conditions were probed directly and none gated — neither the Bash ones nor the file-path ones (the other 2 are inferred, not measured — see the write-up). All 6 were removed from ctk's hooks.json; each hook's own internal guard is and always was the real filter. Cause (best-supported explanation, from the official hooks docs plus measurement): they were wrong twice over — if is a hook-handler field (sibling of type/command), not a matcher-group field, so at group level the key was never read; and if "holds exactly one permission rule — there is no &&, ||, or list syntax," while every value we shipped was a ||-joined list. ⚠ The correct-looking fix is the dangerous one — do NOT "fix the nesting." Moving if into the handlers and splitting the lists is exactly what the CC docs prescribe in general, and on PreToolUse[0] it would confine security-blocker to 20 destructive-verb globs, letting every secret-file read through (cat <envfile>, curl -d @<envfile>, cat ~/.ssh/id_rsa match none of them). PreToolUse[2] is the same trap for the write path. CC's own docs agree on the principle: "the if filter is best-effort, use the permission system rather than a hook to enforce a hard allow or deny." Pinned by plugins/continuity-toolkit/hooks/tests/hooks-manifest.test.ts. The false claim originated in a CHANGELOG gap-analysis that verified the conditions were present and never that they gate. Full measurements, the six-key landmine table, and what remains NOT ESTABLISHED (what CC does with a malformed if at the correct nesting level — undocumented; and the "never read at group level" step is an inference from measurement, not a documented fact): docs/reviews/2026-08-01_98-hook-if-condition-cause.md. Per-version "considered but not adopted" notes are not tracked here — see git log -p CLAUDE.md or the CC CHANGELOG for prior reasoning. ⚠ Two earlier reviews are cited by this header but have no write-up in the repo: the v2.1.159→173 and v2.1.153→158 passes named docs/reviews/2026-06-11_cc-v2.1.173-alignment-audit.md and docs/reviews/2026-05-31_cc-v2.1.158-plugin-system-alignment-audit.md. Measured 2026-08-04: neither file has ever been committed on any branch (git log --all --diff-filter=A returns 0 for both), so those citations have always been dangling. Their findings survive only in this header and in git log -p CLAUDE.md. Do not go looking for the files.