@trench-craft/sds 1.0.0

package/skills/core/subagent-driven-development/implementer-prompt.md

@@ -0,0 +1,122 @@
+# 实现子智能体提示词模板
+
+分派实现子智能体时使用此模板。
+
+```
+spawn_agent:
+  description: "实现任务 N：[任务名称]"
+  message: |
+    你正在实现任务 N：[任务名称]
+
+    ## 任务描述
+
+    [计划中任务的完整文本 - 粘贴到这里，不要让子智能体去读文件]
+
+    ## 上下文
+
+    [场景铺设：这个任务在哪个环节、依赖关系、架构上下文]
+
+    ## 开始之前
+
+    如果你对以下内容有疑问：
+    - 需求或验收标准
+    - 方案或实现策略
+    - 依赖或假设
+    - 任务描述中任何不清楚的地方
+
+    **现在就问。** 在开始工作之前提出任何疑虑。
+
+    ## 你的工作
+
+    当你确认需求清晰后：
+    1. 严格按照任务指定的内容实现
+    2. 编写测试（如果任务要求则遵循 TDD）
+    3. 验证实现是否正常工作
+    4. 提交你的工作
+    5. 自审（见下文）
+    6. 汇报
+
+    工作目录：[directory]
+
+    **工作过程中：** 如果遇到意料之外或不清楚的情况，**提问**。
+    随时可以暂停并澄清。不要猜测或做假设。
+
+    ## 代码组织
+
+    你在能一次性放入上下文的代码上推理效果最好，文件聚焦时编辑也更可靠。
+
+    **文件粒度硬性约束（必须遵守）：**
+    - 单文件不超过 300 行（含空行和注释），超过时必须拆分为多个模块
+    - 单函数/单方法不超过 50 行，超过时提取子函数
+    - 单类不超过 200 行，超过时提取委托对象或策略类
+    - import 语句不超过 15 行，超过说明职责过多，应拆模块
+    - 拆分时先创建模块结构（空文件 + 导出接口），确认结构合理后再逐个填充实现
+
+    请牢记：
+    - 遵循计划中定义的文件结构
+    - 每个文件应有单一明确的职责和定义清晰的接口
+    - 如果你正在创建的文件超出了上述行数限制，**立即停下来拆分**——先创建子模块结构，再继续实现
+    - 如果你正在修改的现有文件已经很大或很混乱，小心操作
+      并在报告中将其标注为疑虑
+    - 如果你正在修改的现有文件已经很大或很混乱，小心操作
+      并在报告中将其标注为疑虑
+    - 在已有代码库中，遵循已建立的模式。像一个好的开发者那样
+      改善你接触的代码，但不要重构你任务范围之外的东西。
+
+    ## 当你力不从心时
+
+    说"这对我来说太难了"完全没问题。劣质的工作比不做更糟。
+    上报不会受到惩罚。
+
+    **遇到以下情况时停下来上报：**
+    - 任务需要在多个有效方案之间做架构决策
+    - 你需要理解提供内容之外的代码但找不到答案
+    - 你对自己的方案是否正确感到不确定
+    - 任务涉及计划未预期的现有代码重构
+    - 你一直在逐个读文件试图理解系统但没有进展
+
+    **如何上报：** 以 BLOCKED 或 NEEDS_CONTEXT 状态汇报。具体描述
+    你卡在哪里、尝试了什么、需要什么帮助。
+    控制者可以提供更多上下文、用更强的模型重新分派，
+    或将任务拆分为更小的部分。
+
+    ## 汇报前：自审
+
+    用全新的视角审查你的工作。问自己：
+
+    **完整性：**
+    - 我是否完全实现了规格中的所有内容？
+    - 我是否遗漏了任何需求？
+    - 是否有我没处理的边界情况？
+
+    **质量：**
+    - 这是我最好的工作吗？
+    - 命名是否清晰准确（匹配事物做什么，而非怎么做）？
+    - 代码是否整洁且可维护？
+
+    **纪律：**
+    - 我是否避免了过度构建（YAGNI）？
+    - 我是否只构建了被要求的内容？
+    - 我是否遵循了代码库中的已有模式？
+
+    **测试：**
+    - 测试是否真正验证了行为（而非只是 mock 行为）？
+    - 如果要求了 TDD，我是否遵循了？
+    - 测试是否全面？
+
+    如果在自审中发现问题，在汇报前就修复。
+
+    ## 汇报格式
+
+    完成后汇报：
+    - **状态：** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+    - 你实现了什么（或尝试了什么，如果被阻塞）
+    - 你测试了什么以及测试结果
+    - 修改了哪些文件
+    - 自审发现（如果有）
+    - 任何问题或疑虑
+
+    如果你完成了工作但对正确性有疑虑，使用 DONE_WITH_CONCERNS。
+    如果你无法完成任务，使用 BLOCKED。如果你需要
+    未提供的信息，使用 NEEDS_CONTEXT。绝不默默产出你不确定的工作。
+```

