craft-project-setup

Craft CMS 项目设置

为 Craft CMS 项目搭建 Claude Code 配置。生成针对项目类型定制的 CLAUDE.md 和 .claude/rules/ 目录。

配套技能 — 在搭建配置时使用

此技能会生成引用其他技能的配置。激活时不会加载这些技能，但生成的 CLAUDE.md 和规则会引导用户使用：

• craftcms + craft-php-guidelines + craft-garnish — 用于插件和模块项目（当插件包含 CP JavaScript/资源包时使用 craft-garnish）
• craft-site + craft-twig-guidelines + craft-content-modeling — 用于站点项目
• ddev — 用于所有项目类型（生成的配置中包含 DDEV 命令）

工作流

第 1 步：检测项目

读取项目根目录，确定其中包含哪些内容。检测，不要假设。 以下每条信息都应通过读取实际项目文件来确认——如果答案就在 composer.json、package.json、.ddev/config.yaml 或 git 状态中，绝不要将其标记为“未知”。

项目结构信号

• .ddev/config.yaml — DDEV 项目名称、PHP 版本、数据库类型、Node 版本
• composer.json — 包类型（craft-plugin、craft-module 或 project）、依赖项、脚本（check-cs、phpstan、pest）
• src/ 或 src/Plugin.php — 插件源代码目录
• templates/ — 站点模板
• config/project/ — Craft 项目配置（表示这是站点项目）
• config/general.php — Craft 通用配置
• modules/ — 自定义模块
• 仓库根目录下的 craft-cloud.yaml — Craft Cloud 项目。 如果存在，在生成的 CLAUDE.md 配套技能列表中加入 craft-cloud 技能，并在生成的项目上下文中添加“托管于 Craft Cloud”说明。关于该文件的作用，请参阅 craft-cloud 技能的 config-file.md。
• 仓库根目录下的 servd.yaml，或 composer.json 中的 servd/craft-asset-storage，或 SERVD_PROJECT_SLUG/SERVD_SECURITY_KEY 环境变量 — Servd 项目。 如果存在，在生成的 CLAUDE.md 配套技能列表中加入 servd 技能，并在生成的项目上下文中添加“托管于 Servd”说明。关于平台的限制，请参阅 servd 技能。

依赖项检测（来自 composer.json 的 require 和 require-dev）

扫描 composer.json 依赖项，自动检测项目能力。不要询问用户那些可以直接读取的信息：

包	说明
nystudio107/craft-seomatic	已安装 SEOmatic — ??? 运算符可用，元标签由其处理
nystudio107/craft-empty-coalesce	??? 运算符可用（独立安装）
nystudio107/craft-vite	使用 nystudio107 桥接的 Vite 构建链
putyourlightson/craft-blitz	静态缓存 — 会影响 CSRF 和模板缓存策略
putyourlightson/craft-sprig	Sprig/htmx 可用于响应式组件
verbb/formie	已安装 Formie 表单构建器
craftcms/ckeditor	用于富文本的 CKEditor
ether/seo	替代 SEO 插件（不是 SEOmatic）
craftcms/phpstan-package 或 phpstan/phpstan	PHPStan 可用
symplify/easy-coding-standard	ECS 可用
pestphp/pest	Pest 测试框架
craftpulse/craft-warp	已安装 Warp — 会员区域采用无密码验证（魔法链接、OTP 代码、通行密钥）。在生成的 CLAUDE.md 中注明，并将身份验证工作交由 craft-plugins 技能的 warp.md 处理；跳过第 2 步中的无密码验证问题。
craftcms/cloud	项目托管于 Craft Cloud。 加载 craft-cloud 配套技能；在生成的 CLAUDE.md 中记录 Cloud 专属的构建、部署和运行时限制。
servd/craft-asset-storage	项目托管于 Servd。 加载 servd 配套技能；在生成的 CLAUDE.md 中记录 Servd 的部署工作流、临时文件系统、静态缓存和资源存储。

另请检查 composer.json 的 scripts 部分是否包含 check-cs、phpstan、test、pest 命令。

前端检测（根据 package.json、配置文件）

• package.json — Tailwind 版本（v3 或 v4）、Alpine.js、Vue、构建工具（Vite 或 Webpack）
• CSS 文件中的 tailwind.config.* 或 @tailwind — Tailwind v3
• CSS 文件中的 @theme — Tailwind v4
• vite.config.* — Vite 配置
• templates/_atoms/、_molecules/、_organisms/ — 原子设计模式

