القائمة
用作 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，导致设计后没有实现、验证或收尾判断