将Claude Code转换为Gutenberg FSE主题
目标
将已批准的Claude Code项目转换为一个原生、可维护的WordPress站点。保留已商定的设计、内容与行为，不将前端原型架构带入WordPress已能通过块提供可编辑方案的场景。
将源项目视为视觉与功能规范。仅在被授权的LocalWP站点上工作。未经明确批准，不得修改生产环境、删除内容、Site Editor的定制化或本地数据。
收集最小上下文
在编辑前确认或发现以下信息：
- 在Claude Code中导出或精炼的项目路径；
- LocalWP站点路径及目标主题路径；
- 构成已批准设计的确切commit、构建或状态；
- 包含的页面、断点、状态与交互；
- 本地站点实际使用的WordPress和PHP版本；
- 目标是1:1对等、经批准的优化还是重新设计；
- 必须从WordPress中可编辑的内容与集成；
- 插件、自定义块、字体和资产许可的限制。
如果缺失任何会改变内容、架构、功能或设计的决策，则暂停并请求该决策。如果缺失可从文件系统、前端或本地站点上获取的数据，则进行检查并记录假设。
加载可复用的基础
根据阶段应用已安装的官方技能：
wp-project-triage：对WordPress项目及其工具链进行分类；wp-block-themes：实现theme.json、模板、部件、模式和FSE样式；wp-block-development：仅当交互需要自定义块时使用；wp-wpcli-and-ops：使用WP-CLI检查或更改内容与选项；unlazy（若已安装）：用于规模较大迁移的关闭纪律（超过一个页面，或任何将报告为完成而无持续监督的工作）。详见下方“以门控纪律关闭每个单元”。
首先确认目标版本。如果官方技能指向的WordPress版本高于LocalWP上的版本，则仅使用兼容的API并查阅官方文档以解决差异。
在适当的时候阅读自有资源：
- source-contract.md：在冻结基线并定义迁移合同之前；
- migration-manifest.md：在捕获基线或实施任何具有视觉影响的更改之前；
- translation-map.md：在决定Gutenberg架构之前，以及在翻译每个组件期间；
- localwp.md：在接触站点或其数据库之前；
- qa-checklist.md：在第一个可见部分之前，以及在宣布工作完成之前再次使用；
- upstream.md：在更新、审计或重新分发复用的基础时；
- templates/gates-fse-migration.md：当为某个页面或部分打开
$unlazy时，作为初始账本进行复制和填写，而非从头编写门控。
执行流程
- 阅读两个项目中的本地指令、Git状态和直接相关的文档。
- 执行
scripts/audit_source.mjs <源路径>并手动审查其发现。不将启发式报告视为架构决策。 - 创建迁移清单，索引所有预期的组合，并执行
scripts/validate_migration_manifest.mjs <清单路径>。 - 在干净环境中启动源前端，并在桌面端、平板端和移动端捕获基线，包括相关的交互状态。
- 创建迁移合同：页面、部分、文案、资产、令牌、交互、数据源、集成和验收标准。
- 将可复用的令牌与局部几何形状分离。将前者映射到
theme.json，并通过块、布局和最少的语义类保留后者。 - 设计FSE架构：模板、模板部件、模式、页面内容，以及仅在必要时才使用的自定义块或插件。
- 先实施一个有代表性的部分。在将该模式扩展到站点其余部分之前，比较前端与Site Editor。
- 逐页、逐节迁移。在整个实施过程中保持源项目可见作为参考。如果
$unlazy可用，通过将 templates/gates-fse-migration.md 复制到该页面或部分自身的GATES.md来打开一个单元（在实施之前，而非之后）。 - 通过项目文档的流程在LocalWP上安装或激活主题。以幂等方式创建或更新内容，并保留现有内容。
- 执行
scripts/validate_fse_theme.mjs <主题路径>并修正所有错误。审查适用的警告。 - 在前端和Site Editor上完成视觉、结构、编辑、响应式、可访问性和性能的QA。
- 通过
capture_visual_evidence.mjs、compare_visual_evidence.mjs和verify_visual_evidence.mjs执行捕获、比较和门控；手动并排和叠加审查。对于每个至少有一个全出血部分的页面，还需执行scripts/verify_editor_frontend_parity.mjs（需要一个由scripts/wp_auth_cookies.php生成的真实会话cookie，见 translation-map.md），并要求PARIDAD_EDITOR_FRONTEND_OK：仅凭人类视觉对比不足以发现此类bug，该项目中已有两次记录。如果该单元有GATES.md，则运行node <unlazy技能目录>/scripts/gate-check.mjs --reverify GATES.md并要求ALL MET才能继续。 - 交付证据、限制、回滚步骤和下一个工作单元。如果使用了
$unlazy，则包括已通过、未通过和废弃的门控的合格ID；不能将存在待处理或废弃门控的单元描述为完成。
以门控纪律关闭每个单元（$unlazy）
当安装了unlazy时，将其视为本技能的关闭纪律层，而非替代方案：本技能决定在FSE迁移中需要验证什么；unlazy强制要求在工作之前将这些标准声明为可执行命令，并在报告完成之前使用真实证据重新验证，而非依赖“看起来不错”的视觉判断。
- 对某个页面或部分使用
unlazy的单独模式（每个单元一个GATES.md，从 templates/gates-fse-migration.md 复制）。仅在站点完整且拥有许多独立页面时使用编排模式，其中每个页面是深度树的一个叶子，具有自己的OWNS:（自己的模板/模式文件），并且一个集成分支验证跨页面导航、共享的header/footer以及页面间无回归。 - 不要将每个琐碎的修正都转换为门控账本。将纪律保留给一个页面、整个站点的迁移，或任何因静默不完整而代价高昂的单元（参见实际案例：模板中硬编码的内容导致页面在数个工作单元中保持空白且不可编辑，直到站点所有者手动发现）。
- 将实际内容门控（
post_content非空）调整为项目中真实的WP-CLI调用；在LocalWP上几乎不会是全局的wp二进制文件（见 localwp.md）。 - 手动门控对于任何命令难以良好衡量的内容（视觉感知保真度、文案编辑审查）仍然有效。不要仅仅为了避免手动门控而强制使用自动指标；本技能的合同已经禁止将感知指标作为对等的自动批准。
- 未经用户明确请求，不要安装
unlazy的可选Stop hook；本技能本身要求如此。 - 根据适用的模型级别分配工作，无论是在
unlazy的编排模式中还是在本技能的逐页迁移中：一个机械且边界明确的任务（直接翻译已在另一页面解决的组件、类调整、已诊断的定点修复）交给较轻量的模型；一个需要架构判断、决定块vs.模式vs. CPT、或任何视觉验证的任务，则保留在会话的模型中。不要为每项小编辑都分配一个完整agent，而应将它们组合成一次通过，以更少的协调达到相同结果。
维护不可协商的合同
- 优先使用核心块、主题模式和WordPress公共API。
- 不要使用
core/html作为捷径来保留原型的HTML。 - 使用
theme.json作为共享令牌的真实来源。 - 将模板和部件用于全局结构；使用页面内容或模式进行编辑性组合。
- 除非有经证实和批准的需求，否则不要在WordPress前端中引入React、Tailwind或原型运行时。
- 仅当核心块无法以可维护的方式表达所需行为或编辑时，才创建自定义块。
- 将业务逻辑、预订、订单和数据模型放在插件中，而非主题中。
- 本地提供字体和图像，并保留许可、来源和替代文本。
- 保持前端和Site Editor作为强制性的表面。
- 未经验证的有效清单和完整矩阵，不得实施视觉迁移。
- 不要将感知指标转换为自动对等批准。
- 不要依赖数据库中偶然保存的全局样式。
- 尊重
prefers-reduced-motion、键盘、可见焦点和WCAG 2.1 AA。 - 不要为了填补设计空白而发明内容、路径或功能。
应用餐厅演示标准
- 使用块和模式建模一个纯编辑性的小型菜单。
- 仅当菜单需要结构化编辑、筛选、复用或实际增长时，才提议使用像
vicu_menu_item这样的CPT；在插件中注册并测试其行为。 - 将预订、订单、支付、动态时间表和可用性视为独立的功能集成。不要使用静态表单静默模拟它们。
- 通过部件或模式复用header、footer、预订呼吁和联系模块，并与已批准的架构同步。
以可验证的单元工作
仅当以下条件满足时，才关闭一个页面或部分：
- 内容、链接和资产与合同匹配；
- 标记有效且其块保持可编辑；
- 前端和编辑器正确呈现样式；
- 桌面端、平板端和移动端已与基线比较；
- 适用的hover、focus、active、loading和error状态已测试；
- 没有控制台错误、意外的远程资源或对Claude Code开发服务器的依赖；
- 证据对应确切的已测试状态；
- 该组合在清单中具有唯一行，且不保持
pending状态。
交付可验证的状态
报告：
- 已完成的页面和部分；
- 受影响的架构和文件；
- 核心块、模式、自定义块或插件的决策；
- 已执行的命令和检查及其结果；
- 用于比较的URL和视口；
- 接受的差异、残余风险和回滚方案；
- 已验证的清单路径及其证据矩阵摘要。
不要因为站点渲染或HTML包含相同文案就断言视觉对等。对等需要视觉比较和可编辑性验证。
调用示例
使用 $transform-claude-to-gutenberg 审计这个Claude Code项目，并为首页到指定LocalWP站点创建迁移合同。
使用 $transform-claude-to-gutenberg 将餐厅演示转换为1:1的FSE块主题，使用核心块和本地资产。
使用 $transform-claude-to-gutenberg 审查已迁移的主题，并列出阻止其被视为可编辑且视觉上等同于已批准原型的问题。