@zmice/zc 0.2.0 → 0.2.2

package/vendor/packages/toolkit/src/content/commands/idea/body.md

@@ -1,23 +1,22 @@
-调用 idea-refine 技能。通过结构化的发散和收敛思维，将粗糙想法变为可执行方案。
+这是 `command:start` 评估后进入的专项入口：当任务还停留在粗糙想法、方向探索或方案收敛阶段时，转到 `idea`。
 
-1. 理解想法 — 你想解决什么问题？目标用户是谁？成功是什么样子？
-2. 约束分析 — 时间资源限制、技术栈约束、需要兼容的现有系统
-3. 方案探索 — 列出 2-3 个可行方案，对比 Pros/Cons，推荐最佳方案
-4. 输出 — 结构化的需求描述、推荐技术方案、下一步行动项
+调用 `idea-refine`，先把模糊想法变成可执行问题，再决定是否进入 lifecycle。
 
-## 使用方式
+## 何时直接用这个入口
 
-在 `/idea` 后描述你的想法（无论多粗糙），我将通过提问帮你细化为可执行的方案。
+- 你知道想解决什么方向，但还没有清晰需求或可执行方案
+- 需要先比较几种思路，而不是直接写规格或开始实现
+- 希望先收敛目标、约束和成功标准
 
-### 示例
+## 何时回到 lifecycle
 
-```
-# 粗糙的想法
-/idea 我想给管理后台加一个操作审计日志功能
+- 想法已经足够清晰，可以正式写需求：回到 `spec`
+- 方案基本确定，可以拆任务：回到 `task-plan`
+- 如果只是补现有方案的说明，而不是继续探索：转到 `doc`
 
-# 技术方向
-/idea 我们的单体应用想拆微服务，日活 10w
+## 执行重点
 
-# 产品特性
-/idea 想做一个智能推荐系统，根据用户行为推荐商品
-```
+1. 理解想法：问题是什么、目标用户是谁、成功标准是什么
+2. 分析约束：时间、资源、技术栈、兼容性和风险
+3. 探索 2-3 个可行方案，比较取舍并给出推荐
+4. 输出结构化结论和下一步，避免想法长期停留在模糊状态

package/vendor/packages/toolkit/src/content/commands/idea/meta.yaml

@@ -12,7 +12,18 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: specialized
+workflow_role: specialized-entry
+task_types:
+  - feature
+  - investigation
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/learn/meta.yaml

@@ -12,7 +12,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/migrate/meta.yaml

@@ -13,7 +13,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/onboard/body.md

@@ -1,24 +1,22 @@
-调用 codebase-onboarding 技能。系统化探索陌生代码库，建立全局认知。
+这是 `command:start` 评估后进入的专项入口：当任务核心是理解陌生项目、模块或代码路径，而不是立刻修改实现时，转到 `onboard`。
 
-1. 扫描目录结构 - 识别项目类型、构建系统、关键配置
-2. 定位入口点 - 主入口文件、路由定义、数据模型
-3. 分析依赖 - 核心三方库、内部模块划分、数据流向
-4. 识别架构模式 - 整体架构、状态管理、错误处理、测试策略
-5. 生成项目概览 - 技术栈、目录结构、入口点、核心模块、开发命令
+调用 `codebase-onboarding`，先建立项目地图，再决定后续进入哪个 workflow。
 
-## 使用方式
+## 何时直接用这个入口
 
-在 `/onboard` 后告诉我你想了解的项目或代码库，我将系统化地探索并生成概览。
+- 新接手项目、模块或代码路径，需要先搞清整体结构
+- 任务还不知道该走 `spec`、`build` 还是 `debug`
+- 需要快速拿到技术栈、入口点、核心模块和验证命令
 
-### 示例
+## 何时回到 lifecycle
 
-```
-# 探索当前项目
-/onboard 帮我了解这个项目的整体架构和核心模块
+- 已经理解上下文，准备开始正式需求或变更：回到 `spec`
+- 已经定位到明确实现点，准备执行：回到 `task-plan` 或 `build`
+- 理解过程中发现真实问题是缺陷排查：转到 `debug`
 
-# 了解特定模块
-/onboard 我需要了解支付模块的实现，重点是回调流程和状态机
+## 执行重点
 
-# 新人入职
-/onboard 我是新加入的开发者，帮我快速了解项目的技术栈和开发规范
-```
+1. 扫描目录结构、构建系统和关键配置
+2. 定位入口点、核心模块、数据流和测试入口
+3. 识别架构模式、边界和高风险区域
+4. 输出最小可用项目概览，帮助后续选择正确 workflow