package/skills/core/subagent-driven-development/skill.yaml

@@ -0,0 +1,12 @@
+id: "subagent-driven-development"
+version: "2.0.0"
+name: "subagent-development"
+description: "通过子代理执行实现计划"
+category: "core"
+phase: "phase-4"
+source: "superpowers"
+dependencies: ["writing-plans"]
+inputs: ["openspec/changes/{name}/plan.md"]
+outputs: []
+size: "large"
+cache_ttl: "7d"

package/skills/core/subagent-driven-development/spec-reviewer-prompt.md

@@ -0,0 +1,61 @@
+# 规格合规审查者提示词模板
+
+分派规格合规审查子智能体时使用此模板。
+
+**目的：** 验证实现者是否构建了所要求的内容（不多不少）
+
+```
+spawn_agent:
+  description: "审查任务 N 的规格合规性"
+  message: |
+    你正在审查一个实现是否与其规格匹配。
+
+    ## 要求的内容
+
+    [任务需求的完整文本]
+
+    ## 实现者声称构建了什么
+
+    [来自实现者的报告]
+
+    ## 关键：不要信任报告
+
+    实现者完成得疑似过快。他们的报告可能不完整、
+    不准确或过于乐观。你必须独立验证所有内容。
+
+    **不要：**
+    - 相信他们关于实现内容的说法
+    - 信任他们关于完整性的声明
+    - 接受他们对需求的解读
+
+    **要做的：**
+    - 阅读他们写的实际代码
+    - 逐行对比实际实现和需求
+    - 检查他们声称已实现但实际遗漏的部分
+    - 寻找他们未提及的多余功能
+
+    ## 你的工作
+
+    阅读实现代码并验证：
+
+    **缺失的需求：**
+    - 他们是否实现了所有被要求的内容？
+    - 是否有他们跳过或遗漏的需求？
+    - 是否有他们声称可用但实际未实现的功能？
+
+    **多余/不需要的工作：**
+    - 他们是否构建了未被要求的内容？
+    - 他们是否过度工程化或添加了不必要的功能？
+    - 他们是否添加了规格中没有的"锦上添花"功能？
+
+    **理解偏差：**
+    - 他们是否以不同于预期的方式解读了需求？
+    - 他们是否解决了错误的问题？
+    - 他们是否实现了正确的功能但方式不对？
+
+    **通过阅读代码来验证，而非信任报告。**
+
+    报告：
+    - ✅ 符合规格（如果经过代码检查后一切匹配）
+    - ❌ 发现问题：[具体列出缺失或多余的内容，附带 file:line 引用]
+```

package/skills/core/writing-plans/SKILL.md

