DEV Community: VincentChabran

Why Your Local Business Loses Leads Before You Even Open Your Email

VincentChabran — Mon, 03 Aug 2026 08:22:29 +0000

Written with AI assistance.

You run a local service business — a plumber, a gym, a salon, a small agency. Someone fills out your contact form at 9:47pm on a Tuesday. They're comparing you against two other providers in town, probably filling out the same form on their sites too. Whoever replies first, or at least acknowledges the request first, has a real edge — not because of superior sales skill, but because the requester's attention and urgency are highest right when they hit submit, and they decay from there.

Here's the problem: most local business owners don't see that form submission until they check their email the next morning, or whenever they get a spare minute between jobs. By then, the requester has often already booked with whoever answered first, or simply moved on. The lead isn't lost because the business did a bad job — it's lost because nobody was watching the inbox in the fifteen minutes that mattered.

The fix isn't "answer faster." It's "acknowledge instantly."

You can't have someone standing by the inbox 24/7 — that's not realistic for a solo plumber or a two-person salon. But you don't need a human to respond in the first sixty seconds. You need three things to happen automatically the moment a lead comes in:

The lead gets an instant, personal-feeling acknowledgment — "Got your request, we'll call you back shortly" — so they stop shopping around and stop assuming they've been ignored.
The lead lands in a system you can act on — not buried in an inbox, but as a row in a sheet you can scan and prioritize.
The owner gets pinged immediately, with everything needed to close the loop fast — not a bare notification, but one with a direct way to call or reply right there.

That's the entire shape of the problem. No CRM migration, no new phone system, no app to install on your technicians' phones. Just: form submitted → three things happen in the background, instantly, every time.

What that looks like as a workflow

Structurally, this is a small automation: a form submission triggers a short chain — send the acknowledgment email, write a row to a tracking sheet, and notify the owner with the lead's details plus quick links to call or reply. Six steps, no manual handoff, no missed lead sitting in a spam folder until Thursday. The acknowledgment email and the tracking row happen in parallel with the owner alert, so nothing waits on anything else.

The part that actually moves the needle isn't clever AI or personalization — it's the instantness. A form that used to sit unanswered for hours now gets a reply inside seconds, and the owner gets the information needed to make a real callback while the lead still remembers filling out the form.

If you're technical and already run n8n (or a similar automation tool) for your own business or for clients, this is a genuinely small build — a form trigger, a couple of email/notification nodes, and a spreadsheet write. If you'd rather not build and test it yourself, or you want something you can hand to a client tomorrow with install guides, onboarding checklists, and editable templates already done, that's exactly what we built.

Where to get it

