AGENTS.md

AGENTS.md

Workflow Orchestration

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

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

3. Self-Improvement Loop

• After ANY correction from the user: record the pattern in tasks/lessons.local.md
• 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

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

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

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

7. Lessons Management

Two-Tier Lessons System

• Use tasks/lessons.local.md as a raw, noisy learning log

  • Session-specific
  • Repetitions allowed
  • Emotional / exploratory notes are fine
  • Never commit this file

• Use tasks/lessons.md for distilled, durable lessons

  • Stable patterns only
  • Clear, actionable rules
  • Written as guidance for a future contributor
  • Commit only when a lesson has proven repeat value

Promotion Rule

Promote a lesson from lessons.local.md to lessons.md when any of the following are true:

• The same mistake occurred multiple times
• The lesson would have prevented a real bug, outage, or rework
• The lesson changes how future work should be done
• A staff-level engineer would expect this to be institutional knowledge

Writing Rules

• Lessons must be:
  • Short and specific
  • Framed as rules or constraints, not stories
  • Focused on prevention, not blame
• Avoid:
  • One-off mistakes
  • Temporary context
  • “Remember to…” reminders

Review Discipline

• Review tasks/lessons.md at the start of each session when relevant
• Periodically prune or merge lessons that become redundant
• If a lesson stops being true, delete it

Git Policy

• Commit: tasks/lessons.md
• Ignore: tasks/lessons.local.md
• Ignore: tasks/todo.md

Task Management

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.
• Minimal Impact: Changes should only touch what’s necessary. Avoid introducing bugs.