agentleFS
ckorhonenckorhonen/claude-skills/skills/agent-engineering/SKILL.md

agent-engineering

Skill17 starsChanged 4 months agoMITView on GitHub

Battle-tested engineering principles for AI coding agents. Covers plan-first workflow, subagent delegation, self-improvement loops, verification gates, elegant solutions, autonomous bug fixing, and structured task management. Use when configuring agent behavior, writing AGENTS.md files, or improving agent reliability and code quality.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 0 are common, 17 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 17

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If something goes sideways, STOP and re-plan immediately — don't keep pushing

    line 29
  2. Distinctive:

    Use plan mode for verification steps, not just building

    line 30
  3. Distinctive:

    Write detailed specs upfront to reduce ambiguity

    line 31
  4. Distinctive:

    Use subagents liberally to keep main context window clean

    line 53
  5. Distinctive:

    After ANY correction from the user:

    line 71
  6. Very specific:

    Update tasks/lessons.md (or equivalent) with the pattern

    line 73
  7. Distinctive:

    Write rules for yourself that prevent the same mistake

    line 74
  8. Distinctive:

    Never mark a task complete without proving it works

    line 99
  9. Distinctive:

    Ask yourself: "Would a staff engineer approve this?"

    line 101
  10. Distinctive:

    Run tests, check logs, demonstrate correctness

    line 102
  11. Distinctive:

    If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"

    line 116
  12. Distinctive:

    When given a bug report: just fix it.

    line 128
  13. Distinctive:

    Rule of thumb: If you can see the error and understand the codebase, fix it.

    line 133
  14. Very specific:

    Plan First: Write plan to tasks/todo.md with checkable items

    line 144
  15. Distinctive:

    Verify Plan: Check in before starting implementation

    line 145
  16. Very specific:

    Document Results: Add review section to tasks/todo.md

    line 148
  17. Very specific:

    Capture Lessons: Update tasks/lessons.md after corrections

    line 149
  18. Distinctive:

    Learn From Mistakes: Every correction becomes a permanent rule.

    line 156
  19. Distinctive:

    Respect Context: Keep main context clean. Delegate ruthlessly.

    line 157
  20. Distinctive:

    After 20+ tool calls, the agent loses track of the original goal and starts solving adjacent problems.

    line 166
  21. Distinctive:

    Add the relevant principles directly to your project's agent configuration:

    line 181

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Engineering Principles

Battle-tested principles for AI coding agents that produce reliable, high-quality work.

When to Use This Skill

  • Writing or reviewing an AGENTS.md / CLAUDE.md / CURSOR.md file for a project
  • Configuring a new AI coding agent or subagent
  • Diagnosing why an agent keeps making the same mistakes
  • Reviewing agent output quality and identifying systemic issues
  • Onboarding an agent to a complex codebase

1. Plan Mode Default

  • Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways, STOP and re-plan immediately — don't keep pushing
  • Use plan mode for verification steps, not just building
  • Write detailed specs upfront to reduce ambiguity

When to skip: Simple, single-file edits with obvious solutions.

Example plan format (tasks/todo.md):

## Task: Migrate auth to JWT

### Plan
- [ ] Audit current session-based auth flow
- [ ] Design JWT payload schema (user_id, roles, expiry)
- [ ] Implement token generation in auth service
- [ ] Update middleware to validate JWT
- [ ] Write tests for edge cases (expired, invalid, revoked)
- [ ] Update docs

### Done
- [x] Audit complete — 4 routes need updating

2. Subagent Strategy

  • Use subagents liberally to keep main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • For complex problems, throw more compute at it via subagents
  • One task per subagent for focused execution

Key insight: Context window pollution is the #1 cause of agent quality degradation. Subagents are cheap — use them.

When to spawn a subagent vs. do it inline:

Use a subagentDo inline
Research task (>10 files)Simple 1-file edit
Independent parallel workQuick config change
Long-running compilation or test runSingle command with clear output
Isolated experiment (risky change)Trivial refactor

3. Self-Improvement Loop

After ANY correction from the user:

  1. Update tasks/lessons.md (or equivalent) with the pattern
  2. Write rules for yourself that prevent the same mistake
  3. Ruthlessly iterate on these lessons until mistake rate drops
  4. Review lessons at session start for relevant project

Lessons Format

## Lesson: [Short title]
- **Trigger:** What went wrong
- **Rule:** What to do instead
- **Added:** [date]

Example lesson:

## Lesson: Don't mutate shared config objects
- **Trigger:** Modified `config.defaults` directly, breaking other callers
- **Rule:** Always deep-clone config before modifying; treat config objects as read-only
- **Added:** 2026-03-15

