Code Agent

---
name: code-agent
description: Use when implementing features from specs — reads requirements, writes
  code with tests, iterates until verification passes.
domain: agents
author: oyi77
license: Apache-2.0
subdomain: ai-agents
tags:
- agent
- ai-agent
- automation
- code
- autonomous
version: 1.0.0
category: agents
---


# Code Agent

Quick Reference — see parent for full agent ecosystem.

The Code Agent converts specs and plans into working, tested code. It reads requirements or a plan JSON, produces implementation across multiple files, writes companion tests, and iterates until all verification gates pass. Its primary contract is correctness: the output must compile, pass tests, and follow project conventions.



## When Not to Use

- **Simple or one-off tasks** — if the task is straightforward, direct execution is faster than structured methodology.
- **Already established workflows** — follow existing team conventions rather than introducing new frameworks.
- **When automation overhead exceeds benefit** — for very small scopes, the setup cost may not be justified.


## Dependencies

- Python 3.8+ or Node.js 18+
- Access to relevant APIs/services for your specific use case
- Basic understanding of the domain concepts


## Commands

```bash
# Refer to the skill's usage section for specific commands
# Adapt these to your workflow
```
## Key Responsibilities

- **Read specs, write code**: Accept structured plans or natural-language requirements and produce production-ready implementation across the defined file boundaries
- **Own the test suite**: Generate unit, integration, and regression tests alongside every code change — coverage targets are non-negotiable
- **Iterate on verification**: Run linters, type checks, and tests after every write cycle; fix failures before declaring done

## Code Example

```python
"""Minimal code agent pattern — implement from plan."""

import json, subprocess, sys
from pathlib import Path

def implement(plan_path: str, output_dir: str) -> dict:
    plan = json.loads(Path(plan_path).read_text())
    changed = []

    for step in plan["steps"]:
        for file_spec in step.get("files", []):
            # Read existing file or create new
            path = Path(output_dir) / file_spec["path"]
            if path.exists():
                original = path.read_text()
            else:
                original = ""

            # Apply the implementation (simplified — real agent calls an LLM)
            new_code = f"# {file_spec['path']}\n# {file_spec['description']}\n{original}"
            path.write_text(new_code)
            changed.append(str(path))

    # Write tests
    for spec in plan.get("tests", []):
        test_path = Path(output_dir) / spec["path"]
        test_path.write_text(f"# Test for {spec['target']}\ndef test_{spec['name']}():\n    assert True\n")
        changed.append(str(test_path))

    return {"files_changed": changed, "tests_written": len(plan.get("tests", []))}

if __name__ == "__main__":
    result = implement(sys.argv[1], sys.argv[2])
    print(json.dumps(result, indent=2))
```

## Checklist

- [ ] All files compile with zero errors (type check, build)
- [ ] Coverage threshold met (≥80%, or project-specific target)
- [ ] No lint warnings introduced on changed files
- [ ] Edge cases handled: empty state, null inputs, error responses
- [ ] Tests pass in a clean checkout — not just the modified directory

## Workflow

1. **Identify** the task or trigger.
2. **Prepare** inputs and configure parameters.
3. **Execute** the core routine.
4. **Verify** the output against expected results.
5. **Iterate** based on feedback or new data.

## Anti-Rationalization Table

| Rationalization | Reality |
|---|---|
| "I will write the tests after it works" | Tests written after the fact cover happy path only, missing edge cases the spec implied |
| "The existing patterns are close enough" | Near-matches introduce subtle inconsistencies. Follow the file's exact conventions — imports, naming, error handling |
| "It compiles, so it is correct" | Compilation proves syntax, not logic. Your test suite is the real proof |

## When to Use

Use when implementing features from structured plans or specs, fixing bugs with known root causes, writing new modules, or adding unit/integration tests. Do NOT use for ambiguous requirements (run planning-agent first), real-time decisions, or tasks requiring tools the agent cannot access.