@@ -0,0 +1,268 @@
+---
+name: writing-plans
+description: "将规格说明拆解为可执行的实现计划，为 subagent-driven-development 或 executing-plans 提供执行依据。在 brainstorming 和 specs 完成后使用。"
+---
+
+# Write Plans
+
+## 触发条件
+
+**触发**：
+- opsx:propose 已完成，proposal/design/specs/tasks 四份工件已就绪
+- 用户主动要求"编写实现计划"或"拆解任务"
+
+**不触发**：
+- ❌ 任何非开发类对话
+- ❌ opsx:propose 尚未完成时
+- ❌ 还在讨论需求或设计方案
+
+编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。
+
+**开始时宣布：** "我正在使用 writing-plans 技能创建实现计划。"
+
+## OpenSpec 工作流中的位置
+
+此技能在 OpenSpec worktree 中运行。输入来自 opsx:propose 生成的 specs.md（Phase 2 产出）：
+
+```
+openspec/changes/<name>/
+├── brainstorming.md  (Phase 1)
+├── proposal.md       (Phase 2)
+├── design.md         (Phase 2)
+├── specs.md          (Phase 2) ← 输入
+├── tasks.md          (Phase 2)
+└── plan.md           (Phase 3) ← 输出
+    或 plan/
+        ├── index.md
+        └── <module>.md
+```
+
+## 计划膨胀问题与解法
+
+plan.md 膨胀的根本原因是把**任务步骤**和**代码细节**混在同一个文件里。
+
+### 解法：分离"骨架"与"细节"
+
+```
+plan.md              ← 骨架：任务列表 + 步骤描述 + 接口契约（精简）
+plan/refs/           ← 细节：大型代码块、schema、配置模板（按需引用）
+  ├── auth-schema.sql
+  └── api-types.ts
+```
+
+**骨架文件（plan.md）** 包含：
+- 每个任务的步骤描述（做什么、怎么验证）
+- 跨模块接口契约（类型定义、数据格式、API 签名）
+- 通过 `→ 详见 plan/refs/xxx` 引用大型代码块
+
+**细节文件（plan/refs/）** 包含：
+- 完整的 schema 定义
+- 大型模板代码
+- 配置文件样板
+- 骨架中通过路径引用，不内联
+
+### 何时需要分割 plan.md 为多个文件
+
+仅当骨架文件仍然过大（>300 行）时才分割。此时按模块拆分为 plan/ 目录。
+
+**分割的唯一原则：每个 chunk 100% 自包含，协调器不需要跨文件读取。**
+
+这意味着：
+- chunk A 定义的接口 → 必须在 chunk B 中**内联重复**（不是引用）
+- 协调器读一个 chunk 文件就能构造完整的 implementer-prompt
+- index.md 只做索引和状态跟踪，**不放任何执行必需的信息**
+
+### 为什么不能让协调器跨文件拼接
+
+协调器本身是 LLM。让它从 index.md 取接口契约、从已完成 chunk 取产出、再注入 implementer-prompt，这要求它做跨文件信息整合——容易漏读、错配、上下文超限。
+
+**正确做法：chunk 自包含，代价是少量重复。这比依赖 LLM 跨文件整合可靠得多。**
+
+## 范围检查
+
+如果规格涵盖了多个独立子系统，它应该在 Phase 2 就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。
+
+## 文件结构
+
+在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。
+
+- **硬性约束：单文件不超过 300 行（含空行），单函数不超过 50 行，单类不超过 200 行**
+- 超出约束时必须在计划阶段就拆分为多个模块，不要留到实现阶段
+- 每个任务涉及 1-2 个文件变更，禁止"在 X.ts 中实现全部功能"这种任务
+- 每个任务输出中包含：涉及文件列表 + 预估行数
+- 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。
+- 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件。
+- 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。
+- 在现有代码库中，遵循已有模式。
+
+## 小步骤任务粒度
+
+**每步是一个操作（2-5 分钟）：**
+- "编写失败的测试" - 一步
+- "运行它确认失败" - 一步
+- "实现最少代码让测试通过" - 一步
+- "运行测试确认通过" - 一步
+- "Commit" - 一步
+
+## 接口契约
+
+**这是计划中最关键的部分。** 每个任务必须明确它依赖和产出的接口。
+
+接口契约放在骨架文件中（不是 refs/），因为协调器构造 implementer-prompt 时必须能看到：
+
+```markdown
+## 接口契约
+
+### AuthService.login
+- 输入：`{ email: string, password: string }`
+- 输出：`{ token: AuthToken, user: User }`
+- 错误：`{ code: 401, message: "Invalid credentials" }`
+
+### AuthToken 格式
+\```typescript
+interface AuthToken {
+  userId: string;
+  role: 'admin' | 'user';
+  iat: number;
+  exp: number;
+}
+\```
+- 签发方：任务 2（认证模块）
+- 消费方：任务 5（用户模块）、任务 8（通知模块）
+```
+
+## 计划文档头部
+
+```markdown
+# [功能名称] 实现计划
+
+> **面向 AI 代理的工作者：** 必需子技能：使用 subagent-driven-development（推荐）
+> 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。
+
+**目标：** [一句话描述要构建什么]
+
+**架构：** [2-3 句话描述方案]
+
+**技术栈：** [关键技术/库]
+
+**上下文文件：** spec: openspec/changes/<name>/specs.md, design: openspec/changes/<name>/design.md
+
+---
+```
+
+## 任务结构
+
+````markdown
+### 任务 N：[组件名称]
+
+**文件：**
+- 创建：`exact/path/to/file.py`
+- 修改：`exact/path/to/existing.py:123-145`
+- 测试：`tests/exact/path/to/test.py`
+
+**接口：**
+- 依赖：[列出本任务依赖的接口，附完整类型签名]
+- 产出：[列出本任务产出的接口，附完整类型签名]
+
+- [ ] **步骤 1：编写失败的测试**
+
+```python
+def test_specific_behavior():
+    result = function(input)
+    assert result == expected
+```
+
+- [ ] **步骤 2：运行测试验证失败**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：FAIL，报错 "function not defined"
+
+- [ ] **步骤 3：编写最少实现代码**
+
+```python
+def function(input):
+    return expected
+```
+
+- [ ] **步骤 4：运行测试验证通过**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：PASS
+
+- [ ] **步骤 5：Commit**
+````
+
+## 禁止占位符
+
+每个步骤都必须包含工程师需要的实际内容。**绝不要写：**
+- "待定"、"TODO"、"后续实现"、"补充细节"
+- "添加适当的错误处理" / "添加验证" / "处理边界情况"
+- "为上述代码编写测试"（没有实际测试代码）
+- 只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）
+
+## plan_review — 调度子代理审查
+
+编写完整计划后，使用 `plan-document-reviewer-prompt.md` 模板调度一个子代理来审查计划。
+
+**执行步骤：**
+
+1. 将计划文档路径和 specs.md 路径传入 `plan-document-reviewer-prompt.md` 模板
+2. 调度审查子代理（使用 spawn_agent）
+3. 如果审查通过（状态：通过）→ 进入执行交接
+4. 如果审查发现问题（状态：发现问题）→ 修复计划文档，重新运行 plan_review
+
+## 目录化模式（计划过大时）
+
+当骨架文件 >300 行时，按模块拆分为 `plan/` 目录：
+
+```
+plan/
+├── index.md        ← 执行顺序 + 状态追踪（不含接口契约）
+├── auth.md         ← 认证模块（自包含：含接口契约 + 任务步骤）
+├── user.md         ← 用户模块（自包含：内联 auth 产出的接口）
+└── refs/           ← 大型代码引用（可选）
+    └── schema.sql
+```
+
+### 目录化模式的规则
+
+1. **index.md 只做索引** — 执行顺序、chunk 列表、完成状态。不含接口、不含任务步骤。
+2. **每个 chunk 自包含** — 协调器读一个 chunk 就能构造完整的 implementer-prompt。
+3. **接口契约在 chunk 间内联重复** — auth.md 定义的 `AuthToken`，在 user.md 中必须重复写明完整定义。不写"见 auth.md"。
+4. **refs/ 是唯一可共享的** — 大型代码块放在 refs/，chunk 通过路径引用。这是因为代码块通常不变，而接口定义可能随任务演进。
+
+### 协调器执行流程
+
+```
+读取 plan/index.md → 获取 chunk 执行顺序
+↓
+对当前 chunk:
+  读取 plan/<chunk>.md → 全文（自包含，无需读其他文件）
+  ↓
+  对 chunk 内每个任务:
+    提取任务文本（含接口契约）→ 粘贴到 implementer-prompt
+    ↓
+    子代理执行 → 审查 → 通过
+    ↓
+    更新 plan/<chunk>.md 标记任务完成
+  ↓
+  chunk 全部完成 → 更新 plan/index.md 状态
+↓
+下一个 chunk（同样的流程，不需要"传递上下文"）
+```
+
+## 执行交接
+
+plan_review 通过后，提供执行选项：
+
+**"计划已完成并通过 plan_review。执行方式：**
+
+**1. subagent-driven-development（推荐）** - 每个任务调度新的子代理，任务间审查
+
+**2. 手动执行** - 在当前会话中内联执行
+
+**选哪种方式？"**
+
+如果选择 subagent-driven-development：
+- 必需子技能：使用 subagent-driven-development
+- 每个任务一个新子代理 + 两阶段审查

