Performs read-only QA on post-execute code changes, analyzing changed areas for input validation, control flow, data flow correctness, and risks. Reports to memory-bank/qa/ without modifications.
From harness-engineeringnpx claudepluginhub alchemiststudiosdotai/harness-engineeringThis skill is limited to using the following tools:
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Evaluate code changes for correctness, risks, and quality. This skill performs read-only analysis of implemented work, producing a QA report without modifying code.
| Activity | Status |
|---|---|
| QA Analysis | ✅ This skill |
| Code Changes | ❌ NO — Read only |
| Bug Fixes | ❌ NO — Report only |
| Execute | ❌ NO — Analysis only |
This skill is STRICTLY for QA evaluation. Do not write code, do not fix issues, and do not perform the Execute phase. Analyze, evaluate, and report.
Use this skill when:
Locate and read the execution log:
memory-bank/execute/<path>memory-bank/execute/Extract:
From the execution log, build a list of:
Focus analysis ONLY on these changed areas. Do not review unchanged code.
For each changed file/function/endpoint, evaluate:
| Check | Question |
|---|---|
| Validation | Are all inputs validated before use? |
| Type safety | Are type assumptions explicit and checked? |
| Null/empty | Are null, undefined, and empty cases handled? |
| Boundaries | Are min/max values, sizes, and limits enforced? |
| Check | Question |
|---|---|
| Branch coverage | Are all branches reachable? Any dead code? |
| Fall-through | Are switch/case fall-throughs intentional? |
| Early returns | Are guard clauses used appropriately? |
| Loop termination | Do all loops have guaranteed termination? |
| Check | Question |
|---|---|
| Invariants | Are invariants preserved through transformations? |
| Mutation scope | Is mutation limited to appropriate scope? |
| Shared state | Is shared state access properly synchronized? |
| Aliasing | Are aliasing risks (multiple refs to same data) handled? |
| Check | Question |
|---|---|
| Idempotency | Is the operation safe to retry? |
| Atomicity | Are multi-step operations atomic? |
| Rollback | Is there a path to undo partial changes? |
| Concurrency | Are race conditions handled? |
| Check | Question |
|---|---|
| Specificity | Are exceptions specific (not broad catches)? |
| Retry logic | Is transient failure handled with backoff? |
| Dead letter | Are unprocessable items routed to DLQ/log? |
| Error context | Do errors include sufficient debugging info? |
| Check | Question |
|---|---|
| Pre-conditions | Are pre-conditions documented and enforced? |
| Post-conditions | Are post-conditions guaranteed on success? |
| Schema drift | Do request/response schemas match implementation? |
| Versioning | Are breaking changes properly versioned? |
| Check | Question |
|---|---|
| Timezones | Are datetime operations timezone-aware? |
| Monotonic time | Is elapsed time measured with monotonic clocks? |
| DST | Are daylight saving time transitions handled? |
| Format stability | Are date/time formats consistent and unambiguous? |
| Check | Question |
|---|---|
| File lifecycle | Are files opened/closed properly (with statements)? |
| Connection pooling | Are connections returned to pools? |
| Timeouts | Do all blocking operations have timeouts? |
| Cancellation | Is cancellation propagated through async chains? |
| Check | Question |
|---|---|
| Empty inputs | Is empty/null input handled gracefully? |
| Max sizes | Are large inputs bounded (pagination, limits)? |
| Partial failure | Is partial failure detectable and recoverable? |
| Resource exhaustion | Are OOM, disk full, quota exceeded handled? |
| Check | Question |
|---|---|
| Backward compat | Are breaking changes intentional and documented? |
| OpenAPI alignment | Do implementations match OpenAPI/JSON schemas? |
| Type exports | Are public types exported and documented? |
| Deprecation | Are deprecated items marked and alternatives provided? |
For each changed public function/endpoint:
Map to test coverage
pytest -q or equivalentcoverage run -m pytest && coverage report --format=markdownIdentify missing test cases
Contract/API verification
Run static analysis tools (read-only, report results):
# Type checking
mypy . --ignore-missing-imports 2>/dev/null || echo "mypy not available"
# Security scan
bandit -r . -q 2>/dev/null || echo "bandit not available"
# Dependency audit
pip-audit 2>/dev/null || npm audit --json 2>/dev/null | jq '.metadata' || echo "audit not available"
Note findings without attempting fixes.
Create memory-bank/qa/YYYY-MM-DD_HH-MM-SS_<topic>_qa.md:
---
title: "<topic> – QA Report"
phase: QA
date: "YYYY-MM-DD HH:MM:SS"
owner: "<agent_or_user>"
parent_execute: "memory-bank/execute/<file>.md"
git_commit_at_qa: "<sha>"
tags: [qa, <topic>]
---
## Summary
| Metric | Count |
|--------|-------|
| Files reviewed | N |
| Functions reviewed | N |
| CRITICAL findings | N |
| WARNING findings | N |
| INFO findings | N |
| PASS (no issues) | N |
## Changed Areas Reviewed
### File: `path/to/file.py`
| Function/Class | Lines | Status |
|----------------|-------|--------|
| `function_name()` | L45-89 | ⚠️ WARNING |
| `ClassName` | L120-200 | ✅ PASS |
#### Findings for `function_name()`
| Severity | Category | Finding | Recommendation |
|----------|----------|---------|----------------|
| WARNING | Error Handling | Broad `except Exception` catch | Catch specific exceptions |
| INFO | Data Flow | Mutation of input parameter | Document or avoid |
### File: `path/to/another.js`
...
## Test Coverage Analysis
| Function | Has Tests | Coverage % | Missing Cases |
|----------|-----------|------------|---------------|
| `function_name()` | ✅ | 85% | Error branch, empty input |
| `another_function()` | ❌ | 0% | All cases |
## Contract/API Verification
| Endpoint | Schema Match | Breaking Changes |
|----------|--------------|------------------|
| `POST /api/items` | ✅ | None |
| `GET /api/items/:id` | ⚠️ | New required field |
## Static Analysis Summary
| Tool | Result |
|------|--------|
| mypy | N errors, M warnings |
| bandit | N low, M medium issues |
| pip-audit | N vulnerabilities |
## Risk Assessment
| Risk | Likelihood | Impact | Mitigation Status |
|------|------------|--------|-------------------|
| Race condition in shared state | Medium | High | Not mitigated |
| Missing error branch coverage | High | Medium | Not tested |
## Recommendations Summary
### Must Fix (CRITICAL)
1. [Description of critical issue]
### Should Fix (WARNING)
1. [Description of warning]
### Observations (INFO)
1. [Description of observation]
| Level | Definition | Action Required |
|---|---|---|
| CRITICAL | Security risk, data loss, or system instability | Must fix before merge |
| WARNING | Potential bugs, maintainability issues, missing coverage | Should fix, can defer |
| INFO | Style observations, suggestions, notes | Optional |
| PASS | No issues found | None |
| Constraint | Rule |
|---|---|
| NO CODE CHANGES | Never write, modify, or delete code |
| NO FIXES | Report issues, do not implement solutions |
| FOCUS ON CHANGES | Only review files listed in the execution log |
| READ-ONLY TOOLS | Use tools that don't modify state |
| DOCUMENT FINDINGS | Every issue must be in the QA report |
If additional analysis is needed:
With subagents available: Deploy maximum 3:
| Subagent | When to Deploy |
|---|---|
| antipattern-sniffer | Review changed code for anti-patterns and code smells |
| codebase-analyzer | Deep analysis of specific function implementations |
| context-synthesis | Identify hidden dependencies affected by changes |
Without subagents: Perform manual analysis following the checklist.
After writing the QA report to memory-bank/qa/, hand off to the user for disposition.
Suggested next action:
Review memory-bank/qa/<file>.md and decide whether to accept the work or create follow-up planning.