Plans

---
date: 2026-03-16T14:00:00Z
planner: claude
branch: main
repository: ai-toolbox
topic: "QA Skill for cc-plugin/base — Implementation Plan"
tags: [plan, qa, skill, cc-plugin, desplega, testing]
status: completed
autonomy: critical
source_research: thoughts/taras/research/2026-03-16-qa-skill.md
last_updated: 2026-03-16
last_updated_by: claude
---

# QA Skill for cc-plugin/base — Implementation Plan

## Overview

Add a QA (functional validation) skill to `cc-plugin/base/` that captures test evidence (screenshots, recordings, links) and produces QA reports in `thoughts/*/qa/`. The skill works standalone and integrates into the existing skill chain via optional per-phase QA specs in plans and handoff additions to verify/review.

## Current State Analysis

The base plugin has 8 skills: brainstorming, researching, planning, tdd-planning, implementing, phase-running, verifying, reviewing. There is **no QA skill**. The `validate-thoughts.py` hook blocks writes to any subdirectory other than `research/`, `plans/`, and `brainstorms/`. The reviewing skill classifies documents by path but has no `/qa/` entry. The verifying skill hands off only to `/review`.

### Key Discoveries:
- `cc-plugin/base/hooks/validate-thoughts.py:29-61` — Hook blocks `qa/` subdirectory writes; needs new pattern + branch
- `cc-plugin/base/skills/reviewing/SKILL.md:63-70` — Path classification table; needs `/qa/` row
- `cc-plugin/base/skills/reviewing/SKILL.md:176-198` — Type-specific handoffs; needs QA option for plans
- `cc-plugin/base/skills/verifying/SKILL.md:142` — Hands off to `/review`; needs `/qa` option
- `cc-plugin/base/skills/implementing/SKILL.md:94` — Invokes phase-running; needs QA spec awareness
- `cc-plugin/base/skills/phase-running/SKILL.md:79-112` — Report format; needs QA spec status
- `cc-plugin/base/skills/planning/SKILL.md:153-168` — Phase writing section; needs QA Spec guidance
- `cc-plugin/base/.claude-plugin/plugin.json:4` — Version `1.5.1`; bump to `1.6.0`
- All commands follow thin-wrapper pattern: frontmatter → parse flags → invoke skill
- All skills follow consistent structure: Working Agreement → Autonomy → Process Steps → Review Integration → Handoff

## Desired End State

- A `/qa` command that invokes a new `desplega:qa` skill
- QA reports persisted at `thoughts/*/qa/YYYY-MM-DD-<topic>.md` with rich evidence (screenshots, videos, links)
- Optional `### QA Spec` sections in plan phases, executed during implementation
- Phase-running agents report QA spec status (`passed`/`pending`/`n/a`)
- Reviewing skill can review QA documents with type-specific criteria
- Verifying skill offers QA as a handoff option
- Plugin version bumped to 1.6.0

## Quick Verification Reference

Common commands to verify the implementation:
- Validate hook: `python3 cc-plugin/base/hooks/validate-thoughts.py` (via stdin JSON)
- Check file exists: `ls cc-plugin/base/skills/qa/SKILL.md`
- Check command exists: `ls cc-plugin/base/commands/qa.md`
- Check template exists: `ls cc-plugin/base/skills/qa/template.md`
- Grep for QA refs: `grep -r "qa" cc-plugin/base/skills/ --include="*.md" -l`

Key files to check:
- `cc-plugin/base/skills/qa/SKILL.md` (new)
- `cc-plugin/base/skills/qa/template.md` (new)
- `cc-plugin/base/commands/qa.md` (new)
- `cc-plugin/base/hooks/validate-thoughts.py` (modified)
- `cc-plugin/base/.claude-plugin/plugin.json` (modified)

## What We're NOT Doing

- **Not building a test runner** — QA uses existing tools (qa-use, manual testing), not a new framework
- **Not modifying brainstorming or researching skills** — QA integrates only downstream from planning
- **Not creating a `/qa-use` command wrapper** — The skill uses qa-use if available, but doesn't wrap it
- **Not making QA specs mandatory in plans** — They're explicitly optional per phase
- **Not adding `qa/` directories upfront** — They get created when the first QA report is written

## Implementation Approach

Six phases, ordered by dependency: first unblock the hook and create scaffolding, then build the core skill, then integrate into the chain from planning → implementing → phase-running → reviewing → verifying, and finally bump the version.