We packaged this exact workflow — a ready-to-import, 6-node n8n Lead Capture workflow (English + French editions), plus a companion Google Review Automation workflow that closes the other end of the loop (asking happy customers for a review after the job's done, with duplicate-detection and a single smart reminder) — into the n8n Local Business Automation Kit, built by Vixelys, a French app & automation studio. It ships with install guides, an onboarding checklist, a QA checklist, editable email templates in both languages, and a commercial license that covers unlimited client projects.

$69, instant download, 14-day guarantee if a kit doesn't import or work as described on a supported n8n version: https://vincentdu2a.gumroad.com/l/mwukc

Your CLAUDE.md is probably too long — here's how to tell and what to do about it

VincentChabran — Mon, 03 Aug 2026 03:59:30 +0000

Most CLAUDE.md files start the same way: five or six bullet points written in the first afternoon of a project — naming convention, package manager, "don't run migrations automatically." Six months later the same file is 300+ lines: half-finished notes from a refactor, a paragraph explaining a decision that got reversed, three slightly different phrasings of "use TypeScript strict mode" added by three different people who didn't check if it was already there. Nobody deletes anything, because nobody's sure what's still load-bearing.

The file still gets read in full on every single turn. That's the part people don't think through.

Length isn't the real problem — signal-to-noise is

A 300-line CLAUDE.md isn't bad because it's long. It's bad because a one-line rule that actually matters ("never touch billing.py, it's synced from another repo") sits at the same visual and semantic weight as forty lines of restated formatting preferences and a stale note about a library you migrated off of two quarters ago. The model has no reliable way to tell which of those lines should change its next action and which are just historical residue. Everything reads as equally "instructions," so nothing gets the emphasis it needs.

This is different from an instruction simply being ignored in a long session — it's noise actively competing with signal for the same attention budget, at every single turn, for the life of the project. A shorter file with the same important rule in it is more likely to get followed, not less, purely because there's less competing for the same slot.

A quick audit: read your CLAUDE.md and cut the dead weight

Go through your file line by line and ask, for each one: if I deleted this right now, would anything I do in the next hour actually change?

Common categories that fail that test and can usually go straight to the trash:

Explanations of why a convention exists, when the convention itself is one line. Keep the rule, cut the essay.
Instructions for a tool, framework, or file that no longer exists in the repo.
Anything phrased as "please try to" or "remember to" for something that must happen every time without exception — that's not a CLAUDE.md line at all, it's a hook (a shell command wired to a lifecycle event, so it's not competing for attention because it isn't a request in the first place).
Multi-step procedures you only run occasionally ("when doing a release, do A then B then C") — that belongs in a slash command you invoke on demand, not a standing instruction read on every unrelated turn.
Duplicate phrasings of the same rule added at different times. Keep the clearest one, delete the rest.

What's actually worth keeping

What survives the cut tends to fall into a small set of categories: the shape of the project (where things live, what's generated vs. hand-written), naming and style conventions that aren't enforced by a linter, hard boundaries ("never," "always," specific files or directories that are off-limits), and non-obvious context a new contributor wouldn't guess — the kind of thing you'd tell a new hire in their first ten minutes, not their first week.

If it's procedural and deterministic, it's a hook. If it's a multi-step task you trigger on purpose, it's a command. If it's a standing fact about the project that shapes every decision, it's CLAUDE.md. Most bloat comes from putting the first two kinds of information into the third bucket because it's the easiest file to open and add a line to.

Prune on a schedule, not just when it hurts

The honest fix isn't a one-time cleanup — it's a habit. Every time you're tempted to add a line, check if an existing line already covers it. Every few weeks, re-read the whole file out loud (or have Claude summarize it back to you — if the summary surprises you, the file has drifted from what you think it says). A CLAUDE.md that's actively maintained at 40 tight lines beats one that grew to 400 and hasn't been fully read by a human in months.

A starter CLAUDE.md template with commented placeholder sections (so you begin from a short, deliberate structure instead of an empty file that grows unchecked), plus 12 slash commands, 6 subagents, 5 hooks, and a git-aware statusline, is packaged as the Claude Code Power Pack (copy-paste into .claude/, €29): https://vincentdu2a.gumroad.com/l/bqndfi. It's an independent, unofficial project — not affiliated with, endorsed by, or sponsored by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic.

(Written with AI assistance.)

Claude Code hooks: why "just tell it not to" doesn't hold up

VincentChabran — Sun, 02 Aug 2026 23:45:52 +0000

If you've spent time customizing Claude Code, you've probably written a line like this in your CLAUDE.md: "always run the formatter after editing a file" or "never touch .env or any .pem/.key file." It works — until a long session, a big diff, or a context window full of other instructions makes that one line easy to deprioritize. The model isn't being careless; a system prompt is advisory. Every instruction in it competes with everything else in context for attention, and instructions written early tend to fade as the conversation grows.

That's a structural limit, not a prompting mistake. And it means anything you actually need to happen every single time — not "usually," not "when the model remembers to" — doesn't belong in a prompt at all.

What a hook actually is

Claude Code hooks are shell commands wired to specific points in the tool's lifecycle: after a file edit, before a tool runs, when Claude finishes responding, when it needs your permission, at the start of a session. They execute as code, deterministically, regardless of what's in the conversation or what the model "decided" to prioritize that turn. The model doesn't get a vote — the hook just runs.

That distinction matters more than it sounds. A CLAUDE.md rule is a request you're hoping gets honored. A hook is a guarantee, because it's not the model doing the enforcing.

Where the line actually falls

Not everything belongs in a hook. The useful split is:

Must always happen, no judgment required → hook. Reformatting a file after every edit. Blocking writes to a credentials file before they land. Running your test suite the moment Claude stops and printing a one-line pass/fail. Pinging your desktop when Claude is waiting on you. Logging that a session started, with a timestamp, every time.
Benefits from reasoning about the specific case → prompt / subagent. Deciding whether a diff has a security problem, what a docstring should say, how to restructure a function — that's judgment, and judgment is what the model is for. Trying to hardcode that into a shell script just moves the fragility somewhere worse.

Getting this backwards is the common failure mode: people write increasingly elaborate CLAUDE.md instructions trying to force deterministic behavior out of a probabilistic system, when a five-line shell hook would have made the question moot.

A cheap companion: visibility instead of enforcement

A statusline doesn't enforce anything — it's just a line under your prompt showing which model, which directory, which git branch you're currently in. It matters for a much smaller reason: once you're running more than one Claude Code session in parallel (a common outcome of subagents and worktrees), "which one is this again" becomes a real source of mistakes. Cheap to add, easy to forget you need until you're context-switching between four terminals.

The takeaway

Before adding another paragraph to your CLAUDE.md, ask whether what you actually want is a rule the model should weigh, or a guarantee that shouldn't depend on it weighing anything at all. If it's the latter, write a hook instead.

(Written with AI assistance.)

A working set of these — auto-format on edit, a secret-file guard that blocks writes to .env/*.pem/*.key before they happen, run-tests-on-stop, desktop notifications, and session logging — plus 12 slash commands, 6 subagents, and a git-aware statusline, is packaged as the Claude Code Power Pack (copy-paste into .claude/, €29): https://vincentdu2a.gumroad.com/l/bqndfi. It's an independent, unofficial project — not affiliated with, endorsed by, or sponsored by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic.

Splitting one "review this code" subagent into three — what changes

VincentChabran — Sun, 02 Aug 2026 15:32:10 +0000

A common way to set up Claude Code review is a single subagent with one prompt: "review this diff for bugs, missing tests, and security issues." One report at the end. It works, sort of — but the reports tend to be shallow in a specific, predictable way: whichever concern comes first in the prompt gets the most attention, and whatever comes last gets a token sentence or nothing at all.

That's not a model-quality problem. It's a structural one.

Why one agent doing three jobs underperforms

A single subagent has one context window and one output budget for the task. Ask it to reason about logic correctness, test coverage, and security in the same pass, and it has to allocate attention across three different mental models at once: "does this code do what it claims," "what inputs are missing coverage," and "how could this be abused." Those aren't the same lens. A reviewer scanning for logic bugs is pattern-matching against intent. A security auditor is pattern-matching against attacker behavior. Forcing one pass to do both means it either picks a dominant lens and treats the others as an afterthought, or it spreads evenly and goes shallow everywhere.

In practice, that tends to show up as: the review agent flags a naming inconsistency and an off-by-one, then adds a bullet like "consider adding tests" with no specifics, and rarely surfaces anything security-related unless the diff is obviously about auth.

Splitting the concern, not just the prompt

The fix isn't a better prompt — it's three separate subagents, each with a narrow job and only the tool access it actually needs:

code-reviewer: read-only access to the diff and surrounding files. Its entire prompt is about correctness, security, and design issues, severity-ranked.
test-writer: read access, plus write access scoped to test files. Its job is to find code paths the diff touches that have no coverage and write deterministic tests in the framework already in the repo.
security-auditor: read-only, but with permission to grep across the whole repo, not just the diff. Injection risks, unsafe deserialization, and secrets-in-code usually require seeing how a value flows outside the immediate change — a diff-only view misses that.

Each one produces a short, focused report instead of one long generic one. Dispatched together (in parallel, since they don't depend on each other), the total review reads like three specialists each did a pass, because that's literally what happened.

The difference isn't that any individual subagent is "smarter" than the combined one — it's that scoping the tool access and the prompt to a single concern removes the tradeoff between depth and breadth. The security-auditor isn't competing for attention with "is this variable named well." It only has one job, so it does that job instead of a third of three jobs.

The part that's easy to get wrong

The temptation is to give every subagent full repo access "just in case." Don't — it slows them down and, worse, it re-introduces the same attention dilution you were trying to fix, just at the tool-selection level instead of the reasoning level. Least-privilege tool access isn't just a security nicety here, it's what keeps each subagent's job narrow enough to actually be good at it.

This reviewer/test-writer/security-auditor split, plus three more subagents (debugger, doc-writer, refactor-specialist), 12 slash commands, 5 hooks, a git-aware statusline, and a CLAUDE.md template are packaged into the Claude Code Power Pack (copy-paste into .claude/, €29): https://vincentdu2a.gumroad.com/l/bqndfi. It's an independent, unofficial project — not affiliated with, endorsed by, or sponsored by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic.

(Written with AI assistance.)

I Automated the Awkward Part of Asking for Google Reviews (n8n, 14 nodes, no code)

VincentChabran — Fri, 31 Jul 2026 17:15:56 +0000

Every local business owner I've talked to agrees on the same thing: asking a client for a Google review feels awkward. You either forget to do it, do it too soon (before they've had time to actually think about the job), or do it once and never follow up because chasing someone for a review feels pushier than the job itself.

So I built a small n8n workflow that removes the awkward part and keeps the polite part.

What it actually does

The workflow triggers when a job is marked complete (from a form, a CRM row, or a simple spreadsheet update — whatever the freelancer already uses). It then:

Checks whether this contact has already been sent a review request before. If yes, it stops there and just logs it. No client gets asked twice for the same job.
Sends a short email with a direct link to leave a Google review — not a generic "please review us," a link that drops the client straight into the review box.
Waits until day 7.
Checks again before doing anything else: has a review already come in, or did the contact opt out? If either is true, it stops. No reminder goes out to someone who already left a review or asked not to be contacted.
If neither happened, it sends exactly one reminder email. Not two, not a drip sequence — one.
Every outcome — sent, reviewed, reminded, skipped, opted out — gets logged to a Google Sheet.

That's 14 nodes total, and the two edge cases above (duplicate detection, stop-on-review) are the ones that actually matter. A review-request workflow that doesn't check for those two things is the kind of thing that annoys a client into leaving a bad review instead of a good one.

What it doesn't do

It doesn't guarantee you'll get more reviews. No workflow can promise that — it depends on the job you did and whether the client actually liked it. What it guarantees is that the ask happens consistently, at the right moment, without ever asking twice or nagging someone who already reviewed you.

Why I built it as a kit instead of a one-off

I do this kind of automation work for local businesses (plumbers, hairdressers, small studios). I got tired of rebuilding the same 14 nodes from scratch every time, so I packaged it: the importable n8n JSON, a setup guide in English and French, a one-page checklist for the end client, and a short compliance note on sending automated follow-up emails responsibly.

I also put together a small GitHub repo that shows the structure of the flow (the node sequence, not the full working file — that part's in the kit).

Where to get it

The kit — importable workflow + FR/EN guides + client checklist + compliance note — is on Gumroad for $49: https://vincentdu2a.gumroad.com/l/lxaziv

Happy to answer questions about the n8n setup in the comments if anyone's building something similar.

A Game Design Document template sized for solo devs (not AAA studios)

VincentChabran — Fri, 31 Jul 2026 08:59:27 +0000

I've been making small games as a side project, and every time I start one, the same thing happens: the "design doc" is either a 40-page template I never finish, or a couple of scattered notes that don't survive contact with week 3.

So I put together a one-document GDD template sized for solo and small-team projects -- the kind of thing you can actually fill in an afternoon, not a semester.

What it covers

11 sections: Overview, Elevator Pitch, Core Mechanics, Game Loop, Controls, Characters, Levels & Progression, Art & Audio Direction, Scope & Cut List, Roadmap & Milestones, Risks & Open Questions.

The one I'd flag: Scope & Cut List. It's the section most first-timers skip, and skipping it is exactly how a two-week prototype turns into a six-month grind. Writing down what you're deliberately NOT building is as useful as writing down what you are.

Worked example included

Rather than ship an empty template and a wall of instructions, the pack includes a full worked example -- a tiny fictional arcade game called "Ember Drift" -- with every section filled in, so you can see what "done" looks like for a small project before you write your own.

Format

Markdown (.md) + PDF. Works in any text editor, or drop it into Notion, Obsidian, or Google Docs.

Repo with the full section breakdown: https://github.com/VincentChabran/game-design-document-template

Full template + PDF + worked example: https://vincentdu2a.gumroad.com/l/galfj

(Built with AI assistance, reviewed and edited by hand before release -- disclosed on the product page.)

8 free-to-preview minimalist SVG weather icons (sun, cloud, rain, snow, wind, storm, fog, moon)

VincentChabran — Thu, 30 Jul 2026 20:27:44 +0000

I put together a small set of 8 weather icons as SVG: sun, cloud, rain, snow, wind, storm, fog, moon. Flat, single-color shapes, built to stay legible at small sizes — the kind of thing you'd drop into a weather widget, a forecast app, a dashboard or a game HUD.

Why SVG

Scalable to any size without quality loss, and easy to recolor by editing the fill attribute directly — no design software needed.

Where to look

The 8 icons are viewable in a small GitHub repo: https://github.com/VincentChabran/weather-icons-svg-pack
The packaged version (zip + README, licensed for personal and commercial use) is on Gumroad: https://vincentdu2a.gumroad.com/l/tfuwr ($3)

A note on process

The icon set was created with the assistance of generative AI tools as part of the design process, then reviewed and finalized by hand before release — a couple of the shapes went through multiple redraws to make sure each one was an original construction rather than a close copy of an existing icon set.

If you use them in something, I'd be curious to see it.

Why Claude Code keeps asking for permission — and how to fix your setup so it stops

VincentChabran — Wed, 08 Jul 2026 17:34:21 +0000

You set up Claude Code, you're in flow, and then: "Allow Bash(git diff)?" You click allow. Thirty seconds later: "Allow Bash(git log)?" Allow. Then the same slash command you already approved yesterday asks again. At some point you're tempted to reach for --dangerously-skip-permissions and be done with it.

Don't. Permission fatigue isn't fixed by surrendering — it's fixed by understanding the three specific reasons Claude Code prompts you, and configuring each one away. That takes about ten minutes, and this article is the complete walkthrough: the permission model, a documented trap inside slash commands that keeps prompting even when you've allowed everything, a copy-paste settings.json, and the case where a hook is safer than a broader allow.

In a previous article I showed the slash commands, subagent, and hooks I install in every repo. This is the deep-dive on the part of that setup that generates the most questions.

Unofficial, community-made. Not affiliated with or endorsed by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic. This is independent config for Claude Code, not a product of Anthropic.

Everything below was verified by actually running it on Claude Code v2.1.x (July 2026). The tool ships fast — if you're reading this much later, double-check the details against the current docs.

The three reasons you get prompted

Every permission prompt you see is one of these:

No rule covers the tool call. The default answer for anything not explicitly allowed is "ask." Fix: an allowlist in settings.json.
A slash command injects shell output, and nothing covers it — neither the command's allowed-tools frontmatter nor your settings. Fix: list the commands in the frontmatter.
The command is listed, but Claude Code can't statically verify it — because it contains dynamic constructs like $(...). This is the sneaky one, and it prompts on every invocation no matter what you've approved. Fix: rewrite the command (section below).

Let's take them in order.

Reason 1: the allowlist you haven't written yet

Claude Code reads permission rules from three settings files, most specific wins:

~/.claude/settings.json — you, on every project.
.claude/settings.json — this project, committed and shared with your team.
.claude/settings.local.json — this project, just you (git-ignored automatically).

Rules live under a permissions key in three lists: allow, ask, and deny — and deny always beats ask, which beats allow. A rule is a tool name plus an optional specifier:

Bash(git diff:*) — any command starting with git diff (the :* makes it a prefix match; without it, only the exact command matches).
Read(./.env) / Read(./secrets/**) — gitignore-style paths for file tools.
WebFetch(domain:docs.anthropic.com) — fetches scoped to a domain.

Two practical notes. First, when you click "always allow" on a prompt, Claude Code writes the rule to your local project settings — handy, but it means your allowlist grows ad hoc and never transfers to the next repo. Writing it deliberately in ~/.claude/settings.json fixes the fatigue everywhere at once. Second, run /permissions inside Claude Code any time to see exactly which rules are in effect and where each one comes from.

Reason 2: slash commands have their own gate

A custom slash command (a markdown file in .claude/commands/) can inject live shell output into its prompt with !`command`. That's the feature that makes commands like /review work on your actual diff. But those injected commands run the moment you invoke the slash command — so each one needs approval first. On v2.1.x, an injection is auto-approved if any of three things covers it: the command's own allowed-tools frontmatter, an allow rule in your settings, or Claude Code's built-in pass for a few safe read-only commands (like date). If none of the three covers it, you get prompted. The frontmatter is the one to reach for:

---
description: "Review the current changes before committing"
allowed-tools: Bash(git status:*), Bash(git diff:*)
---

- Changed files: !`git status --short`
- Full diff: !`git diff HEAD`

Both injections are covered, so this runs silently — for everyone. Skip the frontmatter and the command may still seem fine on your machine, if your own settings happen to allow git status and git diff — and then it prompts the teammate who cloned the repo without your allowlist. The frontmatter is what makes a slash command portable and self-sufficient: it carries its own permissions instead of borrowing yours. If a command of yours always asks, this is the first thing to check.

So far, so documented. Now the trap.

Reason 3: the "too complex to verify" trap

Here's a command that looks perfectly configured — and prompts on every invocation anyway:

---
description: Summarize what this branch changes compared to main
allowed-tools: Bash(git log:*), Bash(git diff:*), Bash(git merge-base:*)
---

## Context

- Commits on this branch: !`git log --oneline $(git merge-base main HEAD)..HEAD`
- Files touched: !`git diff --stat $(git merge-base main HEAD)...HEAD`

## Task

Summarize this branch for a teammate: what changed, why, and what looks risky.

Every piece is listed in allowed-tools — git log, git diff, git merge-base. And yet: permission prompt, each time.

The reason: to auto-approve an injected command, Claude Code has to statically prove it matches an allowed pattern. git diff --stat HEAD is a literal string — provable. git diff --stat $(git merge-base main HEAD)...HEAD contains a command substitution whose output can't be known before running it — so the analyzer classifies the whole command as too complex to verify and falls back to asking you. In my testing on v2.1.x this applies to $(...), backticks, and even innocent-looking git expansions like @{u} (!`git log @{u}..HEAD` prompts too, despite containing no substitution at all).

This is a security feature, not a bug — a $(...) buried inside a pre-approved-looking command is exactly how a prompt-injection attack would smuggle something past your allowlist. So don't fight the analyzer. Restructure instead:

Keep the injections static. Move the dynamic logic into the task, where Claude resolves it at runtime.

---
description: Summarize what this branch changes compared to main
allowed-tools: Bash(git branch:*), Bash(git log:*), Bash(git diff:*), Bash(git merge-base:*)
---

## Context

- Current branch: !`git branch --show-current`
- Recent commits (fallback view): !`git log --oneline -15`

## Task

1. Find where this branch forked: run `git merge-base main HEAD`.
2. Read the exact range using the real SHA from step 1: `git log <base>..HEAD --oneline`
   and `git diff --stat <base>...HEAD` (substitute the SHA for `<base>` — don't nest
   `$(git merge-base ...)` inside the command, or it will trigger a permission prompt).
3. Summarize this branch for a teammate: what changed, why, and what looks risky.

Same capability, zero prompts. The injections are now literal strings the analyzer can match. The fork-point lookup happens as a normal tool call during the task: Claude runs git merge-base main HEAD (covered by Bash(git merge-base:*)), reads the SHA, then runs git log a1b2c3d..HEAD (covered by Bash(git log:*)). Note the warning inside the prompt itself: the same rule applies at runtime, so telling Claude to substitute the literal SHA — instead of nesting $(...) — is what keeps step 2 prompt-free.

Rule of thumb: !`...` injections should be commands you could type from muscle memory — fixed strings, no substitutions, no expansions. Anything conditional belongs in the task instructions.

A clean, copyable `settings.json`

Here's a complete baseline that removes the everyday prompts without opening anything scary. It also includes an auto-format hook (from the free kit linked at the end) so you can see how permissions and hooks coexist in one file:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git branch:*)",
      "Bash(git show:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git merge-base:*)",
      "Bash(ls:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force:*)"
    ]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); [ -z \"$f\" ] && exit 0; case \"$f\" in *.js|*.jsx|*.ts|*.tsx|*.json|*.css|*.scss|*.html|*.md|*.yml|*.yaml) command -v prettier >/dev/null 2>&1 && prettier --write \"$f\" >/dev/null 2>&1 ;; *.py) command -v black >/dev/null 2>&1 && black -q \"$f\" >/dev/null 2>&1 ;; *.go) command -v gofmt >/dev/null 2>&1 && gofmt -w \"$f\" >/dev/null 2>&1 ;; *.rs) command -v rustfmt >/dev/null 2>&1 && rustfmt \"$f\" >/dev/null 2>&1 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

Why these choices:

The allows are read-mostly. Status, diffs, logs, tests, lint — the commands Claude runs constantly and that can't hurt you. git add and git commit are there because committing is the point; there's deliberately no git push in the allowlist, so anything leaving your machine still asks.
The denies protect secrets from being read, not just edited. Claude never needs the contents of .env to help you code.
Put it in ~/.claude/settings.json for yourself everywhere, or .claude/settings.json to share the policy with your team. Restart Claude Code after saving.

When a hook beats a broader allow

Notice the deny rule Bash(git push --force:*). It works — but it's a string prefix. git push -f sails right past it. Permission rules are a convenience layer; when you want a guarantee, use a PreToolUse hook, which runs before the tool executes and can block it regardless of what the permission rules would have allowed.

Say you've allowed file edits broadly because the edit prompts were driving you mad. This hook makes sure that no matter what, credential files stay untouched:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); case \"$f\" in *.env|*.env.*|*.pem|*.key) echo \"Blocked: $f looks like a credentials file. Edit it yourself.\" >&2; exit 2 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

The hook reads the tool's JSON payload on stdin (jq pulls out the file path — brew install jq / sudo apt install jq), and exit code 2 blocks the action and hands your stderr message back to Claude as the reason, so it adapts instead of retrying blindly. Exit 0 stays out of the way.

The mental model: allow rules decide what runs without asking; hooks decide what never runs at all. Broad allow + narrow hard-block is a much nicer place to work than narrow allows + constant prompts — you get the flow back without giving up the guarantees you actually care about.

The 10-minute fix, recapped

Write a deliberate allowlist of read-mostly commands in ~/.claude/settings.json — stop accumulating one-off "always allow" clicks.
Give every custom slash command an allowed-tools frontmatter covering its !`...` injections.
Keep those injections static. Move anything with $(...), backticks, or @{u}-style expansions into the task instructions.
Guard the truly untouchable (secrets, force-pushes) with a PreToolUse hook exiting 2, not with an ever-longer prompt-clicking habit.

Get the files

The slash commands, the subagent, and the auto-format hook from this series — with the permission lessons above already applied — live in a free, MIT-licensed repo you can copy straight into .claude/ (the PreToolUse credentials guard isn't bundled with the kit — copy it straight from this article):

→ Claude Code Starter Kit on GitHub (MIT — use it, change it, ship it)

And if you want the extended set (12 commands, 6 subagents, 5 hooks, a git-aware status line, and a step-by-step guide), that's the paid Power Pack — but everything in this article works with the free repo alone.

Happy building.

The Claude Code setup I install in every repo: slash commands, a review subagent, and hooks

VincentChabran — Tue, 07 Jul 2026 18:04:30 +0000

Claude Code is powerful the moment you install it. But the thing that makes it feel like a real teammate isn't the model — it's the configuration you build up around it: custom slash commands, specialist subagents, and hooks that run at the right moments.

The problem is that a fresh install is a blank .claude/ folder. You get all that value only after you read the docs and write the config yourself.

So here's the config I now copy into every repo. Everything below is a plain file you can paste, read, and change. I'll show you real commands, a subagent, and a hook — with the actual code and why each part is there — so you can rebuild this yourself in an afternoon.

Unofficial, community-made. Not affiliated with or endorsed by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic. This is independent config for Claude Code, not a product of Anthropic.

Where this config lives

Two locations, and you can use both:

~/.claude/ in your home directory — applies to every project you open.
.claude/ in a repo root — applies to that project, and you can commit it to share with your team.

When a project file and a global file collide, the project one wins. I keep general-purpose commands and subagents in ~/.claude/, and project-specific rules in the repo.

1. A slash command is just a markdown file

The file name is the command name: .claude/commands/review.md becomes /review. The body is the prompt Claude runs. Here's a full, useful one — a pre-commit code review:

---
description: "Review the current changes for bugs, risks and quality before you commit"
argument-hint: [optional path or focus]
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*)
---

## Context

- Changed files: !`git status --short`
- Full diff: !`git diff HEAD`

## Task

Act as a careful senior reviewer of the diff above (focus on "$ARGUMENTS" if provided).

Report findings grouped by severity — **Blocking**, **Should-fix**, **Nit** — and for
each give the `file:line`, what is wrong, and a concrete fix. Look specifically for:

- **Correctness**: off-by-one, null/undefined, wrong operators, missed edge cases.
- **Security**: injection, unsafe input handling, secrets committed, missing auth checks.
- **Concurrency & resources**: races, leaks, unclosed handles, missing timeouts.
- **Contracts**: API changes that break callers or aren't reflected in tests/docs.

If the diff is clean, say so plainly instead of inventing problems. End with a one-line
verdict: safe to commit, or not yet.

Three things are doing the work here:

! runs a shell command and injects its output into the prompt. !`git diff HEAD` means Claude reviews your actual current diff, not a description of it. This is the single most useful trick in the whole system.
allowed-tools pre-approves exactly those git commands, so /review doesn't stop to ask permission every time it reads the diff. (If Claude Code still prompts you all the time, I wrote a deep-dive on the permission model and how to fix it — including a trap that makes a command prompt on every run even when everything looks allowed.)
$ARGUMENTS is whatever you type after the command. /review the auth changes focuses the review; /review alone reviews everything.

Now /review gives you a consistent, senior-style pass over your changes every time, instead of a fuzzy "can you check this?"

2. Bake your repo's conventions into `/commit`

Same idea, pointed at commits. The trick here is feeding Claude your recent history so the new message matches the style you already use:

---
description: Create a well-formed git commit from the current changes
argument-hint: [optional message or intent]
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*)
---

## Context

- Current status: !`git status --short`
- Staged diff: !`git diff --cached`
- Recent commits (match this style): !`git log --oneline -10`

## Task

Create one focused git commit for the changes above.

1. If nothing is staged, stage the files that clearly belong together — never unrelated
   files, build artifacts, or anything that looks like a secret.
2. Write a Conventional Commits message (`type(scope): summary`), imperative mood,
   ≤ 72 chars, matching the tone of the recent commits shown above.
3. Commit with `git commit`. Do **not** push. No co-author trailers or tool ads.

If the staged changes cover several unrelated concerns, say so and propose splitting them.

Because !`git log --oneline -10` injects your last ten commits, Claude writes in your house style — not a generic chore: update files. And "do not push" keeps a human in the loop for the one step that leaves your machine.

3. Subagents: specialists with their own context window

A subagent is a markdown file in .claude/agents/ with a bit of frontmatter and a system prompt. Claude can hand a task to it automatically, or you can call it by name. The win: the subagent works in a separate context window, so a long review or audit doesn't clutter your main conversation.

Here's the code-reviewer I use:

---
name: code-reviewer
description: Expert code reviewer. Use PROACTIVELY right after writing or changing code,
  and before committing, to catch correctness, security and design issues.
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior software engineer doing a focused, high-signal code review.
Your job is to catch what matters and say it plainly.

## What you look for, in priority order

1. **Correctness** — logic errors, off-by-one, null/undefined, unhandled error paths.
2. **Security** — untrusted input reaching queries/commands/filesystem, injection,
   missing auth, secrets committed.
3. **Contracts** — API changes that break callers or aren't reflected in tests/docs.
4. **Resource & concurrency** — leaks, races, missing timeouts.
5. **Design & readability** — duplication, dead code, unclear names. Lower priority.

## Rules

- Do not invent problems to seem thorough. If the code is solid, say so and stop.
- End with a one-line verdict: **safe to merge**, **safe after should-fixes**, or **not yet**.

Two details matter:

The description is how Claude decides when to delegate. Writing it as "use PROACTIVELY right after writing code" is what makes the subagent trigger on its own. Vague descriptions never fire.
tools scopes what it can touch. A reviewer only needs to read and search (Read, Grep, Glob, Bash) — it shouldn't be editing your files. Omit tools entirely and it inherits everything.

After this is in place, Claude tends to call the reviewer itself after a change. You can always force it: "have the code-reviewer look at the auth module."

4. Hooks: automate what you'd otherwise forget

Hooks run your shell commands at defined moments in a session. They live in settings.json. The one I'd never work without formats every file the instant Claude edits it:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); [ -z \"$f\" ] && exit 0; case \"$f\" in *.js|*.jsx|*.ts|*.tsx|*.json|*.css|*.scss|*.html|*.md|*.yml|*.yaml) command -v prettier >/dev/null 2>&1 && prettier --write \"$f\" >/dev/null 2>&1 ;; *.py) command -v black >/dev/null 2>&1 && black -q \"$f\" >/dev/null 2>&1 ;; *.go) command -v gofmt >/dev/null 2>&1 && gofmt -w \"$f\" >/dev/null 2>&1 ;; *.rs) command -v rustfmt >/dev/null 2>&1 && rustfmt \"$f\" >/dev/null 2>&1 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

How to read that:

PostToolUse + matcher: "Edit|Write|MultiEdit" means "run after Claude edits or writes a file." The matcher is a regex on the tool name.
Claude Code sends the hook a JSON payload on stdin. Here jq pulls out .tool_input.file_path — the file that was just touched.
It picks a formatter by extension and no-ops silently if that formatter isn't installed, so it never breaks a session on a machine that doesn't have black.
Exit codes are the contract: 0 = fine, continue. 2 = block the action and hand your message back to Claude as the reason. (A PreToolUse hook that exits 2 on .env paths is a nice guard against Claude ever editing your secrets.)

jq is the only dependency (brew install jq / sudo apt install jq).

Install it in two minutes

Grab the files, drop them in, restart:

mkdir -p ~/.claude/commands ~/.claude/agents
cp commands/*.md ~/.claude/commands/
cp agents/*.md   ~/.claude/agents/
# then merge the hooks block into ~/.claude/settings.json

Restart Claude Code, type /, and the commands are there. Run /agents to see the subagent, /hooks to confirm the hook loaded.

One habit that makes all of this better

Notice a theme in the prompts above: they're written to be honest. The review command is told not to invent problems. A companion /pr command writes "not yet tested" instead of pretending. That matters — the fastest way to lose trust in an AI teammate is catching it claim a test passed when it never ran. Bake that into your prompts and the output stays trustworthy.

Get the files

I put the four commands, the code-reviewer subagent, the auto-format hook, and a CLAUDE.md template in a free, MIT-licensed repo so you can copy them straight in:

→ Claude Code Starter Kit on GitHub (MIT — use it, change it, ship it)

If you end up wanting the full set — 12 commands, 6 subagents, 5 hooks, a git-aware status line, and a full CLAUDE.md template — there's a paid Power Pack that bundles it with a step-by-step guide. But the repo above is enough to get real value today.

Happy building.

One Block to Force a Default AWS Region Across Every Terragrunt Module

VincentChabran — Mon, 06 Jul 2026 17:32:57 +0000

A quiet failure mode in multi-module Terragrunt setups: someone copies an existing module to bootstrap a new one, forgets to check the region in the provider config, and a resource lands in us-east-1 instead of eu-west-1 — three weeks later, someone's debugging why a Lambda can't reach a VPC that "should" be right there.

This isn't a Terraform bug. It's a consequence of region being just another string that every module has to get right, independently, forever.

The default pattern (and why it's fragile)

Most Terragrunt setups declare region per-project:

# projects/some-service/project.hcl
locals {
  aws_region = "eu-west-1"
}

Then the provider generation block in root.hcl reads it:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "aws" {
  region = "${local.project.locals.aws_region}"
}
EOF
}

Nothing wrong with this in isolation. The problem shows up at scale: with 20+ modules, aws_region is set 20+ times, by hand, by whoever created each module — usually by copy-pasting an existing project.hcl and hoping they remembered to check every field. New modules silently inherit whatever the copy-paste source happened to have, correct or not.

The pattern: a default that wins unless explicitly overridden

Flip the default. root.hcl computes the region with a fallback, so a project only needs to declare aws_region when it's an actual, deliberate exception:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))

  # Falls back to the org-wide default if the project doesn't override it.
  aws_region = try(local.project.locals.aws_region, "eu-west-1")
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "aws" {
  region = "${local.aws_region}"
}
EOF
}

Now a brand-new project.hcl can be empty on the region question and still deploy to the right place by default:

# projects/brand-new-service/project.hcl
locals {
  legacy_prefix = "brand-new-service"
  # no aws_region — inherits eu-west-1 from root.hcl automatically
}

An exception is now a visible, deliberate line, not a silent inheritance from whatever was copy-pasted:

# projects/legacy-email-sender/project.hcl
locals {
  legacy_prefix = "legacy-email-sender"
  aws_region    = "eu-north-1" # locked to this region — legacy third-party integration, see runbook §3
}

The difference is where the burden of proof sits. Before: every module has to actively get the region right. After: every module gets it right by doing nothing, and getting it "wrong" (i.e., different from the default) requires writing a line down and, ideally, a comment saying why.

Where this generalizes

Region is the clearest example because a wrong region is easy to notice, but the same shape applies to any setting that should be consistent across a growing set of modules and currently isn't enforced by anything except habit: default tags, default VPC, default log retention. Anywhere you find yourself saying "just copy an existing module's config and change what's different," that's a signal the common part belongs in the root config with a try() fallback, and only the actual differences belong in each project's own file.

It costs one extra local in root.hcl. It saves the debugging session three weeks from now.

Renaming Terragrunt Projects Without Migrating State

VincentChabran — Mon, 06 Jul 2026 17:31:33 +0000

If you've run Terragrunt across more than a handful of modules for a while, you've hit this: you want to reorganize your repo — rename a folder, group projects differently, fix a naming mistake from six months ago — and Terragrunt's default behavior punishes you for it.

The problem

By default, Terragrunt derives your remote state key from the file path of the module. Something like:

# root.hcl
remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "${path_relative_to_include()}/terraform.tfstate"
    region = "eu-west-1"
  }
}

path_relative_to_include() is convenient until the day you move projects/old-name/ to projects/new-name/. The key changes, Terraform can no longer find the state for those resources, and you're one terragrunt apply away from either a pile of "already exists" errors or, worse, Terraform trying to recreate live infrastructure because it thinks it's gone.

The usual fixes are painful: terraform state mv per resource, or a full terraform import pass. Both work, both are slow, both are one typo away from downtime on something that's just supposed to be a folder rename.

The pattern: decouple the state key from the file path

Give every project a project.hcl with a legacy_prefix — the state key it should keep, independent of wherever the folder happens to live today:

# projects/new-name/project.hcl
locals {
  legacy_prefix = "old-name"   # the prefix this project's state has always used
  aws_region    = "eu-west-1"
}

Then have root.hcl build the state key from that prefix instead of the live path:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))
}

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "${local.project.locals.legacy_prefix}/terraform.tfstate"
    region = "eu-west-1"
  }
}

Now the folder path is free to change. Rename it, move it, restructure the whole repo — the state key is pinned to legacy_prefix, not to path_relative_to_include(). A new project just sets legacy_prefix to whatever it wants (usually matching its own path, since it has no history to preserve); an existing project keeps its old prefix forever, regardless of where the folder lives.

The proof, not just the theory

Don't take "it should work" on faith. Before you consider a reorganization safe, run:

terragrunt plan

on every module you touched, and the only acceptable output is:

Plan: 0 to add, 0 to change, 0 to destroy.

Anything else means the key computation didn't land on the same value as before, and you stop right there. This one-line proof requirement is what makes the whole pattern trustworthy enough to use on live infrastructure: you're not hoping the refactor is safe, you're verifying it before it touches anything.

When this is worth it

This pattern earns its keep the moment you have more than a few Terragrunt modules and expect to reorganize them more than once — a new team convention, a naming scheme that didn't survive contact with reality, projects that outgrew their original folder structure. If you have three modules that will never move, plain path_relative_to_include() is simpler and you don't need this.

The core idea generalizes beyond Terragrunt: whenever a tool derives a stable identifier (a state key, a resource ID, a cache key) from something that isn't actually stable (a file path, a display name), that's worth decoupling explicitly — before the first painful migration forces you to do it under pressure.

DEV Community: VincentChabran

Why Your Local Business Loses Leads Before You Even Open Your Email

The fix isn't "answer faster." It's "acknowledge instantly."

What that looks like as a workflow

Where to get it

Your CLAUDE.md is probably too long — here's how to tell and what to do about it

Length isn't the real problem — signal-to-noise is

A quick audit: read your CLAUDE.md and cut the dead weight

What's actually worth keeping

Prune on a schedule, not just when it hurts

Claude Code hooks: why "just tell it not to" doesn't hold up

What a hook actually is

Where the line actually falls

A cheap companion: visibility instead of enforcement

The takeaway

Splitting one "review this code" subagent into three — what changes

Why one agent doing three jobs underperforms

Splitting the concern, not just the prompt

The part that's easy to get wrong

I Automated the Awkward Part of Asking for Google Reviews (n8n, 14 nodes, no code)

What it actually does

What it doesn't do

Why I built it as a kit instead of a one-off

Where to get it

A Game Design Document template sized for solo devs (not AAA studios)

What it covers

Worked example included

Format

8 free-to-preview minimalist SVG weather icons (sun, cloud, rain, snow, wind, storm, fog, moon)

Why SVG

Where to look

A note on process

Why Claude Code keeps asking for permission — and how to fix your setup so it stops

The three reasons you get prompted

Reason 1: the allowlist you haven't written yet

Reason 2: slash commands have their own gate

Reason 3: the "too complex to verify" trap

A clean, copyable settings.json

When a hook beats a broader allow

The 10-minute fix, recapped

Get the files

The Claude Code setup I install in every repo: slash commands, a review subagent, and hooks

Where this config lives

1. A slash command is just a markdown file

2. Bake your repo's conventions into /commit

3. Subagents: specialists with their own context window

4. Hooks: automate what you'd otherwise forget

Install it in two minutes

One habit that makes all of this better

Get the files

One Block to Force a Default AWS Region Across Every Terragrunt Module

The default pattern (and why it's fragile)

The pattern: a default that wins unless explicitly overridden

Where this generalizes

Renaming Terragrunt Projects Without Migrating State

The problem

The pattern: decouple the state key from the file path

The proof, not just the theory

When this is worth it

A clean, copyable `settings.json`

2. Bake your repo's conventions into `/commit`