Mathieu Benoit
5fb49da0f2
Le dépôt n'avait aucune règle sur le commentaire de code : le seul modèle d'écriture était le corps de commit, et le gabarit y renvoyait le raisonnement qui n'y tenait pas. Le récit s'écoulait dans les sources, avec les noms qu'il portait. L'épreuve tient en une phrase : le code est le sujet, au présent de ce qu'il fait. Une phrase dont le sujet est un incident, une machine, une date ou une personne part vers tasks/, non versionné ; le mode de défaillance que le code empêche reste. Rien d'identifiant hors de private/, et seulement sur un dépôt privé. --- EN --- The repository had no rule at all about code comments: the only writing model available was the commit body, and the template sent the reasoning that did not fit there into a comment. The story flowed into the sources, carrying the names it named. The test fits in one sentence: the code is the subject, in the present of what it does. A sentence whose subject is an incident, a machine, a date or a person goes to tasks/, unversioned; the failure mode the code prevents stays. Nothing identifying outside private/, and only on a private repository. Assisted-by: Claude Opus 5
2.3 KiB
2.3 KiB
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 the 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
- Capture Lessons: Update AGENT.md with any change in approach the user has asked you to make.
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until the 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, and 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, and failing tests.
- Then resolve them.
- Zero context switching required from the user
- Go fix failing CI tests without being told how
Task Management
- Plan First: Write a 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. L'enquête, les mesures datées, les impasses et les traces d'exécution restent LÀ.tasks/n'est pas versionné : il porte ce que ni le code ni le commit ne doivent porter. Ne les fais pas remonter. - Capture Lessons: Update
tasks/lessons.mdafter corrections