Each phase touches a focused set of files to keep changes reviewable. Phases 3–5 (integrations) are independent of each other but all depend on Phase 2.

---

## Phase 1: Foundation (Hook + Template + Command)

### Overview
Unblock `qa/` directory in the validate-thoughts hook, create the QA document template, and create the `/qa` command wrapper. This enables the QA skill to write files and establishes the command entry point.

### Changes Required:

#### 1. Update validate-thoughts.py hook
**File**: `cc-plugin/base/hooks/validate-thoughts.py`
**Changes**:
- Add `qa_pattern` regex at line ~32 (after `brainstorms_pattern`):
  ```python
  qa_pattern = r'thoughts/[^/]+/qa/\d{4}-\d{2}-\d{2}-[\w-]+\.md$'
  ```
- Add `elif "/qa/" in file_path:` branch at line ~54 (before the `else` block):
  ```python
  elif "/qa/" in file_path:
      if not re.search(qa_pattern, file_path):
          return False, (
              "Invalid QA path format.\n"
              "Expected: thoughts/{username|agentId|shared}/qa/YYYY-MM-DD-topic-slug.md\n"
              f"Got: {file_path}"
          )
  ```
- Update the `else` error message at line ~57 to include `'qa'`:
  ```
  "Thoughts files must be in 'research', 'plans', 'brainstorms', or 'qa' subdirectory.\n"
  ```

#### 2. Create QA document template
**File**: `cc-plugin/base/skills/qa/template.md` (new)
**Changes**: Create file with the template from the research document (Section "QA Template Design"). The template includes:
- YAML frontmatter with `date`, `author`, `topic`, `tags`, `status` (in-progress|pass|fail|blocked), `source_plan`, `source_verification`, `related_pr`, `environment`
- Sections: Context, Scope (In Scope / Out of Scope), Test Cases (TC-N with Steps/Expected/Actual/Status), Edge Cases & Exploratory Testing, Evidence (Screenshots/Videos/Logs/External Links), Issues Found, Verdict, References

#### 3. Create `/qa` command wrapper
**File**: `cc-plugin/base/commands/qa.md` (new)
**Changes**: Create thin wrapper following the pattern from `commands/review.md` and `commands/verify-plan.md`:
- Frontmatter: `description`, `model: inherit`, `argument-hint: [--autonomy=MODE] [source-path]`
- Parse flags: `--autonomy=autopilot|critical|verbose`
- Invoke `desplega:qa` skill with arguments
- If no input provided, prompt for context (plan path, PR URL, or feature description)

### Success Criteria:

#### Automated Verification:
- [x] Hook allows qa/ writes: `echo '{"tool_name":"Write","tool_input":{"file_path":"thoughts/taras/qa/2026-03-16-test.md","content":"---\ndate: 2026-03-16\n---\n# Test"}}' | python3 cc-plugin/base/hooks/validate-thoughts.py; echo "exit: $?"`
- [x] Hook blocks invalid qa/ paths: `echo '{"tool_name":"Write","tool_input":{"file_path":"thoughts/taras/qa/bad-name.md","content":"---\ndate: 2026-03-16\n---\n# Test"}}' | python3 cc-plugin/base/hooks/validate-thoughts.py 2>&1; echo "exit: $?"`
- [x] Template file exists: `ls cc-plugin/base/skills/qa/template.md`
- [x] Command file exists: `ls cc-plugin/base/commands/qa.md`

#### Manual Verification:
- [x] Read `validate-thoughts.py` and confirm the qa pattern matches the same style as research/plans/brainstorms
- [x] Read `template.md` and confirm it has all sections from the research (Context, Scope, Test Cases, Evidence, Verdict, References)
- [x] Read `qa.md` command and confirm it follows the thin-wrapper pattern from `review.md`

**Implementation Note**: After completing this phase, pause for manual confirmation before proceeding to Phase 2.

---

## Phase 2: Core QA Skill

### Overview
Create the main QA skill SKILL.md that defines the full QA process: context gathering, test case design, test execution (with qa-use or manual), evidence capture, result recording, verdict, and knowledge persistence.

### Changes Required:

#### 1. Create QA skill definition
**File**: `cc-plugin/base/skills/qa/SKILL.md` (new)
**Changes**: Create the full skill definition following the consistent pattern across all existing skills. Structure:

**Frontmatter**: `name: qa`, `description: Functional validation skill...`

