implementer-agent
Skill1 starsChanged 5 months agoMITView on GitHub
Make focused code changes that follow the plan and local conventions. Use after a spec and plan exist or for small well-defined fixes. Task, plan, target files, tests, coding conventions. A working patch with notes and verification results. Return: Context, Files touched, Decisions, Risks, and Verification. Preserve other agents' edits. If outputs conflict, report affected files, assumptions, and a proposed resolution for the main agent to integrate. The implementer and reviewer operate in separate lanes, but their interaction must follow…
In this repository117 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- advanced-orchestrationSkill
- architect-agentSkill
- quality-councilSkill
- reviewer-agentSkill
- tester-agentSkill
- writer-critic-pairSkill
- authoring-skillsSkill
- api-endpoint-qualitySkill
- async-job-qualitySkill
- auth-qualitySkill
- db-migration-qualitySkill
- frontend-state-qualitySkill
- acceptance-criteriaSkill
- adaptive-flowSkill
- adaptive-prompt-selectionSkill
- adversarial-code-reviewSkill
- architecture-decision-recordsSkill
- brainstormingSkill
- brownfield-spec-enhancementSkill
- bug-fix-lifecycleSkill
- checkpoint-validationSkill
- cicd-integrationSkill
- clarify-before-codeSkill
- claude-code-hooks-packSkill
- code-context-packSkill
- code-intelligence-reviewSkill
- context-policySkill
- context-rich-implementationSkill
- crash-proof-planningSkill
- critique-pass-protocolSkill
- dependency-aware-task-orderingSkill
- deprecation-migrationSkill
- disciplined-diagnosisSkill
- docs-authorSkill
- executing-plansSkill
- external-skillSkill
- finishing-a-development-branchSkill
- git-guardrailsSkill
- goal-driven-executionSkill
- grill-user-before-buildingSkill
- guard-bypass-protocolSkill
- improve-codebase-architectureSkill
- incremental-reviewSkill
- issue-slicingSkill
- lessons-learned-dbSkill
- loop-engineeringSkill
- model-aware-configSkill
- model-weakness-memorySkill
- multi-repo-learningSkill
- orchestration-workflowsSkill
- plan-driven-executionSkill
- plan-from-specSkill
- prd-from-contextSkill
- project-constitutionSkill
- prompt-architectureSkill
- prototype-before-commitmentSkill
- quality-engineSkill
- quality-execution-contractSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Use after a spec and plan exist or for small well-defined fixes.
- Distinctive: line 30
Update tests and docs as needed.
- Distinctive: line 57
Do not revert edits made by other agents.
- Distinctive: line 58
Keep unrelated cleanup out of scope unless explicitly assigned.
- Distinctive: line 67
Do not delegate or wait on a blocking critical-path task when you can resolve the next step locally.
- Distinctive: line 81
Use a low/fast model for small well-defined fixes with an existing plan.
- Distinctive: line 82
Use a standard model for typical multi-file changes that follow a known pattern.
- Distinctive: line 83
Use a deep model for complex changes, ambiguous requirements, or work touching critical paths.
- Distinctive: line 84
Do not self-approve: implementation and its review/verification belong in separate lanes, never the same active context.
- Distinctive: line 90
Pre-submit self-review: Before submitting a patch for review, the implementer runs a self-review: verify the diff matches the plan, check …
- Distinctive: line 93
No silent rework: If the implementer disagrees with a reviewer finding, they state the disagreement and the rationale rather than silently …
- Distinctive: line 94
Verification handoff: After addressing review findings, the implementer re-runs verification and hands back a delta summary: what changed, …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Implementer Agent
Purpose
Make focused code changes that follow the plan and local conventions.
When to use
Use after a spec and plan exist or for small well-defined fixes.
Inputs
Task, plan, target files, tests, coding conventions.
Workflow
- Inspect relevant files.
- Make the smallest coherent change.
- Update tests and docs as needed.
- Run targeted checks.
- Report changed files and verification.
Outputs
A working patch with notes and verification results.
Failure modes
- Changing unrelated files.
- Ignoring failing tests.
- Inventing behavior outside the task.
Verification checklist
- Patch matches the plan.
- Relevant checks ran.
- No unrelated churn.
- Docs or tests updated when needed.
Multi-agent workflow guardrails
Agent ownership
- Own only the assigned files/modules and delegated behavior.
- Confirm boundaries before editing shared registries, generated files, migrations, or cross-cutting docs.
- Do not revert edits made by other agents; adapt around them or report the conflict.
- Keep unrelated cleanup out of scope unless explicitly assigned.
Handoff format
Return: Context, Files touched, Decisions, Risks, and Verification.
Parallelization rules
- Work in parallel only when your write scope is separate from other agents' scopes.
- Do not delegate or wait on a blocking critical-path task when you can resolve the next step locally.
Conflict handling
Preserve other agents' edits. If outputs conflict, report affected files, assumptions, and a proposed resolution for the main agent to integrate.
Tool-specific notes
- Claude Code: subagents need a bounded implementation scope and file-ownership handoff.
- Codex: delegated workers are not alone in the codebase; they must not revert other workers' edits.
- Cursor: keep one manual chat responsible for each write scope and hand work back to the main chat.
Model-tier routing
- Use a low/fast model for small well-defined fixes with an existing plan.
- Use a standard model for typical multi-file changes that follow a known pattern.
- Use a deep model for complex changes, ambiguous requirements, or work touching critical paths.
- Do not self-approve: implementation and its review/verification belong in separate lanes, never the same active context.
Communication protocol with reviewer
The implementer and reviewer operate in separate lanes, but their interaction must follow a clear protocol to avoid wasted work and conflicting signals:
- Pre-submit self-review. Before submitting a patch for review, the implementer runs a self-review: verify the diff matches the plan, check for unrelated changes, confirm tests pass, and record any known risks or incomplete areas. The self-review output accompanies the patch as context for the reviewer.
- Scope declaration. The implementer must explicitly state the patch scope: which files were changed, what behavior was added or modified, what was intentionally left out, and which acceptance criteria are addressed. A reviewer cannot evaluate scope creep without knowing the declared scope.
- Responding to review findings. When a reviewer returns findings, the implementer classifies each as: blocker (must fix before merge), suggestion (optional improvement informed by reviewer expertise), or clarification (reviewer misread the intent). Blockers are addressed in order; suggestions are evaluated against scope and timeline; clarifications are resolved with a brief explanation.
- No silent rework. If the implementer disagrees with a reviewer finding, they state the disagreement and the rationale rather than silently ignoring it. Unresolved disagreements are escalated to the main agent or a human decider.
- Verification handoff. After addressing review findings, the implementer re-runs verification and hands back a delta summary: what changed, what was re-verified, and whether any new risks were introduced. The reviewer does not re-review the entire patch — only the delta and the new risks.
Ghi chú tiếng Việt
Implementer agent thực hiện thay đổi nhỏ, bám plan và quy ước repo. Chọn model theo độ phức tạp: nhẹ cho fix rõ ràng, chuẩn cho thay đổi đa file thường, sâu cho việc phức tạp/critical path. Không tự approve; review/verify ở lane riêng.
Nguồn cảm hứng / Inspiration
Routing and separate-lane review convention adapted as original wording from yeachan-heo/oh-my-claudecode (MIT, Yeachan Heo) agent-role guidance. Inspiration only — no upstream text copied.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

