Notes

Recent thoughts

• A Claude Code review template you can copy

  ·28 Sept 2026

  This is the structure of the review playbook behind Claude Code Review in Production: How Our Review Rules Evolved Over Five Months, with our company-specific rules removed. Replace the rule documents with your own; the routing, severity ladder, finding format and verifier transfer as they are. In Claude Code, the orchestrator can be a slash command (.claude/commands/review.md), the specialists and verifier are sub-agents (.claude/agents/*.md), and the same playbook can drive a GitHub Action.

  # Code Review Playbook (single source of truth for local /review and CI)
  
  ## 1. Scope
  - CI: the PR diff. Local: ask which branch this merges into; review committed,
    uncommitted and untracked changes against it.
  - Exclude data and config artefacts (.sql, .csv, .json). If nothing reviewable
    remains, report "No reviewable code files changed" and stop.
  - Review ONLY added or changed lines. Never flag pre-existing code.
  
  ## 2. Route (the orchestrator reviews nothing itself)
  | Specialist            | Files                         | Rule document             |
  |-----------------------|-------------------------------|---------------------------|
  | review-api            | API / router files            | docs/rules/api.md         |
  | review-domain         | service / domain files        | docs/rules/domain.md      |
  | review-data           | repository / data-access files| docs/rules/data.md        |
  | review-architecture   | all application code          | docs/rules/architecture.md|
  | review-db-performance | all non-test code             | docs/rules/db-perf.md     |
  | review-style          | all code                      | style guide (caps at WARNING) |
  Dispatch every relevant specialist in parallel. Skip a specialist with no files.
  
  ## 3. Finding format (every specialist)
  ### Finding
  - file: <path>
  - line: <line in the new file>
  - severity: BLOCKING | WARNING | SUGGESTION
  - section: <rule document> §<n> <heading>
  - quote: <offending code, verbatim>
  - issue: <which rule, why it is violated>
  - fix: <concrete fix>
  Or exactly: NO FINDINGS
  
  ## 4. Severity (mechanical, no judgement calls)
  - BLOCKING: violates a documented blocking rule. Must cite file and section.
  - WARNING: violates a documented warning-level or style rule. Must cite it.
  - SUGGESTION: a concern no documented rule covers. Never a rule violation.
  - Style never blocks.
  
  ## 5. Verify (one verifier, after all specialists)
  Reject a finding unless ALL hold:
  1. The file exists.
  2. The quoted code appears within ±5 lines of the cited line.
  3. That line is added or changed in this diff (not context, not removed).
  4. The cited rule section exists and says what the finding claims.
  False positives are far worse than false negatives. Do not re-grade severity.
  Do not add findings. Drop rejected findings silently.
  
  ## 6. Deliver
  - Group approved findings by file; lead with the verdict.
  - CI: request changes if any approved BLOCKING, otherwise approve.
  - Local: print the review; never post.

  For the GitHub side, two settings carried most of the weight for us: run on opened, synchronize, reopened and ready_for_review but skip drafts; and skip branches where a review cannot help, such as release promotions.

  How we got here, and why each rule exists, is in the full post.

• Tune before you scale

  ·23 Nov 2025

  Properly tuning your app configurations can save you a lot of money. Check out my new post on how I saved us on cloud costs by tuning our backend stack: How I Halved My Backend Python App's Memory Usage.

• Two weeks with Claude Skills

  ·3 Nov 2025

  Been tinkering with Claude Skills for the past 2 weeks. Here are some things I feel everyone should know: Claude Skills Might Be Bigger Than MCP.