@jennie-shawn/starwork 0.1.0-alpha.2 → 0.1.0-alpha.21

package/packs/pack-structure-spec.md

@@ -100,8 +100,8 @@ content-creator/
   },
   "flow": ["account_profile", "ideas", "materials", "drafts", "published", "review"],
   "rules": [
-    { "id": "overview", "slot": "pack.overview" },
-    { "id": "workflow", "slot": "pack.workflow" }
+    { "id": "overview", "slot": "pack.content-creator.overview" },
+    { "id": "workflow", "slot": "pack.content-creator.workflow" }
   ],
   "templates": [
     { "id": "content-brief" },
@@ -146,7 +146,7 @@ content-creator/
     "business_work_area": "草稿与脚本/"
   },
   "rules": [
-    { "slot": "pack.overview", "from": "rules/zh/overview.md" }
+    { "slot": "pack.content-creator.overview", "from": "rules/zh/overview.md" }
   ],
   "templates": [
     { "id": "content-brief", "from": "templates/zh/content-brief.md", "description": "单篇内容大纲模板" }
@@ -186,7 +186,7 @@ CLI 安装 Pack 时，应按以下顺序执行：
 4. 合并得到本次安装用的 Pack 配置。
 5. 校验 Core 版本、工作区类型和 capabilities。
 6. 用语言层 `paths` 创建场景目录。
-7. 用语言层 `rules` 渲染 Markdown 片段，并注入 Agent 入口文件。
+7. 用语言层 `rules` 渲染 Markdown 片段，并注入 Agent 入口文件；规则槽必须使用 `pack.<pack-id>.<rule-id>`，避免不同 Pack 互相覆盖。
 8. 用语言层 `seed` 生成占位文件写入计划。
 9. 用语言层 `templates` 登记或复制业务模板。
 10. 展示预览。

package/skills/README.md

@@ -1,17 +1,42 @@
 # StarWork Skills
 
-这里存放 StarWork 自研 Agent skill。
+这里存放会通过 `npx skills add jennie-shawn/StarWork` 安装到 Agent 全局环境的 StarWork 系统级 skill。
+
+Kit 自带 skill 不放在这里，避免被全局安装命令误识别；它们存放在 `product/kit-skills/`，由 `starwork init` 按工作区类型写入具体工作台。
+
+能力开启后才需要的项目内业务 skill 也不放在这里。例如知识库能力的 `starworkKnowledgeProject` 存放在 `product/core/capabilities/knowledge/skills/`，由 `starwork knowledge init` 写入当前项目。
 
 Skill 的职责不是替代 CLI，而是帮助 Agent 更可靠地理解用户意图、生成配置、组织规则和调用 StarWork 工具。
 
+Skill 的安装、项目中心管理、Pack 推荐和项目分发规则见 `product/core/skill-management-spec.md`。一句话边界：Skill 负责判断和生成方案，CLI 负责执行和校验。
+
+## 四层 Skill 层级
+
+| 层级 | 位置 | 是否全局安装 | 作用 |
+|---|---|---:|---|
+| L0 主入口 | `product/skills/starwork/` | 是 | StarWork 产品解释、安装引导、模糊意图路由 |
+| L1 系统专家 | `product/skills/starworkInit/` 等 | 是 | 初始化、诊断、知识库、多 Agent 等明确能力 |
+| L2 Kit 自带 | `product/kit-skills/` | 否 | 项目中心或项目工作台形态自带能力 |
+| L3 Capability 项目内 | `product/core/capabilities/<capability>/skills/` | 否 | 能力开启后写入具体项目的维护能力 |
+
 ## 路由规则
 
 - 与 Core 协议相关的事实源放在 `product/core/`。
 - 与 CLI 命令相关的规格和实现放在 `product/cli/`。
 - 与 Pack 场景相关的正式包放在 `product/packs/`。
-- 与 Agent 工作流相关、可被复用为 skill 的内容放在 `product/skills/`。
+- 系统级 Agent 工作流 skill 放在 `product/skills/`。
+- Kit 自带 skill 放在 `product/kit-skills/`。
+- Capability 自带的项目内业务 skill 放在 `product/core/capabilities/<capability>/skills/`。
 
 ## 当前 Skills
 
-- `starworkSpawn/`：帮助 Agent 设计 `starwork spawn --blueprint` 工作台定制单。
+- `starwork/`：L0 主入口，负责解释 StarWork、安装引导和把模糊请求路由到合适的专家 Skill。
 - `starworkInit/`：帮助 Agent 设计 `starwork init` 初始化方案和 init blueprint。详细 SPEC 见 `starworkInit-spec.md`。
+- `starworkDoctor/`：帮助 Agent 基于 `starwork doctor --json` 的探测结果，对当前工作区或历史模板做理性诊断；用户明确要求升级时，继续确认目录语义并生成 `starwork upgrade --blueprint` 升级施工图。详细 SPEC 见 `starworkDoctor-spec.md`。
+- `starworkMultiagent/`：帮助 Agent 把“常用智能体 / 当前会话职责 / 多 Agent 分工 / 共享输出 / 跨会话指令 / lane session 编排”翻译成安全的 `starwork multiagent` 命令组合；宿主能力由 CLI 运行时判断。详细 SPEC 见 `starworkMultiagent-spec.md` 和 `product/planning/features/multiagent/specs/v0.4-runtime-host-routing.md`。
+- `starworkKnowledge/`：帮助 Agent 通过 `starwork knowledge` 开启、检查和维护项目本地知识库；负责判断哪些内容值得长期沉淀，区分 `pages/` 和 `synthesis/`，不默认提交项目中心。
+
+Host Adapter v0.2 已进入系统级 Skill：`starwork`、`starworkInit`、`starworkDoctor`、`starworkMultiagent`、`starworkKnowledge` 会引用 `starwork adapt` / `doctor --host` 的宿主准备结果。具体业务命令能否自动执行由 CLI 运行时判断；不支持标准后台投递时，`starworkMultiagent` 解释 CLI 返回的 `manual_handoff_required`、`needs_adapt`、`unbound` 等状态。
+
+`starworkAudit` 是项目中心工作台模板自带 skill，源码在 `product/kit-skills/starworkAudit/`；规格仍保留在 `starworkAudit-spec.md`。
+`starworkKnowledgeProject` 是知识库能力的项目内业务 skill，源码在 `product/core/capabilities/knowledge/skills/starworkKnowledgeProject/`；它不参与全局安装。

package/skills/starwork/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: starwork
+description: 'Primary StarWork entrypoint: explain what StarWork is, guide installation, route fuzzy requests to init, doctor, knowledge, multiagent, or project-center flows.'
+---
+
+# starwork
+
+使用这个 skill 作为 StarWork 的统一入口。它负责产品解释、安装引导、模糊意图判断和能力路由，不复制专家 Skill 的完整流程。
+
+## 第一屏
+
+当用户说“StarWork 是什么”“怎么开始”“帮我用 StarWork”“把这个项目接入 StarWork”但还没有明确专家场景时，先这样回答：
+
+```text
+StarWork 是给 AI 协作准备的项目工作台。
+
+它会把项目说明、当前任务、协作规则、交接记录和健康检查入口放到固定位置，让 AI 每次进入项目时不用从零猜上下文。
+
+我会先判断你现在是哪种情况，再带你走对应流程。整个过程会先预览，不会直接改业务代码，也不会直接覆盖已有 AI 规则文件。
+```
+
+然后只问一个问题：
+
+```text
+你现在是想：
+1. 安装 StarWork；
+2. 创建或接入一个项目工作台；
+3. 诊断一个旧目录；
+4. 开启知识库；
+5. 创建多个 Agent 分工；
+6. 管理项目中心？
+```
+
+如果用户已经表达清楚意图，不要重复问，直接路由。
+
+## 路由
+
+完整路由规则见：
+
+```text
+references/routing.md
+```
+
+常用判断：
+
+- 安装 StarWork、让 AI 会用 StarWork：按 `references/install.md` 引导安装 CLI 和 Skills。
+- 创建、接入、初始化项目工作台或项目中心：进入 `starworkInit`。
+- 诊断旧目录、解释 doctor 结果、设计升级方案：进入 `starworkDoctor`。
+- 开启、检查、维护项目知识库：进入 `starworkKnowledge`。
+- 多 Agent 分工、lane、跨会话消息、Codex 会话控制：进入 `starworkMultiagent`。
+- 从项目中心创建项目：如果当前工作台有项目中心 Kit，使用 `starworkSpawn`；否则先引导用户回到项目中心或创建项目中心。
+- 巡检项目中心：如果当前工作台有项目中心 Kit，使用 `starworkAudit`。
+- 阶段收尾、整理、归档：如果当前工作台有 `neat-freak`，优先使用它。
+
+## 安装
+
+安装最小流程见：
+
+```text
+references/install.md
+```
+
+安装阶段只做 CLI + 全局系统 Skills 安装和验证，不初始化工作台，不创建测试目录。
+
+全局系统 Skills 是：
+
+- `starwork`
+- `starworkInit`
+- `starworkDoctor`
+- `starworkKnowledge`
+- `starworkMultiagent`
+
+Kit 自带 Skill 和 Capability 项目内 Skill 只在对应工作台或能力开启后出现。
+
+## 边界
+
+- 不维护另一套初始化、知识库、诊断或多 Agent 详细流程。
+- 不假设宿主支持自动 Skill-to-Skill 调用；用文本级路由契约说明下一步。
+- 不在用户确认前执行写入命令。
+- 不把 Kit 自带 Skill 当成全局系统 Skill。
+- 不把普通资料整理误判成知识库能力；长期稳定知识才进入 `starworkKnowledge`。

package/skills/starwork/references/install.md

@@ -0,0 +1,64 @@
+# StarWork 安装引导
+
+本文件供 `starwork` 主 Skill 在“安装 StarWork / 让 AI 会用 StarWork”场景引用。
+
+## 安装目标
+
+安装阶段只完成三件事：
+
+1. 确认 Node.js 和 npm 可用。
+2. 安装或更新 StarWork CLI。
+3. 安装或更新 StarWork 主入口和 L1 专家 Skills。
+
+不要在安装阶段初始化工作台、创建测试目录或改动用户项目文件。
+
+## 命令
+
+检查环境：
+
+```bash
+node --version
+npm --version
+```
+
+安装 CLI：
+
+```bash
+npm install -g @jennie-shawn/starwork@latest
+starwork --version
+starwork --help
+```
+
+安装 Skills：
+
+```bash
+npx skills add jennie-shawn/StarWork -g -a codex -y
+```
+
+验证：
+
+```bash
+npx skills ls -g -a codex --json
+```
+
+应能看到这些全局系统 Skills：
+
+- `starwork`
+- `starworkInit`
+- `starworkDoctor`
+- `starworkKnowledge`
+- `starworkMultiagent`
+
+项目中心 Kit、项目工作台 Kit 和 Capability 会在对应工作台或能力开启后写入自己的 Skill，不属于这里的全局清单。
+
+## 汇报话术
+
+```text
+StarWork 已经装好了。
+
+我已经确认两件事：
+1. StarWork 命令可以正常运行。
+2. 当前 AI 工具已经安装好 StarWork 主入口和专家 Skills。
+
+现在你可以直接对我说“帮我用 StarWork”，我会从主入口判断下一步。
+```

package/skills/starwork/references/routing.md

@@ -0,0 +1,44 @@
+# StarWork 主入口路由
+
+本文件是 `starwork` 主 Skill 的路由参考。主 Skill 只判断方向，不复制专家 Skill 的完整流程。
+
+## 层级
+
+| 层级 | 位置 | 作用 |
+|---|---|---|
+| L0 主入口 | `product/skills/starwork/` | 产品解释、安装引导、模糊意图路由 |
+| L1 系统专家 | `product/skills/starworkInit/` 等 | 明确能力的专家流程 |
+| L2 Kit 自带 | `product/kit-skills/` | 跟项目中心或项目工作台形态绑定 |
+| L3 Capability 项目内 | `product/core/capabilities/*/skills/` | 能力开启后写入具体项目 |
+
+## 路由矩阵
+
+| 用户意图 | 主入口动作 | 专家或项目内能力 |
+|---|---|---|
+| StarWork 是什么、能做什么、怎么开始 | 解释产品并问下一步 | `starwork` |
+| 安装 StarWork、让 AI 会用 StarWork | 引导安装 CLI 和全局系统 Skills | `starwork` |
+| 创建工作台、接入当前项目、初始化项目 | 路由到初始化流程 | `starworkInit` |
+| 诊断旧目录、doctor 结果怎么看、旧模板升级 | 路由到诊断和升级方案流程 | `starworkDoctor` |
+| 开启知识库、维护项目知识库、长期知识沉淀 | 路由到知识库流程 | `starworkKnowledge` |
+| 多 Agent、Agent Lanes、lane、跨会话消息、开发 Agent | 直接使用多 Agent 专家流程 | `starworkMultiagent` |
+| 从项目中心创建项目 | 当前在项目中心时使用项目创建流程 | `starworkSpawn` |
+| 巡检项目中心、修复登记项目 | 当前在项目中心时使用巡检流程 | `starworkAudit` |
+| 收尾、整理、阶段结束 | 当前项目有整理 Skill 时优先使用 | `neat-freak` |
+
+## 模糊意图处理
+
+如果用户只说“帮我用 StarWork”“这个项目怎么接入”“我该用哪个能力”，先给第一屏产品解释，再问一个选择题。
+
+如果用户已经明确说出能力，不要拦在主入口：
+
+- “开启知识库”直接进入 `starworkKnowledge`。
+- “创建多个 Agent / 让开发 Agent 开始做”直接进入 `starworkMultiagent`。
+- “诊断这个旧目录”直接进入 `starworkDoctor`。
+- “初始化当前项目”直接进入 `starworkInit`。
+
+## 冲突处理
+
+- 用户请求普通资料整理或阶段收尾时，不要默认进入知识库；优先判断是否是 `neat-freak` 场景。
+- 用户在普通项目里说“从项目中心创建项目”时，先说明这需要项目中心工作台；不要在普通项目里伪造项目中心能力。
+- 用户在非 StarWork 目录里请求多 Agent、知识库或项目中心能力时，先回到 `starworkInit` 接入工作台。
+- 当前宿主不支持自动切换 Skill 时，主入口可以按专家 Skill 的公开规则继续执行高层确认，但复杂细节仍以专家 Skill 为事实源。

package/skills/starworkAudit-spec.md

@@ -0,0 +1,354 @@
+# `starworkAudit` Skill SPEC
+
+## 状态
+
+- 版本：v0.1 draft
+- 所属模块：StarWork Skills
+- Skill 名称：`starworkAudit`
+- 实现状态：待实现
+- 相关命令：`starwork audit`、`starwork repair`、`starwork doctor`
+- 目标：帮助 Agent 基于 Hub 巡检结果，解释多个 Satellite 的健康状况、判断问题优先级，并在用户确认后生成可 dry-run 的 `repair blueprint`
+
+## 一句话定义
+
+`starworkAudit` 是 Hub 视角的 Satellite 巡检解读与修复蓝图设计 skill。
+
+它不是 `audit` 命令本身，也不是 `repair` 执行器。它负责在 CLI 暴露事实之后做 AI 判断：
+
+```text
+starwork audit --json
+  ↓
+Hub / registry / Satellite / doctor facts
+  ↓
+starworkAudit skill 分析和解释
+  ↓
+用户确认修复范围
+  ↓
+repair-blueprint.json
+  ↓
+starwork repair --blueprint
+```
+
+## 产品边界
+
+| 层 | 负责 | 不负责 |
+|---|---|---|
+| `audit` CLI | 扫描 Hub 和 Satellite，输出事实 JSON | 主观判断、修复建议、写文件 |
+| `starworkAudit` skill | 解释巡检结果、分级、追问、生成 repair blueprint | 直接改文件、替用户做不可逆决定 |
+| `repair` CLI | 校验和执行用户确认过的 repair blueprint | 自行判断业务语义 |
+
+一句话：
+
+> `starworkAudit` 是多项目中枢的“体检报告医生”，不是施工队。
+
+## Skill 触发场景
+
+用户可能这样触发：
+
+- “帮我检查一下这个 Hub 下面的所有卫星项目”
+- “这些 Satellite 健康吗”
+- “Hub registry 里哪些项目有问题”
+- “帮我做一次多项目巡检”
+- “根据 audit 结果帮我生成修复蓝图”
+- “把这些卫星项目的旧跨项目结构整理成新版”
+
+## 输入要求
+
+优先运行：
+
+```bash
+starwork audit --hub <hub-path> --json --inventory-depth all
+```
+
+如果用户已经提供 `audit-result.json`，优先读取该文件。
+
+如果用户没有提供 Hub 路径：
+
+- 当前目录是 Hub：直接使用当前目录。
+- 当前目录不是 Hub：询问 Hub 路径，不要默认扫描用户主目录。
+
+## 对 `audit` 输出的要求
+
+`starworkAudit` 依赖 `starwork.audit.result.v0.1`。
+
+必须读取：
+
+- `hub.path`
+- `hub.ok`
+- `registry`
+- `summary`
+- `projects[]`
+- 每个 project 的 `checks`
+- 每个 project 的 `doctor_ok`
+- 每个 project 的 `sync_ok`
+- 每个 project 的 `legacy_signals`
+
+`audit` JSON 不应包含 next steps 或建议。Skill 自己负责判断。
+
+## 工作流程
+
+### Step 1：确认巡检对象
+
+先判断：
+
+- 这是哪个 Hub？
+- registry 里有多少项目？
+- 这次是全量巡检，还是指定项目巡检？
+- 是否有 archived / paused 项目需要跳过深度判断？
+
+第一屏输出必须先说人话：
+
+```text
+我先把这个 Hub 当作中枢来看。它登记了 8 个项目，其中 7 个可访问，1 个路径失效。现在最需要处理的是路径失效和两个共享资源断链，其余规则更新可以放到第二批。
+```
+
+### Step 2：建立问题分组
+
+按项目和问题类型分组。
+
+问题类型：
+
+| 类型 | 说明 |
+|---|---|
+| `hub-health` | Hub 自身结构问题。 |
+| `registry` | `projects/registry.json` 解析、重复、路径、状态问题。 |
+| `reachability` | Satellite 路径不存在、不可读、不是目录。 |
+| `doctor` | Satellite 自身 doctor fail / warn。 |
+| `sync` | `.core-sync.json`、Hub path、project_id 不一致。 |
+| `shared-resource` | knowledge / identity / lessons / skills 挂载异常。 |
+| `handoff` | `.starwork/handoff/` 缺失或旧路径残留。 |
+| `rules` | `AGENTS.md` 仍使用旧规则或缺少关键规则。 |
+| `maintenance` | 长期未更新、联络队列积压、可读性提醒。 |
+
+### Step 3：判断严重程度
+
+使用四级：
+
+| 等级 | 含义 | 示例 |
+|---|---|---|
+| `blocking` | 阻塞，巡检或项目使用不可靠。 | 路径不存在、不是 StarWork、workspace state 无法解析。 |
+| `high` | 高风险，可能导致 Hub / Satellite 关系错误。 | `.core-sync.json` 指向错误 Hub、project_id 不一致。 |
+| `repairable` | 可通过保守修复补齐。 | 缺 `.starwork/handoff/`、缺 state.json、规则插槽缺失。 |
+| `notice` | 提醒，不急于修。 | 项目长期未更新、队列有积压、输出区为空。 |
+
+不要伪造精确分数。
+
+### Step 4：区分“可自动修”和“需要确认”
+
+可自动修的典型问题：
+
+- 缺 `.starwork/handoff/` 子目录。
+- 缺 `.starwork/handoff/state.json`。
+- `.core-sync.json` 中 Hub path 明显不一致，且用户确认当前 Hub 是唯一中枢。
+- registry 中 path 为旧路径，用户确认项目已移动到当前路径。
+- `AGENTS.md` 缺新版 handoff 规则，可以追加受控插槽。
+
+需要用户确认的问题：
+
+- 项目是否已经归档。
+- registry 中路径失效时，项目真实位置在哪里。
+- 断链资源应重建软链接，还是改为本地副本。
+- 旧 `_系统/跨项目/` 中的内容是否要迁移到 `.starwork/handoff/`。
+- 项目规则是否允许被追加新版 Satellite 规则。
+
+禁止自动处理：
+
+- 删除项目记录。
+- 删除旧跨项目目录。
+- 移动正式成果。
+- 合并 `.incoming/` 候选内容。
+- 修改 identity / lessons 正文。
+
+### Step 5：输出巡检报告
+
+报告结构：
+
+1. 总结：Hub 和项目整体健康状态。
+2. 阻塞问题：需要先解决。
+3. 高风险问题：建议尽快修。
+4. 可批量修复项：适合生成 repair blueprint。
+5. 需要用户确认的问题：最多 3 个。
+6. 下一步：是否生成 repair blueprint。
+
+建议语气：
+
+```text
+这不是“项目坏了”，更像是 Hub 和几个 Satellite 的登记信息有点不同步。先修路径和同步关系，再处理规则升级，会比较稳。
+```
+
+### Step 6：生成 repair blueprint
+
+只有用户明确要求时，才生成：
+
+```text
+repair-blueprint.json
+rules/
+```
+
+repair blueprint 和配套文件是 StarWork 巡检 / 修复过程材料，必须写入 Hub 的机制目录，而不是 Hub 或 Satellite 的业务工作区：
+
+```text
+<hub>/.starwork/audit-runs/<YYYY-MM-DD-or-run-id>/
+├── audit-result.json
+├── repair-blueprint.json
+└── rules/
+```
+
+禁止写入：
+
+- Hub `workspace/`
+- Satellite `workspace/`
+- `输出/`、`outputs/`
+- `知识/`、`knowledge/`
+- `参考资料/`、`references/`
+- 任何项目正式成果目录
+
+默认不要生成 `.mjs`、`.js`、`.sh` 等脚本型中间产物。`starworkAudit` 的标准产物是 JSON blueprint 和 Markdown 规则片段；除非用户明确要求调试 CLI，否则不应创建脚本文件。
+
+生成前最多问 3 个问题，且只问会影响蓝图的问题。
+
+推荐问题：
+
+```text
+路径失效的这个项目，是已经归档，还是移动到了新位置？
+```
+
+```text
+共享知识断链时，你希望重建软链接，还是改成本地副本？
+```
+
+```text
+我可以只在 AGENTS.md 追加新版 Satellite 规则插槽，不覆盖原文，可以吗？
+```
+
+## Repair Blueprint 设计原则
+
+`starworkAudit` 生成的蓝图必须保守：
+
+- 不删除。
+- 不移动用户内容。
+- 不覆盖已有文件。
+- 修改范围只限 Hub registry、StarWork state、`.core-sync.json`、handoff 目录、受控规则插槽和共享资源链接。
+- 每个 action 都要能解释来源和原因。
+
+蓝图 schema 使用：
+
+```json
+{
+  "schema": "starwork.repair_blueprint.v0.1",
+  "generated_by": "starworkAudit"
+}
+```
+
+完整 action 见：
+
+```text
+../cli/repair-spec.md
+```
+
+## 关键判断规则
+
+### Hub 自身有 fail
+
+如果 Hub 自身 doctor fail 或 registry 无法解析：
+
+- 不继续生成跨项目修复蓝图。
+- 先解释 Hub 自身问题。
+- 只允许生成 Hub 层面的最小修复蓝图。
+
+### Satellite 路径失效
+
+如果 registry 路径不存在：
+
+- 不猜路径。
+- 输出该项目为 `blocking`。
+- 询问用户是否已移动、归档或删除。
+- 只有用户确认新路径后，才能生成 `update_hub_registry` action。
+
+### Satellite 不是 StarWork
+
+如果路径存在但不是 StarWork：
+
+- 不使用 `repair`。
+- 解释它可能需要 `doctor -> starworkDoctor -> upgrade`。
+- 不把它写进 repair blueprint。
+
+### 旧跨项目路径
+
+如果发现：
+
+```text
+_系统/跨项目/
+_system/cross-project/
+```
+
+处理方式：
+
+- 作为 legacy local handoff 信号。
+- 不建议删除旧目录。
+- 可建议补齐 `.starwork/handoff/`。
+- 是否迁移旧消息内容必须单独确认。
+
+### 共享资源断链
+
+断链不一定等于错误。
+
+需要区分：
+
+- Hub 资源目录是否存在。
+- Satellite 目标路径是否存在。
+- 目标是软链接、真实目录还是缺失。
+- 项目是否刻意使用本地副本。
+
+只有在“目标是断链”或“目标缺失且用户确认要挂 Hub 资源”时，才生成 `repair_symlink`。
+
+## 输出蓝图后的提示
+
+生成 blueprint 后，建议用户先 dry-run：
+
+```bash
+starwork repair --blueprint repair-blueprint.json --dry-run
+```
+
+用户确认后再执行：
+
+```bash
+starwork repair --blueprint repair-blueprint.json --yes
+```
+
+执行后再巡检：
+
+```bash
+starwork audit --hub <hub-path>
+```
+
+## 参考文件
+
+正式实现时建议新增：
+
+```text
+product/kit-skills/starworkAudit/
+├── SKILL.md
+└── references/
+    ├── response-guide.md
+    ├── issue-taxonomy.md
+    └── repair-blueprint-guide.md
+```
+
+其中：
+
+- `response-guide.md`：巡检报告话术。
+- `issue-taxonomy.md`：问题分类和严重程度。
+- `repair-blueprint-guide.md`：如何从 audit 结果生成 repair blueprint。
+
+## 验收标准
+
+第一版 skill 可验收，至少满足：
+
+1. 能读取 `starwork audit --json`。
+2. 能把多个项目问题按严重程度分组。
+3. 能区分可修复项和必须确认项。
+4. 不把 audit JSON 中的事实直接当最终判断。
+5. 不建议删除或移动用户内容。
+6. 用户明确要求后，能生成符合 `starwork.repair_blueprint.v0.1` 的 blueprint。
+7. 输出中能解释 `audit`、`starworkAudit`、`repair` 三者边界。