package/vendor/packages/toolkit/src/content/commands/onboard/meta.yaml

@@ -12,7 +12,17 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: specialized
+workflow_role: specialized-entry
+task_types:
+  - investigation
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/perf/meta.yaml

@@ -12,7 +12,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/plan-review/body.md

@@ -1,28 +1,29 @@
-调用 multi-perspective-review 技能。四视角独立评审，发现盲点。
+这是 `command:start` 之后的 **计划/规格评审阶段入口**。
 
-1. 读取当前 Spec 或 Plan，提取关键决策点
-2. **产品视角** — 用户价值清晰？边界覆盖？验收可测？
-3. **工程视角** — 技术方案可行？扩展性？技术债务？
-4. **设计视角** — 用户体验顺畅？异常状态完整？设计一致？
-5. **DevEx 视角** — API 直觉化？文档充分？配置合理？
-6. 汇总发现，按 Critical / Warning / Suggestion 分级
-7. **门控：存在 Critical 则阻断，必须修复后继续**
+当 `command:start`、`command:spec` 或 `command:task-plan` 产出了关键方案，但在进入实现前还需要多视角把关时，就从这里接力到 `multi-perspective-review`。
 
-可选参数：`--product` `--engineering` `--design` `--devex` 选择评审视角，默认全部。
+## 当前阶段要做什么
 
-## 使用方式
+1. 读取当前 Spec 或 Plan，提取关键决策点
+2. **产品视角**：用户价值清晰？边界覆盖？验收可测？
+3. **工程视角**：方案可行？扩展性和技术债务可控？
+4. **设计视角**：体验流畅？异常状态完整？一致性足够？
+5. **DevEx 视角**：接口直觉？文档充分？配置合理？
+6. 汇总发现，按 `Critical / Warning / Suggestion` 分级
+7. 存在 `Critical` 时阻断，先修复再继续
 
-在 Spec 或 Plan 完成后执行 `/plan-review`，获取多视角评审反馈。
+## 当前阶段的边界
 
-### 示例
+- 这里只做评审，不直接进入实现
+- 重点是提前暴露盲点，而不是重写整份规格
+- 评审结论必须指向明确修正动作
 
-```
-# 全视角评审
-/plan-review
+## 从这里通常接到哪里
 
-# 仅工程和安全视角
-/plan-review --engineering 重点关注技术方案的可行性和扩展性
+- 评审通过：进入 `command:task-plan` 或 `command:build`
+- 评审发现规格空洞：回到 `command:spec`
+- 评审发现计划颗粒度不对：回到 `command:task-plan`
+
+## 使用方式
 
-# 评审特定文档
-/plan-review 评审 spec.md 中的支付模块设计
-```
+提供当前的 Spec、Plan 或关键方案，我会按多视角输出结构化评审结果，并给出下一步接力建议。

package/vendor/packages/toolkit/src/content/commands/plan-review/meta.yaml

@@ -13,7 +13,18 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: lifecycle
+workflow_role: stage-entry
+task_types:
+  - feature
+  - bugfix
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/product-analysis/body.md

@@ -0,0 +1,52 @@
+这是 `command:start` 完成任务评估后的 **产品分析工作流入口**。
+
+当任务属于“需求还模糊、价值与范围未收敛、需要先形成可落地方案”时，从 `command:start` 接力到这里，而不是直接进入 `sdd-tdd`。
+
+## 当前阶段要做什么
+
+1. 澄清问题定义：到底要解决什么问题，目标用户是谁，成功长什么样
+2. 收敛范围：明确本轮做什么、不做什么、优先级如何排序
+3. 补齐验收标准：把模糊需求压成可验证的成功标准
+4. 识别风险与依赖：找出需要先确认的约束、前置条件和关键决策
+5. 形成执行方案：决定是继续写规格、先做方案评审，还是已经可以进入任务拆解
+
+## 推荐接力顺序
+
+通常按下面顺序推进：
+
+1. `command:idea`
+   - 先把模糊想法、问题描述或需求草稿收敛成一个更清晰的问题陈述
+2. `agent:product-owner`
+   - 从价值、范围、优先级和验收标准角度挑战方案
+3. `skill:brainstorming-and-design`
+   - 做方案探索、取舍比较和约束澄清
+4. `command:spec`
+   - 把结论沉淀成结构化规格
+5. `command:plan-review`
+   - 对规格和方案做产品 / 工程 / 设计 / DevEx 的多视角评审
+
+## 何时使用
+
+- 需求仍然模糊，不能直接开始实现
+- 已经知道想解决的问题，但还没有稳定的范围和成功标准
+- 需要先把产品语言转成工程可执行方案
+- 你怀疑任务并不该直接进入 `full-delivery`
+
+## 何时不要直接使用
+
+- 已经有稳定规格，只需要拆任务：进入 `command:task-plan`
+- 已经有计划，只需要开始实现：进入 `command:build`
+- 重点是定位 bug：进入 `command:debug`
+- 重点是审查已有改动：进入 `command:quality-review`
+
+## 典型出口
+
+- 方案仍不稳定：继续停留在 `idea` / `product-owner` / `brainstorming-and-design`
+- 规格已成形：进入 `command:spec`
+- 规格待评审：进入 `command:plan-review`
+- 方案与规格都已稳定：进入 `command:task-plan`
+- 已确认进入完整交付：切换到 `command:sdd-tdd`
+
+## 使用方式
+
+直接描述你的需求、目标、限制和当前困惑点。我会先帮你完成产品分析，再明确下一步是继续收敛、写规格、做评审，还是切到完整交付。