package/skills/core/writing-plans/plan-document-reviewer-prompt.md

@@ -0,0 +1,63 @@
+# 计划文档审查员提示模板
+
+调度计划文档审查员子代理时使用此模板。
+
+**用途：** 验证计划是否完整、与规格匹配，并且任务分解合理。
+
+**调度时机：** 完整计划编写完成后。
+
+```
+spawn_agent:
+  description: "审查计划文档"
+  message: |
+    你是一名计划文档审查员。验证此计划是否完整并准备好进行实现。
+
+    **待审查计划：** [PLAN_FILE_PATH 或 PLAN_DIR_PATH]
+    **参考规格：** [SPEC_FILE_PATH]
+
+    ## 审查模式
+
+    单文件（plan.md）：直接审查。
+
+    目录化（plan/）：
+      1. 读 plan/index.md 了解执行顺序
+      2. 逐个审查 chunk 文件
+      3. 重点检查：每个 chunk 是否自包含（协调器只读该 chunk 就能执行）
+
+    ## 检查内容
+
+    | 类别 | 检查要点 |
+    |------|----------|
+    | 完整性 | TODO、占位符、不完整的任务、缺失的步骤 |
+    | 规格对齐 | 计划覆盖了规格需求，没有重大范围蔓延 |
+    | 任务分解 | 任务有清晰的边界，步骤可执行 |
+    | 可构建性 | 工程师能否按此计划执行而不会卡住？ |
+    | 接口契约 | 每个任务的依赖/产出接口有完整类型签名 |
+    | 自包含性 | （目录模式）chunk 不依赖"见其他 chunk"的引用 |
+
+    ## 校准标准
+
+    **只标记会在实现阶段造成实际问题的事项。**
+
+    特别关注：
+    - 任务写了"见 auth.md"但没有内联接口定义 → 必须标记
+    - 接口契约缺少类型签名或参数说明 → 必须标记
+    - 任务步骤描述清晰但缺少验证方式 → 建议（不阻止）
+
+    除非存在严重缺陷——规格中的需求遗漏、
+    矛盾的步骤、占位内容、或者模糊到无法执行的任务——否则应予以通过。
+
+    ## 输出格式
+
+    ## 计划审查
+
+    **状态：** 通过 | 发现问题
+
+    **问题（如有）：**
+    - [任务 X，步骤 Y]：[具体问题] - [为什么这对实现很重要]
+
+    **建议（仅供参考，不阻止通过）：**
+    - [改进建议]
+```
+
+**审查员返回：** 状态、问题（如有）、建议

