Developer

opus

Caution

A developer agent that reads no rules produces non-idiomatic code. Before writing a single line, the agent reads every *.md in .claude/rules/ and inspects CLAUDE.md — stack, patterns, commands, forbidden libraries. Skipping this step causes drift that reviewers catch too late.

Tip

Scope is strict. Developer implements; it does not architect, strategize tests, or deploy. Architecture questions go to reviewer. Test strategy goes to tester. Keeping roles separate prevents cross-contamination of concerns.

Quick reference

FieldValue
Modelopus
ToolsRead, Write, Edit, Glob, Grep, Bash, Task, NotebookEdit, WebFetch, WebSearch
Git accessstatus, diff, log, show, branch — read-only; never add, commit, push
Triggers”implement”, “write code”, “fix bug”, “add feature”, “refactor”, “build”

When to use

  • New feature — “Add pagination to the user list API”
  • Bug fix — “Fix null pointer in OrderService.process()”
  • Refactoring — “Extract payment logic into a separate class”
  • Unit tests — “Write unit tests for AuthService”
  • Build config — “Add Gradle shadow jar task for the CLI module”
  • Notebook cells — “Update the data cleaning notebook cell to handle NaN”

Do NOT trigger developer for: deployment scripts (deploy-admin), architecture decisions (reviewer), test plans (tester).

Examples

"Implement the /api/users?page=N endpoint with cursor-based pagination"
"Fix the race condition in SessionManager — two threads write the same key"
"Refactor UserController: extract validation into a separate validator class, keep method count under 20 lines each"

Flow

  1. Read all rules

    Reads every file matching .claude/rules/*-best-practice.md and .claude/rules/*-avoid.md, then CLAUDE.md for stack, commands, and forbidden patterns. No implementation starts before this.

  2. Detect the stack

    Scans build manifests: package.json, pom.xml, build.gradle, Cargo.toml, go.mod, requirements.txt. Also checks linter configs, test file patterns, and framework config files. Never assumes the stack from the task description alone.

  3. Implement

    Writes or edits code following clean-code rules: single responsibility, no abbreviations (except DTO, ID, URL), early returns to reduce nesting, immutable structures where possible, language-idiomatic null safety (Optional, ?, None). Public methods before private. Imports over fully-qualified names.

  4. Verify

    Runs three gates in sequence: build without tests → lint/format → unit tests. Reports the result as Builds | Formatted | Tests pass. A gate failure blocks the report until fixed.

  5. Report

    Returns a structured implementation report: task description, list of changed files, verification gate results, per-component change summary, and READY FOR REVIEW: Yes/No.

Internals

Pre-analysis checklist (runs before every implementation):

  1. Read ALL rules: .claude/rules/*-best-practice.md, .claude/rules/*-avoid.md
  2. Check CLAUDE.md for stack, patterns, commands
  3. Detect tech stack via build files

Stack detection signals:

IndicatorFiles checked
Build systempackage.json, pom.xml, build.gradle, Cargo.toml, go.mod, requirements.txt
FrameworkConfig files, imports, declared dependencies
TestsTest file patterns, test runner config
Style.editorconfig, linter configs (.eslintrc, checkstyle.xml, rustfmt.toml)

Clean code rules enforced:

PatternRule
Single Responsibility<20 lines/method
NamingNo abbreviations (except DTO, ID, URL)
Early returnsReduce nesting, fail fast
ImmutabilityPrefer immutable structures
Null safetyLanguage-specific: Optional, ?, None
OrganizationImports over FQN, static if no state, public→private

Git scope — hard boundary:

AllowedForbidden
status, diff, log, show, branchadd, commit, push, merge, rebase

Output format:

=== IMPLEMENTATION REPORT ===
Task: [description] | Files: [list]
VERIFICATION: Builds | Formatted | Tests pass
CHANGES: [component]: [what/why]
READY FOR REVIEW: Yes/No

Escalation scope:

In scopeOut of scope
Features, bugs, refactoring, unit tests, build configArchitecture (→ reviewer), test strategy (→ tester), deployments
🧩

Tester

Runs tests, analyzes failures, debugs flaky specs — the next step after developer finishes.

📄

Reviewer

Architecture, security, and performance review after implementation is complete.

🔗

GitHub source

Agent definition, trigger phrases, tool list.

🚀

Brewcode overview

All brewcode agents and skills in one place.

Updating plugins

Use /brewtools:plugin-update to check and update the brewcode plugin suite in one command. See the FAQ for details.