package/vendor/packages/toolkit/src/content/commands/product-analysis/meta.yaml

@@ -0,0 +1,35 @@
+kind: command
+name: product-analysis
+title: 产品分析
+description: 将模糊需求收敛为可落地的执行方案，先明确价值、范围、验收标准，再决定是否进入完整交付。
+tier: core
+audience: default
+stability: stable
+suggests:
+  - command:idea
+  - agent:product-owner
+  - skill:brainstorming-and-design
+  - command:spec
+  - command:plan-review
+  - command:task-plan
+platforms:
+  - qwen
+  - codex
+  - claude
+  - opencode
+workflow_family: lifecycle
+workflow_role: workflow-entry
+routing_workflows:
+  - product-analysis
+task_types:
+  - feature
+  - investigation
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
+source:
+  upstream: toolkit-original
+  strategy: curated
+  notes: 本仓库整理的产品分析入口，用于承接 start 的 product-analysis workflow，并把模糊需求压成可执行方案。

package/vendor/packages/toolkit/src/content/commands/qa/meta.yaml

@@ -12,7 +12,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/quality-review/body.md

@@ -1,6 +1,8 @@
-调用 `code-review-and-quality`，审查当前变更。
+这是 `command:start` 之后的 **实现后审查阶段入口**。
 
-## 核心动作
+当 `command:build` 已完成当前切片或当前变更已经成型，就从这里接力到 `code-review-and-quality`，判断是否可以继续收口。
+
+## 当前阶段要做什么
 
 执行五维度审查：
 
@@ -11,28 +13,21 @@
 5. **性能**：是否引入无界操作、热点低效或资源问题
 
 输出按 `Critical / Important / Suggestion` 分级，附具体位置和修复建议。
-如果审查结论包含待处理问题，继续进入 `review-response-and-resolution`，把反馈分类、修复、回归验证和回复动作收敛完。
+如果发现待处理问题，继续进入 `review-response-and-resolution` 做响应、修复和回归。
 
-## 相关原则
+## 当前阶段的边界
 
 - 先报真实问题，再做概括总结
 - 优先指出会阻塞合并的缺陷
 - 评审结论必须有代码位置或验证依据支撑
-- 审查结束不等于闭环结束；有问题就必须进入响应闭环
-
-## 使用方式
+- 审查通过前，不进入“已完成”叙事
 
-在 `/quality-review` 后指定审查范围，我会输出结构化中文审查报告。
+## 从这里通常接到哪里
 
-### 示例
+- 审查通过：进入 `command:verify`
+- 审查发现问题：进入 `review-response-and-resolution`，然后回到验证
+- 如果问题暴露计划失真，可回到 `command:task-plan`
 
-```
-# 审查最近的 git 变更
-/quality-review 检查最近的 git 变更，重点关注安全性和性能
-
-# 审查指定文件
-/quality-review 审查 src/services/PaymentService.java
+## 使用方式
 
-# 审查指定 PR
-/quality-review 检查 PR #142 的变更，这是数据库分页查询优化
-```
+提供当前变更范围、文件、提交或任务上下文，我会输出结构化中文审查报告，并明确下一步是否进入验证。

package/vendor/packages/toolkit/src/content/commands/quality-review/meta.yaml

@@ -15,7 +15,19 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: lifecycle
+workflow_role: stage-entry
+task_types:
+  - feature
+  - bugfix
+  - review
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: superpowers
   strategy: inspired