**Working Agreement**: Standard pattern — AskUserQuestion primary, establish preferences upfront, autonomy modes.

**User Preferences** (upfront via AskUserQuestion):
1. **QA approach**: Manual-only / Browser automation (qa-use) / Mixed
2. **File review preference**: Use file-review for inline feedback on QA report?

**When to Use**: User invokes `/qa`, another skill references `desplega:qa`, user asks to test or validate a feature.

**Autonomy Mode**: Standard table (Autopilot/Critical/Verbose).

**Process Steps**:
1. **Context & Scope** — Determine the source of QA specs. The skill handles three input modes:
   - **Plan path provided** → Read the plan, extract `### QA Spec` sections from each phase, aggregate into QA document
   - **Separate QA spec document provided** → Read the standalone QA spec (could be a dedicated file in `thoughts/*/qa/` or any markdown with test scenarios), use it as the basis
   - **No source / PR / issue / description only** → Build test cases from scratch with the user
   Create QA document from template in all cases.
2. **Test Case Design** — Define test cases (happy path, edge cases, error scenarios). If sourced from a plan, aggregate phase QA specs. If sourced from a separate spec, use those scenarios as the starting point and augment with exploratory cases. If browser automation selected and qa-use available, design qa-use test steps.
3. **Execute Tests** — For browser automation: use qa-use CLI (explore → snapshot → interact → screenshot). For manual: guide user through steps, collect evidence. For each test case, record actual result and pass/fail.
4. **Capture Evidence** — Screenshots via qa-use or user-provided, video URLs, log output, links to external systems.
5. **Record Results** — Update QA document with actual results, evidence links, pass/fail per test case.
6. **Verdict** — Aggregate results into PASS / FAIL / BLOCKED. Summary sentence.
7. **Persist QA Knowledge** — If the project's CLAUDE.md or agents.md doesn't document how QA is done, offer to add a QA section. Also persist patterns to memory if they emerge across QA sessions.

**Browser Automation Default**: Check for qa-use availability (look for `qa-use:*` in available skills). Check if CLAUDE.md specifies a different QA tool. Fall back to manual if neither.

**Review Integration**: If file-review available and user opted in, launch file-review on completed QA report.

**Workflow Handoff**: AskUserQuestion with:
- Run post-QA verification (→ `/verify-plan`)
- Run review on QA report (→ `/review`)
- Done

### Success Criteria:

#### Automated Verification:
- [x] Skill file exists: `ls cc-plugin/base/skills/qa/SKILL.md`
- [x] Has frontmatter: `head -3 cc-plugin/base/skills/qa/SKILL.md`
- [x] Contains key sections: `grep -c "## Working Agreement\|## Autonomy Mode\|## Process Steps\|## Review Integration" cc-plugin/base/skills/qa/SKILL.md`
- [x] References qa-use: `grep -c "qa-use" cc-plugin/base/skills/qa/SKILL.md`

#### Manual Verification:
- [x] Read SKILL.md fully and confirm it follows the same structural pattern as `verifying/SKILL.md` and `reviewing/SKILL.md`
- [x] Confirm all 7 process steps are present with clear instructions
- [x] Confirm autonomy mode table matches the standard format
- [x] Confirm workflow handoff offers verify and review as next steps
- [x] Confirm the skill checks for qa-use availability before defaulting to manual

**Implementation Note**: This is the largest phase. After completing, pause for thorough manual review before integration phases.

---

## Phase 3: Planning Integration

### Overview
Add optional QA Spec sections to the planning skill and template, so plans can embed per-phase test scenarios that the QA skill later aggregates.

### Changes Required:

#### 1. Update planning SKILL.md
**File**: `cc-plugin/base/skills/planning/SKILL.md`
**Changes**: In Step 4 (Detailed Plan Writing), after the existing guidance about Success Criteria, add a note about optional QA Specs:

```markdown
**QA Specs (optional)**: Phases that change user-facing behavior, add UI, modify API responses, or alter auth/permissions SHOULD include an optional `### QA Spec (optional):` section after the Success Criteria. See the template for the exact format. Phases that are internal refactors, type changes, config updates, or dependency bumps should omit QA specs.
```

Also add to the Success Criteria Requirements section's "Validation Checklist":
```markdown
- [ ] Phases with user-facing changes have optional `### QA Spec` sections (if applicable)
```

#### 2. Update planning template
**File**: `cc-plugin/base/skills/planning/template.md`
**Changes**: After the `**Implementation Note**` line in each phase template block, add:

```markdown
### QA Spec (optional):

