Agents

Overview

Coding Friend includes 12 specialized agents, each optimized for specific engineering workflows. Agents are automatically selected based on the skill you invoke.

Agent Reference

Context column shows the prompt footprint of the agent's system prompt (⚡ = low). Agents run in forked sessions with their own context window. See Context Footprint for details.

When Each Agent Is Used

cf-reviewer (orchestrator)

Invoked by /cf-review [target]. The agent orchestrates a multi-agent review pipeline — dispatching 5 specialist agents in parallel, then merging results via a reducer agent.

Review pipeline:

1. Prepare shared context (diff + changed files + review mode)
2. Dispatch specialist agents in parallel (3 in QUICK mode, 5 in STANDARD/DEEP)
3. Collect all specialist outputs
4. Dispatch reducer agent to deduplicate, severity-rank, and merge into unified report

Specialist agents:

QUICK mode skips cf-reviewer-plan and cf-reviewer-rules for faster feedback on small changes.

Findings from all specialists are collected into 4 severity categories (🚨 Critical, ⚠️ Important, 💡 Suggestions, 📋 Summary). Each finding is tagged with its source layer inline (e.g., [L3: Security]). Multi-agent agreement on the same issue raises confidence.

/cf-review (workflow orchestration)
    ↓ fork + dispatch
cf-reviewer (orchestrator)
    ↓ parallel dispatch
cf-reviewer-plan + cf-reviewer-security + cf-reviewer-quality + cf-reviewer-tests + cf-reviewer-rules
    ↓ collect outputs
cf-reviewer-reducer (dedup + rank → unified report)

cf-explorer

The foundational exploration agent used by multiple skills and agents. Runs on Claude Haiku for cost efficiency. Given a goal and specific questions, it checks project memory first for cached exploration results, then maps project structure, searches for relevant files, reads code, and returns a structured report with findings, key files, dependencies, and code snippets. The memory-first approach reduces token usage when the same codebase areas are explored multiple times in a session.

When a context file path is provided by the orchestrating skill, cf-explorer writes its findings as structured JSON (task summary, relevant files, key findings, constraints) to that file. This enables downstream agents like cf-implementer to consume findings programmatically rather than through text serialization.

Used by:

• /cf-plan — explores codebase before the cf-planner designs approaches
• /cf-ask — gathers code context to answer questions
• /cf-fix — explores code around a bug before diagnosing root cause

/cf-plan (clarify → explore → plan → approve)
    ↓ dispatch (with context file path)
cf-explorer (map → search → read → write context file → report)
    ↓ context file + findings
cf-planner (analyze → design approaches → plan tasks)

/cf-ask (parse question)
    ↓ dispatch
cf-explorer (search → read → report)
    ↓ findings
cf-ask (synthesize answer → save to memory)

/cf-fix (understand bug → verify)
    ↓ dispatch (with context file path)
cf-explorer (trace code path → find relevant files → write context file → report)
    ↓ context file + findings
cf-fix (diagnose root cause → confirm → dispatch cf-implementer)

cf-implementer

Dispatched by /cf-plan [task], /cf-fix [bug], and /cf-optimize [target] for test-first implementation. Also dispatched by cf-tdd for substantial implementations (3+ files).

The agent runs in an isolated context and follows strict RED → GREEN → REFACTOR discipline. When a context file path is provided, the agent reads the structured JSON (written by cf-explorer or cf-planner) for primary context. The orchestrating skill manages the context file lifecycle (cleanup after success, update on retry).

Result signals: The agent always ends its response with [CF-RESULT: success] or [CF-RESULT: failure] <reason>. The orchestrating skill parses this to determine whether to proceed or retry.

Auto-retry: If the agent fails (tests fail, compile error, or empty output), the orchestrating skill retries once with error context appended to the context file under a previous_failure key. The user is always notified when a retry happens. If the retry also fails, the skill escalates to the user.

For parallel phases in /cf-plan, multiple cf-implementer agents run concurrently as background agents — each handling one independent task. For sequential phases, agents run one at a time as before.

Output quality gates: Reports must include specific files created/modified, actual test output (not just "tests pass"), TDD compliance evidence (RED → GREEN → REFACTOR steps), decisions made, and any concerns.

/cf-plan (clarify → explore → plan → approve)
    ↓ dispatch per phase
    ├── [parallel] phase: cf-implementer × N (concurrent, background)
    └── [sequential] phase: cf-implementer × N (one at a time)

/cf-fix (diagnose → confirm approach)
    ↓ dispatch (with context file)
cf-implementer (read context → write regression test → fix → verify → report)
    ↓ [CF-RESULT: success] or [CF-RESULT: failure]
    ↓ if failure → retry once with error context → escalate if still failing

/cf-optimize (baseline → analyze → plan)
    ↓ dispatch
cf-implementer (write test → optimize → verify → report)

cf-tdd (auto-invoked for substantial work)
    ↓ dispatch (with context file)
cf-implementer (read context → RED → GREEN → REFACTOR → report)
    ↓ [CF-RESULT: success] or [CF-RESULT: failure]
    ↓ if failure → retry once with error context → escalate if still failing

cf-planner

Invoked by /cf-plan [task] after the cf-explorer gathers codebase context. Takes the exploration report and designs 2-3 implementation approaches with pros, cons, effort, risk, and confidence levels. Recommends one approach and breaks it into phased tasks — grouping independent tasks into [parallel] phases and dependent tasks into [sequential] phases.

When a context file path is provided, cf-planner writes its plan findings as structured JSON to that file, enabling downstream agents (cf-implementer) to consume the plan programmatically.

Output quality gates: Plans must include at least 2 approaches (or explain why alternatives were ruled out), concrete file paths for every task, a verify step for each task, phase markers ([parallel] / [sequential]) on every task group, and at least 1 risk with mitigation.

cf-writer

Used for quick document generation, skill documentation, and lightweight markdown files.

cf-writer-deep

Invoked by /cf-learn [topic] with deep reasoning enabled. Extracts nuanced knowledge and creates comprehensive technical documentation.