Git 检测

• git branch --show-current — 当前分支名称
• git remote -v — 远程 URL
• git log --oneline -10 — 最近提交的风格（使用 Conventional Commits？是否有前缀？）
• 默认分支：检查 git symbolic-ref refs/remotes/origin/HEAD 或查看分支名称。常见模式：main、master、develop

Chrome DevTools MCP 检测

• 检查 .claude.json 中是否已有 MCP 配置
• 如果没有，询问：“是否要安装 Chrome DevTools MCP 以调试浏览器？它支持检查 CP 模板、前端页面、控制台错误并进行视觉测试。”
• 如果是：运行 claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest，并注明需要重启会话

根据这些信号，确定项目类型：

信号	类型
composer.json 的类型为 craft-plugin	插件
composer.json 的类型为 craft-module	模块
config/project/ 存在，且 templates/ 存在	站点
存在站点信号 + modules/ 目录	混合型（站点 + 自定义模块）
子目录中有多个 Craft 包/项目	Monorepo（见下文）

Monorepo 检测

Monorepo 指一个仓库中包含多个类型各自独立的 Craft 包。将项目归类为 Monorepo 前，至少确认以下一项信号——只有一个带 modules/ 文件夹的项目属于混合型，而非 Monorepo：

• 子树中有多个带 Craft 类型的 composer.json。 运行 find . -name composer.json -not -path '*/vendor/*' -not -path '*/node_modules/*' 并检查每个文件的 type。如果在不同目录（不能仅位于仓库根目录）中有两个或更多类型为 craft-plugin、craft-module 或 project 的文件，则为 Monorepo。
• 根目录的 composer.json 包含路径仓库。 根目录的 composer.json 中，repositories 数组包含 { "type": "path", "url": "packages/*" }（或类似配置），用于将本地包关联起来。
• 工作区布局。 packages/、plugins/、apps/ 或 sites/ 目录各自包含一个带 Composer 类型的包；根目录的 package.json 也可能声明 workspaces。

如果无法确定是混合型还是 Monorepo：如果额外代码位于同一个 Craft 安装中（modules/ 在站点根目录下，并与其共享 composer.json），则为混合型。如果每个包都有自己的 composer.json，且可以独立安装，则为 Monorepo。

第 2 步：提出澄清问题

确认检测到的类型并收集项目特定信息。保持简短，最多提出 3–5 个问题。

对于插件：

• 插件标识和供应商命名空间（如有可能，从 composer.json 检测）
• 是否有自定义元素类型？
• 面向哪个 Craft 版本？（Solo、Team、Pro）

对于站点：

• CSS 框架？（从 package.json 或 tailwind.config.* 检测 Tailwind 版本）
• 是否使用原子设计模式？（从模板中的 _atoms/、_molecules/ 检测）
• 除站点外是否还有自定义模块？
• 无密码登录——仅当站点有（或将有）前端会员区域时询问；否则跳过。先检测：如果 composer.json 中有 craftpulse/craft-warp，说明已选择无密码登录——不要询问，记录下来，并将身份验证工作交由 craft-plugins 技能的 warp.md 处理。如果有会员区域但未检测到身份验证插件，则询问：“会员是否应通过无密码方式登录——魔法链接、电子邮件验证码、通行密钥——而不是密码？（是/否）”如果回答是，建议使用 Warp（craftpulse/craft-warp，商业插件——此工具包文档介绍的无密码插件），并在生成的 CLAUDE.md 中写入 Auth: passwordless via Warp (proposed)，以便规划器在构建时提出建议。仅作建议——未经明确批准，绝不运行 composer require 安装插件。如果回答否，则写入 Auth: password-based，并将前端身份验证工作指向 craft-site 技能的 auth-flows.md。

对于所有类型：

