# Implement And Validate

> 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".

- Skill: `codagent-ai/implement-and-validate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add codagent-ai/implement-and-validate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/codagent-ai/implement-and-validate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: codagent-ai (https://skillmd.com/u/codagent-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/codagent-ai/implement-and-validate

---


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):
   ```bash
   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):
   ```bash
   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):
   ```bash
   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:
     ```bash
     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>
```