CLAUDE.md 生成器

/init

Set up a minimal CLAUDE.md optimized for agent performance. CLAUDE.md is loaded into every Claude Code session, so it must stay compact and high-signal.

Optimization policy:
- Hardcode CLAUDE.md as the instruction file target. Do not generate any alternate instruction filename.
- Treat CLAUDE.md as a living friction log, not a codebase overview.
- Before adding any line to CLAUDE.md, ask: can the agent discover this by reading the repo, docs, manifests, CI, or config? If yes, do not include it.
- Do not include directory trees, tech stack summaries, architecture overviews, module catalogs, or generic best-practice filler.
- Prefer operational landmines only: tooling gotchas, non-obvious conventions, unsafe legacy traps, deployment pitfalls, and commands the agent would otherwise guess wrong.
- If a problem can be fixed in code, linting, tests, hooks, or automation, prefer fixing the root cause over adding another persistent instruction.
- Prefer scoped CLAUDE.md files in subdirectories for module-specific rules instead of bloating the root file.
- Avoid mentioning legacy or incidental patterns unless they are still operationally relevant for current work.
- Remove stale instructions once the underlying issue is fixed.

## Phase 1: Ask what to set up

Use AskUserQuestion to find out what the user wants:

- "Which CLAUDE.md files should /init set up?"
  Options: "Project CLAUDE.md" | "Personal CLAUDE.local.md" | "Both project + personal"
  Description for project: "Team-shared operational instructions checked into source control."
  Description for personal: "Your private preferences for this project (gitignored, not shared) such as role, sandbox URLs, and workflow quirks."

- "Also set up skills and hooks?"
  Options: "Skills + hooks" | "Skills only" | "Hooks only" | "Neither, just CLAUDE.md"
  Description for skills: "On-demand capabilities you or Claude invoke with `/skill-name` for repeatable workflows."
  Description for hooks: "Deterministic shell commands that run on tool events, such as formatting after edits."

## Phase 2: Explore the codebase

Launch a subagent to survey the codebase and read key files: manifest files (package.json, Cargo.toml, pyproject.toml, go.mod, pom.xml, etc.), README, Makefile/build configs, CI config, existing CLAUDE.md, .claude/rules/, .cursor/rules or .cursorrules, .github/copilot-instructions.md, .windsurfrules, .clinerules, .mcp.json.

Detect:
- Build, test, and lint commands the agent could guess wrong
- Languages, frameworks, and package manager only as working context; do not copy them into CLAUDE.md unless they imply a non-obvious rule
- Project structure only to decide whether scoped subdirectory CLAUDE.md files are needed
- Code style rules that differ from language defaults
- Non-obvious gotchas, required env vars, workflow quirks, and legacy hazards
- Existing .claude/skills/ and .claude/rules/ directories
- Formatter configuration (prettier, biome, ruff, black, gofmt, rustfmt, or a unified format script like `npm run format` / `make fmt`)
- Git worktree usage via `git worktree list` if the user wants a personal CLAUDE.local.md

For every candidate note, apply this filter:
- If the agent can discover it quickly from the repo, exclude it from CLAUDE.md.
- If it is broad explanatory prose instead of a concrete operational constraint, exclude it.
- If it belongs to one subsystem only, prefer a scoped CLAUDE.md near that subsystem instead of the root file.

Note what you could NOT figure out from code alone. Those become interview questions.

## Phase 3: Fill in the gaps

Use AskUserQuestion to gather only the missing information needed to write good CLAUDE.md files and skills. Ask only things the code cannot answer.

If the user chose project CLAUDE.md or both: ask about non-obvious commands, workflow traps, branch or PR conventions, required env setup, testing quirks, and landmines. Skip anything already obvious from the repo.

If the user chose personal CLAUDE.local.md or both: ask about the user, not the codebase. Examples:
  - Their role on the team
  - Their familiarity with this codebase and its languages/frameworks
  - Personal sandbox URLs, test accounts, API key paths, or local setup details
  - Communication preferences such as "be terse" or "always explain tradeoffs"

Synthesize a proposal from Phase 2 findings, but only include items that survive the optimization policy:
- Hook if it should be enforced mechanically on a tool event
- Skill if it is an on-demand workflow
- CLAUDE.md note only if it is truly non-discoverable and not better enforced elsewhere

