pi-ixel/Awesome-Agent-Workflow

aaw-workflow

配置驱动的 AAW 工作流 CLI 入口技能。读取 aaw CLI 返回的自描述工作单，按工作单调用子技能、执行 prompt、检查交付件并推进流程。提供 sr（严谨流程）、ar（从 AR 切入）和 dev（个人开发者轻量流程）三个入口。

dev-design-gate

个人开发者轻量设计门禁。对 dev-design.md 做 7 项质量检查，判断其是否足以进入任务拆分（task-split），输出 通过/不通过/阻塞 结论与整改清单。报告落盘 .sdd/{SR}/.context/dev-design-gate.md，只写结论与需整改项，不填充冗余模板。Use when the user asks for 轻量门禁、设计检查、dev-design-gate，或通过 aaw-workflow 的 dev 入口完成设计后进行门禁。

dev-design

个人开发者轻量设计。把一个需求一次性收敛为单份 dev-design.md，覆盖需求、现状、方案、契约变更、影响面、验收标准、存疑和现状附录，替代 SR 入口的功能设计、AR 澄清、模块边界与 TOBE 详设四段。设计前先读需求与架构，启动 SubAgent 委托代码探索并带回带引用的报告；主进程基于报告汇总「现状摘要」（需求与方案之间）与「现状附录」（文末全量）。取证后按设计树轮次制向用户提问：一轮抛出当前全部可问问题并各带推荐答案，逐题等用户表态后再按新前沿推进下一轮。不再分档，篇幅由需求复杂度自然决定。Use…

task-dev

按 AAW task-dev 工作单实现一个明确的 T[N] 任务，并通过 CLI 持久化阶段状态，完成实现与测试、独立语义 Review、修复重验、独立 CodeCheck subAgent 门禁和候选 commit message。Use when the user asks to 实现当前 Task、执行 task-dev、继续或恢复 T1/T2 开发。支持严格模式（SR/AR 入口，以模块详细设计与测试用例设计为事实来源）与轻量模式（dev 入口，以单份 dev-design.md…

task-split

基于已确认的设计与测试规格，生成单文件薄任务计划 tasks-overview.md；任务只保留目标、范围、权威设计/测试引用、依赖和状态，不复制或改写设计正文。Use when the user asks for 任务拆分、开发任务规划、有序任务计划、task split，或希望把已评审设计组织为可串行调度的 T1/T2 任务。支持两种模式：严格模式（SR/AR 入口）以详细设计文档、测试用例设计文档和通过的模块设计门禁结果为输入；轻量模式（dev 入口）以单份 dev-design.md…

effective-document-writing

起草、重构或评审面向交付的技术文档、设计文档、方案、报告、说明和 Markdown。用于解决主线不清、黑话或空话过多、内容重复、细节淹没重点、术语混乱，以及把对话和修改过程带入正式文档等问题；不替代特定文件格式的排版工具。

mermaid-diagram

为 Markdown 和技术文档选择、编写、审视并离线编译验证 Mermaid 图。当前任务涉及流程、时序、状态、依赖或数据关系，且图比文字或表格更利于理解和评审时使用；不用于装饰文档或替代本应精确定义的契约。

sr-design

帮助开发者创建功能/模块设计文档。用户描述系统整体要做什么，你负责研究代码仓库， 确定如何调整内部结构来实现目标，并通过逐题澄清消除所有不确定细节。 文档聚焦软件架构、功能设计与模块设计，而非代码实现细节。

module-design-gate

对当前 SDD 工作流指定的正式《模块详细设计说明书.md》和独立《模块测试用例设计.md》进行质量门禁检查，围绕证据链、边界链、执行链、验证链和风险链判断成果物是否足以支持用户评审并进入后续 AICoding，同时识别实现细节越界、核心设计未讲清和冗余重复等低质量内容。当前需要确认详设和测试设计是否可进入 AICoding、发现阻断问题、生成整改清单、驱动回到 ASIS、TOBE 或测试设计补齐并多轮复检时使用。门禁阶段不得编辑正式说明书、测试设计正文或详细设计上下文；门禁结论单独写入模块目录下的…

module-test-design

基于模块目录下的正式《模块详细设计说明书.md》、`.context/详细设计上下文.md` 中的 ASIS 测试覆盖现状和 TOBE 可测试性输入，生成同目录下的独立《模块测试用例设计.md》。本 skill 只输出最小充分测试用例集、覆盖矩阵、断言、建议位置和缺口；不得替 TOBE 补设计，不得拆分 AICoding 任务。

module-tobe-design

基于当前 SDD 工作流指定的正式《模块详细设计说明书.md》及模块目录下的 `.context/详细设计上下文.md`，设计模块内与本次需求相关的 TOBE 详细方案。TOBE 是唯一可以编辑正式说明书的阶段，必须按正式大纲写入需求背景、外部依赖、整体方案、模块详细方案、对外接口、数据库/表设计、受影响模块与交互、关键契约清单和附录/三方件约束。TOBE 只负责目标设计和可测试性输入，不生成测试用例，不拆分 AICoding 任务；测试用例设计交由…

repo-init

Use when the user asks for 软件实现设计/software_architect/初始化代码仓/sdd/初始化/init/更新代码仓软件架构/更新代码仓软件实现设计.

原文语言：多语言混合

ar-clarify

基于 SR 设计文档中的指定 AR，或基于直接提供的 AR 原文/描述， 从代码实现角度审视并澄清未覆盖的细节，生成独立的 AR 范围文档作为后续详细设计和开发的唯一输入。

sr-design-gate

对 SR-design.md 进行设计质量门禁，检查需求范围、架构边界、接口与数据契约、验收闭环、风险处置、图表变更表达以及文档跨章节一致性。用于 SR 设计完成后、进入 ar-split 前判断 SR 级设计是否完整，并输出通过、不通过或阻塞结论。

module-asis-analysis

对代码仓中某个模块内与特定 SDD 需求、AR、功能点、影响范围或计划变更相关的部分进行 ASIS 逆向分析，并只更新模块目录下的 `.context/详细设计上下文.md`，记录关键事实、证据索引、调用链、工程约束、规格漂移和阻塞项。当前置 TOBE 详细设计、门禁或 AICoding 需要基于代码证据确认现状事实、隐藏约束、依赖、风险、测试覆盖和实现行为时使用。ASIS 阶段不得创建或编辑正式《模块详细设计说明书.md》；正式说明书只能由 TOBE 阶段基于详细设计上下文中的证据生成。必须存在…

module-boundary-design

模块边界设计。基于已完成的功能设计（SR-design），识别受影响模块，逐模块定义边界（职责、上游依赖、下游暴露），绘制模块交互时序，并通过对抗式审查发现边界冲突（职责泄漏、循环依赖、边界破坏、重复能力）。输出 module-boundary-design.md。用于AAW工作流步骤3。Use when the user asks for 模块边界设计、module-boundary-design。

module-deep-research

使用独立 CLI 执行连续、长程的既有模块研究，通过当前代码取证、Git 提交线索反查和用户补充问题三条轨道，把代码、测试、配置和文档中的当前行为沉淀为经过最终审查的专家级模块认知资产。支持完成后重新追加问题并刷新认知。适用于深入理解模块职责、运行路径、数据与状态、外部契约、失败恢复、并发一致性、配置、安全、可观测性、性能和变更风险。只读业务代码，只写 .sdd/modules/<module>/；不依赖 aaw-workflow。