The /init slash command has been significantly expanded. It now runs a structured 8-phase guided interview that covers far more than creating a CLAUDE.md.
/initThe new flow works as follows:
Phase 0: Checks whether a CLAUDE.md already exists and branches accordingly — offering to review and improve it, leave it alone, or start fresh.
Phase 1: Asks what to set up, with four options:
- Project
CLAUDE.md(team-shared, committed to source control) - Personal
CLAUDE.local.md(private, gitignored) - Both project and personal files
- "Let Claude decide" — fastest path, no follow-on questions
A second question asks whether to also set up skills and/or hooks.
Phase 2: Launches a subagent to survey the codebase — manifest files, README, CI config, existing AI tool configs (.cursor/rules, .github/copilot-instructions.md, AGENTS.md, .devin/rules/, .windsurf/rules/, .clinerules), formatter config, and git worktree layout.
Phase 3: Asks targeted follow-up questions about anything the code scan couldn't determine — non-standard commands, branch conventions, required env vars, testing quirks, or personal workflow preferences. Synthesizes a proposal listing exactly which files, skills, and hooks will be created, and asks for approval before proceeding.
Phase 4: Writes the project CLAUDE.md using a strict "would removing this cause Claude to make mistakes?" test to keep it concise. Handles the "review and improve" path with diff proposals rather than silent overwrites. For large projects, suggests organizing into .claude/rules/ subdirectory files.
Phase 5: Writes CLAUDE.local.md for personal preferences (role, sandbox URLs, communication style). For repos using sibling/external git worktrees, it writes the content to ~/.claude/<project-name>-instructions.md and creates a one-line stub import in each worktree's CLAUDE.local.md.
Phase 6: Creates skills from the proposal — both skills the user requested during the interview and additional suggestions that fit the codebase (reference knowledge, repeatable deploy or release workflows, etc.). Places each at .claude/skills/<name>/SKILL.md. Distinguishes between skills that can be model-invoked vs. user-only skills with side effects (disable-model-invocation: true).
Phase 7: Checks for GitHub CLI (which gh) and offers to explain its benefits if missing; checks for a lint config and offers to set one up if absent; wires up any requested hooks by calling the update-config skill for proper schema validation and live testing.
Phase 8: Recaps all files written and suggests next steps, including relevant official plugins (frontend-design, playwright, skill-creator) based on what was found in the codebase.
- The "Review and improve" path in Phase 0 skips the interview and goes straight to proposing specific diffs against the existing file.
- The "Leave it" path in Phase 0 skips CLAUDE.md entirely and jumps to skills and hooks setup.
- Q2 (skills/hooks) is a hint rather than a hard filter — if no hook-shaped work exists,
/initsays so and proposes better-fitting artifacts instead. - Hook target file defaults: project choice →
.claude/settings.json; personal choice →.claude/settings.local.json. Only asks if the user picked "both". - Git pre-commit hooks are correctly distinguished from Claude Code
PostToolUsehooks — if a user asks to "gate before committing",/initroutes that to a git hook or husky rather than silently creating a mismatched Claude Code hook.
New qKp string literal contains the full 8-phase guided setup instructions (search for "Phase 0: Check for an existing CLAUDE.md"). New WKp string literal contains the standalone CLAUDE.md creation instructions for non-interactive contexts (search for "Please analyze this codebase and create a CLAUDE.md file").
Strings lifted out of the shipped bundle, so the claim above can be checked against them.