package/skills/core/writing-plans/skill.yaml

@@ -0,0 +1,12 @@
+id: "writing-plans"
+version: "2.0.0"
+name: "write-plans"
+description: "将规格拆解为实现计划"
+category: "core"
+phase: "phase-3"
+source: "superpowers"
+dependencies: ["opsx:propose"]
+inputs: ["openspec/changes/{name}/specs.md"]
+outputs: ["openspec/changes/{name}/plan.md"]
+size: "medium"
+cache_ttl: "30d"

package/skills/locale/chinese-code-review/SKILL.md

@@ -0,0 +1,17 @@
+# chinese-code-review - 中文代码审查
+
+## 用途
+
+在保持专业严谨的同时，用符合国内团队文化的方式给出有效的代码审查反馈。
+
+## 触发条件
+
+- 用户 locale 配置为 zh-CN 时自动加载
+- 进行代码审查时手动调用
+
+## 核心流程
+
+1. 使用中文术语描述代码问题
+2. 遵循国内团队习惯的反馈方式
+3. 保持专业性的同时注重沟通效率
+4. 提供具体的改进建议和示例代码

package/skills/locale/chinese-code-review/skill.yaml

@@ -0,0 +1,16 @@
+id: "locale:zh-CN:chinese-code-review"
+version: "2.0.0"
+name: "chinese-code-review"
+description: "中文代码审查规范"
+category: "locale"
+phase: "on-demand"
+source: "superpowers"
+trigger_conditions:
+  - type: user_config
+    key: "locale"
+    value: "zh-CN"
+dependencies: []
+inputs: []
+outputs: []
+size: "small"
+cache_ttl: "30d"

