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
- juninmd/skillstheir own version, first seen Nov 8, 2026
- mehulpratapsing/ai-engineer-skill-stacktheir own version, first seen Oct 8, 2026
- six-ddc/skillstheir own version, first seen Jul 28, 2026
- thekernelkiller/skillstheir own version, first seen May 13, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- six-ddc/skills★ 3same name
- juninmd/skills★ 2same name
- mehulpratapsing/ai-engineer-skill-stack★ 1same name
- thekernelkiller/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository60 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-browserSkill
- app-marketing-copySkill
- ascii-pixel-artSkill
- autopredictSkill
- autoresearchSkill
- babysit-prSkill
- bird-fastSkill
- blockchain-auditorSkill
- brainstormingSkill
- ceo-reviewSkill
- ck-reviewSkill
- cloudflare-managerSkill
- codex-advisorSkill
- content-trend-researcherSkill
- continuous-learningSkill
- coreml-optimizerSkill
- cto-reviewSkill
- direct-mail-strategistSkill
- evangelion-designSkill
- executing-plansSkill
- freshdesk-apiSkill
- gemini-image-generatorSkill
- gemini-visualSkill
- github-actions-templatesSkill
- googleSkill
- gsplat-optimizerSkill
- hyperagentSkill
- idea-mdSkill
- imagegenSkill
- ios-app-testerSkill
- llm-advisorSkill
- llm-evaluationSkill
- macos-appsSkill
- markdown-fetchSkill
- mcp-builderSkill
- mcp-testerSkill
- nano-bananaSkill
- opensea-apiSkill
- paperclipSkill
- playdate-devSkill
- poke-assistantSkill
- poplar-direct-mailSkill
- practical-typographySkill
- prompt-factorySkill
- qmdSkill
- scientific-critical-thinkingSkill
- security-best-practicesSkill
- security-threat-modelSkill
- seo-optimizerSkill
- shadertoySkill
- skill-finderSkill
- skimmableSkill
- subway-infoSkill
- systematic-debuggingSkill
- tui-designerSkill
- ui-designSkill
- video-editorSkill
- writing-plansSkill
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
- Distinctive: line 29
If something goes sideways, STOP and re-plan immediately — don't keep pushing
- Distinctive: line 30
Use plan mode for verification steps, not just building
- Distinctive: line 31
Write detailed specs upfront to reduce ambiguity
- Distinctive: line 53
Use subagents liberally to keep main context window clean
- Distinctive: line 71
After ANY correction from the user:
- Very specific: line 73
Update tasks/lessons.md (or equivalent) with the pattern
- Distinctive: line 74
Write rules for yourself that prevent the same mistake
- Distinctive: line 99
Never mark a task complete without proving it works
- Distinctive: line 101
Ask yourself: "Would a staff engineer approve this?"
- Distinctive: line 102
Run tests, check logs, demonstrate correctness
- Distinctive: line 116
If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Distinctive: line 128
When given a bug report: just fix it.
- Distinctive: line 133
Rule of thumb: If you can see the error and understand the codebase, fix it.
- Very specific: line 144
Plan First: Write plan to tasks/todo.md with checkable items
- Distinctive: line 145
Verify Plan: Check in before starting implementation
- Very specific: line 148
Document Results: Add review section to tasks/todo.md
- Very specific: line 149
Capture Lessons: Update tasks/lessons.md after corrections
- Distinctive: line 156
Learn From Mistakes: Every correction becomes a permanent rule.
- Distinctive: line 157
Respect Context: Keep main context clean. Delegate ruthlessly.
- Distinctive: line 166
After 20+ tool calls, the agent loses track of the original goal and starts solving adjacent problems.
- Distinctive: line 181
Add the relevant principles directly to your project's agent configuration:
“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.
Files
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.mdfile 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 updating2. 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 subagent | Do inline |
| Research task (>10 files) | Simple 1-file edit |
| Independent parallel work | Quick config change |
| Long-running compilation or test run | Single command with clear output |
| Isolated experiment (risky change) | Trivial refactor |
3. Self-Improvement Loop
After ANY correction from the user:
- Update
tasks/lessons.md(or equivalent) with the pattern - Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until mistake rate drops
- 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-15This 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:
- Plan First: Write plan to
tasks/todo.mdwith checkable items - Verify Plan: Check in before starting implementation
- Track Progress: Mark items complete as you go
- Explain Changes: High-level summary at each step
- Document Results: Add review section to
tasks/todo.md - Capture Lessons: Update
tasks/lessons.mdafter 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 madeFor 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.mdThen 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).
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.

