FRAN CANETE

My Claude Code setup.

A static note on how I keep my coding-agent workflow version-controlled: prompts, commands, conventions, and the review loop that makes Claude Code useful day to day.

Coding agents / setup

I keep my Claude Code setup in a repo for the same reason I keep dotfiles in a repo: the small defaults matter, and I want them to be portable.

francanete/.claudeMy version-controlled Claude Code setup
ToolClaude Code
FormatVersion-controlled setup
GoalSmall, reviewable agent work

What the repo is for

It is not meant to be a magic prompt library. It is more like a working notebook for how I want a coding agent to behave: how much context it should read before changing code, when it should plan, what kind of diffs I want back, and which repeated workflows are worth turning into commands or agents.

The main CLAUDE.md follows the Karpathy-style principles I keep coming back to: make the agent read context first, keep the solution simple, change only what is needed, and verify the result with evidence instead of confidence.

The point: make the boring parts repeatable so I can spend more attention on the actual decision-making.

The shape of the setup

example structure.claude/
~/.claude
├── CLAUDE.md              # default behaviour and working principles
├── commands/              # repeatable prompts for common workflows
├── agents/                # focused helpers for review, research, planning
└── settings.json          # hooks, permissions, and local preferences

The exact files will keep changing. That is the point of having it in Git. I can try things, keep what survives real work, and delete what only sounded clever in the abstract.

My working loop

  1. 01

    Read first. Ask the agent to inspect the relevant files, callers, tests, and config before it suggests a change.

  2. 02

    Plan when useful. For non-trivial work, I want a short plan and a verification step before code changes start.

  3. 03

    Keep diffs small. The bigger the agent-generated diff, the harder it is to trust.

  4. 04

    Verify with evidence. Tests, builds, screenshots, or clear manual checks beat confidence.

A prompt pattern I reuse

prompt patternplan-first
Read the relevant files before editing.

Then give me:
1. What you found
2. The smallest safe plan
3. The verification command or manual check

Do not change code until the plan is clear.

That pattern sounds basic, but it prevents a lot of bad sessions. The agent is most useful when it is anchored to the repo instead of guessing from a vague request.

What I put in commands

Commands are useful when a prompt becomes a habit. If I type the same instruction three or four times, it probably belongs in the setup.

command idea/review-diff
Review the current diff.
Focus on:
- bugs or broken assumptions
- unnecessary complexity
- missing verification
- changes outside the requested scope

Return only actionable notes.

The habits that matter most

Read before editingSmall diffsExplicit verificationReview everything

The biggest improvements have not come from one perfect prompt. They have come from boring constraints repeated consistently. Claude Code is fast, but speed is not the same as judgment. The setup is there to make it a better collaborator, not to remove taste, review, or responsibility.