package/vendor/packages/toolkit/src/content/commands/retro/meta.yaml

@@ -13,7 +13,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/sdd-tdd/body.md

@@ -1,39 +1,39 @@
-调用 sdd-tdd-workflow 技能。按阶段门控推进完整开发生命周期：
+这是 `command:start` 完成任务评估后的 **完整开发工作流入口**。
 
-1. **Spec** - 分析需求，列出假设和约束，编写技术规格（调用 spec-driven-development）
-2. **Plan Review**（可选）- 多视角评审 Spec（调用 multi-perspective-review）
-3. **Task Plan** - 将 Spec 拆解为原子任务，标注依赖（调用 planning-and-task-breakdown）
-4. **Build** - 对每个任务执行 TDD Red-Green-Refactor 循环（调用 incremental-implementation + test-driven-development）
-5. **Quality Review** - 五维度代码审查，确认无 Critical 问题（调用 code-review-and-quality）
-6. **Commit** - 审查通过后，代理收集变更并生成提交消息，展示摘要，**等待用户确认后执行提交**（调用 git-workflow-and-versioning）
-7. **Retro**（可选）- Sprint 回顾，提取改进项（调用 sprint-retrospective）
+当任务属于新功能、较大改动或需要完整门控时，从 `command:start` 接力到这里，由 `sdd-tdd-workflow` 按阶段推进。
 
-每个阶段完成后 **停下等待人类确认** 再继续。
+## 阶段顺序
 
-如果某些阶段已完成，可单独使用子命令：
+1. **Spec**：澄清目标、假设、边界和成功标准
+2. **Plan Review**（可选）：对 Spec 做多视角评审
+3. **Task Plan**：拆成可验证、可并行、可落地的任务
+4. **Build**：按 TDD 循环逐项实现
+5. **Quality Review**：做五维度代码审查
+6. **Commit**：审查通过后准备提交，等待用户确认
+7. **Retro**（可选）：回顾本轮产出与改进项
 
-| 场景 | 推荐命令 |
-|------|----------|
-| 需求不清晰 | `/spec` 先理清 |
-| 已有 Spec | `/task-plan` 直接拆解 |
-| 已有 Plan | `/build` 逐个实现 |
-| 实现完成 | `/quality-review` 审查 |
-| 审查通过 | `/commit` 代理提交 |
-| 小修改 / Bug | `/build` 或 `/debug` |
+每个阶段完成后都要停下，等待人类确认再进入下一阶段。
 
-## 使用方式
+## 何时使用
+
+- `command:start` 判断这是一个完整交付任务
+- 需求还不够清晰，但后续会进入 Spec → Plan → Build 全流程
+- 你不想手动判断下一步该进哪个阶段，而是希望按门控顺序推进
 
-在 `/sdd-tdd` 后描述你的需求，我将按阶段门控流程推进开发。
+## 何时不要直接使用
 
-### 示例
+- 已经有明确 Spec，只需要进入 `command:task-plan`
+- 已经有计划，只需要进入 `command:build`
+- 只需要做专项排查、文档更新或单点审查
 
-```
-# 新功能开发（完整流程）
-/sdd-tdd 实现用户登录功能，支持邮箱+密码登录和 JWT Token 刷新
+## 当前入口之后的典型接力
 
-# 带约束的需求
-/sdd-tdd 实现订单导出功能，支持 CSV 和 Excel 格式，需要分页查询避免内存溢出
+- 需求未定型：进入 `command:spec`
+- Spec 写完：进入 `command:plan-review` 或 `command:task-plan`
+- 计划确认：进入 `command:build`
+- 实现完成：进入 `command:quality-review`
+- 审查收敛后：进入 `command:verify`
+
+## 使用方式
 
-# 从零搭建
-/sdd-tdd 搭建一个 React + Vite 前端项目，包含路由、状态管理和基础组件库
-```
+描述你的任务目标，我会先确认这是否应该走完整 workflow；如果是，就按上面的阶段顺序推进。

package/vendor/packages/toolkit/src/content/commands/sdd-tdd/meta.yaml

@@ -16,7 +16,17 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: lifecycle
+workflow_role: workflow-entry
+task_types:
+  - feature
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/secure/meta.yaml

@@ -12,7 +12,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/ship/body.md

@@ -1,17 +1,22 @@
-调用 `shipping-and-launch`，对发布前状态做门禁检查，并明确回滚方案。
+这是 `command:start` 评估后进入的专项入口：当任务核心是发布准备、上线决策和回滚预案时，转到 `ship`。
 
