| name | coding-agent |
| description | Delegate substantial coding work to an external coding harness or background implementation agent that can explore repositories, edit files, run commands, and iterate on code changes. Use when the task is implementation-heavy, benefits from autonomous repo exploration, or needs a dedicated coding lane rather than a normal conversational answer. Do not use for tiny inline edits, pure code review, or non-coding analysis. |
Coding Agent
Use this skill to hand off real coding work to a dedicated implementation agent.
This skill exists for tasks where the right move is not to explain how to code something, but to spin up a coding lane that can inspect the repository, change files, run checks, and return concrete results.
Scope
Use this skill for:
- feature implementation that touches multiple files
- non-trivial bug fixes requiring repo exploration
- iterative refactors with validation steps
- PR-sized code changes that benefit from autonomy
- coding tasks delegated to Codex, Claude Code, Pi, or similar harnesses
- background implementation work that should continue outside the main conversation flow
Use this skill when
Use this skill when the task needs:
- actual code changes rather than advice only
- agent-led file exploration before implementation
- command execution, testing, or build verification
- sustained iteration in a dedicated coding session
- separation between orchestration in chat and execution in a coding lane
Do not use this skill when
Do not use this skill for:
- trivial one-file edits that can be done directly inline
- pure architectural discussion with no code execution yet
- code review as the main deliverable
- documentation-only or research-only tasks
- interactive terminal control better handled by a tmux-specific flow
Inputs to gather
Before delegating, identify:
- repository or working directory
- concrete goal, bug, or requested feature
- acceptance criteria or definition of done
- constraints on files, branches, dependencies, or permissions
- required validation steps such as tests, lint, typecheck, or build
- whether the run should be one-shot, backgrounded, or thread-bound
If the task is vague, turn it into a crisp coding brief before spawning the agent.
Output expectations
Return outputs such as:
- implemented code change
- concise change summary
- files touched or major modules affected
- validation performed and its result
- open risks, follow-ups, or unresolved blockers
- branch, commit, or PR status when relevant
Prefer shipped results over speculative implementation notes.
Working method
1. Define the implementation target
State clearly:
- what must change
- what success looks like
- what must not be changed
- how completion will be verified
The coding agent should receive a bounded brief, not a vague aspiration.
2. Choose the right execution lane
Pick the harness and mode that fit the work:
- one-shot run for focused implementation
- persistent session for iterative back-and-forth
- thread-bound session when the work should stay tied to a chat thread
- background or delegated execution when the task may take time
Use the smallest execution surface that still gives the agent enough autonomy.
3. Provide repo-aware context
Include:
- repo path
- relevant files or subsystems
- current constraints and guardrails
- commands to run for verification if known
- any prohibited changes, such as avoiding unrelated refactors
Good delegation reduces wasted exploration.
4. Optimize for concrete artifacts
Ask the agent to produce:
- working code
- focused diffs
- validation evidence
- a short implementation summary
Avoid delegations that invite generic brainstorming when the real need is code.
5. Keep scope controlled
Expect the coding agent to:
- follow existing codebase patterns unless there is a strong reason not to
- avoid opportunistic rewrites unrelated to the task
- call out uncertainty instead of inventing hidden assumptions
- leave breadcrumbs about anything unverified
A strong coding run is narrow, correct, and reviewable.
6. Treat verification as part of completion
A coding task is not done when files were edited. It is done when the best available checks were run or when missing validation is explicitly documented.
Look for:
- tests added or updated when behavior changed
- lint, type, or build checks where appropriate
- notes on gaps when the environment blocks full verification
Adjacent skill boundaries
- code-implementer: implements code directly in the current lane; this skill is for delegating that work to a dedicated coding agent
- code-reviewer: evaluates changes after implementation; this skill creates them
- backend-dev / frontend-dev / fullstack-dev: domain-specialist builders; this skill is the delegation mechanism for substantial coding execution
- project-architect: defines structure and direction; this skill executes bounded implementation work
- tmux: controls an already-running interactive terminal workflow rather than selecting a coding delegation strategy
Quality bar
A strong result should:
- delegate to the right coding lane quickly
- give the agent enough context to work autonomously
- keep scope and guardrails explicit
- produce real code and validation evidence
- return a crisp summary of what changed and what remains
References to use
Use prompt.md for delegation posture and run framing.
Use guides/qa-checklist.md before finalizing a handoff or accepting agent output.
Use examples/README.md for briefing patterns.
Use meta/skill.json for boundaries and metadata.
