‹ 首页

qa-commit

@wellapp-ai · 收录于 5 天前 · 上游提交 1 个月前

Verify implementation against QA Contract (G#N, AC#N), auto-invoke debug on RED

适合你,如果需要在提交前自动检查代码是否满足QA合约

/ 通过 npx 安装 校验哈希
npx oh-my-skill add wellapp-ai/well/qa-commit
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- wellapp-ai/well/qa-commit
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify wellapp-ai/well/qa-commit
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
340GitHub stars
~1.1K上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 782601c · 表述以原文为准
它做什么

装上后,Claude 会在提交前检查代码是否满足指定的测试场景和验收标准。如果全部通过,返回 GREEN;如果有失败项,返回 RED 并自动启动调试流程来修复。

什么时候触发

在 PR 审查通过后、提交代码前自动触发,或在提交工作流中自动运行。也可手动说“use qa-commit skill”来执行。

装好后可以这样说
Claude 将检查这两个标准并报告结果。
执行所有验证阶段并给出最终裁定。
触发完整验证流程,包含技术检查和测试。
技能原文 SKILL.md作者撰写 · MIT · 782601c

QA Commit Skill

Verify that the current commit satisfies its assigned QA Contract criteria (G#N Gherkin scenarios and AC#N acceptance criteria). Returns GREEN (pass) or RED (fail, triggers debug).

When to Use
  • After pr-review passes, before git commit
  • During Agent Mode commit-level workflow
  • Manually with "use qa-commit skill"
Input: Commit Context

Before running, identify:

  1. Current commit from Commit Plan
  2. Assigned criteria: "Satisfies: G#X, AC#Y, ..."
  3. Related files being changed
Phase 1: Load QA Contract

Retrieve the assigned criteria for this commit:

## Commit: [Name]
**Satisfies:** G#1, G#2, AC#1, AC#3

### Criteria to Verify:
- G#1: [Scenario description]
- G#2: [Scenario description]
- AC#1: [Acceptance criteria]
- AC#3: [Acceptance criteria]
Phase 2: Technical Validation

Use Cursor tools for technical checks:

2.1 ReadLints
ReadLints:
  paths: [changed files]

Expect: No errors related to committed functionality

2.2 Type Safety
npm run typecheck

Expect: Exit code 0

2.3 Related Tests (if exist)
npm run test -- --grep "[feature name]"

Expect: All tests pass

Phase 3: Gherkin Verification (Backend - G#N)

For each G#N assigned to this commit:

3.1 Endpoint Existence

Verify the API endpoint exists and is implemented:

SemanticSearch: "Where is [endpoint] implemented?"
3.2 Response Shape

Check response matches expected schema:

Grep: "interface.*Response" in related files
3.3 Error Handling

Verify error cases are handled:

Grep: "throw|catch|error" in handler files
Gherkin Checklist

| G#N | Scenario | Status | Notes | |-----|----------|--------|-------| | G#1 | [Name] | PASS/FAIL | [Details] | | G#2 | [Name] | PASS/FAIL | [Details] |

Phase 4: Acceptance Verification (Frontend - AC#N)

For each AC#N assigned to this commit:

4.1 Component Existence

Verify component is implemented:

Glob: **/*[ComponentName]*.tsx
4.2 Storybook Story (if AC involves visual)

Check Storybook story exists:

Glob: **/*[ComponentName]*.stories.tsx
4.3 Browser MCP Verification (if running)

For interactive acceptance criteria:

Browser MCP:
1. browser_navigate to Storybook URL
2. browser_snapshot to check state
3. browser_click/browser_type to test interaction
4. browser_take_screenshot for evidence
Acceptance Checklist

| AC#N | Criteria | Status | Evidence | |------|----------|--------|----------| | AC#1 | [Criteria] | PASS/FAIL | [Screenshot/Notes] | | AC#3 | [Criteria] | PASS/FAIL | [Screenshot/Notes] |

Phase 5: Generate Verification Report
## Verification Report

**Commit:** [Name]
**Satisfies:** G#1, G#2, AC#1, AC#3

### Technical Validation

| Check | Status |
|-------|--------|
| ReadLints | PASS/FAIL |
| TypeCheck | PASS/FAIL |
| Tests | PASS/FAIL/SKIP |

### Gherkin Scenarios (Backend)

| ID | Scenario | Status | Notes |
|----|----------|--------|-------|
| G#1 | [Name] | PASS/FAIL | [Details] |
| G#2 | [Name] | PASS/FAIL | [Details] |

### Acceptance Criteria (Frontend)

| ID | Criteria | Status | Evidence |
|----|----------|--------|----------|
| AC#1 | [Criteria] | PASS/FAIL | [Link/Notes] |
| AC#3 | [Criteria] | PASS/FAIL | [Link/Notes] |

### Verdict

**[GREEN / RED]**

[If GREEN: All criteria verified, ready to commit]
[If RED: Failed criteria listed, invoking debug skill]
Phase 6: Handle Verdict
GREEN Verdict
All criteria verified. Proceeding to git commit.
RED Verdict - Auto-Invoke Debug
**Verification failed. Auto-invoking debug skill.**

### Failed Criteria:
- [G#N or AC#N]: [What failed]
- [G#N or AC#N]: [What failed]

### Context for Debug:
- Error messages: [from ReadLints]
- Expected behavior: [from QA Contract]
- Actual behavior: [observed]

Invoking debug skill with context...

After debug fixes, re-run qa-commit to verify.

Integration with Debug

When verdict is RED:

  1. Automatically invoke debug skill
  2. Pass context:
  3. Failed G#N or AC#N
  4. Error messages from ReadLints/Shell
  5. Browser console/network errors (if applicable)
  6. Debug skill fixes issue
  7. Re-run qa-commit
  8. Repeat until GREEN or user intervention
MCP Tools Used

| Tool | Purpose | |------|---------| | ReadLints | Get lint/type errors | | Shell | Run tests, typecheck | | Browser MCP | Storybook verification | | SemanticSearch | Find implementations | | Grep | Search for patterns |

Invocation

Invoked by:

  • commit.mdc - After pr-review passes
  • agent.mdc - Part of commit-level workflow

Or manually with "use qa-commit skill".

按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。