All authors
Claude Skills by mingdui
github.com/mingdui19 skills0 installs0 views
- Qa Code ReviewerQA 流程倒数第二步的独立审查环节。在 qa-test-runner 执行完成后，以独立视角审查代码本身——检查架构、安全、并发正确性、数据一致性、 回归风险、测试覆盖缺口——不受执行方结论的影响。产出 code-review.json（含 severity 分级发现和 readiness 约束）， 和 assert-code-review 门禁一起构成代码审查证据，交给 qa-report-generator 汇入最终报告。P0/P1 安全问题、资金逻辑缺陷、权限漏洞、数据不一致风险标记为 blocking。 不适用：生成用例、执行测试、修改产品代码（除非用户明确要求）、报告生成。Votes: 0GitHub stars: 22
- Qa Context ProfilerQA 上游阶段——为仓库构建事实画像和环境证据。当你需要收集模块的代码上下文、索引已有用例和测试、 检查前后端服务可达性、准备环境快照时触发。只收集事实，不做风险分析、不写用例、不判断质量。 通常在 quality-assurance-agent 的调度下作为第一阶段执行。 不适用：风险分析、用例设计、测试执行、质量判定（由下游阶段负责）。Votes: 0GitHub stars: 22
- Qa Report GeneratorQA 流程的收口阶段——汇总执行（completion）、审查（code-review）、就绪（readiness）三个门禁产物，渲染最终 HTML 报告，给出最终就绪判定。 在 qa-test-runner 执行完成、qa-code-reviewer 审查完成后触发。只读已有门禁产物，不重新执行测试、不审查代码。 不适用：执行测试、修复失败、代码审查、用例设计。Votes: 0GitHub stars: 22
- Qa Risk Analyzer在测试用例设计之前，先识别高风险业务路径和必需的验证断言（oracle）。分析需求文档、代码 diff、已有用例和上下文， 找出资金/权限/状态机/并发/异步/数据一致性等高危区域，输出每条风险的 businessPath、requiredAssertions、suggestedTestLayers， 以及覆盖率缺口。不要在风险未明确前写业务用例。 不适用：写业务用例、写测试代码、修改产品代码。Votes: 0GitHub stars: 22
- Qa Test Runner在 spec-task 和测试脚本就绪后，逐条执行、分类失败、修最小根因、收集证据、跑 completion 门禁。 你只负责"跑"——不生成报告、不审查代码、不判 Ready。审查留给 qa-code-reviewer，报告与判定留给 qa-report-generator。 不适用：报告生成、代码审查、用例设计。Votes: 0GitHub stars: 22
- Qa Test Script Generator在用户确认用例之后，把已确认的业务用例展开为可执行的 spec-task 和测试脚本。你产出的是 test-spec-tasks.json——后续执行阶段通过它逐条运行并收集证据。 你只负责"生成可执行的东西"，不负责"执行"。pass/fail/ready 的判断由后续的执行阶段来做。 不适用：执行测试、标记 pass/fail、就绪判定。Votes: 0GitHub stars: 22
- Qa Testcase Designer在风险分析完成后、写测试代码之前，生成中文业务用例并等待用户确认。这是整个 QA 流程中唯一的强制人工门禁——确认后不可回头改用例。 从 context、risk-analysis、已有用例索引出发，生成只含业务行为的 test-cases.json（不含技术检查如 Maven/build/安装）， 渲染 test-cases.html 供用户审阅，运行三模型交叉审查，合成反馈修改后提交确认。确认后 promote 到长期 knowledge base。 不适用：写测试代码、执行测试、代码审查。Votes: 0GitHub stars: 22
- Quality Assurance Agent端到端 QA 验收编排器。当用户要求做功能验收、回归测试、质量检查、或对某个模块/流程/branch/PR进行系统化测试时触发。 作为顶层路由器，按阶段调度子 skill（上下文收集 → 风险分析 → 用例设计 → 脚本生成 → 执行与修复 → 代码审查 → 报告生成）。 你自己不写测试代码也不直接判断质量——你把每个阶段交给专职子 skill 处理。 用例确认是流程中唯一的强制人工门禁，其余阶段自动衔接。 不适用：单次手动测试、纯开发/代码生成任务、无明确验收范围的技术问答。Votes: 0GitHub stars: 22
- Acceptance Checklist基于 PRD 和交付包生成结构化验收清单，产出 docs/prd/<feature-name>/acceptance.md。按核心流程、边界与异常、UI 还原度、数据埋点四个维度拆解，每条标 P0/P1/P2 优先级并注明依据出处（引用 PRD 的需求编号）。适用于研发提测后的产品走查、上线前的功能验收；不用于写测试代码、执行自动化测试或判定代码质量。Votes: 0GitHub stars: 4
- Context To Prd把已经聊透的需求上下文直接落成 PRD，不做采访。适用于你已经跟 AI 把问题、边界、方案讨论清楚，只差成文的场景；需求还停在口头、边界没问清时改用 requirement-clarify，要复用已有产品体验基线或做增量 PRD 时用 prd-write。产物与 prd-write 完全同构，落在 docs/prd/<feature-name>/prd.md。Votes: 0GitHub stars: 4
- Design Spec Prototyper将 `design.md` / `DESIGN.md` 等有证据支撑的设计规格，**配合设计稿图片或截图**，转为高保真、无障碍且响应式的 UI 原型。规格提供品牌令牌、组件规则与字体（持续沉淀的产品事实），图片提供本次页面的实际构图，两者同时参考。适用于用 HTML/Tailwind、React、Next.js、Vue 或其他前端技术栈设计并实现原型的场景；在线独立原型默认可使用 Google Fonts；仅在规格缺少 UX 或实现指导时结合你自己已装的设计类 skill。Votes: 0GitHub stars: 4
- Grill With Prd针对 PRD 文档的逐项审查会话，挑战需求的完整性、一致性和可实现性，并将确认的决策同步回 docs/prd/{feature-name}/prd.md。适用于用户想在开始实现前压测 PRD 的场景。Votes: 0GitHub stars: 4
- Pm Frontend Prototype仅当用户明确要求在已有前端项目中生成、制作、构建或完善“原型”（例如高保真原型、可点击演示或评审 Demo）时使用此 Skill。默认基于现有源码复用组件、设计变量和技术栈，创建与正式业务入口隔离的原型页面或路由，并使用页面级模拟数据完成可点击演示；除非用户明确要求，否则不直接改动正在使用的业务页面、不接入后端或生产数据链路。Votes: 0GitHub stars: 4
- Prd Write编写或维护项目内的 PRD。适用于首版/重大方案的完整 PRD，也适用于已有产品基线后的功能迭代 PRD；先复用 docs/product 下已确认的体验规则，只记录本次新增、偏离、候选模式和待决问题。输出保存到 docs/prd 下的功能目录。Votes: 0GitHub stars: 4
- Product Experience Foundation为一个具体产品项目建立或维护可持续演进的体验基线，包括产品上下文、C 端或 Admin 的信息架构、视觉与交互规则、页面模式和组件晋升记录。适用于首版 PRD、项目启动、跨功能体验不一致，或已确认的重复模式需要升级为产品级规范时使用；不用于单个孤立功能的常规实现。Votes: 0GitHub stars: 4
- Product Prd Extract把 Word（.docx）PRD 或粘贴的 PRD 文本转成结构化 Markdown，落到 docs/prd/<feature-name>/prd.md，直接接进本仓库的链路。当用户提到「解析 PRD」「提取需求文档」「PRD 转结构化」「PRD 转 Markdown」「Word 转需求」「导入 PRD」，或直接丢来一个 .docx 要求分析时使用。适用于需求来源方只给了一份 Word 的情况；不需要解析 Word、要直接写 PRD 时用 prd-write 或 context-to-prd。Votes: 0GitHub stars: 4
- Prototype Html生成交互式HTML产品原型的专家技能。当用户需要创建产品原型、UI界面原型、 可交互的HTML演示页面、产品功能展示页面，或提到"原型"、"prototype"、 "产品界面"、"UI原型"、"交互原型"、"演示页面"等时使用。Votes: 0GitHub stars: 4
- Requirement Clarify在写 PRD 之前，用采访的方式把一句模糊需求补成可以落笔的完整输入。逐个问清目标角色、触发场景、范围、明确不做的部分和已知约束，产出 docs/prd/<feature-name>/clarify.md。适用于需求还停留在口头、聊天记录或一句话描述，或需求来源方只讲了「要什么」没讲「边界在哪」的情况；不用于评审已成文的 PRD（那一步用 grill-with-prd）。Votes: 0GitHub stars: 4
- Web Design Extractor从公开网站或已获授权的网站 URL、一个或多个网页截图中提取有证据支撑、可直接用于实现的 `design.md`。适用于需要为复刻、设计系统文档或 UI 实现简报逆向分析网站的视觉系统、布局、组件、响应式行为、内容层级或交互状态的场景。Votes: 0GitHub stars: 4