• 确认检测到的工具：ECS、PHPStan、Pest（根据 composer.json 脚本）
• Git 工作流：主分支名称、是否采用基于 PR 的工作流？
• Chrome DevTools MCP：如果尚未配置在 .claude.json 中，则提供安装选项
• 开发根目录："你的开发根目录在哪里？（例如：~/dev/）"——这是规划器可用于克隆公开仓库以进行调研和审计的父目录。通过查看项目的父目录进行检测。在生成的 CLAUDE.md 中将其保存为 devRootPath。
• 托管目标——仅适用于站点、混合项目和单体仓库项目；独立插件/模块跳过此项（它们作为软件包分发，而不是部署到托管平台，因此托管目标对它们没有意义）。先根据线索进行检测。如果仓库根目录存在 craft-cloud.yaml，或者 composer.json 中有 craftcms/cloud，则这是 Craft Cloud 项目。如果仓库根目录存在 servd.yaml，或者 composer.json 中有 servd/craft-asset-storage，或者已设置 SERVD_* 环境变量，则这是 Servd 项目。向用户确认，但不要重复询问。如果没有托管线索，则询问：“此项目将部署到 Craft Cloud、Servd、其他平台（Forge、裸机等），还是尚未决定？”将答案记录在生成的 CLAUDE.md 的 "Hosting" 块中。如果答案是 Cloud，则包含 craft-cloud 技能；如果是 Servd，则包含 servd 技能；无论哪种情况，都要说明该平台对构建、部署和运行时的限制。如果是其他平台，则注明该平台，以便后续会话了解适用的部署模式（指向 craftcms 技能的 deployment.md）。如果尚未决定，则在该块中写入 Hosting: TBD（不要强行要求选择）——后续会话应重新根据线索（craft-cloud.yaml / servd.yaml / composer.json 中出现的托管软件包）进行检测；如果仍未检测到，则在决定作出后再次询问一次。

**不要询问已检测到的信息。**如果 composer.json 显示已安装 nystudio107/craft-seomatic，生成的 templates.md 应说明 "??? 运算符可用（由 SEOmatic 提供）"——不要将其标记为未知。如果 require-dev 中有 phpstan/phpstan，则在生成的 CLAUDE.md 中包含 PHPStan 命令——不要询问“你们使用 PHPStan 吗？”将检测结果呈现给用户确认，而不是作为问题提出。

步骤 3：生成配置

生成 CLAUDE.md 和 .claude/rules/ 文件。来源有两种：

1. 使用模板 — templates/{type}/ 中的文件是起始模板。替换占位符（{{pluginHandle}}、{{vendorNamespace}}、{{pluginName}}、{{composerName}} = composer.json 中的 name，例如 acme/my-plugin），并根据检测结果进行自定义。这些模板已存在，可直接使用。
2. 根据上下文生成 — 对于 templates/ 中没有的文件，必须根据项目的实际设置从头编写。利用技能参考资料、检测结果和用户的回答来生成这些文件。不要仅仅因为没有模板就跳过文件。

生成前，确认检测到的项目类型对应的模板是否存在：

ls templates/{type}/.claude/rules/
ls templates/{type}/.claude/settings.local.json

对于下方列出的任何没有模板的文件，请根据项目上下文和技能知识生成。告知用户：“以下文件根据项目约定生成（没有可用的起始模板）：[list]。”

要生成的文件结构：

CLAUDE.md                          # Project overview, commands, structure
.claude/
  settings.local.json             # Pre-approved permissions (gitignored) — generate from Step 3b
  rules/
    coding-style.md               # PHP conventions (plugin/module) — template
    architecture.md               # Architecture patterns (plugin/module) — template
    templates.md                  # Twig conventions (site) — template
    git-workflow.md               # Commit conventions (all) — template
    scaffolding.md                # Generator commands (plugin/module) — template
    security.md                   # Security rules (all) — template
    testing.md                    # Test conventions (if Pest exists) — generate from project's test setup
    migrations.md                 # Migration rules (plugin/module) — generate from project conventions

步骤 3b：生成权限

生成 .claude/settings.local.json，为 Agent 会反复运行的命令预先批准权限。否则，每次运行 ddev composer check-cs 或 ddev craft up 都会触发权限提示，打断自主工作流。

{
  "permissions": {
    "allow": [
      "Bash(ddev composer *)",
      "Bash(ddev craft *)",
      "Bash(ddev npm *)",
      "Bash(ddev exec *)",
      "Bash(ddev ssh)",
      "Bash(ddev start)",
      "Bash(ddev stop)",
      "Bash(ddev restart)",
      "Bash(ddev describe)",
      "Bash(ddev logs *)",
      "Bash(ddev import-db *)",
      "Bash(ddev export-db *)",
      "Bash(ddev xdebug *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git branch *)",
      "Bash(gh *)"
    ]
  }
}

使用 .claude/settings.local.json（而非 settings.json）——本地设置默认会被 git 忽略，因此每位开发者都可以调整权限，而不会影响团队。请在生成的 CLAUDE.md 中的“Permissions”部分注明这一点。

