Agents

Overview

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

CLI Requirement

Eleven of twelve agents are NONE-tier — they work without coding-friend-cli. The single exception is cf-explorer, which is OPTIONAL-tier: it uses memory_search as an exploration cache when the CLI's memory MCP is installed and falls back to fresh exploration when not. See the full CLI requirements matrix.

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]. Also dispatched by cf-tdd for substantial implementations (3+ files).

By default the agent uses direct implementation — writes code and runs existing tests without creating new ones. Pass --add-tests or set tdd: true in config to enable TDD (RED → GREEN → REFACTOR). 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/lint output, decisions made, and any concerns. In TDD mode, reports also include RED → GREEN → REFACTOR compliance evidence.

/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, --add-tests if TDD mode)
cf-implementer (read context → implement directly OR 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.