メニュー
QA validation and fix loop workflow — validates implementation completeness then iterates fix cycles until all acceptance criteria pass and quality gates clear
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/oimiragieo/agent-studio --skill qa-workflowコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Agent frontmatter enhancements — disallowedTools, mcpServers scoping, fork_eligible field
Context management — pre-compact persistence, threshold alignment, microcompact/circuit breaker detection
Hook enhancements — updatedInput for bash safety prefixes, suppressOutput for verbose blocks, denial-based routing feedback
SOC 職業分類に基づく
SKILL.md を表示中
| name | qa-workflow |
| description | QA validation and fix loop workflow — validates implementation completeness then iterates fix cycles until all acceptance criteria pass and quality gates clear |
| version | 1.1.0 |
| model | sonnet |
| invoked_by | both |
| user_invocable | true |
| tools | ["Read","Write","Edit","Bash","Glob","Grep"] |
| agents | ["qa","developer","code-reviewer"] |
| category | Validation & Quality |
| tags | ["qa","testing","validation","fix-loop","quality-assurance","sign-off"] |
| verified | true |
| lastVerifiedAt | "2026-02-22T00:00:00.000Z" |
| best_practices | ["Be thorough - you are the last line of defense","Be specific with file paths and line numbers","Fix what QA found, don't add features"] |
| error_handling | graceful |
| streaming | supported |
| source | builtin |
| trust_score | 100 |
| provenance_sha | 20cc308c655217c9 |
Comprehensive quality assurance workflow that validates implementation completeness and correctness, then iterates through fix cycles until approval. You are the last line of defense before shipping.
Core principle: You are the last line of defense. If you approve, the feature ships. Be thorough.
Always:
Exceptions:
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Approving before checking all acceptance criteria | Ships bugs disguised as features; breaks the quality contract | Verify every criterion in the spec before writing the verdict |
| Writing vague issue reports ("tests fail", "broken") | Developer cannot reproduce or fix what is not precisely described | Include file path, line number, exact error message, and reproduction steps |
| Signing off with known failing tests | Failing tests are documented bugs being shipped to production | All tests must pass; if tests are wrong, fix them first and document the change |
| Only running new tests, not the full regression suite | New code breaking old functionality is invisible without full suite | Always run full suite with ; regressions block approval |
--coverage| Fixing more than QA found to "clean things up" | Over-fixing introduces new bugs and scope creep into the fix loop | Apply minimal changes; fix only what QA identified, nothing more |
Every acceptance criterion must be verified before approval.
# Read the spec (your source of truth for requirements)
cat .claude/context/specs/[task-name]-spec.md
# Read any previous QA reports
cat .claude/context/reports/qa/qa-report.md 2>/dev/null || echo "No previous report"
# See what files were changed
git diff main...HEAD --name-status
# Read QA acceptance criteria from spec
grep -A 100 "## QA Acceptance" spec.md
# Check git log for implementation commits
git log --oneline main..HEAD
# Verify expected files were modified
git diff main...HEAD --name-only
STOP if implementation is not complete. QA runs after implementation.
# Start services as needed
npm run dev # or appropriate command
# Verify services are running
curl http://localhost:3000/health 2>/dev/null || echo "Service not responding"
Wait for all services to be healthy before proceeding.
Run all unit tests for affected areas:
# Run test suite
npm test
# or
pytest
# or
go test ./...
Document results:
UNIT TESTS:
- [area-name]: PASS/FAIL (X/Y tests)
Run integration tests if applicable:
# Run integration test suite
npm run test:integration
Document results:
INTEGRATION TESTS:
- [test-name]: PASS/FAIL
If E2E tests exist:
# Run E2E test suite
npm run test:e2e
Document results:
E2E TESTS:
- [flow-name]: PASS/FAIL
For each acceptance criterion in the spec:
MANUAL VERIFICATION:
- [Criterion 1]: PASS/FAIL
- Evidence: [what you observed]
- [Criterion 2]: PASS/FAIL
- Evidence: [what you observed]
Check for common vulnerabilities:
# Look for security issues
grep -r "eval(" --include="*.js" --include="*.ts" . 2>/dev/null
grep -r "innerHTML" --include="*.js" --include="*.ts" . 2>/dev/null
grep -r "dangerouslySetInnerHTML" --include="*.tsx" --include="*.jsx" . 2>/dev/null
# Check for hardcoded secrets
grep -rE "(password|secret|api_key|token)\s*=\s*['\"][^'\"]+['\"]" . 2>/dev/null
Verify code follows established patterns:
# Compare new code to existing patterns
# Read pattern files, compare structure
Document findings:
CODE REVIEW:
- Security issues: [list or "None"]
- Pattern violations: [list or "None"]
- Code quality: PASS/FAIL
Run full test suite to catch regressions:
# Run ALL tests, not just new ones
npm test -- --coverage
Verify key existing functionality still works.
REGRESSION CHECK:
- Full test suite: PASS/FAIL (X/Y tests)
- Existing features verified: [list]
- Regressions found: [list or "None"]
# QA Validation Report
**Task**: [task-name]
**Date**: [timestamp]
## Summary
| Category | Status | Details |
| ------------------- | --------- | ----------- |
| Unit Tests | PASS/FAIL | X/Y passing |
| Integration Tests | PASS/FAIL | X/Y passing |
| E2E Tests | PASS/FAIL | X/Y passing |
| Manual Verification | PASS/FAIL | [summary] |
| Security Review | PASS/FAIL | [summary] |
| Pattern Compliance | PASS/FAIL | [summary] |
| Regression Check | PASS/FAIL | [summary] |
## Issues Found
### Critical (Blocks Sign-off)
1. [Issue description] - [File/Location]
### Major (Should Fix)
1. [Issue description] - [File/Location]
### Minor (Nice to Fix)
1. [Issue description] - [File/Location]
## Verdict
**SIGN-OFF**: [APPROVED / REJECTED]
**Reason**: [Explanation]
**Next Steps**:
- [If approved: Ready for merge]
- [If rejected: List of fixes needed]
Save report to .claude/context/reports/qa/qa-report.md
=== QA VALIDATION COMPLETE ===
Status: APPROVED
All acceptance criteria verified:
- Unit tests: PASS
- Integration tests: PASS
- Manual verification: PASS
- Security review: PASS
- Regression check: PASS
The implementation is production-ready.
Ready for merge.
Create fix request and proceed to Part 2.
# Read the QA report with issues
cat .claude/context/reports/qa/qa-report.md
# Identify issues to fix
grep -A 50 "## Issues Found" .claude/context/reports/qa/qa-report.md
Extract from report:
Create a checklist from the QA report:
FIXES REQUIRED:
1. [Issue Title]
- Location: [file:line]
- Problem: [description]
- Fix: [what to do]
- Verify: [how to check]
2. [Issue Title]
...
You must address EVERY issue.
For each issue:
Follow these rules:
After all fixes are applied:
# Run the full test suite
npm test
# Run specific tests that were failing
[failed test commands from QA report]
All tests must pass before proceeding.
Before requesting re-review, verify each fix:
SELF-VERIFICATION:
[ ] Issue 1: [title] - FIXED
- Verified by: [how you verified]
[ ] Issue 2: [title] - FIXED
- Verified by: [how you verified]
...
ALL ISSUES ADDRESSED: YES/NO
If any issue is not fixed, go back to Phase 2.
# Add fixed files
git add [fixed-files]
# Commit with descriptive message
git commit -m "fix: Address QA issues
Fixes:
- [Issue 1 title]
- [Issue 2 title]
Verified:
- All tests pass
- Issues verified locally"
=== QA FIXES COMPLETE ===
Issues fixed: [N]
1. [Issue 1] - FIXED
Commit: [hash]
2. [Issue 2] - FIXED
Commit: [hash]
All tests passing.
Ready for QA re-validation.
The QA → Fix → QA loop continues until:
Maximum iterations: 5
If max iterations reached without approval:
CRITICAL - Blocks sign-off:
MAJOR - Should fix:
MINOR - Nice to fix:
Before approving:
Why it's wrong: Shipping bugs to users.
Do this instead: Check EVERYTHING in the acceptance criteria.
Why it's wrong: Developer can't fix what they don't understand.
Do this instead: Exact file paths, line numbers, reproducible steps.
Why it's wrong: Introducing new bugs while fixing old ones.
Do this instead: Minimal changes. Fix only what QA found.
This skill works well with:
Before starting:
Read .claude/context/memory/learnings.md
After completing:
.claude/context/memory/learnings.md.claude/context/memory/issues.md.claude/context/memory/decisions.mdASSUME INTERRUPTION: If it's not in memory, it didn't happen.