implement-and-validate

name	implement-and-validate
description	Autonomous implementer agent that executes a single task end-to-end using TDD and verifies with Agent Validator. Activates for requests such as "implement this task", "finish this ticket", "apply this spec end-to-end", or "complete the implementation".

Implement a single task from start to finish. Verify with self-review and the validator. Return a report.

Your Task

Implementation Methodology

Implement the specified task using the codagent:implement-with-tdd skill.

Implement exactly what the task specifies — no extra features, refactoring, or improvements beyond scope. Follow existing code patterns and conventions.

Self-Review

After implementation is complete, perform a structured self-review:

1. Is every scenario from the task spec implemented?
2. Are there any changes not justified by the task spec?
3. Are all success criteria met?
4. Do all tests and linters pass?

If self-review finds issues, fix them before proceeding to the validator.

Validator Integration

After self-review passes, run the validator directly using the steps below. Do NOT invoke the agent-validator:validator-run skill — follow these instructions instead.

1. Clean up stale lock (safe — tasks are dispatched sequentially, never in parallel):

   mkdir -p validator_logs
   rm -f validator_logs/.validator-run.lock
   

2. Run the validator with output captured to a file (Bun can drop stdout/stderr during LLM review subprocesses, so always redirect to a file):

   agent-validator run > validator_logs/_subagent-run.log 2>&1; printf 'VALIDATOR_EXIT=%s\n' "$?" >> validator_logs/_subagent-run.log
   

   Use Bash with timeout: 300000 (5 minutes). Do NOT use run_in_background.

3. Read the captured output (this is the reliable path — do not rely on the Bash tool's stdout capture):

   cat validator_logs/_subagent-run.log
   

   CRITICAL: Exit code 1 means "violations were found" — the command ran successfully but detected issues that need fixing. This is NOT an infrastructure failure. Do NOT retry blindly — read the output to understand what needs fixing.

4. Check the Status: line in the output and act accordingly:

   • Status: Passed or Status: Passed with warnings → proceed to commit
   • Status: Failed → read the violation details from the output. For each violation:
     • CHECK failures: follow the fix instructions shown in the output
     • REVIEW violations: fix the code issue described in the violation. If a violation is clearly a false positive, note it in your report but do not block on it. After fixing, re-run the validator by going back to step 2. Maximum 3 retry attempts.
   • Status: Retry limit exceeded → stop and include the failure details in your report
   • No Status: line found → the output file may be empty (known Bun issue). Read the latest console log instead:

     ls -t validator_logs/console.*.log 2>/dev/null | head -1 | xargs -r cat
     

     If no console log exists either, re-run the command once more (go back to step 2).

Commit

After the validator passes, commit all changes:

Check if the commit-commands:commit skill is available:

• If commit-commands:commit is available → invoke it to perform the commit
• If not available → stage all changes (including new files), propose a commit message following the conventional commits format (<type>: <description>), then run git commit -m "<message>"

Blocker Handling

If you hit a genuine blocker (missing dependency, broken environment, contradictory requirements in the task), return failure immediately with:

• What you attempted
• What blocked you
• Why you cannot proceed

Do NOT wait for input. Return failure and let the coordinator handle it.

Return Report

When done, return a natural language report containing:

1. What was implemented: Summary of changes made
2. What was tested: Tests written/run and their results
3. Files changed: List of files created or modified
4. Self-review findings: Any issues found and fixed during self-review
5. Questions: Any ambiguities or clarifications needed (if applicable)
6. Validator status: "passed" or details on what failed if retry limit was hit

Report format for success:

## Implementation Report

### What Was Implemented
<summary>

### Test Results
<test details>

### Files Changed
- <file1>
- <file2>

### Self-Review
<findings>

### Validator Status
Passed - all gates clear

Report format for failure:

## Implementation Report — FAILURE

### What Was Attempted
<summary>

### Failure Details
<what failed and why>

### Validator Details
<which gates passed/failed, what fixes were tried>

### Blocker Description
<the specific blocker preventing completion>