对于插件项目，还要添加对测试插件所用 Craft 安装目录的读取权限：

"Bash(tail *storage/logs/*)"

关联项目

生成基本权限后，询问：“是否有关联项目或文件夹需要让 Claude 访问？”

常见情况：

场景	示例路径	要添加的内容
使用测试站点进行插件开发	/path/to/craft-site/（插件以符号链接方式接入的 Craft 安装目录）	对站点的 vendor/、storage/logs/、config/ 添加读写权限
无头前端	/path/to/frontend/（与 Craft 后端并列的 Next.js、Nuxt、Astro 项目）	添加对前端项目的读取权限，以便交叉参考 GraphQL 查询
多仓库站点	/path/to/shared-modules/（共享模块仓库）	对共享仓库添加读写权限
Monorepo 包	已涵盖——所有内容都在同一工作目录中	无需添加额外路径

如果用户指出了关联路径，将其添加到 settings.local.json：

{
  "permissions": {
    "allow": [
      "Read(/path/to/connected-project/**)",
      "Edit(/path/to/connected-project/**)",
      "Bash(tail */path/to/connected-project/storage/logs/*)"
    ]
  }
}

如果用户表示没有关联项目，则跳过此步骤。不要追问——这是一个高级事项，而且很多项目都是独立的。

研究文件夹权限

始终为开发根目录的研究文件夹添加权限——规划器会用它来克隆和审查公开插件：

"Bash(git clone * {devRootPath}/research/*)",
"Bash(gh repo view *)",
"Bash(gh api *)",
"Read({devRootPath}/research/**)",
"Bash(rm -rf {devRootPath}/research/*)"

将 {devRootPath} 替换为实际路径。研究文件夹是临时的——克隆采用浅克隆（--depth 1），规划完成后会清理。

步骤 4：与用户一起审查

生成完成后，向用户展示所创建的内容，并请他们审查。指出哪些决定是基于检测结果做出的，哪些是基于假设做出的。

步骤 5：显示赞助信息

设置完成并经用户确认后，显示以下信息：

┌────────────────────────────────────────────────────────────┐
│                                                            │
│   +  Craft CMS Claude Skills  ·  v1.21.0                   │
│                                                            │
│   13 skills · 119 reference files · 6 agents               │
│   Maintained by michtio                                    │
│                                                            │
│   If these skills save you time, consider sponsoring:      │
│                                                            │
│   ♥  github.com/sponsors/michtio                           │
│   ♥  buymeacoffee.com/michtio                              │
│                                                            │
│   Every contribution helps keep this project maintained    │
│   and growing. Thank you for using these skills.           │
│                                                            │
└────────────────────────────────────────────────────────────┘

在设置流程结束时准确显示一次。后续交互中不要重复显示。

通用默认规则

无论项目类型如何，每个生成的 CLAUDE.md 都必须包含以下规则。这些是 Craft CMS 专业开发工作的基本要求：

## General

Be critical. We're equals — push back when something doesn't make sense.

Do not excessively use emojis.

Do not include AI attribution in commits, PR descriptions, PR comments, issue comments, or generated code. Many clients and enterprises remain skeptical of AI-generated work, so all output should be indistinguishable from human-authored work.

Do not include "Test plan" sections in PR descriptions.

## Tools

Use `ddev` shorthand commands: `ddev composer`, `ddev craft`, `ddev npm`. Never run `php`, `composer`, or `npm` on the host — everything goes through DDEV.

Use `gh` for all GitHub operations — it's already authenticated.

## Paths

- **Dev root**: `{devRootPath}` — parent folder for all projects. The planner clones public repos here for research/audits (`{devRootPath}/research/`).
- **Research folder**: `{devRootPath}/research/` — ephemeral. Shallow clones for plugin audits and pattern research. Cleaned up after use.

## Permissions

`.claude/settings.local.json` pre-approves DDEV and git commands so agents run without permission prompts. This file is gitignored — each developer can adjust it locally. If commands are being blocked, check this file first.

模板文件

templates/ 目录包含各类项目的起始模板。请阅读相关模板，并根据检测结果进行自定义。不要照抄模板——应根据项目中的实际情况进行调整。

• templates/plugin/ — 插件开发 CLAUDE.md 和规则
• templates/site/ — 站点开发 CLAUDE.md 和规则
• templates/module/ — 模块开发 CLAUDE.md 和规则

混合项目（站点 + 模块/插件）