Respect the Phase 1 skills/hooks choice as a hard filter. Never propose an artifact type the user did not opt into.

Show the proposal via AskUserQuestion's `preview` field, not as a separate text message. Keep previews compact and operational.

Build the preference queue from the accepted proposal. Each entry: {type: hook|skill|note, description, target file, any discovered command or workflow detail}. Phases 4-7 consume this queue.

## Phase 4: Write CLAUDE.md (if user chose project or both)

Write a minimal CLAUDE.md at the project root. Every line must pass both tests:
- Would removing this make Claude more likely to make a mistake?
- Could Claude discover this by inspecting the repo on demand?

If the answer to the first is no, cut it.
If the answer to the second is yes, cut it.

Consume `note` entries from the Phase 3 preference queue whose target is CLAUDE.md.

Include only:
- Commands Claude is likely to guess wrong
- Code style rules that differ from defaults
- Testing quirks and validation traps
- Repo etiquette only when it changes how Claude should operate
- Non-obvious setup steps, landmines, and architectural hazards
- Important constraints from existing AI tool configs only when they are still operationally relevant

Exclude:
- File-by-file structure or component lists
- Standard language conventions Claude already knows
- Generic advice such as "write clean code" or "handle errors"
- Detailed API docs or long references; use `@path/to/import` instead
- Information that changes frequently if the source can be referenced directly
- Legacy patterns that should not bias new work unless the repo still depends on them

Prefix the file with:

```
# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
```

If the repo has distinct subdirectories or modules with different constraints, prefer additional scoped CLAUDE.md files near those directories over expanding the root file.

If CLAUDE.md already exists: read it, propose specific diffs, and remove stale or redundant lines instead of only appending more text.

## Phase 5: Write CLAUDE.local.md (if user chose personal or both)

Write a minimal CLAUDE.local.md at the project root. This file is automatically loaded alongside CLAUDE.md. After creating it, add `CLAUDE.local.md` to the project's .gitignore so it stays private.

Consume `note` entries from the Phase 3 preference queue whose target is CLAUDE.local.md.

Include:
- The user's role and familiarity with the codebase
- Personal sandbox URLs, test accounts, or local setup details
- Personal workflow or communication preferences

Keep it short and user-specific.

If Phase 2 found multiple git worktrees and the user confirmed they use sibling/external worktrees: write the real personal content to `~/.claude/<project-name>-instructions.md` and make CLAUDE.local.md a one-line stub importing it with `@~/.claude/<project-name>-instructions.md`.

If CLAUDE.local.md already exists: propose precise additions instead of overwriting it.

## Phase 6: Suggest and create skills (if user chose "Skills + hooks" or "Skills only")

Skills add capabilities Claude can use on demand without bloating every session.

First, consume `skill` entries from the Phase 3 preference queue.
Then suggest additional skills only when they capture repeatable workflows or subsystem-specific knowledge better than root-level prose.

If `.claude/skills/` already exists, review it first and only propose complementary skills.

Create each skill at `.claude/skills/<skill-name>/SKILL.md`:

```yaml
---
name: <skill-name>
description: <what the skill does and when to use it>
---

<Instructions for Claude>
```

For workflows with side effects, add `disable-model-invocation: true` and use `$ARGUMENTS` to accept input.

## Phase 7: Suggest additional optimizations

Tell the user you are suggesting a few optimizations now that CLAUDE.md and skills (if chosen) are in place.

Check the environment and ask about each applicable gap:
- GitHub CLI if missing and the project uses GitHub
- Linting if the project lacks lint configuration
- Proposal-sourced hooks if the user opted into hooks

When a repeated agent mistake could be prevented mechanically, prefer suggesting a hook, linter rule, test, or CI guard over a permanent CLAUDE.md note.

Consider whether the repo would benefit from a lightweight maintenance workflow for pruning stale CLAUDE.md lines as the codebase evolves.

## Phase 8: Summary and next steps

Recap what was set up and why each file exists.

Remind the user that CLAUDE.md is not a permanent dumping ground. It should stay small, focus on non-discoverable landmines, and lose lines as the underlying friction gets fixed.

Present any follow-up suggestions as a short, relevant to-do list ordered by impact.