package/skills/locale/chinese-commit-conventions/SKILL.md

@@ -0,0 +1,17 @@
+# chinese-commit-conventions - 中文提交规范
+
+## 用途
+
+适配国内团队的 Git commit message 规范，支持 changelog 自动化生成。
+
+## 触发条件
+
+- 用户 locale 配置为 zh-CN 时自动加载
+- 创建 Git 提交时自动应用
+
+## 核心流程
+
+1. 使用中文编写 commit message
+2. 遵循约定式提交格式（feat/fix/docs/style/refactor/test/chore）
+3. 在 description 中使用中文描述变更内容
+4. 确保 message 可被 changelog 工具正确解析

package/skills/locale/chinese-commit-conventions/skill.yaml

@@ -0,0 +1,16 @@
+id: "locale:zh-CN:chinese-commit-conventions"
+version: "2.0.0"
+name: "chinese-commit-conventions"
+description: "中文 Git 提交规范"
+category: "locale"
+phase: "on-demand"
+source: "superpowers"
+trigger_conditions:
+  - type: user_config
+    key: "locale"
+    value: "zh-CN"
+dependencies: []
+inputs: []
+outputs: []
+size: "small"
+cache_ttl: "30d"

package/skills/locale/chinese-documentation/SKILL.md

@@ -0,0 +1,17 @@
+# chinese-documentation - 中文技术文档
+
+## 用途
+
+中文技术文档写作规范，确保排版、术语、结构一步到位，告别机翻味。
+
+## 触发条件
+
+- 用户 locale 配置为 zh-CN 时自动加载
+- 编写技术文档时自动应用
+
+## 核心流程
+
+1. 使用规范的中文技术术语
+2. 遵循中文排版规范（标点、空格、数字）
+3. 采用清晰的文档结构（标题层级、列表、代码块）
+4. 避免生硬的翻译腔，使用自然的中文表达

package/skills/locale/chinese-documentation/skill.yaml

@@ -0,0 +1,16 @@
+id: "locale:zh-CN:chinese-documentation"
+version: "2.0.0"
+name: "chinese-documentation"
+description: "中文技术文档写作规范"
+category: "locale"
+phase: "on-demand"
+source: "superpowers"
+trigger_conditions:
+  - type: user_config
+    key: "locale"
+    value: "zh-CN"
+dependencies: []
+inputs: []
+outputs: []
+size: "small"
+cache_ttl: "30d"

package/skills/locale/chinese-git-workflow/SKILL.md

@@ -0,0 +1,17 @@
+# chinese-git-workflow - 中文 Git 工作流
+
+## 用途
+
+适配国内 Git 平台（Gitee、Coding、极狐 GitLab、CNB）和团队习惯的工作流规范。
+
+## 触发条件
+
+- 用户 locale 配置为 zh-CN 时自动加载
+- 执行 Git 工作流操作时自动应用
+
+## 核心流程
+
+1. 适配国内 Git 平台的特性和限制
+2. 遵循国内团队的分支命名和合并策略
+3. 使用中文编写 PR/MR 描述和评审意见
+4. 处理国内平台特有的 CI/CD 集成问题

package/skills/locale/chinese-git-workflow/skill.yaml

@@ -0,0 +1,16 @@
+id: "locale:zh-CN:chinese-git-workflow"
+version: "2.0.0"
+name: "chinese-git-workflow"
+description: "适配国内 Git 平台的工作流规范"
+category: "locale"
+phase: "on-demand"
+source: "superpowers"
+trigger_conditions:
+  - type: user_config
+    key: "locale"
+    value: "zh-CN"
+dependencies: []
+inputs: []
+outputs: []
+size: "small"
+cache_ttl: "30d"