This is the most underused agent pattern. Most agents make the same mistakes repeatedly because they have no feedback mechanism. A lessons file closes the loop.

4. Verification Before Done

  • Never mark a task complete without proving it works
  • Diff behavior between main and your changes when relevant
  • Ask yourself: "Would a staff engineer approve this?"
  • Run tests, check logs, demonstrate correctness

Anti-pattern: "I've made the changes" without evidence they work.

Verification checklist before marking done:

  • Tests pass (npm test / pytest / go test ./...)
  • No new lint errors
  • Manual smoke test of the changed code path
  • Diff reviewed for unintended changes
  • Edge cases (empty input, error paths, concurrent access) considered

5. Demand Elegance (Balanced)

  • For non-trivial changes: pause and ask "is there a more elegant way?"
  • If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
  • Skip this for simple, obvious fixes — don't over-engineer
  • Challenge your own work before presenting it

The balance: Elegance matters for code that will be maintained. For throwaway scripts, ship it.

Elegance signals: Code reads like prose. New engineers understand it without explanation. The abstraction boundaries are obvious. There's nothing to add, and nothing to remove.

Over-engineering signals: 3 abstraction layers for a 20-line problem. Generic framework for a one-time use. "We might need this later" reasoning.

6. Autonomous Bug Fixing

  • When given a bug report: just fix it. Don't ask for hand-holding
  • Point at logs, errors, failing tests — then resolve them
  • Zero context switching required from the user
  • Go fix failing CI tests without being told how

Rule of thumb: If you can see the error and understand the codebase, fix it. Only ask when genuinely blocked.

Blocked means:

  • The fix requires a product/UX decision (not a technical one)
  • You need access/credentials you don't have
  • Two reasonable fixes have significantly different tradeoffs and the owner should choose

7. Task Management Cycle

For any non-trivial task, follow this 6-step cycle:

  1. Plan First: Write plan to tasks/todo.md with checkable items
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Document Results: Add review section to tasks/todo.md
  6. Capture Lessons: Update tasks/lessons.md after corrections

Core Principles

  • Simplicity First: Make every change as simple as possible. Impact minimal code.
  • No Laziness: Find root causes. No temporary fixes. Senior developer standards.
  • Prove It Works: Tests, logs, evidence. Not just "it should work."
  • Learn From Mistakes: Every correction becomes a permanent rule.
  • Respect Context: Keep main context clean. Delegate ruthlessly.
  • Ship, Don't Discuss: Bias toward action. Fix it, don't debate it.

Common Failure Patterns (Anti-Patterns)

The Endless Loop

Agent keeps retrying the same failing approach with minor variations. Fix: Stop, re-read the error, consult the lessons file, try a fundamentally different approach.

Context Drift

After 20+ tool calls, the agent loses track of the original goal and starts solving adjacent problems. Fix: Re-read the original task at each major milestone.

Premature Confidence

Agent marks a task done based on "the code looks right" without running it. Fix: Always run tests/commands, never assume.

Scope Creep

Fixing a bug, agent also refactors unrelated code "while it's in there." Fix: One change, one commit. Refactors go in separate PRs.

Silent Failure

Command exits with 0 but nothing actually changed (e.g., dry-run mode left on). Fix: Verify the change happened (check logs, diff, reload config).

Applying These Principles

For AGENTS.md / CLAUDE.md Files

Add the relevant principles directly to your project's agent configuration:

## Engineering Standards

### Before Starting
- [ ] Read tasks/lessons.md for this project
- [ ] Plan non-trivial work in tasks/todo.md
- [ ] Verify plan before implementing

### While Working
- [ ] One task per subagent
- [ ] Verify each step works before moving on
- [ ] Track progress in todo.md

### Before Marking Done
- [ ] Run tests / check logs
- [ ] "Would a staff engineer approve this?"
- [ ] Update lessons.md if any corrections were made

For CI/Review Integration

These principles map well to PR review automation:

  • Verification (#4) → Require test evidence in PR descriptions
  • Elegance (#5) → Code review checklist item
  • Lessons (#3) → Post-merge retrospective notes

Bootstrapping a New Project

For a new codebase with no tasks/ directory:

mkdir tasks
echo "# Todo\n\n(empty)" > tasks/todo.md
echo "# Lessons\n\n(empty)" > tasks/lessons.md

Then add both files to .gitignore if they're agent-local, or track them if the team shares them.

References

Inspired by community-shared agent engineering patterns (March 2026).

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.