菜单
用作 NextClaw 标准开发流程/交付流程的总 owner；当用户要求规范开发流程、实现、修复、重构、方案到实现、验证、提交、收尾、完成工作，或需要阶段化节奏与主动汇报时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when implementing, refactoring, or designing source-level contracts in this repository, especially if a task touches frontend/backend i18n or user-facing copy, frontend base/display components, tool schemas, API/protocol parameters, shared contracts, compatibility paths, fallback-heavy logic, duplicate branches, weak abstractions, unclear file placement, ad-hoc helpers, or patch-style fixes that would turn into garbage code.
Create or update complete NextClaw lightweight apps, deciding whether the user needs a Panel App, a Service App, or a combined Panel + Service App. Use for NextClaw applets, small tools, dashboards, local file tools, AI-assisted UI tools, apps that may combine right-side UI with backend actions, or questions about what NextClaw/Panel apps can do and which app APIs/capabilities they can use.
当用户要求提交、收尾、统一 NPM 发布、GitHub release、changelog、release notes、版本更新说明、产品更新笔记、变更汇总，或担心并行会话导致发布内容靠记忆整理时使用。适用于需要进入用户可见发布说明的 NextClaw workspace 包变更、Changesets 聚合、AI 撰写版本更新笔记、可拉取结构化 release notes JSON，以及 update manifest releaseNotesUrl 闭环。
Use when building, verifying, or releasing NextClaw desktop installers, DMGs, update bundles, update manifests, or one-command desktop beta/stable release automation. Enforces the packaged update public key contract, the required verification commands, and the rule that raw electron-builder output is not enough.
当用户要求“发布 beta”“统一 beta 发版”“发一个新的 NPM beta 版本”“一键 beta release”或希望直接复用 NextClaw 的 beta 发布闭环时使用。适用于 nextclaw 及其相关 workspace 包的 beta 发布，也适用于需要同时闭合 npm registry 与 NPM runtime update channel 的场景。
Use when publishing NextClaw NPM packages or NPM runtime update channels, including beta/stable dist-tags, nextclaw@beta validation, runtime bundle manifests, packaged update public keys, and npm registry closure checks.
| name | nextclaw-delivery-workflow |
| description | 用作 NextClaw 标准开发流程/交付流程的总 owner；当用户要求规范开发流程、实现、修复、重构、方案到实现、验证、提交、收尾、完成工作，或需要阶段化节奏与主动汇报时使用。 |
提供一个统一的开发节奏入口，避免代理记住了很多零散规则，却仍然漏掉跨阶段义务。
AGENTS.md 负责固定的主流程骨架。
本 skill 负责这些主步骤背后的条件细节、skill 路由、阶段门、收尾强制检查与最终主动汇报。
本 skill 统一承接：
它不替代专项 skill，而是编排它们。
按需使用并遵守：
nextclaw-clean-implementationnextclaw-solution-designpredictable-behavior-firstnextclaw-validation-workflowpost-edit-maintainability-guardpost-edit-maintainability-reviewnextclaw-release-notes-automationnextclaw-iteration-log-governancelearning-from-failuresnextclaw-agent-instructions-governanceAGENTS.md 已固定 6 个主步骤。
本 skill 负责这些主步骤背后的条件展开，避免主流程骨架与条件细节分离后漂移。
动手前必须明确：
如果不是新增用户能力，默认目标是：
非测试语义代码净增 <= 0条件联动：
long-chain-debuggingiteration-work-notesgoal-progress-anchorgoal-mode当任务涉及新能力、架构边界、交互结构、目录组织、跨模块 owner、持久化合同、运行链路或用户明确要求“先方案/设计文档”时，进入实现前必须联动 nextclaw-solution-design。
小型局部 bugfix 或纯机械改动可以跳过设计文档，但仍要能说清当前事实、owner 和验证标准。
方案设计只负责设计阶段，不接管完整开发流程；完成设计后必须回到本 skill 继续实现、验证、收尾或明确停止在设计交付。
进入编辑前，必须先过 nextclaw-clean-implementation。
至少要能说清：
进入实质编辑前，先把容易后置失败的事实探测清楚。目标是提前发现约束，而不是等实现后被 tsc、governance、真实 smoke 或 provider 错误倒逼返工。
必须按改动类型做最小前置探测：
module-structure.config.json、相关 tsconfig alias、已有同类文件落点和命名后缀。providers/*.provider.ts，contribution root 的 index.ts 只保 contribution 装配入口。apiBase、wireApi、模型 id 前缀约定；不得打印 key/token。前置探测结果必须直接影响实现方案。如果发现需要先搬文件、加 alias、剥 provider 前缀、重建 dist、或分层验证 raw event，就在实现前纳入计划，而不是等后置失败后补丁式修。
如果任务涉及 fallback、compatibility、环境救援或 just-in-case 逻辑，必须再联动：
predictable-behavior-first如果命名、目录落点、文件角色不清，按场景联动：
file-naming-conventionrole-first-file-organizationcollapsible-feature-root-architecturefile-organization-governance实现时持续遵守：
如果触达 NextClaw 自管理命令语义，还必须同步：
docs/USAGE.mdpackages/nextclaw/resources/USAGE.mdnextclaw-self-manage并说明是否运行了 sync-usage-resource。
改完后使用 nextclaw-validation-workflow。
至少覆盖相关子集：
tsc生成产物固定处理：
pnpm clean:generated，把 packages/nextclaw/ui-dist 等生成产物恢复到 git 状态；这些文件不进入业务提交。如果最真实的验证路径被阻塞，必须说明：
对源码、脚本、测试、运行链路配置改动，还必须继续进入：
post-edit-maintainability-guardpost-edit-maintainability-review这一步对源码、脚本、测试、运行链路配置改动是强制项。
必须主动收集并汇报：
不能等用户追问“代码是不是变多了”才补说。
如果这是非功能改动且排除纯格式化噪音后的 非测试语义代码净增 > 0，任务不能收尾。
对于 bugfix、异常修复、重构、发布闭环，或者任何暴露流程摩擦的任务，最终回复前必须做一个短复盘：
AGENTS.md、已有 skill、新 skill、命令、自动化还是普通文档如果复盘来自重复犯错、用户明确要求从教训中学习，或现有规则没有阻止同类失败，必须联动：
learning-from-failures联动后不能只写一条规则就收尾；必须确认学习闭环是否成立：
AGENTS.mddescription 是否会在下次相似场景自动加载如果是小而明确的机制改进，应该在同一任务里直接落实，而不是只提建议。
如果复盘结论涉及治理系统，必须联动：
nextclaw-agent-instructions-governance提交、收尾或本次改动可能需要进入 NPM/GitHub 用户发布说明时，必须联动：
nextclaw-release-notes-automation只有用户需要感知的产品变更才添加 .changeset；内部治理、测试、docs/logs 或纯工程文档不添加发布说明片段。
收尾阶段必须使用 nextclaw-iteration-log-governance 判断是否需要 docs/logs。
不要因为工作开始了就自动建 log。
但只要代码、测试、脚本、运行链路配置或治理系统发生了实质变化，就要认真判断是更新最近相关迭代，还是新建一个版本更高的迭代目录。
最终回复里，凡是适用的项都要主动覆盖：
tsc 命令不适用只要其中某个适用项被漏报，就不算真正完成收尾。
以下场景默认由本 skill 作为总流程 owner：
以下都视为流程失败：
nextclaw-solution-design 当成完整开发流程 owner，导致设计后没有实现、验证或收尾判断