qa-from-execution

name: qa-from-execution description: Perform quality assurance on code changes after research-plan-execute workflow. STRICTLY read-only analysis—NO coding, NO fixing, NO execution. Focuses on changed areas only, emphasizing control/data flow correctness. allowed-tools: Read Bash

QA From Execution

Evaluate code changes for correctness, risks, and quality. This skill performs read-only analysis of implemented work, producing a QA report without modifying code.

CRITICAL BOUNDARIES

This skill is STRICTLY for QA evaluation. Do not write code, do not fix issues, do not execute. Analyze, evaluate, and report.

When to Use

Use this skill when:

• Execution from a plan is complete
• Code has been written and needs quality evaluation
• The task is to assess correctness of changes, not modify them
• Pre-merge or post-implementation review is needed

Workflow

Step 1: Load Execution Context

Locate and read the execution document:

• If a path is provided: Read from memory-bank/execution/<path>
• If a topic is provided: Find the latest matching file in memory-bank/execution/

Extract:

• Which files were modified
• Which functions/endpoints were added or changed
• What the acceptance criteria were
• Any issues encountered during execution

Step 2: Identify Changed Areas

From the execution log, build a list of:

• Files modified: Paths to all changed files
• Functions changed: Public functions that were added or modified
• Interfaces changed: API endpoints, CLI commands, public methods
• State changes: Database schema, configuration, shared resources

Focus analysis ONLY on these changed areas. Do not review unchanged code.

Step 3: Apply QA Checklist Per Changed Area

For each changed file/function/endpoint, evaluate:

3.1 Inputs & Preconditions

3.2 Control Flow

3.3 Data Flow

3.4 State & Transactions

3.5 Error Handling

3.6 Contracts

3.7 Time & Locale

3.8 Resource Hygiene

3.9 Edge Cases

3.10 Public Surface

Step 4: Test & Contracts Analysis

For each changed public function/endpoint:

1. Map to test coverage

   • Run: pytest -q or equivalent
   • Run: coverage run -m pytest && coverage report --format=markdown
   • Identify which changed functions have tests

2. Identify missing test cases

   • Error branches: Are failure paths tested?
   • Boundary conditions: Are min/max values tested?
   • Property invariants: Are data guarantees verified?
   • Mutation tests: Would incorrect code fail tests?

3. Contract/API verification

   • Compare OpenAPI/JSON schema to implementation
   • Verify request/response DTOs match spec
   • Check for breaking field/enum changes

Step 5: Secondary Scans (Optional)

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.

Step 6: Write QA Report

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_execution: "memory-bank/execution/<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]

Finding Severity Levels

Constraints

Subagent Usage

If additional analysis is needed:

With subagents available: Deploy maximum 3:

Without subagents: Perform manual analysis following the checklist.