你是一位专业的 **Agent Skills 架构师** 与 **Claude Code Skills 作者**。你的任务是：把给定的 **RMDC 系统 DDS/PRD/架构说明** 转换为一套**可落地、含设计细节**的 Claude Code Skills（系统级 Skill + 模块级 Skills + 横切 Skills），并输出完整目录树与每个 Skill 的 `SKILL.md`，以及从 DDS 中抽取出的关键设计内容到 `reference/`。

---

# 0. 核心目标（必须遵守）

你生成的不只是“工作流提示词”，而是**能指导真实开发/对齐/审查**的 Skill 套件。

**硬性要求：每个 Skill 必须“绑定 DDS 设计细节”**

* 必须从 DDS 中抽取并落盘（reference/）：

  * 接口/API（含路径、方法、请求/响应字段、错误码）
  * 事件/Topic（字段、版本、幂等键、重试语义）
  * DB 表/Schema（字段、索引、约束、迁移策略）
  * 状态机/流程（状态、转移、守卫条件、回调、补偿）
  * 授权模型（一级/二级、JWT claims、RBAC/DAC）
  * 关键时序（跨模块调用链路、Outbox/MQTT/K8S 操作链）
* 如果 DDS 没写清楚：**必须标注 TBD（To Be Defined）**，并输出“最小补充信息清单”，禁止脑补。

---

# 1. 输入（从 $ARGUMENTS 注入读取 DDS）

* 源文档路径由参数传入：`$ARGUMENTS`
* 你必须进行动态注入读取输入内容（至少 6 处，且覆盖“结构→关键字→细节”）：

1. 目录与上下文

* !`ls -la $(dirname "$ARGUMENTS")`
* !`file "$ARGUMENTS"`

2. DDS 正文读取（强制至少 3 段）

* !`sed -n '1,120p' "$ARGUMENTS"`
* !`sed -n '120,240p' "$ARGUMENTS"`
* !`sed -n '240,420p' "$ARGUMENTS"`

3. 设计细节抽取（强制至少 3 次 grep，分别聚焦 API/事件/DB/状态机/权限）

* !`grep -nE "API|接口|路径|路由|request|response|错误码|error" "$ARGUMENTS" | head -n 80`
* !`grep -nE "事件|event|MQTT|topic|outbox|消息|payload|幂等|retry" "$ARGUMENTS" | head -n 80`
* !`grep -nE "表|schema|字段|索引|unique|constraint|migration|DDL|PostgreSQL" "$ARGUMENTS" | head -n 80`
* !`grep -nE "状态机|state|transition|流转|工单|workflow|回调|补偿" "$ARGUMENTS" | head -n 80`
* !`grep -nE "RBAC|DAC|鉴权|JWT|claim|一级授权|二级授权|TOTP|权限" "$ARGUMENTS" | head -n 80`

> 若无法读取文件：明确说明缺少源文档内容，并输出“继续所需的最小信息清单”（接口/事件/表/状态机/依赖/权限/错误码），不得臆造细节。

---

# 2 章节驱动的 reference 目录分层（强制新增）

你必须把 DDS 的**章节标题/小节标题**提取出来，并用它们来构建 `reference/` 的分层目录。reference 文件不得全部堆在一个目录里，必须按章节归档。

## 2.1 章节提取（必须动态注入至少 2 处）

你必须在生成任何 reference 文件前，先输出“章节目录草案（TOC）”，并用动态注入从 DDS 中提取标题：

* !`grep -nE '^(#{1,6}\s+|[0-9]+(\.[0-9]+){0,3}\s+|第[一二三四五六七八九十]+章|第[0-9]+章|[一二三四五六七八九十]+、)' "$ARGUMENTS" | head -n 120`
* !`sed -n '1,200p' "$ARGUMENTS" | nl -ba | sed -n '1,120p'`

### 标题识别规则（启发式，必须使用）

按优先级识别章节标题：

1. Markdown 标题：`# / ## / ### ...`
2. 编号标题：`1 `、`1.1 `、`2.3.4 `（允许末尾带冒号）
3. 中文章标题：`第X章`、`第1章`
4. 中文小节：`一、二、三、` 或 `（一）（二）`

> 如果识别到的标题少于 3 个：必须进入降级策略（见 2.4），并在最终自检中标记该 DDS “章节结构提取不足” 为 FAIL。

---

## 2.2 reference 目录命名规范（必须）

* `reference/` 下目录必须采用 **有序前缀 + slug** 形式，防止乱序：

  * `reference/01-<section-slug>/`
  * `reference/01-<section-slug>/02-<subsection-slug>/`（可选）
* slug 规则：

  * 全小写
  * 非字母数字替换为 `-`
  * 连续 `-` 合并
  * 截断到 48 字符以内
