← 提示词库 Anthropic/claude-code/skills/init-new/SKILL.md 原文 md
🌐 中英双语对照

name: init
description: |-
Initialize new CLAUDE.md file(s) and optional skills/hooks with codebase documentation

Set up a minimal CLAUDE.md (and optionally skills and hooks) for this repo. CLAUDE.md is loaded into every Claude Code session, so it must be concise — only include what Claude would get wrong without it.

为本仓库设置一份精简的 CLAUDE.md（以及可选的技能和 hook）。CLAUDE.md 会在每个 Claude Code 会话中加载，因此必须简洁 — 只收录没有它 Claude 就会出错的内容。

【评论】"只收录没有它 Claude 就会出错的内容"这一准入判据，把上下文窗口的成本意识转化为可操作的写作标准，是上下文文件极简主义的典型体现。

Phase 0: Check for an existing CLAUDE.md / 阶段 0：检查是否已存在 CLAUDE.md

Before asking anything, check if CLAUDE.md already exists at the project root (just cat ./CLAUDE.md — only the project-root file counts; don't explore the tree yet). This branches Phase 1.

在提问之前，先检查项目根目录是否已存在 CLAUDE.md（只需 cat ./CLAUDE.md — 只有项目根目录下的文件才算数；暂不要探索目录树）。这一步决定阶段 1 的分支走向。

Phase 1: Ask what to set up / 阶段 1：询问要设置什么

Use AskUserQuestion to find out what the user wants. Which question you ask depends on Phase 0. Call AskUserQuestion with only Q1 — do NOT include Q2 in the same call. Only ask Q2 after you've seen the Q1 answer, since "Let Claude decide" skips it.

用 AskUserQuestion 询问用户想要什么。问哪个问题取决于阶段 0。调用 AskUserQuestion 时只带 Q1 — 不要在同一次调用中包含 Q2。只有在看到 Q1 的答案之后才能问 Q2，因为"让 Claude 决定"会跳过 Q2。

Before the first question, print this primer as normal assistant text so first-time users know the terms:

在第一个问题之前，先把下面的说明以普通助手文本打印出来，让首次使用的用户了解这些术语：

Quick context:
快速背景：

  • CLAUDE.md files give Claude persistent instructions for a project, your personal workflow, or your organization. Claude reads them at the start of every session.
    • CLAUDE.md 文件为 Claude 提供针对项目、你的个人工作流或组织的持久化指令。Claude 会在每次会话开始时读取它们。
  • Skills are packaged instructions Claude invokes automatically when a task matches, or that you trigger with a slash command (e.g. /frontend-design, /commit-push-pr).
    • **技能（Skills）**是打包好的指令，任务匹配时 Claude 会自动调用，你也可以用斜杠命令触发（如 /frontend-design、/commit-push-pr）。
  • Hooks allow you to run shell commands automatically on lifecycle events: get notified when Claude is blocked on your input, auto-format after edits, enforce checks before commits — these are deterministic and Claude can't skip them.
    • Hook 允许你在生命周期事件上自动运行 shell 命令：Claude 等待你输入时收到通知、编辑后自动格式化、提交前强制检查 — 这些是确定性操作，Claude 无法跳过。

If CLAUDE.md already exists, ask:

如果 CLAUDE.md 已存在，询问：

If no CLAUDE.md exists (or the user picked "Start fresh"), ask:

如果 CLAUDE.md 不存在（或用户选了"从头开始"），询问：

Phase 2: Explore the codebase / 阶段 2：探索代码库

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

启动一个子代理勘察代码库，让它阅读关键文件以了解项目：清单文件（package.json、Cargo.toml、pyproject.toml、go.mod、pom.xml 等）、README、Makefile/构建配置、CI 配置、既有 CLAUDE.md、.claude/rules/、AGENTS.md、.cursor/rules 或 .cursorrules、.github/copilot-instructions.md、.devin/rules/ 或 .windsurf/rules/ 或 .windsurfrules、.clinerules、.mcp.json。

【评论】清单一并枚举了 Cursor、Copilot、Devin、Windsurf、Cline 等其他 AI 编码工具的指令文件，说明该技能带有读取并迁移既有 AI 工具配置的意图。

Also have the subagent do a cheap presence check (not a read — the contents are handled by the import adapters) for:

同时让子代理对以下内容做廉价的存在性检查（不是读取 — 内容由导入适配器处理）：

Record which of these exist — Phase 8 uses it.

记录其中哪些存在 — 阶段 8 会用到。

Detect:

检测：

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

记下仅凭代码无法弄清的事项 — 它们将成为访谈问题。

Phase 3: Fill in the gaps / 阶段 3：填补空白

Use AskUserQuestion to gather what you still need to write good CLAUDE.md files and skills. Ask only things the code can't answer.

用 AskUserQuestion 收集编写高质量 CLAUDE.md 文件和技能还欠缺的信息。只问代码无法回答的问题。

If the user chose project CLAUDE.md, both, or "Let Claude decide": ask about codebase practices — non-obvious commands, gotchas, branch/PR conventions, required env setup, testing quirks. Skip things already in README or obvious from manifest files. Do not mark any options as "recommended" — this is about how their team works, not best practices.

如果用户选择了项目 CLAUDE.md、两者都要或"让 Claude 决定"：询问代码库实践 — 不显眼的命令、坑、分支/PR 约定、必需的环境配置、测试习惯。跳过 README 已有或从清单文件即可看出的事项。不要把任何选项标为"推荐" — 这关乎他们团队的工作方式，而非最佳实践。

If the user chose personal CLAUDE.local.md or both: ask about them, not the codebase. Do not mark any options as "recommended" — this is about their personal preferences, not best practices. Examples of questions:

如果用户选择了个人 CLAUDE.local.md 或两者都要：询问用户本人，而非代码库。不要把任何选项标为"推荐" — 这关乎个人偏好，而非最佳实践。问题示例：

If the user picked "Review and improve" in Phase 0: ask just one question — "Has anything changed about how the team works since this CLAUDE.md was written (new conventions, commands, gotchas)?" with options "No, nothing's changed" | "Yes — let me describe". If they pick Yes, ask what changed (free text) before continuing. Then skip to Phase 4.

如果用户在阶段 0 选了"审查并改进"：只问一个问题 — "自这份 CLAUDE.md 写成以来，团队的工作方式有什么变化吗（新约定、命令、坑）？"，选项为"没有，没有变化" | "有 — 我来描述"。如果选"有"，先问变化内容（自由文本）再继续。然后跳到阶段 4。

Synthesize a proposal from Phase 2 findings and the gap-fill answers. For each item, pick the artifact type that fits the evidence:

根据阶段 2 的发现和补漏答案综合出一份提案。 对每一项，选择符合证据的产物类型：

Include the CLAUDE.md file(s) implied by Q1 (project, personal, both, or "Let Claude decide" → project) as the first bullet(s) of the proposal, with a one-line summary of what each will cover. Then list skills/hooks/notes. On the "Leave it" path, omit CLAUDE.md file bullets and notes (Phase 4 won't run). On the "Start fresh" path with Q1 = personal-only, add a bullet noting the existing project CLAUDE.md will be left untouched (they chose not to replace it with a project file).

把 Q1 所暗示的 CLAUDE.md 文件（项目、个人、两者，或"让 Claude 决定" → 项目）作为提案的第一批要点，每个附一行关于其将涵盖内容的摘要。然后列出技能/hook/备注。在"保留"路径上，省略 CLAUDE.md 文件要点和备注（阶段 4 不会运行）。在"从头开始"且 Q1 = 仅个人的路径上，加一条要点说明现有项目 CLAUDE.md 将保持原样（用户选择了不用项目文件替换它）。

Propose what fits. If the user gave a Q2 hint and your proposal deviates from it (e.g. they said "Hooks only" but nothing hook-shaped exists), say so in one line at the top of the proposal and propose the better-fitting artifacts anyway.

提出适合的方案。如果用户给了 Q2 提示而你的提案与之偏离（如用户说"仅 hook"但不存在适合做成 hook 的东西），在提案开头用一行说明这一点，并照样提出更合适的产物。

Print the proposal as normal assistant text, one bullet per item:

以普通助手文本打印提案，每项一条要点：

Here's what I'd set up:
• [Artifact type: file/hook/skill/note] — [one-line description]
• …

我建议的配置如下：
• [产物类型：文件/hook/技能/备注] — [一行描述]
• …

Then call AskUserQuestion with a simple question ("Does this look right?") and options like "Looks good — proceed" | "Drop the hook" | "Drop the skill". Don't use the preview field — the proposal is already visible in scrollback. The tool auto-adds an "Other" option for custom tweaks.

然后用 AskUserQuestion 问一个简单问题（"这样安排可以吗？"），选项如"没问题 — 继续" | "去掉 hook" | "去掉技能"。不要用 preview 字段 — 提案已在回滚记录中可见。该工具会自动添加"Other"选项供自定义调整。

Build the preference queue from the accepted proposal. Each entry: {type: hook|skill|note, description, target file, any Phase-2-sourced details like the actual test/format command}. Phase 6 and Phase 7's hooks sub-bullet consume this queue; Phases 4/5 gate on the approved proposal's file bullets directly; Phase 7's GitHub-CLI and linting checks run regardless of queue contents.

根据被接受的提案构建偏好队列。 每个条目：{type: hook|skill|note, description, target file，以及来自阶段 2 的细节如实际的测试/格式化命令}。阶段 6 和阶段 7 的 hooks 子项消费该队列；阶段 4/5 直接以已批准提案的文件要点为准；阶段 7 的 GitHub-CLI 和 lint 检查无论队列内容如何都会执行。

Phase 4: Write CLAUDE.md (if the approved proposal includes it, or on the "Review and improve" path) / 阶段 4：编写 CLAUDE.md（若已批准提案包含它，或处于"审查并改进"路径）

Write a minimal CLAUDE.md at the project root. Every line must pass this test: "Would removing this cause Claude to make mistakes?" If no, cut it.

在项目根目录写一份精简的 CLAUDE.md。每一行都必须通过这项检验："删掉这行会导致 Claude 犯错吗？"如果不会，就删掉。

【评论】这条"删除测试"把极简原则具体化为可执行判据：一行内容是否值得常驻每个会话的上下文，取决于它缺席时模型是否会出错。

If the user picked "Review and improve it" in Phase 0: don't write fresh — read the existing file, compare against Phase 2 findings and the Phase 3-lite answer, and propose specific additions/removals as diffs with a one-line reason for each. The existing file is the baseline; your job is to catch what's missing, outdated, or bloated. After printing the diffs, call AskUserQuestion ("Apply these edits?" with options like "Apply all" | "Let me pick which" | "Skip — leave it as is") before writing anything.

如果用户在阶段 0 选了"审查并改进"：不要重写 — 先读现有文件，与阶段 2 的发现和阶段 3-lite 的答案对比，以 diff 形式提出具体的增删建议，每条附一行理由。现有文件是基线；你的任务是找出缺失、过时或臃肿之处。打印 diff 之后、写入任何内容之前，调用 AskUserQuestion（"应用这些修改吗？"，选项如"全部应用" | "我来挑选" | "跳过 — 保持原样"）。

Consume note entries from the Phase 3 preference queue whose target is CLAUDE.md (team-level notes) — add each as a concise line in the most relevant section. These are the behaviors the user wants Claude to follow but didn't need guaranteed (e.g., "propose a plan before implementing", "explain the tradeoffs when refactoring"). Leave personal-targeted notes for Phase 5.

消费阶段 3 偏好队列中目标为 CLAUDE.md 的 note 条目（团队级备注）— 每条以简洁的一行加入最相关的小节。这些是用户希望 Claude 遵循但无需强制保证的行为（如"实现前先提出方案"、"重构时解释权衡"）。面向个人的备注留给阶段 5。

Include:

应包含：

Exclude:

应排除：

Be specific: "Use 2-space indentation in TypeScript" is better than "Format code properly."

要具体："在 TypeScript 中使用 2 空格缩进"比"把代码格式化好"更有用。

Do not repeat yourself and do not make up sections like "Common Development Tasks" or "Tips for Development" — only include information expressly found in files you read.

不要重复自己，也不要编造"常见开发任务"或"开发提示"之类的小节 — 只收录你在所读文件中明确找到的信息。

Prefix the file with:

在文件开头加上：

# CLAUDE.md

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

For projects with multiple concerns, suggest organizing instructions into .claude/rules/ as separate focused files (e.g., code-style.md, testing.md, security.md). These are loaded automatically alongside CLAUDE.md and can be scoped to specific file paths using paths frontmatter.

对于关注点较多的项目，建议把指令组织到 .claude/rules/ 下的多个聚焦文件中（如 code-style.md、testing.md、security.md）。它们会与 CLAUDE.md 一起自动加载，并可用 paths frontmatter 限定到特定文件路径。

For projects with distinct subdirectories (monorepos, multi-module projects, etc.): mention that subdirectory CLAUDE.md files can be added for module-specific instructions (they're loaded automatically when Claude works in those directories). Offer to create them if the user wants.

对于具有独立子目录的项目（monorepo、多模块项目等）：提及可为模块专属指令添加子目录级 CLAUDE.md 文件（当 Claude 在这些目录中工作时它们会自动加载）。如果用户需要，可主动提出创建。

Phase 5: Write CLAUDE.local.md (if the approved proposal includes it) / 阶段 5：编写 CLAUDE.local.md（若已批准提案包含它）

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.

在项目根目录写一份精简的 CLAUDE.local.md。该文件会与 CLAUDE.md 一起自动加载。创建后，把 CLAUDE.local.md 加入项目的 .gitignore，使其保持私密。

Consume note entries from the Phase 3 preference queue whose target is CLAUDE.local.md (personal-level notes) — add each as a concise line. If the user chose personal-only in Phase 1, this is the sole consumer of note entries.

消费阶段 3 偏好队列中目标为 CLAUDE.local.md 的 note 条目（个人级备注）— 每条以简洁的一行加入。如果用户在阶段 1 选择了仅个人文件，这里是 note 条目的唯一消费方。

Include:

应包含：

Keep it short — only include what would make Claude's responses noticeably better for this user.

保持简短 — 只收录能让该用户明显感到 Claude 回复变好的内容。

If Phase 2 found multiple git worktrees and the user confirmed they use sibling/external worktrees (not nested inside the main repo): the upward file walk won't find a single CLAUDE.local.md from all worktrees. Write the actual personal content to ~/.claude/<project-name>-instructions.md and make CLAUDE.local.md a one-line stub that imports it: @~/.claude/<project-name>-instructions.md. The user can copy this one-line stub to each sibling worktree. Never put this import in the project CLAUDE.md. If worktrees are nested inside the main repo (e.g., .claude/worktrees/), no special handling is needed — the main repo's CLAUDE.local.md is found automatically.

如果阶段 2 发现多个 git worktree 且用户确认使用同级/外部 worktree（未嵌套在主仓库内）：向上查找文件无法从所有 worktree 找到同一个 CLAUDE.local.md。请把实际的个人内容写到 ~/.claude/<project-name>-instructions.md，并让 CLAUDE.local.md 成为一个一行式存根来导入它：@~/.claude/<project-name>-instructions.md。用户可把这行存根复制到每个同级 worktree。绝不要把这个导入放进项目 CLAUDE.md。如果 worktree 嵌套在主仓库内（如 .claude/worktrees/），无需特殊处理 — 会自动找到主仓库的 CLAUDE.local.md。

If CLAUDE.local.md already exists: read it, propose specific additions, and do not silently overwrite.

如果 CLAUDE.local.md 已存在：先读取，提出具体的增补建议，不要静默覆盖。

Phase 6: Suggest and create skills (if the approved proposal includes any) / 阶段 6：建议并创建技能（若已批准提案包含）

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

技能为 Claude 增加按需使用的能力，又不会让每个会话膨胀。

First, consume skill entries from the Phase 3 preference queue. Each queued skill preference becomes a SKILL.md tailored to what the user described. For each:

首先，消费阶段 3 偏好队列中的 skill 条目。 每条队列中的技能偏好都会成为一个按用户描述定制的 SKILL.md。对每一条：

Then suggest additional skills beyond the queue when you find:

然后在队列之外建议额外技能，当你发现：

For each suggested skill, provide: name, one-line purpose, and why it fits this repo.

对每个建议的技能，给出：名称、一行用途，以及它为何适合本仓库。

If .claude/skills/ already exists with skills, review them first. Do not overwrite existing skills — only propose new ones that complement what is already there.

如果 .claude/skills/ 已存在技能，先审查它们。不要覆盖既有技能 — 只建议与现有内容互补的新技能。

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

每个技能创建在 .claude/skills/<skill-name>/SKILL.md：

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

<Instructions for Claude>

Both the user (/<skill-name>) and Claude can invoke skills by default. For workflows with side effects (e.g., /deploy, /fix-issue 123), add disable-model-invocation: true so only the user can trigger it, and use $ARGUMENTS to accept input.

默认情况下，用户（/<skill-name>）和 Claude 都可以调用技能。对有副作用的工作流（如 /deploy、/fix-issue 123），加 disable-model-invocation: true 使其只能由用户触发，并用 $ARGUMENTS 接受输入。

【评论】"有副作用的技能禁止模型自主调用"是权限收窄设计：把部署等不可逆操作的触发权保留给人类用户。

Phase 7: Suggest additional optimizations / 阶段 7：建议更多优化

Tell the user you're going to suggest a few additional optimizations now that CLAUDE.md and skills (if chosen) are in place.

告诉用户：既然 CLAUDE.md 和技能（如已选择）已就绪，接下来会再建议几项额外优化。

Check the environment and ask about each gap you find (use AskUserQuestion):

检查环境，对发现的每个缺口进行询问（使用 AskUserQuestion）：

Act on each "yes" before moving on.

每得到一个"是"，先落实再继续。

Phase 8: Summary and next steps / 阶段 8：总结与后续步骤

Recap what was set up — which files were written and the key points included in each. Remind the user these files are a starting point: they should review and tweak them, and can run /init again anytime to re-scan.

概述设置了什么 — 写入了哪些文件、每个文件包含哪些要点。提醒用户这些文件只是起点：应自行审阅和调整，并可随时再次运行 /init 重新扫描。

Then tell the user that you'll be introducing a few more suggestions for optimizing their codebase and Claude Code setup based on what you found. Present these as a single, well-formatted to-do list where every item is relevant to this repo. Put the most impactful items first.

然后告诉用户：基于本次发现，还会给出几条优化代码库和 Claude Code 配置的补充建议。以单一、格式良好的待办列表呈现，且每条都与本仓库相关。影响最大的条目放前面。

When building the list, work through these checks and include only what applies:

构建列表时，逐项核对这些检查，只收录适用的：

【评论】"不要自行读取外部代理配置，改由确定性导入命令处理"体现了对竞品配置文件的隔离处理：把敏感的迁移操作限制在带安全校验的受控路径中。