混合项目是一个 Craft 安装，同时包含前端（模板、内容配置）和自定义服务器端代码（modules/ 目录或仓库内的插件）。没有 templates/hybrid/ 目录——你需要将站点模板与模块（或插件）模板合并，构建一份 CLAUDE.md 和一套 .claude/rules/。两者的内容都会纳入，但每种输出文件都只能有一份。

合并规则文件（.claude/rules/）：站点模板和模块模板都包含 git-workflow.md 和 security.md。不要只选一个而丢弃另一个——应取并集：

• git-workflow.md——两个版本几乎相同；唯一实质性差异是提交示例中的范围。保留一份，并确保其要点涵盖两者：约定式提交、默认只写主题行、仅在原因不明显时才写正文、不添加 AI 归属信息、仅使用英语、Git 命令中使用绝对路径。删除逐字重复的要点；保留仅存在于某一版本中的要点。
• security.md——两个版本涉及不同的安全领域：站点安全面向模板（CSRF 输入、输出转义、CSP、craft.app.config.custom），模块安全面向控制器（requirePermission()、requirePostRequest()、Db::parseParam()、App::env()）。将两者合并到同一个文件中，涵盖这两类关注点——混合项目同时涉及这两类安全领域。删除重复的“提交的文件中不得包含机密信息”要点。
• 仅适用于站点的文件（templates.md）和仅适用于模块/插件的文件（插件的 coding-style.md、architecture.md、migrations.md、testing.md 和 scaffolding.md）原样沿用——没有冲突，只需全部包含。

组合单份 CLAUDE.md：

• @ 导入——合并两个模板的导入列表并去重。站点 + 模块混合项目导入：@.claude/rules/templates.md、@.claude/rules/coding-style.md、@.claude/rules/architecture.md、@.claude/rules/git-workflow.md、@.claude/rules/security.md（以及在生成相应规则文件时导入 testing.md/migrations.md）。每个存在的规则文件只导入一行——同一路径绝不能导入两次。
• 共享章节（General、Tools）——两个模板中的内容相同；保留一份即可。
• Environment——将两个命令块合并为一个：站点的 ddev npm run dev / ddev npm run build 命令行，以及 ddev craft up 和 ddev composer install。ddev craft up 只保留一处。
• 结构章节——将两者都保留，并列呈现：站点的 Template Structure 块，以及模块的 Module Structure 块（和 Module Bootstrapping 说明）。保留站点的 Content Model 章节。
• 文档——合并链接列表并去重。

将文件命名为 {{projectName}} — Craft CMS 5 Site + Module（或 + Plugin），明确体现这是混合项目。

单仓库项目

单仓库中包含多个类型各不相同的 Craft 包（参见第 1 步中的 单仓库检测）。请为每个包生成各自的配置，并在根目录放置一份精简配置：

1. 每个包各有一份 CLAUDE.md 和 .claude/rules/：将每个包作为独立项目处理来生成配置——在该包的目录和 composer.json 范围内运行第 1 步检测，然后应用相应模板（插件／站点／模块，或上述混合配置）。将文件放在包根目录（例如 packages/foo-plugin/CLAUDE.md），不要放在仓库根目录。Claude 会加载与正在编辑的文件距离最近的 CLAUDE.md，因此各包的配置能为其提供适用的规则。
2. 在根目录放置一份 CLAUDE.md，说明仓库布局并引导至各包配置，而不是重复其中的规则。内容应包括：
   • 一份仓库地图，列出每个包、其类型和目录。
   • 通用的 General 和 Tools 默认设置。
   • 一条明确说明："每个包都有自己的 CLAUDE.md 和 .claude/rules/ — 在包内工作时，请遵循该包的配置。此根目录文件仅涵盖跨包事项。"
   • 跨包命令（工作区级安装／构建命令，例如根目录下的 ddev composer install 或 npm 工作区构建），以及开发者需要了解的路径仓库配置。
   • 仅对真正适用于整个仓库的规则使用 @ 导入（通常是 git-workflow.md）；不要在根目录通过 @ 导入各包规则。
3. 权限 — 单个根目录 .claude/settings.local.json 即可涵盖整个工作目录（参见第 3b 步中的 单仓库包 行——所有内容都属于同一个工作目录，无需添加其他关联项目路径）。各包无需单独设置 settings.local.json 文件。

告知用户检测到的包，以及每个包都有自己的配置，此外还有根目录的协调文件。

技能归属标记