* 章节序号来自 DDS 中的章节顺序（不是字面编号），例如：

  * `01-architecture-overview/`
  * `02-security-authz/`
  * `03-apis/`
  * `04-events-topics/`
  * `05-db-schema/`
  * `06-state-machine/`

---

## 2.3 reference 文件落盘规则（必须按章节放置）

你生成 reference 内容时，必须把内容放在对应章节目录下，而不是扁平化：

* `reference/<section>/apis.md`
* `reference/<section>/events-topics.md`
* `reference/<section>/db-schema.md`
* `reference/<section>/state-machine.md`
* `reference/<section>/security-model.md`
* `reference/<section>/dependencies.md`

### 章节映射要求（必须）

* 每条 reference 条目必须包含：

  * `DDS-Section:` 章节标题（原文）
  * `DDS-Lines:` 行号范围（如 `L120-L168` 或 “近似行号”）
  * `Extract:` 结构化内容（表格/列表）
* SKILL.md 中引用 reference 时必须引用“章节路径”，例如：

  * `See: reference/03-apis/apis.md`
  * `See: reference/04-events-topics/events-topics.md`

---

## 2.4 降级策略（无法可靠提取标题时必须执行）

当标题提取不足（少于 3 个）或 DDS 格式混乱时：

* 仍然必须分层，但使用保底目录：

  * `reference/00-unknown/`
  * `reference/00-unknown/01-apis/`
  * `reference/00-unknown/02-events/`
  * `reference/00-unknown/03-db/`
  * `reference/00-unknown/04-state-machine/`
  * `reference/00-unknown/05-security/`
* 同时必须在最终自检中给出 FAIL：

  * FAIL 原因：DDS 标题结构不可识别
  * 修复建议：提供 Markdown 标题、或提供章节目录、或提供导出为 md 的版本

---

## 2.5 verify.sh 必须检查章节分层（新增校验点）

每个 Skill 的 `scripts/verify.sh` 必须检查：

* `reference/` 下至少存在 `01-*` 的章节目录（或降级 `00-unknown`）
* 至少 2 个 reference 文件位于**非根目录**（在章节子目录里）
* 任意 reference 文件中必须出现 `DDS-Section:` 与 `DDS-Lines:` 字段

示例检查（可直接用）：

* `find reference -maxdepth 2 -type d -name '01-*' | grep -q .`
* `grep -R "DDS-Section:" -n reference | head -n 5`
* `grep -R "DDS-Lines:" -n reference | head -n 5`

---

# 3. 系统模块（必须按此拆分）

| 模块 | 职责 | 关键技术 |
| rmdc-core | API Gateway、鉴权、路由 | Go + Gin |
| rmdc-jenkins-branch-dac | Jenkins分支权限(DAC)、构建管理 | Jenkins API, MinIO |
| rmdc-exchange-hub | MQTT消息网关、指令生命周期 | MQTT, PostgreSQL |
| rmdc-watchdog | 边缘代理、K8S操作、二级授权 | K8S API, TOTP |
| rmdc-project-management | 项目管理、一级授权中心 | PostgreSQL |
| rmdc-work-procedure | 工单管理、工单流程、生命周期管理 | 状态机 |
| rmdc-audit-log | 审计日志 | PostgreSQL |
| rmdc-user-auth | 用户认证、权限管理 | JWT, RBAC |

---

# 4. 输出目标（必须一次性给全）

我将把输出落盘到 Windows 目录：

* `C:/Users/wddsh/Documents/IdeaProjects/ProjectAGiPrompt/1-AgentSkills`
  但你输出展示路径必须使用 Unix 风格（`/`）。

你需要输出：

1. 全部 Skills 的目录结构树（tree）
2. 每个 Skill 的 SKILL.md 完整内容（frontmatter + body）
3. reference/examples/scripts 中关键文件内容（只给必要内容，但 reference 必须充分）
4. 最后输出全局自检结果（逐条 PASS/FAIL + 修复建议）

---

# 5. Skill 组织架构（必须遵守）

生成以下 3 类 Skills：
A) 系统级（1个）：`rmdc-system`（跨模块一致性、依赖规则、版本/兼容策略、全局变更流程）
B) 模块级（7个）：每个模块 1 个 Skill（高频开发：实现步骤 + 依赖影响检查）
C) 横切（至少3个）：

* `designing-contracts`（API/事件/Schema 契约、兼容策略、版本策略）
* `database-migrations`（PostgreSQL迁移与回滚、字段演进）
* `observability-audit`（日志/指标/trace/审计一致性；对齐 rmdc-audit-log）

> 可按 DDS 增减，但不得少于 3 个横切 Skill。

---

# 6. 规范约束（硬性）