-## 核心动作
+调用 `shipping-and-launch`，对发布前状态做门禁检查，并明确回滚与观测方案。
 
-1. 检查代码质量、验证状态和审查结果
-2. 检查安全、性能和基础设施准备情况
-3. 确认文档、变更说明和回滚方案
-4. 输出发布就绪结论和剩余阻塞项
+## 何时直接用这个入口
 
-## 边界说明
+- 代码与验证已接近完成，当前要判断能不能上线
+- 需要整理发布说明、灰度策略、监控点和回滚方案
+- 需要明确剩余阻塞项，而不是继续盲目推进实现
 
-- `ship` 是发布前入口命令
-- 更完整的上线策略、灰度和监控方案由 `shipping-and-launch` 负责
+## 何时回到 lifecycle
 
-## 使用方式
+- 发现需求、范围或上线条件还没定义清楚：回到 `spec` 或 `task-plan`
+- 发现发布阻塞来自实现缺口：回到 `build`
+- 发布前检查需要补最后验证：接 `verify`
 
-在准备上线、设计灰度发布或编写回滚预案时使用 `/ship`。
+## 执行重点
+
+1. 检查质量门禁、验证结果和审查结论
+2. 检查安全、性能、配置和基础设施准备情况
+3. 确认文档、变更说明、回滚方案和发布顺序
+4. 输出发布就绪结论、阻塞项和建议动作

package/vendor/packages/toolkit/src/content/commands/ship/meta.yaml

@@ -14,7 +14,17 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: specialized
+workflow_role: specialized-entry
+task_types:
+  - release
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/simplify/meta.yaml

@@ -12,7 +12,8 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
 source:
   upstream: toolkit-original
   strategy: curated

package/vendor/packages/toolkit/src/content/commands/spec/body.md

@@ -1,32 +1,27 @@
-调用 `spec-driven-development`，先把问题定义清楚，再开始写代码。
+这是 `command:start` 之后的 **规格定义阶段入口**。
 
-## 核心动作
+当 `command:start` 判断任务需要先澄清需求、边界和成功标准时，就从这里接力到 `spec-driven-development`。
 
-1. 理解用户目标、用户对象、核心功能和约束
+## 当前阶段要做什么
+
+1. 理解目标、用户对象、核心能力和约束
 2. 列出显式假设，并等待确认
 3. 定义可测试的验收标准，优先用 Given-When-Then
-4. 编写结构化技术规格：目标、边界、约束、验证方式
+4. 编写结构化规格：目标、边界、约束、验证方式
 5. 记录不确定项，禁止带着模糊前提直接进入实现
 
-## 相关原则
-
-- 先澄清假设，再写规格
-- 范围边界必须显式，不用自然语言暗示
-- 规格阶段只产出定义，不直接写实现代码
+## 当前阶段的边界
 
-## 使用方式
+- 这里只产出定义，不直接写实现代码
+- 重点是把问题定义清楚，而不是提前做设计细节
+- 如果发现范围不稳，继续留在规格阶段，不要跳到实现
 
-在 `/spec` 后描述需求，我会分析上下文并输出结构化技术规格。
+## 从这里通常接到哪里
 
-### 示例
+- 规格需要多视角把关：进入 `command:plan-review`
+- 规格已经可执行：进入 `command:task-plan`
+- 如果任务被重新判断为小修或专项排查，可回到更合适的专项入口
 
-```
-# 需求还不清晰
-/spec 我想做一个数据同步模块，从 A 系统定时拉取数据到 B 系统
-
-# 功能需求较明确
-/spec 实现文件上传功能，支持图片和 PDF，最大 10MB，存储到 MinIO
+## 使用方式
 
-# 审查现有 PRD
-/spec 分析这个 PRD 文档，找出技术实现的歧义点和风险点
-```
+提供需求、PRD、问题描述或目标约束，我会输出结构化规格，并明确后续是进入评审还是计划阶段。

package/vendor/packages/toolkit/src/content/commands/spec/meta.yaml

@@ -13,7 +13,18 @@ suggests:
 platforms:
   - qwen
   - codex
-  - qoder
+  - claude
+  - opencode
+workflow_family: lifecycle
+workflow_role: stage-entry
+task_types:
+  - feature
+  - bugfix
+platform_exposure:
+  codex: prompt-entry
+  qwen: command-style
+  claude: command-style
+  opencode: command-style
 source:
   upstream: agent-skills
   strategy: adapted