**Approach:** browser-automation | manual | cli-verification
**Test Scenarios:**
- [ ] TC-1: [Scenario name]
  - Steps: [1. Navigate to X, 2. Click Y, 3. Verify Z]
  - Expected: [What should happen]
- [ ] TC-2: [Scenario name]
  - Steps: [...]
  - Expected: [...]
```

Add only to the Phase 1 example block (not all phases — the pattern is self-evident after one example).

**Note on QA spec location**: The planning skill should mention that QA specs can live either inline in plan phases (for per-phase validation) or as a separate standalone document (for cross-cutting or feature-level QA). The inline approach is the default for plans; the QA skill handles both sources transparently.

#### 3. Update tdd-planning SKILL.md
**File**: `cc-plugin/base/skills/tdd-planning/SKILL.md`
**Changes**: In Step 4 (Detailed Plan Writing, around line 151-161), add a note about optional QA Specs at the Feature level:

```markdown
**QA Specs (optional)**: Features that change user-facing behavior SHOULD include an optional `### QA Spec (optional):` section at the Feature level (after the feature header, before the first TDD cycle). Unlike regular plans where QA specs attach per-phase, TDD plans attach them per-feature since the RED/GREEN cycle itself serves as the per-cycle verification. See the template for the format.
```

#### 4. Update tdd-planning template
**File**: `cc-plugin/base/skills/tdd-planning/template.md`
**Changes**: After the `## Feature 1: [Feature Name]` header (around line 50), add an optional QA Spec block:

```markdown
### QA Spec (optional):

**Approach:** browser-automation | manual | cli-verification
**Test Scenarios:**
- [ ] TC-1: [Scenario name]
  - Steps: [1. Navigate to X, 2. Click Y, 3. Verify Z]
  - Expected: [What should happen]
```

Add only to the Feature 1 example block (not all features — the pattern is self-evident).

### Success Criteria:

#### Automated Verification:
- [x] Planning SKILL.md mentions QA Spec: `grep -c "QA Spec" cc-plugin/base/skills/planning/SKILL.md`
- [x] Planning template has QA Spec block: `grep -c "QA Spec" cc-plugin/base/skills/planning/template.md`
- [x] QA Spec is marked optional: `grep "QA Spec (optional)" cc-plugin/base/skills/planning/template.md`
- [x] TDD planning SKILL.md mentions QA Spec: `grep -c "QA Spec" cc-plugin/base/skills/tdd-planning/SKILL.md`
- [x] TDD planning template has QA Spec block: `grep -c "QA Spec" cc-plugin/base/skills/tdd-planning/template.md`

#### Manual Verification:
- [x] Read the modified planning SKILL.md and confirm the QA Spec guidance is clear about when to include/omit
- [x] Read the modified template and confirm the QA Spec section fits naturally after Success Criteria
- [x] Confirm the QA Spec is NOT in every phase template block — only Phase 1 as an example
- [x] Read the modified tdd-planning SKILL.md and confirm QA Spec guidance references Feature-level attachment (not per-cycle)
- [x] Read the modified tdd-planning template and confirm QA Spec is at the Feature level, before TDD cycles

**Implementation Note**: After completing this phase, pause for manual confirmation.

---

## Phase 4: Implementing & Phase-Running Integration

### Overview
Wire QA spec awareness into the implementing and phase-running skills so that phases with QA specs are executed and reported on.

### Changes Required:

#### 1. Update implementing SKILL.md
**File**: `cc-plugin/base/skills/implementing/SKILL.md`
**Changes**:

In the "Background Sub-Agent Mode" section (around line 155), after step 4 ("Review the agent's report"), add awareness of QA spec status:

```markdown
5. **Check QA spec status** — If the phase agent reports `QA: pending`, present the QA spec's test scenarios to the user and offer:
   - Execute QA now (→ invoke `desplega:qa` with plan path + phase context)
   - Skip QA for this phase
   - If `QA: passed`, note it and proceed. If `QA: n/a`, proceed normally.
```

Renumber subsequent steps accordingly.

In the "Inline Mode" section (around line 170), add similar awareness after step 2 ("Fix any issues before proceeding"):

