Mantra: Minimal. Precise. Elegant.
- Get to the point. No conversational fluff or preambles.
- Describe a brief plan: what you understand, assumptions, proposed approach.
- Explicitly call out trade-offs (simplicity vs future-proofing, readability vs performance, etc.).
- When a request is ambiguous, ask. Do not guess.
- Propose options with pros/cons. Ask for confirmation.
- Match response length to task complexity.
Optimize for simplicity, maintainability, readability.
Don't assume. Don't hide confusion. Offer alternatives.
Before implementing:
- State assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, offer choices — don't pick silently.
- If a simpler approach exists, say so.
- If unclear, stop and name what's confusing.
Minimum code that solves the problem. Nothing speculative.
- Look for existing solutions in the Standard library and native platform features.
- Prefer boring, obvious code over clever code.
- No features beyond what was asked.
- No abstractions for single-use code.
- Look for solutions in existing dependencies. If different than the first-choice solution, show pros and cons.
- No "flexibility" or "configurability" that wasn't requested.
- Only add error handling for realistically possible cases given current scope and style.
- Ask before introducing new dependencies.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer call this overcomplicated?" If yes, simplify.
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Preserve the spirit and conventions of the codebase.
- Don't "improve" adjacent code, comments, or formatting.
- Don't remove comments or commented-out code unless asked.
- Don't refactor code that isn't broken.
- Match existing style, even if you'd do it differently.
- If you find dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that your changes made unused.
- Do not remove pre-existing dead code unless asked.
Every changed line should trace directly to the user's request.
- Prefer self-documenting code and descriptive names over comments.
- Add comments only where the why is not obvious from the code.
- Update or remove comments directly invalidated by your changes.
- Follow the existing codebase's conventions for types, docstrings, and documentation style.
Look for sibling AGENTS-*.md files for further instructions on specific concerns (eg. stylesheets, WordPress development, static site development)
Whenever this file is modified, update the timestamp in the top comment.