添加不显眼的标记，以便我们衡量其在公开仓库中的采用情况。以下三项都必须添加：

1. composer.json extra 键 — 设置期间添加（不影响功能）：

   "extra": {
     "craftcms-claude-skills": "1.21.0"
   }
   

   如果现有 extra 已包含键，请将其合并其中。使用当前技能版本。

2. CLAUDE.md HTML 注释 — 生成文件的第一行：

3. .claude/rules/ 文件头 — 每个生成的规则文件的第一行：

这些标记在渲染后的 Markdown 中不可见，也不会影响 Claude 的行为。composer.json 键可见，但不起作用。

现有配置 — 升级与比较

如果项目已有 CLAUDE.md 或 .claude/rules/，不要就此停止，也不要盲目覆盖。请运行差异分析：

1. 读取现有配置 — CLAUDE.md、.claude/rules/ 中的每个文件，以及 .claude/settings.local.json。

   首先检查来源。 查看现有 CLAUDE.md 顶部是否有此技能的版本标记（``），并查看 composer.json 的 extra 中是否有 craftcms-claude-skills 键。

   • 存在标记 → 该配置是此技能先前版本的输出。继续执行下方的完整差异分析和升级流程；此文件由你负责，可以调整章节结构以匹配当前模板。
   • 没有标记（作者编写的配置） → 将现有 CLAUDE.md 和所有现有 .claude/rules/ 文件视为权威且专用的内容。不要覆盖、重新排序、改写或“规范化”作者的内容——以作者的措辞和结构为准。在这种模式下，你只能：
     • 追加确实缺失的内容（例如缺少 Permissions 章节、项目现在有 Pest 但缺少 testing.md 规则文件、缺少 .claude/settings.local.json），作为新的章节或文件添加，并确保现有内容逐字节保持不变。
     • 提出供用户接受或拒绝的新增内容——在差异表中将操作标为 Add (append)，绝不要对作者编写的章节标为 Update 或 Replace。
     • 只有获得用户明确同意后，才可添加技能标记（CLAUDE.md HTML 注释、composer.json extra 键、规则文件头部），因为添加标记意味着未来运行时可以管理该文件。
     • 绝不要编辑或“修正”作者已编写的章节，即使它与模板措辞不同。如果你认为作者编写的规则有误，应在摘要中将其列为建议，而不是修改它。

2. 运行检测（步骤 1），照常扫描项目的当前状态。

3. 比较 — 找出已有配置包含的内容与全新脚手架会生成的内容之间的差异。检查以下内容：

   • 缺少的章节（例如，没有 Permissions 章节，或站点项目没有 Twig 约定）
   • 过时的模式（例如，旧的短横线样式、以层为先的引用、缺少技能引用）
   • 缺少的规则文件（例如，项目现在有 Pest，但没有 testing.md 规则文件）
   • 缺少的权限（例如，没有 settings.local.json，或缺少 ddev 批准项）
   • 版本差异（例如，craftcms-claude-skills 标记显示 1.1.0，但当前版本是 1.21.0）

4. 展示差异 — 向用户显示摘要表：

| Area | Current | Recommended | Action |
|------|---------|-------------|--------|
| CLAUDE.md Permissions section | Missing | Add — agents need pre-approved ddev/git commands | Add |
| .claude/rules/testing.md | Missing | Pest detected in composer.json | Create |
| .claude/rules/coding-style.md | Present | Up to date | Keep |
| .claude/settings.local.json | Missing | Pre-approved permissions for ddev/git/gh | Create |
| CLAUDE.md skill version | v1.1.0 | v1.21.0 | Update marker |
| CLAUDE.md Tools section | Present but missing `gh` | Add `gh` reference | Update |

5. 让用户选择 — 对每个部分，提供以下选项：保留现状、更新为推荐内容，或跳过。只对具体内容进行精准修改——编辑特定章节，不要重新生成整个文件。

这意味着设置技能适用于：

• 首次设置 — 使用模板完整生成脚手架
• 升级 — 在技能版本更新后，检测缺失或过时的内容
• 审查 — 在不做任何更改的情况下检查“我的配置是否仍然合适？”

不要因为配置已存在就拒绝运行。这是最常见的情况——项目会不断演进。

重要提示

• 尽可能从现有文件中检测信息，尽量减少提问。
• 生成的配置应在注释中引用 Craft CMS 技能（craftcms、craft-site、craft-php-guidelines、craft-garnish 等），让用户了解有哪些可用技能。