```markdown
3. If the phase has a `### QA Spec` section, execute the test scenarios or offer to invoke `/qa`
```

#### 2. Update phase-running SKILL.md
**File**: `cc-plugin/base/skills/phase-running/SKILL.md`
**Changes**:

In Step 4 (Run Verification, around line 67), add a new sub-step after automated verification:

```markdown
5. If the phase has a `### QA Spec (optional):` section:
   - If the QA approach is `cli-verification`, execute the test steps and record results
   - If the approach is `browser-automation` or `manual`, report `QA: pending` — the caller handles these
   - If no QA spec exists, report `QA: n/a`
```

In Step 6 (Report Results, around line 82), add QA status to the report formats:

For "completed":
```
QA: passed | pending | n/a
```

For "blocked" and "failed", add:
```
QA status: [status at time of block/failure]
```

### Success Criteria:

#### Automated Verification:
- [x] Implementing SKILL.md mentions QA spec: `grep -c "QA Spec\|QA spec" cc-plugin/base/skills/implementing/SKILL.md`
- [x] Phase-running SKILL.md mentions QA status: `grep -c "QA:" cc-plugin/base/skills/phase-running/SKILL.md`
- [x] Phase-running reports include QA line: `grep "QA: passed\|QA: pending\|QA: n/a" cc-plugin/base/skills/phase-running/SKILL.md`

#### Manual Verification:
- [x] Read implementing SKILL.md and confirm QA spec handling is present in both Background and Inline modes
- [x] Read phase-running SKILL.md and confirm QA status is in all three report formats (completed/blocked/failed)
- [x] Confirm the implementing skill offers to invoke `/qa` when QA is pending (not forcing it)

**Implementation Note**: After completing this phase, pause for manual confirmation.

---

## Phase 5: Review & Verify Integration

### Overview
Add QA document type support to the reviewing skill and QA handoff option to the verifying skill.

### Changes Required:

#### 1. Update reviewing SKILL.md
**File**: `cc-plugin/base/skills/reviewing/SKILL.md`
**Changes**:

In Step 1 (Read & Classify), add to the path classification table (around line 63-70):
```markdown
| `/qa/` | QA report |
```

In Step 2 (Structural Check), add QA-specific requirements:
```markdown
**QA reports:**
- YAML frontmatter with required fields (date, author, topic, status)
- Context section
- Scope section (In Scope / Out of Scope)
- Test Cases with Steps, Expected, Actual, Status per case
- Evidence section (Screenshots, Videos, Logs, or External Links)
- Verdict section with overall status and summary
```

In Step 3 (Content Analysis), add QA-specific quality criteria:
```markdown
**QA reports:**
- Does every test case have an actual result and status?
- Is evidence provided for failures (screenshots, logs)?
- Is the verdict consistent with individual test case results?
- Are edge cases and exploratory testing documented?
- Are external references (Sentry, PRs, CI) linked where relevant?
```

In the Workflow Handoff (Step 7), add QA-specific handoff:
```markdown
**If reviewing a QA report:**

| Question | Options |
|----------|---------|
| "Review complete. What's next for this QA report?" | 1. Run post-QA verification (→ `/verify-plan`), 2. Address issues found, 3. Done |
```

#### 2. Update verifying SKILL.md
**File**: `cc-plugin/base/skills/verifying/SKILL.md`
**Changes**:

In the "Integration with Reviewing Skill" section (around line 142), expand the handoff:

Change:
```
After verification completes, offer: "Would you like me to also run `/review` on this plan for a final quality check?"
```
To:
```
After verification completes, use **AskUserQuestion** with:

