awesome-agent-workflow

Plugin awesome-agent-workflow from marketplace awesome-agent-workflow in pi-ixel/Awesome-Agent-Workflow. Commands read from the repo's manifest — yesterday.

Skills (22)

• aaw-workflow

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

• ar-clarify

  基于 SR 设计文档中的指定 AR，或基于直接提供的 AR 原文/描述， 从代码实现角度审视并澄清未覆盖的细节，生成独立的 AR 范围文档作为后续详细设计和开发的唯一输入。 - pattern: | (?:澄清|细化|审视|检查|review|分析|提取).*(?:AR|分配需求|需求条目) description: 用户想要对某条 AR 进行实现层面的澄清，可来自 SR 设计文档，也可来自直接 AR 输入。

• code-check

  使用随 Skill 发布的 CodeCheck CLI 检查代码变更，直接修复明确、局部且低风险的问题并复查；当修复涉及业务行为、公共契约、数据兼容、安全边界、已评审设计或大范围重构时，停止并请求用户决策。适用于功能实现后、提交或交付前的代码质量检查，也可独立调用。

• dev-design-gate

  个人开发者轻量设计门禁。对 dev-design.md 与 test-design.md 做 3 项准入检查——决策已收敛、代码论断可回溯、契约与验收可执行——判断设计是否足以进入任务拆分（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：需求、现状摘要、方案、契约变更、影响面、验收标准、存疑。问人与问代码是同一个循环的两个出口——代码能答的问题攒批取证（优先委托只读 SubAgent，无宿主支持时主进程只读批量取证），代码证不出的问题按设计树轮次向用户提问（一轮抛全部前沿、各带推荐答案）。不设独立现状附录，代码论断在方案、契约变更、影响面处内联 file:line 引用。Use when the user asks for 轻量设计、个人项目设计、dev-design，或通过 aaw-workflow 的 dev 入口进入设计阶段。

• effective-document-writing

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

• mermaid-diagram

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

• module-asis-analysis

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

• 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。

• module-design-gate

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

• module-test-design

  把已定稿的设计目标、契约、流程、异常边界、风险和可测试性输入转化为可执行的最小充分验证集，输出独立测试用例设计文档。本 skill 只输出最小充分测试用例集、覆盖矩阵、断言、建议位置和缺口；不得替设计补内容，不得拆分 AICoding 任务。支持两种模式：严格模式（SR/AR 入口）基于模块目录下的正式《模块详细设计说明书.md》与 `.context/详细设计上下文.md`，生成同目录《模块测试用例设计.md》；轻量模式（dev 入口）基于单份 `dev-design.md`，生成 `.sdd/{SR}/test-design.md`，由工作单显式声明。

• module-tobe-design

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

• open-code-review

  使用 alibaba/open-code-review（ocr CLI）对 Git 变更执行 AI 代码评审：OCR 以确定性工程完成文件选择与规则匹配，产出行级定位、按严重度分级的结构化意见（bug/安全/性能等）。默认委托模式由当前 Agent 执行评审，无需配置额外 LLM；也可切换 OCR 托管模式。适用于功能实现后、提交或交付前的语义级代码评审，也可独立调用。

• repo-init

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

• skill-a

  理清多模块代码仓的模块之间的关系，产出模块关系说明（占位：替换为真实技能内容）。

• skill-b

  为单个模块产出模块设计说明书（占位：替换为真实技能内容）。

• skill-c

  汇总所有模块设计说明书，综合输出设计总览（占位：替换为真实技能内容）。

• sr-design-gate

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

• sr-design

  帮助开发者创建功能/模块设计文档。用户描述系统整体要做什么，你负责研究代码仓库， 确定如何调整内部结构来实现目标，并通过逐题澄清消除所有不确定细节。 文档聚焦软件架构、功能设计与模块设计，而非代码实现细节。 - pattern: | (?:写|创建|生成|输出|帮我|写一份|出一份|设计).*(?:design\s*doc|设计文档|技术方案|详细设计|功能设计|模块设计) description: 用户想要创建或完善功能/模块设计文档。

• task-dev

  按 AAW task-dev 工作单实现一个明确的 T[N] 任务，并通过 CLI 持久化阶段状态。实现与测试先交 implementation.json，随后语义 Review、修复重验、CodeCheck 与候选提交信息合并交一份 completion.json。Use when the user asks to 实现当前 Task、执行 task-dev、继续或恢复 T1/T2 开发。支持严格模式（SR/AR 入口，以模块详细设计与测试用例设计为事实来源）与轻量模式（dev 入口，以 dev-design.md 与 test-design.md 为事实来源），由工作单显式声明。每次只处理

• task-split

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

MCP servers (1)

• question-tracker

  runs: uv run --with fastmcp python ${CLAUDE_PLUGIN_ROOT}/skills/sr-design/mcp_server.py

Similar plugins