claude-code-autoconfig
CLAUDE.md2 starsChanged 2 months agoMITView on GitHub
CLI tool that auto-configures Claude Code for any project. One command analyzes your project, configures Claude, and shows you what it did. After publish, push the branch AND the release tag explicitly (the postversion changelog hook re-tags lightweight): git push origin main && git push origin v<x.y.z>. CHANGELOG.md regenerates from commit subjects on every npm version, and the installer shows those bullets verbatim to users on upgrade (bin/update-summary.js). So: - Subjects may stay technical, but then the commit body MUST…
- Commits and pushes
In this repositoryOne other file it gives its agents.
- plan-authoringSkill
The file
Show its rules and text
We split this CLAUDE.md into the rules it gives an agent
13 rules. About 0 are common, 5 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 35
After publish, push the branch AND the release tag explicitly (the postversion changelog hook re-tags lightweight): git push origin main && …
- Very specific: line 48
Keep the feat:/fix: conventional prefix on the subject — it drives the summary's "New features" vs "Fixes & improvements" grouping.
- Distinctive: line 74
NEVER jump to a fix based on assumptions: When investigating a bug:
- Distinctive: line 80
If you can't determine the root cause from code reading alone, add diagnostic logging and ask the user to reproduce.
- Very specific: line 95
Rule: If the update is just a file → put it in the right directory and let the CLI copy it.
- Very specific: line 97
Command versioning: Every command file must have a <!-- @version N --> comment (typically line 2, after @description).
- Distinctive: line 104
If a file exceeds 500 LOC, it likely lacks separation of concerns — look for decomposition opportunities
- Distinctive: line 105
Keep cyclomatic complexity under 10 per function — extract helper functions or simplify branching if higher
- Distinctive: line 131
MUST run tests and verify they pass:
- Very specific: line 224
Never edit a copy — the next sync clobbers it.
- Very specific: line 268
When modifying the "READY ..." boxes in bin/cli.js:
- Very specific: line 270
All lines must be exactly 46 visible characters wide (including the ║ borders)
- Very specific: line 275
Always run npm test after any box modifications — test/box-alignment.test.js runs the real CLI (fresh + upgrade) and asserts the rendered …
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- AUTO-GENERATED BY /autoconfig at 2026-01-14 19:54:27 UTC — Do not edit. Use .claude/feedback/ for corrections. -->claude-code-autoconfig
CLI tool that auto-configures Claude Code for any project. One command analyzes your project, configures Claude, and shows you what it did.
Tech Stack
- Runtime: Node.js (>=18.0.0)
- Type: npm CLI package
- Entry:
bin/cli.js
Commands
npm test # Run ALL tests (full suite — see Testing Requirements below)
npm run test:box # Run box alignment tests only
npm run test:install # Run CLI install tests onlyProject Structure
bin/cli.js— Main CLI entry point, handles bootstrap and /autoconfig launch.claude/commands/— Slash command definitions (/autoconfig, /autoconfig-update, etc.).claude/hooks/— Hook scripts (format.js for JS/TS projects).claude/feedback/— Team feedback and correctionstest/— Test files
Publishing
npm version patch && npm publishAfter publish, push the branch AND the release tag explicitly (the postversion changelog
hook re-tags lightweight): git push origin main && git push origin v<x.y.z>.
Changelog is user-facing — write commits accordingly
CHANGELOG.md regenerates from commit subjects on every npm version, and the installer
shows those bullets verbatim to users on upgrade (bin/update-summary.js). So:
- Subjects may stay technical, but then the commit body MUST carry a plain-language
trailer the changelog uses instead:
Changelog: More reliable 'awaiting your reply' tab indicator. Write it for a CCA user, not a maintainer — name the visible outcome, never internals (no hook/regex/TDZ/function names). Changelog: none(orskip) hides an internal-only commit from the changelog.- Keep the
feat:/fix:conventional prefix on the subject — it drives the summary's "New features" vs "Fixes & improvements" grouping. - Already-pushed commits can't be reworded in git; add a row to
OVERRIDESinscripts/generate-changelog.jsinstead (valuenulldrops the bullet). New work never uses OVERRIDES — author the trailer.
Team Feedback
@.claude/feedback/FEEDBACK.md
<!-- END AUTO-GENERATED at 2026-01-14 19:54:27 UTC — Use .claude/feedback/ for corrections. -->Discoveries
<!-- Claude: append project-specific learnings, gotchas, and context below. This section persists across /autoconfig runs. -->Publishing to npm — bypass-2FA token flow (web-auth publish is a DEAD END)
(Supersedes the auto-generated "## Publishing" one-liner above.)
- Primary flow (agent can do it end-to-end):
npm test+npm version patch(commit + tag) →npm whoamito verify the Bypass-2FA granular token in~/.npmrcstill authenticates → plainnpm publish(works headless, no OTP) → after the+ claude-code-autoconfig@<version>line,git push origin main --follow-tags. Never double-bump if the version is already bumped. - If
npm whoamireturns E401, the token is dead/expired (90-day cap). The human rotates it (npmjs.com → Access Tokens → Granular → "Bypass 2FA", read-write, scoped to this package only) and pastes it into~/.npmrcin an editor — never via a command. Stopgap without a token:npm publish --otp=<recovery-code>in the human's own terminal. - Do NOT use
npm login --auth-type=web && npm publish: login succeeds but publish still diesEOTP— the npm CLI can't route publish-time 2FA to the browser on this webauthn-only account (confirmed 2026-07-03, npm 10.9.2). Don't retry it in-agent, and don't ask for a typed TOTP (none exists). Full procedure:.claude/commands/deploy-to-npmjs.md(/deploy-to-npmjs).
Debugging Methodology — Evidence Before Solutions
NEVER jump to a fix based on assumptions. When investigating a bug:
- Gather evidence first — add logging, check server logs, inspect actual data
- Confirm the root cause — present findings to the user with evidence
- Only then propose a fix — based on what you observed, not what you guessed
If you can't determine the root cause from code reading alone, add diagnostic logging and ask the user to reproduce. Do NOT:
- Guess the root cause and immediately start coding a fix
- Assume data mismatches without checking the actual data
- Rewrite logic because you think values "might" differ
The cost of a wrong fix is high: wasted time, unnecessary code complexity, and potentially masking the real issue.
Update System Guidelines
The .claude/updates/ directory is for updates that require Claude to execute instructions — writing to MEMORY.md, modifying user config, running migrations, etc.
Do NOT create update files for simple command file drops. Command files in .claude/commands/ are automatically installed/updated by copyTree in the CLI. The CLI detects new and modified commands and reports them in the console output. Creating an update file for a command that's already shipped via copyTree is redundant.
Rule: If the update is just a file → put it in the right directory and let the CLI copy it. If the update needs instructions → create a NNN-*.md update file.
Command versioning: Every command file must have a <!-- @version N --> comment (typically line 2, after @description). Bump the version number whenever you modify a command. The CLI parses this to show version transitions on upgrade (e.g., ↑ /recover-context (v1 → v2)).
Design Principles
- Each file should have a single responsibility (one reason to change)
- If a file exceeds 500 LOC, it likely lacks separation of concerns — look for decomposition opportunities
- Keep cyclomatic complexity under 10 per function — extract helper functions or simplify branching if higher
Development Rules
Parallel sessions — work in a git worktree
Several Claude sessions run against this repo at once. If another may be open, call
EnterWorktree before your first write to a repo file, then node scripts/bootstrap-worktree.js
— a fresh worktree has every tracked file and no gitignored one, so without bootstrap there is no
node_modules (the full suite fails in complexity-ratchet.test.js, which loads eslint), no
.claude/settings.local.json (re-prompts on every Bash call), and no
scripts/hook-fleet.local.json for the fleet check. Read-only sessions never enter one; it is one
worktree per session, not per task. Skip it entirely when the work touches no repo files, or when
it builds on uncommitted changes already in this checkout — those do not come along.
Full loop, the worktree.baseRef: head gotcha, and the list of things worktrees do NOT
isolate (~/.claude and the hook fleet, the live twin, .claude/updates/ numbers,
publishing): .claude/rules/parallel-session-worktrees.md.
That rule is dev-only — gated out of user installs by DEV_ONLY_FILES in bin/cli.js
and the package.json files negation. scripts/ is not in files at all, so the bootstrap
script never ships.
Testing Requirements
CRITICAL: Before committing any change to bin/, scripts/, or .claude/hooks/*.js, you
MUST run tests and verify they pass:
npm testThis runs the FULL suite:
box alignment, CLI install, update system, plugin system, terminal-title behavior,
golden endings, live-twin parity, update summary, changelog generation, and the hook
suites (npm run test:hooks fans out to .claude/hooks/tests/*.test.cjs — token-saver
lives there, and those tests do NOT run any other way).
DO NOT commit or present code changes if tests fail. Fix the issues first.
Dev-box pre-push guard (per-machine setup, not tracked)
.git/hooks/ is untracked, so this hook lives only on the dev box — it is not shipped and
not committed. It is the one mechanical guard for the fleet-parity class that CI structurally
cannot see: live-twin-parity.test.js skips on CI, so CI green never proves the hook fleet is in
sync (see trap 5 / T8 below). The hook blocks a push unless npm test passes AND
node scripts/sync-hook-fleet.js (check mode) reports zero drift.
Since 2026-07-25 it checks the whole manifest (terminal-title + token-saver), not just
terminal-title — token-saver is the file that actually drifted 231 lines, precisely because
nothing checked it. A blocked push means an adopting repo is stale: run
node scripts/sync-hook-fleet.js --write, commit the target repo, push again.
Check mode compares against HEAD, not the working tree (2026-08-07). Several sessions edit
fleet-synced files here at once, and reading canonical from the working tree meant any one of them
holding a file open made every downstream copy read as drifted — blocking every other session's
push over a change nobody had committed. A target matching HEAD is therefore let through, narrated
as in sync with HEAD (canonical has uncommitted edits). --write deliberately keeps using the
working tree, since edit → --write → commit is the normal authoring loop.
test/hook-fleet-sync.test.js runs everywhere (it drives the actuator against throwaway dirs)
and pins its semantics — adopt-only, the ~/.claude token-saver carve-out, check-vs-write, the
exit codes this hook depends on. It does not replace the guard: it proves the actuator is
correct, never that this machine's fleet is actually in sync. Only the check-mode run does that.
A third check warns, never blocks (2026-08-19): after both blocking checks, the hook prints
unlandedBranches from .claude/scripts/sync-worktrees.js --json — branches merged nowhere that
have no worktree left. A push is the wrong moment to refuse over a branch that isn't the one
you're pushing, and a guard that blocks on advisory information is a guard somebody deletes; but
nothing else surfaces this without a human remembering to run /sync-worktrees, which is the same
passivity that let a branch sit a day behind. Its || true is load-bearing — set -e is on, so a
non-zero exit there would abort the push.
On a fresh checkout, recreate .git/hooks/pre-push (then chmod +x it):
#!/bin/sh
# CCA dev-box pre-push guard (see CLAUDE.md). Not tracked; recreate on a fresh checkout.
# Blocks a push unless the full suite passes AND the canonical hook fleet is in sync
# (the parity class CI cannot see — live-twin-parity.test.js skips on CI).
set -e
echo "[pre-push] running full test suite (npm test)..."
npm test
echo "[pre-push] checking hook fleet sync..."
node scripts/sync-hook-fleet.js
# Unlanded-branch notice — WARN ONLY, last on screen, and `|| true` because `set -e` is on.
echo "[pre-push] unlanded branches (warn only)..."
node .claude/scripts/sync-worktrees.js --json 2>/dev/null | node -e '
let s = "";
process.stdin.on("data", (d) => (s += d)).on("end", () => {
let u = [];
try { u = JSON.parse(s).unlandedBranches || []; } catch { return; }
if (!u.length) { console.log("[pre-push] none."); return; }
console.log("[pre-push] WARNING: " + u.length + " unlanded branch(es) with no worktree:");
for (const b of u) {
console.log("[pre-push] " + b.branch + " - " + b.ahead + " unlanded, " + b.behind + " behind");
}
console.log("[pre-push] Not blocking. Land them, or reverse-merge before they drift further.");
});
' || true
echo "[pre-push] OK - tests green, fleet in sync."Invariants & Landmines — read before editing
Cross-file contracts that don't look like contracts. Each of these survives a naive read and a green feeling, then breaks something real:
- Generated files — never hand-edit.
CHANGELOG.mdis rebuilt from git history byscripts/generate-changelog.json everynpm version(reword bullets viaChangelog:trailers or its OVERRIDES map)..claude/docs/autoconfig.docs.htmlis rebuilt bynode .claude/scripts/sync-docs.js, which locates exact string markers inside that HTML — reformatting the file breaks the next sync. - The
.claude/hookscopies here are the canonical ones —terminal-title.js,terminal-title.directive.md, andtoken-saver.js(the manifest inscripts/sync-hook-fleet.js). Edit only these, then runnode scripts/sync-hook-fleet.js --writeto push them to~/.claudeand the fleet. Never edit a copy — the next sync clobbers it; drift failslive-twin-parity.test.json this machine (the test skips on CI, so CI green ≠ parity ok). Syncing is adopt-only: a target that doesn't already have the file is skipped, never created, so a repo never acquires a hook by sync (that's the installer's job, and an unwired hook reads as adoption while doing nothing).scripts/sync-terminal-title.jsstill works — it is now a thin front-end over the same code, kept because plan and audit docs name it. - Dev-only gating lives in
DEV_ONLY_FILES(bin/cli.js), NOT package.jsonfiles. The npmfilesnegations only shape the tarball; anything absent fromDEV_ONLY_FILESis installed into every user project. token-saver + its commands are deliberately gated — do not "fix" that by shipping them. The installer also RETRACTS the 1.0.224 leak (deletes token-saver.js and the pre-rename token-guard.js, plus their commands, and strips both hook entries) unlesscca.config.jsoncarriestokenSaver.verdictServiceKey(paid) ortokenSaver.devFleet: true(one of our own repos, where the file arrives viascripts/sync-hook-fleet.js; a legacytokenGuardblock is migrated totokenSaveron install). Every fleet repo that holds token-saver.js needs the devFleet flag, or its next@latestupgrade deletes the file. - Commits about dev-gated work need a
Changelog: nonetrailer. feat/fix/perf/refactor bullets surface verbatim on users' upgrade screens (bin/update-summary.js) — announcing a feature users can't receive is a bug. Already-pushed leaks: add an OVERRIDESnull.scripts/generate-changelog.jsalso cross-checks each commit's touched paths againstDEV_ONLY_FILES: a commit whose only shipped-area files are gated is dropped whatever its trailer says (stderr names it), a mixed commit keeps its bullet with a verify note, and an explicit OVERRIDES row wins. The trailer still governs mixed and maintainer-only commits. - token-saver's
--analyzedigest wording is a machine interface./analyze-sessionkeys on the literal "live context at end" and the RENT/BOMBS/FLEETS/TTL headers. R6 scope data comes from terminal-title's per-title ledger (.titles/{sid}.history.jsonl:ts,title, optionaltokens), parsed byledgerScopes()and read by/migrate-new-sessiontoo. Renaming those ledger fields (they're written by terminal-title.js) silently breaks token-saver drift + that command. .claude/updates/numbers are append-only — next is005;002is a retired tombstone (see.claude/updates/README.md). A reused number is silently skipped by installs that applied the original..claude/settings.jsondetails are load-bearing:CLAUDE_CODE_DISABLE_TERMINAL_TITLEstays"1"(else Claude Code's own title writer races the hook), the--idle-rescuearg on theidle_promptNotification entry selects a distinct code path (don't "dedupe" the two Notification entries), and hook commands stay${CLAUDE_PROJECT_DIR:-.}-anchored.- Hooks fail silent by design (token-saver, terminal-title swallow errors and exit 0). A regression won't crash anything — it quietly stops warning/painting. Run the hook suites; "it didn't error" proves nothing.
test/golden-endings.jsonis append-only — never relabel or delete an entry without explicit sign-off; each records a real incident.
Box Drawing Guidelines
When modifying the "READY ..." boxes in bin/cli.js:
- All lines must be exactly 46 visible characters wide (including the
║borders) - ANSI escape codes (
\x1b[...m) don't count toward visible width - The boxes are rendered by
boxLine(text)/printReadyBox(title, command)insidemain()—boxLinepads the visible text (ANSI stripped) to 44 chars between the borders, so never hand-count spaces; wrap colored spans withpaint(color, text) - Always run
npm testafter any box modifications —test/box-alignment.test.jsruns the real CLI (fresh + upgrade) and asserts the rendered width/structure of both boxes
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