| Question | Options |
|----------|---------|
| "Verification complete. What's next?" | 1. Run QA (→ `/qa`), 2. Run review (→ `/review`), 3. Done |
```

### Success Criteria:

#### Automated Verification:
- [x] Reviewing SKILL.md has QA path: `grep "/qa/" cc-plugin/base/skills/reviewing/SKILL.md`
- [x] Reviewing SKILL.md has QA structural checks: `grep "QA report" cc-plugin/base/skills/reviewing/SKILL.md`
- [x] Verifying SKILL.md offers QA handoff: `grep "/qa" cc-plugin/base/skills/verifying/SKILL.md`

#### Manual Verification:
- [x] Read reviewing SKILL.md and confirm QA appears in all three relevant steps (Classify, Structural Check, Content Analysis) plus the Handoff
- [x] Read verifying SKILL.md and confirm the handoff now offers QA as first option
- [x] Confirm the reviewing skill's QA structural requirements match the template from Phase 1

**Implementation Note**: After completing this phase, pause for manual confirmation.

---

## Phase 6: Version Bump & E2E Validation

### Overview
Bump the plugin version to 1.6.0 and perform a manual end-to-end walkthrough of the full QA flow.

### Changes Required:

#### 1. Bump plugin version
**File**: `cc-plugin/base/.claude-plugin/plugin.json`
**Changes**: Change `"version": "1.5.1"` to `"version": "1.6.0"` (minor bump — new feature, no breaking changes)

### Success Criteria:

#### Automated Verification:
- [x] Version is 1.6.0: `grep '"version"' cc-plugin/base/.claude-plugin/plugin.json`
- [x] All new files exist: `ls cc-plugin/base/skills/qa/SKILL.md cc-plugin/base/skills/qa/template.md cc-plugin/base/commands/qa.md`
- [x] Hook has qa pattern: `grep "qa_pattern" cc-plugin/base/hooks/validate-thoughts.py`
- [x] All modified skills reference QA: `grep -Eli "qa" cc-plugin/base/skills/planning/SKILL.md cc-plugin/base/skills/tdd-planning/SKILL.md cc-plugin/base/skills/implementing/SKILL.md cc-plugin/base/skills/phase-running/SKILL.md cc-plugin/base/skills/reviewing/SKILL.md cc-plugin/base/skills/verifying/SKILL.md`

#### Manual Verification:
- [x] Read through the full `/qa` command → SKILL.md → template chain and confirm consistency
- [x] Verify the QA Spec in the planning template is consistent with what the implementing and phase-running skills expect
- [x] Confirm the reviewing skill's structural requirements for QA reports match the template exactly
- [x] Walk through the handoff chain: implement → verify → qa → verify(post) → review — confirm each skill offers the correct next step

**Implementation Note**: This is the final phase. After completing, confirm all manual checks pass before committing.

---

## Manual E2E Validation

After all phases are complete, validate the full flow:

```bash
# 1. Verify hook allows QA writes
echo '{"tool_name":"Write","tool_input":{"file_path":"thoughts/taras/qa/2026-03-16-test.md","content":"---\ndate: 2026-03-16\ntopic: test\n---\n# Test"}}' | python3 cc-plugin/base/hooks/validate-thoughts.py; echo "exit: $?"

# 2. Verify hook blocks invalid QA paths
echo '{"tool_name":"Write","tool_input":{"file_path":"thoughts/taras/qa/invalid.md","content":"test"}}' | python3 cc-plugin/base/hooks/validate-thoughts.py 2>&1; echo "exit: $?"

# 3. Check all new files exist
ls -la cc-plugin/base/skills/qa/SKILL.md cc-plugin/base/skills/qa/template.md cc-plugin/base/commands/qa.md

# 4. Check version
cat cc-plugin/base/.claude-plugin/plugin.json | grep version

# 5. Grep for QA integration across all skills
grep -rn "QA\|/qa" cc-plugin/base/skills/ --include="*.md" | grep -v "^Binary"

# 6. Verify no broken cross-references
grep -rn "desplega:qa" cc-plugin/base/ --include="*.md"
```

## Testing Strategy

- **Hook testing**: stdin JSON pipe tests for valid/invalid QA paths (Phase 1)
- **Structural review**: Manual read-through of each modified skill for consistency (each phase)
- **Cross-reference audit**: Grep to confirm all skills that should reference QA do so (Phase 6)
- **Template consistency**: Compare reviewing skill's structural requirements against the actual template (Phase 6)
- **Handoff chain**: Trace the workflow from implement → verify → qa → review and confirm each offers the right next step (Phase 6)

## References
- Research: `thoughts/taras/research/2026-03-16-qa-skill.md`

## Review Errata

_Reviewed: 2026-03-16 by Claude_

### Critical
_(none)_

### Important
_(none — all resolved)_

### Resolved
- [x] **TDD planning skill not addressed** — Added `tdd-planning/SKILL.md` and `tdd-planning/template.md` modifications to Phase 3, with Feature-level QA Spec attachment (not per-cycle, since RED/GREEN serves as per-cycle verification)
- [x] Phase 6 grep portability: `grep -l "qa\|QA"` uses GNU basic regex alternation — auto-fixed to `grep -Eli "qa"` for macOS compatibility