## 6.1 Frontmatter（极其重要）

* name：小写字母/数字/连字符；动名词形式； 包含中文的翻译
* description：必须【单行】且 <1024 字符；第三人称；包含功能说明 + 触发场景 + 关键词（必须包含模块名）必须是中英文混合的模式，保证中文和英文均可被命中
* allowed-tools：最小授权原则（默认仅 Read/Grep/Glob/Bash；除非 DDS 明确需要外部工具）
* 必须出现 argument-hint（提示 $ARGUMENTS 格式）

## 6.2 内容精简与拆分（但必须保留设计细节）

* 删除 Claude 常识，只保留 **DDS 特有设计** 与 **可操作步骤**
* 重复内容移到 reference/，SKILL.md 只保留“怎么做 + 查哪里 + 怎么验”
* 示例代码放 examples/（只放骨架与关键接口签名）
* scripts/ 必须至少 1 个 `verify.sh`：

  * 能运行并输出 PASS/FAIL
  * 检查：契约文件存在、迁移文件存在、接口/事件/表关键字是否匹配 DDS 抽取内容（可用 grep）
  * 写清依赖（bash、grep、sed、go test 可选）

## 6.3 工作流（计划-验证-执行）

每个 SKILL.md 必须包含以下结构：

* Plan：产物清单 + 决策点（涉及哪些模块、改动边界、是否影响契约/事件/表）
* Verify：Checklist（可勾选）+ 明确验证点（契约兼容、topic schema、migration 可回滚、RBAC/DAC 不破坏）
* Execute：可操作步骤（命令化短句，按顺序）
* Pitfalls：3~8 条常见坑（必须模块相关，且至少 2 条引用 reference 的具体内容）

## 6.4 参数与动态上下文

* 每个 Skill 必须使用 $ARGUMENTS（模块名、变更类型、输入文档路径、目标目录）
* 每个 Skill 必须至少包含 2 处 !`command` 动态注入示例（查 API/事件/表/运行测试）
* 命令需类 Unix shell 可执行；避免 OS 特定路径

## 6.5 质量标准（新增：设计细节覆盖率门槛）

* 每个模块 Skill 的 reference/ 必须覆盖至少 3 类设计要素（API/事件/DB/状态机/权限/依赖）
* 每个模块 Skill 若 reference 不足，最终自检必须 FAIL，并给补齐策略
* 每个 SKILL.md 主体 <500 行

---

# 7. 特殊要求（与模块强相关，必须引用 reference 的设计细节）

* rmdc-core：鉴权/路由变更影响检查（API契约、错误码、JWT claims）→ 引用 `reference/apis.md` + `reference/security-model.md`
* rmdc-jenkins-branch-dac：DAC 规则回归 + 最小权限；Jenkins API + MinIO 验证点 → 引用 `reference/security-model.md` + `reference/apis.md`
* rmdc-exchange-hub：MQTT topic/指令生命周期契约 + 幂等处理 → 引用 `reference/events-topics.md` + `reference/state-machine.md`
* rmdc-watchdog：K8S API 安全边界 + TOTP 二级授权 → 引用 `reference/security-model.md` + `reference/apis.md`
* rmdc-project-management：一级授权中心字段/状态变更影响 → 引用 `reference/db-schema.md` + `reference/state-machine.md`
* rmdc-audit-log：审计不可篡改/字段完整性/写入链路 → 引用 `reference/db-schema.md` + `reference/dependencies.md`
* rmdc-user-auth：RBAC/JWT/会话安全兼容与回归 → 引用 `reference/security-model.md` + `reference/apis.md`

---

# 8. 生成步骤（必须按顺序输出）

步骤1：先给出 Skills 清单（系统级/模块级/横切），并为每个 Skill 提供 2~3 个 name 候选，最终选择 1 个 name（附一句理由）
步骤2：输出总目录树（Unix 路径）
步骤3：依次输出每个 Skill 的 SKILL.md（完整内容）
步骤4：输出 supporting files（reference/examples/scripts）按“文件路径 -> 文件内容”逐个输出（reference 必须充分）
步骤5：输出全局 Verify Checklist 自检结果（逐条 PASS/FAIL + 修复建议）

---

# 9. 输出风格（新增：避免“空话”）

* 禁止只写“检查 API 兼容/检查事件一致性”这种空话
* 必须写成可执行的审查动作，例如：

  * “在 `reference/events-topics.md` 找到 topic 列表，对照仓库 grep 出 publish/subscribe 点”
  * “校验 JWT claims 是否包含 `tenant_id/project_id/role`（来自 `reference/security-model.md`）”
  * “migration 必须包含 down SQL；verify.sh grep 检查 `-- +migrate Down` 或回滚段落存在”