更新RMDC系统的模块SKILL
This commit is contained in:
zeaslity
275
2-需求转换专业设计/2-DDS转AgentSkills.md
Normal file
275
2-需求转换专业设计/2-DDS转AgentSkills.md
Normal file
@@ -0,0 +1,275 @@
|
||||
你是一位专业的 **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` 或回滚段落存在”
|
||||
@@ -3,9 +3,9 @@
|
||||
# 输入
|
||||
- 源文档路径由参数传入：$ARGUMENTS
|
||||
- 你必须使用动态注入读取输入内容（至少 2 处）：
|
||||
- !`ls -la $(dirname "$ARGUMENTS")`
|
||||
- !`sed -n '1,200p' "$ARGUMENTS"`
|
||||
- （可选）!`grep -nE "模块|module|service|接口|API|事件|MQTT|topic|表|schema|RBAC|鉴权|状态机" "$ARGUMENTS" | head -n 50`
|
||||
- !`ls -la $(dirname "$ARGUMENTS")`
|
||||
- !`sed -n '1,200p' "$ARGUMENTS"`
|
||||
- （可选）!`grep -nE "模块|module|service|接口|API|事件|MQTT|topic|表|schema|RBAC|鉴权|状态机" "$ARGUMENTS" | head -n 50`
|
||||
|
||||
如果无法读取文件：明确说明缺少源文档内容，并输出“继续所需的最小信息清单”（模块接口/事件/表/状态机/依赖关系等），不要臆造细节。
|
||||
|
||||
@@ -112,4 +112,8 @@ scripts/
|
||||
|
||||
### claude name命名 rmdc-watchdog-skill
|
||||
watchdog模块的设计文档说明见目录 C:\Users\wddsh\Documents\IdeaProjects\ProjectAGiPrompt\8-CMII-RMDC\6-rmdc-watchdog
|
||||
请将详细系统设计转换为单独的SKILL
|
||||
|
||||
### claude name命名 rmdc-user-auth-skill
|
||||
user-auth模块的设计文档说明见C:\Users\wddsh\Documents\IdeaProjects\ProjectAGiPrompt\8-CMII-RMDC\9-rmdc-user-auth\2-user-auth-DDS.md
|
||||
请将详细系统设计转换为单独的SKILL
|
||||
1
2-需求转换专业设计/中文表头转换.md
Normal file
1
2-需求转换专业设计/中文表头转换.md
Normal file
@@ -0,0 +1 @@
|
||||
请你将下面的AgentSkill的FrontFormatter 转换为中英文的形式，要求翻译的尽可能贴切实际开发，可以修改原始的英文
|
||||
@@ -17,3 +17,10 @@
|
||||
|
||||
|
||||
|
||||
你是一位专业的 Agent Skills 架构师与 Claude Code Skills 作者。你的任务是：把给定的 RMDC 系统设计文档（DDS/PRD/架构说明）转换为一套可落地的 Claude Code Skills（系统级 Skill + 模块级 Skills + 横切 Skills），并输出完整目录树与每个 Skill 的 SKILL.md。
|
||||
|
||||
请你分析并修改 1-AgentSkills/coding-go-gin-gorm
|
||||
1. 现在我发现LLM很少能够拉到reference里面的详细内容
|
||||
2. 现在很多地方定义了api的回复的错误code，请统一回复的Code定义
|
||||
3. 回复的Code定义中，不要出现HTTP的错误code，不需要按照模块区分错误Code
|
||||
4. 回复结构体请统一标准为 1-AgentSkills/coding-go-gin-gorm/reference/api-response-spec.md
|
||||
Reference in New Issue
Block a user