- No bot / Claude signatures — Never add
Co-Authored-By: Claudeor any AI signature in commits - Commit often to track history
- Unrelated changes → separate commits
- Use
git add <files>only (no-aor-A) unless asked otherwise
- Before commit, run the appropriate confidence suite for the change
- Do not ask the user to choose which tests to run, run them
- Simple, predictable, readable code, lisible for humans
- No hacks
- If you comment the code: do not repeat the code, explain the why, in English
- Do not add useless commenting
- All text, comments, and documentation must be in English unless explicitly requested otherwise.
- Be critical
- Say no to bad ideas
- Be radically honest
- Propose alternatives when they represent industry best practices
Default review panel: GLM + Codex + Grok. Run them in parallel (background), then synthesize.
GLM-5.2
opencode run "[PROMPT]" -m zai-coding-plan/glm-5.2or zai -p (claude code with model aliass)
Codex (gpt-5.6-sol — frontier tier, the most powerful)
codex exec "[PROMPT]" -m gpt-5.6-sol -c model_reasoning_effort=xhigh -s read-only -o /dev/stdout(model_reasoning_effort:low|medium|high|xhigh|max)-s read-only: codex can read the whole disk but cannot write — enforces the read-only rule mechanically (verified working non-interactively). Do NOT use--dangerously-bypass-approvals-and-sandboxfor reviews.- Do NOT silence stderr (
2>/dev/null): errors must stay visible. - Never use
model_reasoning_effort=ultra
Grok
grok -p "[PROMPT]"
When sending code for review to sub-agents you should share the list of modified files and not a diff. Share that a review is for static analysis only: - ALWAYS include in the prompt: "Do not modify any files. Static analysis only. Return your observations/recommendations. Do not create sub-agents with other models."
After each multi-model review, print a short summary per model (max 3-4 lines) with a count of points raised (e.g. "3 remarks: 1 potential bug, 1 perf, 1 style"), then the global synthesis.
- Never propose to pause or stop ongoing work
- Before changing code, inspect surrounding files and existing patterns
- Search for similar implementations before introducing a new one
- Read relevant tests before writing new logic
- Understand call sites before changing public behavior
- Prefer the smallest safe change that fully solves the problem
- Avoid speculative refactors during bug fixes
- Do not rename/move/restructure unrelated code while fixing a focused issue
- To cast a string to a boolean, use
ActiveRecord::Type::Boolean.new.cast - Avoid
yieldin Ruby methods — prefer&block+block.call(and avoid this pattern if possible) - No new gems unless necessary
- Code must be conventional Rails 8 + Hotwire + DHH Style
link_to: ✅data: { turbo_method: :delete, turbo_confirm: "..." }(Turbo intercepts the click)button_to: ✅method: :delete, data: { turbo_confirm: "..." }(generates a<form>with_method=delete)
- more info:
~/Projets/hadrienblanc/utils/omarchy/README.md