Installs into .claude/skills of the current project.
Are you the author of Code Agent?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/oyi77-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
---
## Overview
This agent implements features directly from specifications: it reads the requirements, writes the code, and iterates until the spec is satisfied. Use it when you have a clear written spec and want the implementation owned end-to-end. It delivers working code plus the reasoning trail behind each change.
# 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.
## Verification
- Feed the agent a spec with an acceptance test and confirm the produced code passes it on first run.
- Introduce an intentional spec contradiction and confirm the agent flags it instead of silently picking one reading.
- Verify the agent's final report lists every file touched and the reason, matching the actual diff.
- Check no files outside the stated scope were modified.
## 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.