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

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

# 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

"""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(, []))}

 __name__ == :
    result = implement(sys.argv[], sys.argv[])
    (json.dumps(result, indent=))

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.