Recipe Add Integration Tests

Required Skills [LOAD BEFORE EXECUTION]

1. [LOAD IF NOT ACTIVE] testing — test strategy and quality gates
2. [LOAD IF NOT ACTIVE] integration-e2e-testing — integration and E2E test patterns
3. [LOAD IF NOT ACTIVE] documentation-criteria — document creation rules and templates
4. [LOAD IF NOT ACTIVE] llm-friendly-context — clear prompts, handoffs, and generated artifacts

Spawn rule: every spawn_agent call uses fork_turns="none" so the subagent receives only the task message and explicitly provided context.

Context: Test addition workflow for existing implementations

Orchestrator Definition

Core Identity: "I am not a worker. I am an orchestrator."

First Action: Register Steps 0-8 before any execution.

Why Spawn: Orchestrator's context is shared across all steps. Direct implementation consumes context needed for review and quality check phases. Task files create context boundaries. Subagents work in isolated context.

Execution Method:

• Skeleton generation -> Spawn acceptance-test-generator agent
• Task file creation -> Orchestrator creates directly (minimal context usage)
• Test implementation -> Spawn task-executor agent
• Test review -> Spawn integration-test-reviewer agent
• Quality checks -> Spawn quality-fixer agent

Document paths: $ARGUMENTS

Prerequisites

• At least one Design Doc must exist (created manually or via reverse-engineer)
• Existing implementation to test

Execution Flow

Step 0: Prepare Context

Reference documentation-criteria skill for task file template in Step 3.

Step 1: Discover and Validate Documents

# Verify at least one document path was provided
test -n "$ARGUMENTS" || { echo "ERROR: No document paths provided"; exit 1; }

# Verify provided paths exist
ls $ARGUMENTS

Use only the user-provided paths in $ARGUMENTS. Do not auto-discover additional Design Docs or UI Specs.

Classify provided documents by path and filename, using first-match-wins:

• Path matches docs/ui-spec/*.md -> UI Spec
• Path matches docs/design/*-backend-*.md or docs/design/*backend*.md -> Design Doc (backend)
• Path matches docs/design/*-frontend-*.md or docs/design/*frontend*.md -> Design Doc (frontend)
• Path matches docs/design/*.md and none of the above -> single-layer Design Doc

If a filename appears to match both backend and frontend, halt and ask the user which layer it belongs to.

Step 2: Skeleton Generation

Spawn acceptance-test-generator agent with only the documents that exist from Step 1:

Generate test skeletons from the following documents:
- Design Doc (backend): [path]     `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
- Frontend skeletons exist -> `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
- Single-layer (no backend/frontend distinction) -> `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`

**Template** (per task file):
```markdown
---
name: Implement [layer] integration tests for [feature name]
type: test-implementation
---

## Objective

Implement test cases defined in skeleton files.

## Target Files

- Skeleton: [layer-specific paths from Step 2 generatedFiles]
- Design Doc: [layer-specific Design Doc from Step 1]

## Tasks

- [ ] Implement each test case in skeleton
- [ ] Verify all tests pass
- [ ] Ensure coverage meets requirements

## Acceptance Criteria

- All skeleton test cases implemented
- All tests passing
- No quality issues

Output: "Task file(s) created at [path(s)]. Ready for Step 4."

Step 4: Test Implementation

For each task file from Step 3, invoke task-executor routed by filename pattern:

• *-backend-task-* -> Spawn task-executor
• *-frontend-task-* -> Spawn task-executor-frontend
• Prompt: "Task file: [task file path from Step 3]. Implement tests following the task file."

Execute one task file at a time through Steps 4 -> 5 -> 6 -> 7 before starting the next.

Expected output: status, testsAdded

Step 5: Test Review

Spawn integration-test-reviewer agent: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [layer-specific paths from Step 2 generatedFiles matching current task's layer]."

Expected output: status (approved/needs_revision), requiredFixes

Step 6: Apply Review Fixes

Check Step 5 result:

• status: approved -> Mark complete, proceed to Step 7
• status: needs_revision -> Spawn the layer-appropriate executor with: "Fix the following issues in test files: [requiredFixes from Step 5]." Then return to Step 5. Maximum 2 revision cycles per task file; if still needs_revision, escalate to the user.

Step 7: Quality Check

Spawn quality-fixer routed by task filename pattern:

• *-backend-task-* -> Spawn quality-fixer
• *-frontend-task-* -> Spawn quality-fixer-frontend
• Prompt: "Final quality assurance for test files added in this workflow. Task file: [current task file]. filesModified: [Step 4 testsAdded]. Use these files as the stub-detection scope. Run all tests and verify coverage."

Expected output: status (stub_detected/approved/blocked)

Step 8: Commit

On quality-fixer result:

• status: "stub_detected" -> Return to Step 4 with stubFindings
• status: "blocked" -> Escalate to user
• status: "approved" -> Commit test files
• MUST commit test files with appropriate message

ENFORCEMENT: Commits without quality-fixer approval are invalid.

Completion Criteria

• [ ] Design Doc validated and located
• [ ] Skeleton generated via acceptance-test-generator
• [ ] Task file created and confirmed
• [ ] Tests implemented via task-executor
• [ ] Tests reviewed via integration-test-reviewer (approved or fixes applied)
• [ ] Quality check passed via quality-fixer
• [ ] Test files committed
• [ ] Task files created by this recipe deleted from docs/plans/tasks/

Final Cleanup

Before the completion report, delete only the integration-test task files this recipe created for the current run. Their work is committed; docs/plans/ is ephemeral working state.

If cleanup fails, report the failed path but do not invalidate completed test work.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: shinpr
• Source: shinpr/codex-workflows
• License: MIT

Install and usage instructions live in the source repository linked above.