I’m sure there are other posts and I’m reading some of them, but what’s your favorite hooks. I’ve been happy so far with just using some custom commands and Claude.md files but I want to try hooks and looking for ideas to try

I made this guide so you actually know which one to use and when.

The hook system is incredibly powerful, but the docs don't really explain when to use each one. So I built this reference guide.

• Validating prompts?

• Handling permissions?

• Processing tool results?

• Notifications and logs?

From SessionStart to SessionEnd, understanding the lifecycle is the difference between a hook that works and one that fights against Claude Code's execution flow.

Hey everyone

Working with Claude Code is incredible, but I realized I needed better change tracking for my agentic workflows. So I built rins_hooks, starting with an auto-commit hook that gives Claude Code automatic version history.

What the auto-commit hook does:

1. 🔄 Every Claude edit = automatic git commit with full context📋 See exactly what changed - which tool, which file, when.

2. ⏪Instant rollback - git revert any change you don't like🤖 Zero overhead - works silently in the background

Example of what you get:

$ git log --oneline                               
a1b2c3d Auto-commit: Edit modified api.js         
e4f5g6h Auto-commit: Write modified config.json   
i7j8k9l Auto-commit: MultiEdit modified utils.py  

Each commit shows the exact file, tool used, and session info. Perfect for experimenting with different approaches or undoing changes that didn't work out.

To install:

npm -g rins_hooks

To Run:

rins_hooks install auto-commit --project

This is just the first tool in what I'm building as a comprehensive toolkit for agentic workflows in Claude Code. I'm planning to add hooks for:

- 📊 Agent Performance monitoring (track token usage, response times)

- 🔍 Code quality gates (run linters, tests before commits)

- 📱 Smart notifications (Slack/Discord integration for long tasks)

- 🛡 Safety checks (prevent commits to sensitive files)

-🌿 Commands that don't time out using tmux

The goal is making AI-assisted development more reliable, trackable, and reversible.

Check it out:

- GitHub: https://github.com/rinadelph/rins_hooks

- NPM: https://www.npmjs.com/package/rins_hooks

Any practical guides?

I took the course on deeplearning.ai to work with claude more efficiently, since i use it almost everyday now...

When and where do you use hooks and subagents? I would like to knwo some practical use-cases.

TL;DR: We’ve set up file-specific hooks with Claude Code (CC) that run commands only on certain files. Here’s how we got it working, and the quirks we had to solve.

1. Opportunity

Claude Code recently introduced hooks, which allow you to run commands when certain events occur – like when CC edits a file. This opens up the ability to automatically run formatting (ruff), linting, and type checks (basedpyright) on Python file changes. Super useful.

2. Problems

1. Absolute paths requirement
   Anthropic recommends using absolute paths for hook scripts for security reasons. I’m not fully convinced why – maybe because CC can’t control its CWD? Regardless, this makes it hard to check in project-specific scripts in .claude/settings.json, which we want to share across the team.

2. Monorepo context
   Since we use a monorepo, all commands should run from the repo root to ensure the right pyproject.toml config is picked up. So we needed a way to detect and run from the monorepo root, even if the changed file is nested deeper.

3. No file-type filtering
   CC doesn’t let you filter hooks by file type. So if you edit a markdown file, the hook still runs – and if you pass that file path to a Python type checker, it’ll throw errors. We needed a way to avoid this.

4. Exit code + stderr expectations
   For PostToolUse hooks, CC expects exit code 2 if there’s feedback, and it reads that feedback from stderr. Most CLI tools exit with code 1 and write to stdout, so we had to rewrite both.

5. Efficiency on large codebases
   The official docs examples assume you’ll run hook commands on the entire codebase. That’s fine for fast tools like ruff, but basedpyright is slower – and we don’t want to run it on legacy code. We needed a way to only run it on files that were created or edited.

3. Solution

We got CC to generate this bash command configured as a PostToolUse hook to solve the above:

jq -r \
	'.tool_input.file_path | select(endswith(\".py\")) | . as $full | split(\"/mono/\")[0] + \"/mono\" + \" \" + $full' | \
	xargs -n2 sh -c 'uv run --directory \"$1\" basedpyright \"$2\" >&2' --; [ $? -eq 1 ] && exit 2 || true

Here’s what it does:

1. Takes CC input
   It reads the file path from tool_input.file_path.

2. Extracts the monorepo root
   We assume our monorepo path contains /mono/, and split around it to get the root. Not bulletproof, but works for us.

3. Filters for Python files
   We ignore any files that don’t end in .py.

4. Handles exit codes and output streams
   If the underlying command exits with 1, we convert that to 2 so CC picks it up as feedback. We also redirect any output to stderr.

5. Executes the check
   xargs is used to pass the monorepo root as $1 and the changed file as $2 to basedpyright.

4. Conclusion

This setup works really well for us. It only runs on relevant files, uses our monorepo config, handles the mentioned quirks, and integrates cleanly with our existing toolchain.

That said, it feels like a pretty roundabout way to solve what should be a simple problem. Curious to hear how others have handled this – surely there’s a cleaner way.

Edit: Many of you are asking for a repo so I will make an effort to get one up in the next couple days. All of this is a part of a work project at the moment, so I have to take some time to copy everything into a fresh project and scrub any identifying info. I will post the link here when it's up. You can also follow me and I will post it on my profile so you get notified. Thank you all for the kind comments. I'm happy to share this info with others since I don't get much chance to do so in my day-to-day.

Edit (final?): I bit the bullet and spent the afternoon getting a github repo up for you guys. Just made a post with some additional info here or you can go straight to the source:

🎯 Repository: https://github.com/diet103/claude-code-infrastructure-showcase

Quick tip from a fellow lazy person: You can throw this book of a post into one of the many text-to-speech AI services like ElevenLabs Reader or Natural Reader and have it read the post for you :)

Disclaimer

I made a post about six months ago sharing my experience after a week of hardcore use with Claude Code. It's now been about six months of hardcore use, and I would like to share some more tips, tricks, and word vomit with you all. I may have went a little overboard here so strap in, grab a coffee, sit on the toilet or whatever it is you do when doom-scrolling reddit.

I want to start the post off with a disclaimer: all the content within this post is merely me sharing what setup is working best for me currently and should not be taken as gospel or the only correct way to do things. It's meant to hopefully inspire you to improve your setup and workflows with AI agentic coding. I'm just a guy, and this is just like, my opinion, man.

Also, I'm on the 20x Max plan, so your mileage may vary. And if you're looking for vibe-coding tips, you should look elsewhere. If you want the best out of CC, then you should be working together with it: planning, reviewing, iterating, exploring different approaches, etc.

Quick Overview

After 6 months of pushing Claude Code to its limits (solo rewriting 300k LOC), here's the system I built:

• Skills that actually auto-activate when needed

• Dev docs workflow that prevents Claude from losing the plot

• PM2 + hooks for zero-errors-left-behind

• Army of specialized agents for reviews, testing, and planning Let's get into it.

Background

I'm a software engineer who has been working on production web apps for the last seven years or so. And I have fully embraced the wave of AI with open arms. I'm not too worried about AI taking my job anytime soon, as it is a tool that I use to leverage my capabilities. In doing so, I have been building MANY new features and coming up with all sorts of new proposal presentations put together with Claude and GPT-5 Thinking to integrate new AI systems into our production apps. Projects I would have never dreamt of having the time to even consider before integrating AI into my workflow. And with all that, I'm giving myself a good deal of job security and have become the AI guru at my job since everyone else is about a year or so behind on how they're integrating AI into their day-to-day.

With my newfound confidence, I proposed a pretty large redesign/refactor of one of our web apps used as an internal tool at work. This was a pretty rough college student-made project that was forked off another project developed by me as an intern (created about 7 years ago and forked 4 years ago). This may have been a bit overly ambitious of me since, to sell it to the stakeholders, I agreed to finish a top-down redesign of this fairly decent-sized project (~100k LOC) in a matter of two to three months...all by myself. I knew going in that I was going to have to put in extra hours to get this done, even with the help of CC. But deep down, I know it's going to be a hit, automating several manual processes and saving a lot of time for a lot of people at the company.

It's now six months later... yeah, I probably should not have agreed to this timeline. I have tested the limits of both Claude as well as my own sanity trying to get this thing done. I completely scrapped the old frontend, as everything was seriously outdated and I wanted to play with the latest and greatest. I'm talkin' React 16 JS → React 19 TypeScript, React Query v2 → TanStack Query v5, React Router v4 w/ hashrouter → TanStack Router w/ file-based routing, Material UI v4 → MUI v7, all with strict adherence to best practices. The project is now at ~300-400k LOC and my life expectancy ~5 years shorter. It's finally ready to put up for testing, and I am incredibly happy with how things have turned out.

This used to be a project with insurmountable tech debt, ZERO test coverage, HORRIBLE developer experience (testing things was an absolute nightmare), and all sorts of jank going on. I addressed all of those issues with decent test coverage, manageable tech debt, and implemented a command-line tool for generating test data as well as a dev mode to test different features on the frontend. During this time, I have gotten to know CC's abilities and what to expect out of it.

A Note on Quality and Consistency

I've noticed a recurring theme in forums and discussions - people experiencing frustration with usage limits and concerns about output quality declining over time. I want to be clear up front: I'm not here to dismiss those experiences or claim it's simply a matter of "doing it wrong." Everyone's use cases and contexts are different, and valid concerns deserve to be heard.

That said, I want to share what's been working for me. In my experience, CC's output has actually improved significantly over the last couple of months, and I believe that's largely due to the workflow I've been constantly refining. My hope is that if you take even a small bit of inspiration from my system and integrate it into your CC workflow, you'll give it a better chance at producing quality output that you're happy with.

Now, let's be real - there are absolutely times when Claude completely misses the mark and produces suboptimal code. This can happen for various reasons. First, AI models are stochastic, meaning you can get widely varying outputs from the same input. Sometimes the randomness just doesn't go your way, and you get an output that's legitimately poor quality through no fault of your own. Other times, it's about how the prompt is structured. There can be significant differences in outputs given slightly different wording because the model takes things quite literally. If you misword or phrase something ambiguously, it can lead to vastly inferior results.

Sometimes You Just Need to Step In

Look, AI is incredible, but it's not magic. There are certain problems where pattern recognition and human intuition just win. If you've spent 30 minutes watching Claude struggle with something that you could fix in 2 minutes, just fix it yourself. No shame in that. Think of it like teaching someone to ride a bike - sometimes you just need to steady the handlebars for a second before letting go again.

I've seen this especially with logic puzzles or problems that require real-world common sense. AI can brute-force a lot of things, but sometimes a human just "gets it" faster. Don't let stubbornness or some misguided sense of "but the AI should do everything" waste your time. Step in, fix the issue, and keep moving.

I've had my fair share of terrible prompting, which usually happens towards the end of the day where I'm getting lazy and I'm not putting that much effort into my prompts. And the results really show. So next time you are having these kinds of issues where you think the output is way worse these days because you think Anthropic shadow-nerfed Claude, I encourage you to take a step back and reflect on how you are prompting.

Re-prompt often. You can hit double-esc to bring up your previous prompts and select one to branch from. You'd be amazed how often you can get way better results armed with the knowledge of what you don't want when giving the same prompt. All that to say, there can be many reasons why the output quality seems to be worse, and it's good to self-reflect and consider what you can do to give it the best possible chance to get the output you want.

As some wise dude somewhere probably said, "Ask not what Claude can do for you, ask what context you can give to Claude" ~ Wise Dude

Alright, I'm going to step down from my soapbox now and get on to the good stuff.

My System

I've implemented a lot changes to my workflow as it relates to CC over the last 6 months, and the results have been pretty great, IMO.

Skills Auto-Activation System (Game Changer!)

This one deserves its own section because it completely transformed how I work with Claude Code.

The Problem

So Anthropic releases this Skills feature, and I'm thinking "this looks awesome!" The idea of having these portable, reusable guidelines that Claude can reference sounded perfect for maintaining consistency across my massive codebase. I spent a good chunk of time with Claude writing up comprehensive skills for frontend development, backend development, database operations, workflow management, etc. We're talking thousands of lines of best practices, patterns, and examples.

And then... nothing. Claude just wouldn't use them. I'd literally use the exact keywords from the skill descriptions. Nothing. I'd work on files that should trigger the skills. Nothing. It was incredibly frustrating because I could see the potential, but the skills just sat there like expensive decorations.

The "Aha!" Moment

That's when I had the idea of using hooks. If Claude won't automatically use skills, what if I built a system that MAKES it check for relevant skills before doing anything?

So I dove into Claude Code's hook system and built a multi-layered auto-activation architecture with TypeScript hooks. And it actually works!

How It Works

I created two main hooks:

1. UserPromptSubmit Hook (runs BEFORE Claude sees your message):

• Analyzes your prompt for keywords and intent patterns

• Checks which skills might be relevant

• Injects a formatted reminder into Claude's context

• Now when I ask "how does the layout system work?" Claude sees a big "🎯 SKILL ACTIVATION CHECK - Use project-catalog-developer skill" (project catalog is a large complex data grid based feature on my front end) before even reading my question

2. Stop Event Hook (runs AFTER Claude finishes responding):

• Analyzes which files were edited

• Checks for risky patterns (try-catch blocks, database operations, async functions)

• Displays a gentle self-check reminder

• "Did you add error handling? Are Prisma operations using the repository pattern?"

• Non-blocking, just keeps Claude aware without being annoying

skill-rules.json Configuration

I created a central configuration file that defines every skill with:

• Keywords: Explicit topic matches ("layout", "workflow", "database")

• Intent patterns: Regex to catch actions ("(create|add).*?(feature|route)")

• File path triggers: Activates based on what file you're editing

• Content triggers: Activates if file contains specific patterns (Prisma imports, controllers, etc.)

Example snippet:

{
  "backend-dev-guidelines": {
    "type": "domain",
    "enforcement": "suggest",
    "priority": "high",
    "promptTriggers": {
      "keywords": ["backend", "controller", "service", "API", "endpoint"],
      "intentPatterns": [
        "(create|add).*?(route|endpoint|controller)",
        "(how to|best practice).*?(backend|API)"
      ]
    },
    "fileTriggers": {
      "pathPatterns": ["backend/src/**/*.ts"],
      "contentPatterns": ["router\\.", "export.*Controller"]
    }
  }
}

The Results

Now when I work on backend code, Claude automatically:

1. Sees the skill suggestion before reading my prompt

2. Loads the relevant guidelines

3. Actually follows the patterns consistently

4. Self-checks at the end via gentle reminders

The difference is night and day. No more inconsistent code. No more "wait, Claude used the old pattern again." No more manually telling it to check the guidelines every single time.

Following Anthropic's Best Practices (The Hard Way)

After getting the auto-activation working, I dove deeper and found Anthropic's official best practices docs. Turns out I was doing it wrong because they recommend keeping the main SKILL.md file under 500 lines and using progressive disclosure with resource files.

Whoops. My frontend-dev-guidelines skill was 1,500+ lines. And I had a couple other skills over 1,000 lines. These monolithic files were defeating the whole purpose of skills (loading only what you need).

So I restructured everything:

• frontend-dev-guidelines: 398-line main file + 10 resource files

• backend-dev-guidelines: 304-line main file + 11 resource files

Now Claude loads the lightweight main file initially, and only pulls in detailed resource files when actually needed. Token efficiency improved 40-60% for most queries.

Skills I've Created

Here's my current skill lineup:

Guidelines & Best Practices:

• backend-dev-guidelines - Routes → Controllers → Services → Repositories

• frontend-dev-guidelines - React 19, MUI v7, TanStack Query/Router patterns

• skill-developer - Meta-skill for creating more skills

Domain-Specific:

• workflow-developer - Complex workflow engine patterns

• notification-developer - Email/notification system

• database-verification - Prevent column name errors (this one is a guardrail that actually blocks edits!)

• project-catalog-developer - DataGrid layout system

All of these automatically activate based on what I'm working on. It's like having a senior dev who actually remembers all the patterns looking over Claude's shoulder.

Why This Matters

Before skills + hooks:

• Claude would use old patterns even though I documented new ones

• Had to manually tell Claude to check BEST_PRACTICES.md every time

• Inconsistent code across the 300k+ LOC codebase

• Spent too much time fixing Claude's "creative interpretations"

After skills + hooks:

• Consistent patterns automatically enforced

• Claude self-corrects before I even see the code

• Can trust that guidelines are being followed

• Way less time spent on reviews and fixes

If you're working on a large codebase with established patterns, I cannot recommend this system enough. The initial setup took a couple of days to get right, but it's paid for itself ten times over.

CLAUDE.md and Documentation Evolution

In a post I wrote 6 months ago, I had a section about rules being your best friend, which I still stand by. But my CLAUDE.md file was quickly getting out of hand and was trying to do too much. I also had this massive BEST_PRACTICES.md file (1,400+ lines) that Claude would sometimes read and sometimes completely ignore.

So I took an afternoon with Claude to consolidate and reorganize everything into a new system. Here's what changed:

What Moved to Skills

Previously, BEST_PRACTICES.md contained:

• TypeScript standards

• React patterns (hooks, components, suspense)

• Backend API patterns (routes, controllers, services)

• Error handling (Sentry integration)

• Database patterns (Prisma usage)

• Testing guidelines

• Performance optimization

All of that is now in skills with the auto-activation hook ensuring Claude actually uses them. No more hoping Claude remembers to check BEST_PRACTICES.md.

What Stayed in CLAUDE.md

Now CLAUDE.md is laser-focused on project-specific info (only ~200 lines):

• Quick commands (pnpm pm2:start, pnpm build, etc.)

• Service-specific configuration

• Task management workflow (dev docs system)

• Testing authenticated routes

• Workflow dry-run mode

• Browser tools configuration

The New Structure

Root CLAUDE.md (100 lines)
├── Critical universal rules
├── Points to repo-specific claude.md files
└── References skills for detailed guidelines

Each Repo's claude.md (50-100 lines)
├── Quick Start section pointing to:
│   ├── PROJECT_KNOWLEDGE.md - Architecture & integration
│   ├── TROUBLESHOOTING.md - Common issues
│   └── Auto-generated API docs
└── Repo-specific quirks and commands

The magic: Skills handle all the "how to write code" guidelines, and CLAUDE.md handles "how this specific project works." Separation of concerns for the win.

Dev Docs System

This system, out of everything (besides skills), I think has made the most impact on the results I'm getting out of CC. Claude is like an extremely confident junior dev with extreme amnesia, losing track of what they're doing easily. This system is aimed at solving those shortcomings.

The dev docs section from my CLAUDE.md:

### Starting Large Tasks

When exiting plan mode with an accepted plan: 1.**Create Task Directory**:
mkdir -p ~/git/project/dev/active/[task-name]/

2.**Create Documents**:

- `[task-name]-plan.md` - The accepted plan
- `[task-name]-context.md` - Key files, decisions
- `[task-name]-tasks.md` - Checklist of work

3.**Update Regularly**: Mark tasks complete immediately

### Continuing Tasks

- Check `/dev/active/` for existing tasks
- Read all three files before proceeding
- Update "Last Updated" timestamps

These are documents that always get created for every feature or large task. Before using this system, I had many times when I all of a sudden realized that Claude had lost the plot and we were no longer implementing what we had planned out 30 minutes earlier because we went off on some tangent for whatever reason.

My Planning Process

My process starts with planning. Planning is king. If you aren't at a minimum using planning mode before asking Claude to implement something, you're gonna have a bad time, mmm'kay. You wouldn't have a builder come to your house and start slapping on an addition without having him draw things up first.

When I start planning a feature, I put it into planning mode, even though I will eventually have Claude write the plan down in a markdown file. I'm not sure putting it into planning mode necessary, but to me, it feels like planning mode gets better results doing the research on your codebase and getting all the correct context to be able to put together a plan.

I created a strategic-plan-architect subagent that's basically a planning beast. It:

• Gathers context efficiently

• Analyzes project structure

• Creates comprehensive structured plans with executive summary, phases, tasks, risks, success metrics, timelines

• Generates three files automatically: plan, context, and tasks checklist

But I find it really annoying that you can't see the agent's output, and even more annoying is if you say no to the plan, it just kills the agent instead of continuing to plan. So I also created a custom slash command (/dev-docs) with the same prompt to use on the main CC instance.

Once Claude spits out that beautiful plan, I take time to review it thoroughly. This step is really important. Take time to understand it, and you'd be surprised at how often you catch silly mistakes or Claude misunderstanding a very vital part of the request or task.

More often than not, I'll be at 15% context left or less after exiting plan mode. But that's okay because we're going to put everything we need to start fresh into our dev docs. Claude usually likes to just jump in guns blazing, so I immediately slap the ESC key to interrupt and run my /dev-docs slash command. The command takes the approved plan and creates all three files, sometimes doing a bit more research to fill in gaps if there's enough context left.

And once I'm done with that, I'm pretty much set to have Claude fully implement the feature without getting lost or losing track of what it was doing, even through an auto-compaction. I just make sure to remind Claude every once in a while to update the tasks as well as the context file with any relevant context. And once I'm running low on context in the current session, I just run my slash command /update-dev-docs. Claude will note any relevant context (with next steps) as well as mark any completed tasks or add new tasks before I compact the conversation. And all I need to say is "continue" in the new session.

During implementation, depending on the size of the feature or task, I will specifically tell Claude to only implement one or two sections at a time. That way, I'm getting the chance to go in and review the code in between each set of tasks. And periodically, I have a subagent also reviewing the changes so I can catch big mistakes early on. If you aren't having Claude review its own code, then I highly recommend it because it saved me a lot of headaches catching critical errors, missing implementations, inconsistent code, and security flaws.

PM2 Process Management (Backend Debugging Game Changer)

This one's a relatively recent addition, but it's made debugging backend issues so much easier.

The Problem

My project has seven backend microservices running simultaneously. The issue was that Claude didn't have access to view the logs while services were running. I couldn't just ask "what's going wrong with the email service?" - Claude couldn't see the logs without me manually copying and pasting them into chat.

The Intermediate Solution

For a while, I had each service write its output to a timestamped log file using a devLog script. This worked... okay. Claude could read the log files, but it was clunky. Logs weren't real-time, services wouldn't auto-restart on crashes, and managing everything was a pain.

The Real Solution: PM2

Then I discovered PM2, and it was a game changer. I configured all my backend services to run via PM2 with a single command: pnpm pm2:start

What this gives me:

• Each service runs as a managed process with its own log file

• Claude can easily read individual service logs in real-time

• Automatic restarts on crashes

• Real-time monitoring with pm2 logs

• Memory/CPU monitoring with pm2 monit

• Easy service management (pm2 restart email, pm2 stop all, etc.)

PM2 Configuration:

// ecosystem.config.jsmodule.exports = {
  apps: [
    {
      name: 'form-service',
      script: 'npm',
      args: 'start',
      cwd: './form',
      error_file: './form/logs/error.log',
      out_file: './form/logs/out.log',
    },
// ... 6 more services
  ]
};

Before PM2:

Me: "The email service is throwing errors"
Me: [Manually finds and copies logs]
Me: [Pastes into chat]
Claude: "Let me analyze this..."

The debugging workflow now:

Me: "The email service is throwing errors"
Claude: [Runs] pm2 logs email --lines 200
Claude: [Reads the logs] "I see the issue - database connection timeout..."
Claude: [Runs] pm2 restart email
Claude: "Restarted the service, monitoring for errors..."

Night and day difference. Claude can autonomously debug issues now without me being a human log-fetching service.

One caveat: Hot reload doesn't work with PM2, so I still run the frontend separately with pnpm dev. But for backend services that don't need hot reload as often, PM2 is incredible.

Hooks System (#NoMessLeftBehind)

The project I'm working on is multi-root and has about eight different repos in the root project directory. One for the frontend and seven microservices and utilities for the backend. I'm constantly bouncing around making changes in a couple of repos at a time depending on the feature.

And one thing that would annoy me to no end is when Claude forgets to run the build command in whatever repo it's editing to catch errors. And it will just leave a dozen or so TypeScript errors without me catching it. Then a couple of hours later I see Claude running a build script like a good boy and I see the output: "There are several TypeScript errors, but they are unrelated, so we're all good here!"

No, we are not good, Claude.

Hook #1: File Edit Tracker

First, I created a post-tool-use hook that runs after every Edit/Write/MultiEdit operation. It logs:

• Which files were edited

• What repo they belong to

• Timestamps

Initially, I made it run builds immediately after each edit, but that was stupidly inefficient. Claude makes edits that break things all the time before quickly fixing them.

Hook #2: Build Checker

Then I added a Stop hook that runs when Claude finishes responding. It:

1. Reads the edit logs to find which repos were modified

2. Runs build scripts on each affected repo

3. Checks for TypeScript errors

4. If < 5 errors: Shows them to Claude

5. If ≥ 5 errors: Recommends launching auto-error-resolver agent

6. Logs everything for debugging

Since implementing this system, I've not had a single instance where Claude has left errors in the code for me to find later. The hook catches them immediately, and Claude fixes them before moving on.

Hook #3: Prettier Formatter

This one's simple but effective. After Claude finishes responding, automatically format all edited files with Prettier using the appropriate .prettierrc config for that repo.

No more going into to manually edit a file just to have prettier run and produce 20 changes because Claude decided to leave off trailing commas last week when we created that file.

⚠️ Update: I No Longer Recommend This Hook

After publishing, a reader shared detailed data showing that file modifications trigger <system-reminder> notifications that can consume significant context tokens. In their case, Prettier formatting led to 160k tokens consumed in just 3 rounds due to system-reminders showing file diffs.

While the impact varies by project (large files and strict formatting rules are worst-case scenarios), I'm removing this hook from my setup. It's not a big deal to let formatting happen when you manually edit files anyway, and the potential token cost isn't worth the convenience.

If you want automatic formatting, consider running Prettier manually between sessions instead of during Claude conversations.

Hook #4: Error Handling Reminder

This is the gentle philosophy hook I mentioned earlier:

• Analyzes edited files after Claude finishes

• Detects risky patterns (try-catch, async operations, database calls, controllers)

• Shows a gentle reminder if risky code was written

• Claude self-assesses whether error handling is needed

• No blocking, no friction, just awareness

Example output:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 ERROR HANDLING SELF-CHECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️  Backend Changes Detected
   2 file(s) edited

   ❓ Did you add Sentry.captureException() in catch blocks?
   ❓ Are Prisma operations wrapped in error handling?

   💡 Backend Best Practice:
      - All errors should be captured to Sentry
      - Controllers should extend BaseController
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The Complete Hook Pipeline

Here's what happens on every Claude response now:

Claude finishes responding
  ↓
Hook 1: Prettier formatter runs → All edited files auto-formatted
  ↓
Hook 2: Build checker runs → TypeScript errors caught immediately
  ↓
Hook 3: Error reminder runs → Gentle self-check for error handling
  ↓
If errors found → Claude sees them and fixes
  ↓
If too many errors → Auto-error-resolver agent recommended
  ↓
Result: Clean, formatted, error-free code

And the UserPromptSubmit hook ensures Claude loads relevant skills BEFORE even starting work.

No mess left behind. It's beautiful.

Scripts Attached to Skills

One really cool pattern I picked up from Anthropic's official skill examples on GitHub: attach utility scripts to skills.

For example, my backend-dev-guidelines skill has a section about testing authenticated routes. Instead of just explaining how authentication works, the skill references an actual script:

### Testing Authenticated Routes

Use the provided test-auth-route.js script:


`node scripts/test-auth-route.js http://localhost:3002/api/endpoint`

The script handles all the complex authentication steps for you:

1. Gets a refresh token from Keycloak

2. Signs the token with JWT secret

3. Creates cookie header

4. Makes authenticated request

When Claude needs to test a route, it knows exactly what script to use and how to use it. No more "let me create a test script" and reinventing the wheel every time.

I'm planning to expand this pattern - attach more utility scripts to relevant skills so Claude has ready-to-use tools instead of generating them from scratch.

Tools and Other Things

SuperWhisper on Mac

Voice-to-text for prompting when my hands are tired from typing. Works surprisingly well, and Claude understands my rambling voice-to-text surprisingly well.

Memory MCP

I use this less over time now that skills handle most of the "remembering patterns" work. But it's still useful for tracking project-specific decisions and architectural choices that don't belong in skills.

BetterTouchTool

• Relative URL copy from Cursor (for sharing code references)

  • I have VSCode open to more easily find the files I’m looking for and I can double tap CAPS-LOCK, then BTT inputs the shortcut to copy relative URL, transforms the clipboard contents by prepending an ‘@’ symbol, focuses the terminal, and then pastes the file path. All in one.

• Double-tap hotkeys to quickly focus apps (CMD+CMD = Claude Code, OPT+OPT = Browser)

• Custom gestures for common actions

Honestly, the time savings on just not fumbling between apps is worth the BTT purchase alone.

Scripts for Everything

If there's any annoying tedious task, chances are there's a script for that:

• Command-line tool to generate mock test data. Before using Claude code, it was extremely annoying to generate mock data because I would have to make a submission to a form that had about a 120 questions Just to generate one single test submission.

• Authentication testing scripts (get tokens, test routes)

• Database resetting and seeding

• Schema diff checker before migrations

• Automated backup and restore for dev database

Pro tip: When Claude helps you write a useful script, immediately document it in CLAUDE.md or attach it to a relevant skill. Future you will thank past you.

Documentation (Still Important, But Evolved)

I think next to planning, documentation is almost just as important. I document everything as I go in addition to the dev docs that are created for each task or feature. From system architecture to data flow diagrams to actual developer docs and APIs, just to name a few.

But here's what changed: Documentation now works WITH skills, not instead of them.

Skills contain: Reusable patterns, best practices, how-to guides Documentation contains: System architecture, data flows, API references, integration points

For example:

• "How to create a controller" → backend-dev-guidelines skill

• "How our workflow engine works" → Architecture documentation

• "How to write React components" → frontend-dev-guidelines skill

• "How notifications flow through the system" → Data flow diagram + notification skill

I still have a LOT of docs (850+ markdown files), but now they're laser-focused on project-specific architecture rather than repeating general best practices that are better served by skills.

You don't necessarily have to go that crazy, but I highly recommend setting up multiple levels of documentation. Ones for broad architectural overview of specific services, wherein you'll include paths to other documentation that goes into more specifics of different parts of the architecture. It will make a major difference on Claude's ability to easily navigate your codebase.

Prompt Tips

When you're writing out your prompt, you should try to be as specific as possible about what you are wanting as a result. Once again, you wouldn't ask a builder to come out and build you a new bathroom without at least discussing plans, right?

"You're absolutely right! Shag carpet probably is not the best idea to have in a bathroom."

Sometimes you might not know the specifics, and that's okay. If you don't ask questions, tell Claude to research and come back with several potential solutions. You could even use a specialized subagent or use any other AI chat interface to do your research. The world is your oyster. I promise you this will pay dividends because you will be able to look at the plan that Claude has produced and have a better idea if it's good, bad, or needs adjustments. Otherwise, you're just flying blind, pure vibe-coding. Then you're gonna end up in a situation where you don't even know what context to include because you don't know what files are related to the thing you're trying to fix.

Try not to lead in your prompts if you want honest, unbiased feedback. If you're unsure about something Claude did, ask about it in a neutral way instead of saying, "Is this good or bad?" Claude tends to tell you what it thinks you want to hear, so leading questions can skew the response. It's better to just describe the situation and ask for thoughts or alternatives. That way, you'll get a more balanced answer.

Agents, Hooks, and Slash Commands (The Holy Trinity)

Agents

I've built a small army of specialized agents:

Quality Control:

• code-architecture-reviewer - Reviews code for best practices adherence

• build-error-resolver - Systematically fixes TypeScript errors

• refactor-planner - Creates comprehensive refactoring plans

Testing & Debugging:

• auth-route-tester - Tests backend routes with authentication

• auth-route-debugger - Debugs 401/403 errors and route issues

• frontend-error-fixer - Diagnoses and fixes frontend errors

Planning & Strategy:

• strategic-plan-architect - Creates detailed implementation plans

• plan-reviewer - Reviews plans before implementation

• documentation-architect - Creates/updates documentation

Specialized:

• frontend-ux-designer - Fixes styling and UX issues

• web-research-specialist - Researches issues along with many other things on the web

• reactour-walkthrough-designer - Creates UI tours

The key with agents is to give them very specific roles and clear instructions on what to return. I learned this the hard way after creating agents that would go off and do who-knows-what and come back with "I fixed it!" without telling me what they fixed.

Hooks (Covered Above)

The hook system is honestly what ties everything together. Without hooks:

• Skills sit unused

• Errors slip through

• Code is inconsistently formatted

• No automatic quality checks

With hooks:

• Skills auto-activate

• Zero errors left behind

• Automatic formatting

• Quality awareness built-in

Slash Commands

I have quite a few custom slash commands, but these are the ones I use most:

Planning & Docs:

• /dev-docs - Create comprehensive strategic plan

• /dev-docs-update - Update dev docs before compaction

• /create-dev-docs - Convert approved plan to dev doc files

Quality & Review:

• /code-review - Architectural code review

• /build-and-fix - Run builds and fix all errors

Testing:

• /route-research-for-testing - Find affected routes and launch tests

• /test-route - Test specific authenticated routes

The beauty of slash commands is they expand into full prompts, so you can pack a ton of context and instructions into a simple command. Way better than typing out the same instructions every time.

Conclusion

After six months of hardcore use, here's what I've learned:

The Essentials:

1. Plan everything - Use planning mode or strategic-plan-architect

2. Skills + Hooks - Auto-activation is the only way skills actually work reliably

3. Dev docs system - Prevents Claude from losing the plot

4. Code reviews - Have Claude review its own work

5. PM2 for backend - Makes debugging actually bearable

The Nice-to-Haves:

• Specialized agents for common tasks

• Slash commands for repeated workflows

• Comprehensive documentation

• Utility scripts attached to skills

• Memory MCP for decisions

And that's about all I can think of for now. Like I said, I'm just some guy, and I would love to hear tips and tricks from everybody else, as well as any criticisms. Because I'm always up for improving upon my workflow. I honestly just wanted to share what's working for me with other people since I don't really have anybody else to share this with IRL (my team is very small, and they are all very slow getting on the AI train).

If you made it this far, thanks for taking the time to read. If you have questions about any of this stuff or want more details on implementation, happy to share. The hooks and skills system especially took some trial and error to get right, but now that it's working, I can't imagine going back.

TL;DR: Built an auto-activation system for Claude Code skills using TypeScript hooks, created a dev docs workflow to prevent context loss, and implemented PM2 + automated error checking. Result: Solo rewrote 300k LOC in 6 months with consistent quality.

Claude Code’s newly introduced hooks make it way easier to build certain things, like agent notifications. A whole new wave of possibilities opening up.

Right now there are 4 hooks: PreToolUse, PostToolUse, Notification, and Stop.

I tried wiring up the last two to a custom notification script that pushes alerts to my phone, so I can be notified immediately when the agent finishes its job.

There are probably other fun ways to use these I think. Might be good for automatically running lint checks or kicking off tests. A lot to dig into.

Just watched Ray Fernando's livestream about Anthropic's new Hooks feature that apparently dropped like 12 hours ago. I haven't tried it myself yet, but the concept seems pretty interesting and I'm curious what others think.

The basic idea (from what I understood):

• You can now run shell scripts at different stages of Claude Code's execution

• Similar to git hooks but for AI code generation

• Supposed to make Claude more deterministic/consistent

What caught my attention:

• Ray used it to enforce code reuse (stopping Claude from creating duplicate functions)

• The meta part where Claude wrote its own hook system was pretty wild

• Could potentially solve the "why won't Claude remember my coding patterns" problem

But I'm also wondering:

• Is this overcomplicating things? Like, are we fixing a problem that shouldn't exist?

• The setup looked non-trivial with debugging path issues and overly aggressive blocking

• Could this limit Claude's creativity or is it just adding necessary guardrails?

I'm currently on the $100/month Claude plan myself, but haven't jumped into Claude Code yet. For those who have:

1. Has anyone actually tried Hooks? What's your experience?

2. What use cases make sense beyond Ray's optimization rules?

3. Is this addressing a real pain point you've had with AI coding assistants?

4. Are other tools (Cursor, Cody, etc.) doing something similar?

Part of me is excited about the possibilities (auto-formatting, logging, enforcing team standards), but another part wonders if we're just adding complexity to something that should be simpler.

Would love to hear from both people who've tried it and those who are skeptical. Is this the future of AI-assisted development or are we overthinking how to use these tools?

Edit: For clarity, I haven't implemented any of this myself - just sharing what I learned from the stream and looking for community thoughts before I dive in!

I have seen people creating voice hooks, slack hooks etc but still haven't seen much development on hooks after their release. Any interesting stuff anyone is doing with hooks?

Quick disclaimer: I used an LLM to clean up my terrible English and organize this resource dump better, but this is genuinely my research and testing over the past few weeks. Don’t want this to sound like corporate AI slop - these are real tools I actually tried.

Okay so confession time. I’ve been using Claude Code since May and got really into collecting tools. Like, unhealthily into it. Every time someone on r/ClaudeAI or r/ClaudeCode posts about a new MCP server or plugin, I’d install it.

My setup got bloated. Had 15 plugins, 8 MCP servers, 30 slash commands running simultaneously. Claude started acting weird - slower responses, sometimes confused about what tools it had access to.

So I uninstalled everything and started fresh. Spent the last few weeks actually testing stuff and cataloguing what I found. Ended up with notes on 100+ tools across the ecosystem.

Figured I’d share what actually worked vs what’s just noise.

📚 The Main Reference Repository

awesome-claude-code by hesreallyhim
https://github.com/hesreallyhim/awesome-claude-code
13.2K stars

This is basically the unofficial documentation. The maintainer curates it actively and has opinions on what’s actually good vs hype.

I keep it open in a tab constantly. When I hit an issue, I search this before googling.

Warning: it’s a lot. Don’t try installing everything. I started with just the hooks section.

Other collections worth checking:

• https://github.com/jqueryscript/awesome-claude-code (more organized by category)

• https://github.com/LangGPT/awesome-claude-code (has Chinese resources too)

💰 Usage Tracking Tools

ccusage by ryoppippi
https://github.com/ryoppippi/ccusage

Real-time usage tracking with burn rate predictions. v15.0.0 added a live dashboard.

Install: npx ccusage@latest blocks --live

Helps you catch when you’re burning through tokens on huge files. Probably saved me $100-150 last month just from awareness.

Other options I tested:

ccflare
https://github.com/snipeship/ccflare
Web UI dashboard with really nice metrics visualization

Claude Code Usage Monitor
https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor
Terminal-based with progress bars

viberank
https://github.com/nikshepsvn/viberank
Community leaderboard for usage stats (if you’re into that)

I stuck with ccusage but ccflare’s web interface is really polished.

🛠️ CLI Tools & Session Management

claude-code-tools by pchalasani
https://github.com/pchalasani/claude-code-tools

This one’s specifically for tmux users. If you don’t use tmux, probably skip it.

The tmux-cli tool lets Claude control interactive CLI applications. I’ve watched it debug Python in pdb, manage multiple processes, launch nested Claude instances.

Also includes:

• find-session for searching across sessions

• Vault for encrypted env backup

• Some safety hooks

Takes about 15 min to set up but worth it if you live in tmux.

Other session management tools:

cc-sessions
https://github.com/GWUDCAP/cc-sessions
Opinionated production development workflow

cchistory
https://github.com/eckardt/cchistory
Shows all bash commands Claude ran in a session

cclogviewer
View .jsonl conversation files in HTML
(couldn’t find the direct GitHub link but it’s listed in awesome-claude-code)

ccexp
https://github.com/nyatinte/ccexp
Interactive CLI for managing configs with nice terminal UI

claudekit
Has auto-save checkpointing, 20+ specialized subagents including one that uses GPT-5 for complex decisions
(listed in awesome-claude-code under tools)

🤖 Multi-Instance Orchestrators

You can run multiple Claude Code instances simultaneously. Pretty useful for parallel development.

Claude Squad
https://github.com/smtg-ai/claude-squad
Terminal app managing multiple Claude Code, Codex, and Aider instances

Claude Swarm
https://github.com/parruda/claude-swarm
Connects Claude to a swarm of agents

Happy Coder
https://github.com/GrocerPublishAgent/happy-coder
Spawn multiple Claudes with push notifications when they need input

TSK
https://github.com/dtormoen/tsk
Rust CLI tool - sandboxes agents in Docker, returns git branches for review

crystal
https://github.com/stravu/crystal
Full desktop app for orchestrating Claude Code agents

I use Claude Squad when I’m working on multiple features at once.

🔌 MCP Servers That Are Actually Useful

MCP servers connect Claude to external tools. There are literally 3,000+ out there now. These are the ones I actually use:

Official/Stable Ones:

GitHub MCP Server (official)
https://github.com/github/github-mcp-server
Native GitHub integration. Worth the 10 min setup to get API tokens.

Playwright MCP
Browser automation for testing
https://github.com/microsoft/playwright (look for MCP integration docs)

Docker MCP
Container management
(check the awesome-mcp-servers list below)

PostgreSQL MCP
https://github.com/crystaldba/postgres-mcp
Query databases with natural language

Notion MCP (official)
https://github.com/makenotion/notion-mcp-server
Full Notion integration

Slack MCP
Channel management, messaging
(listed in MCP directories)

Context7 MCP
Provides up-to-date code documentation from source
https://context7.com or search in MCP directories

GPT Researcher MCP
https://github.com/assafelovic/gpt-researcher (look for MCP version)
Does research with citations

Specialized ones I use:

Obsidian MCP Tools
https://github.com/jacksteamdev/obsidian-mcp-tools
If you use Obsidian for notes

VoiceMode MCP
Natural voice conversations with Claude Code
(listed in awesome-claude-code)

Reddit MCP
https://claudelog.com/claude-code-mcps/reddit-mcp/
Browse subreddits, analyze discussions

Twitter/X MCP
https://claudelog.com/claude-code-mcps/twitter-mcp/
Post tweets, search content

Github MCP https://github.com/github/github-mcp-server

Full MCP directories:

• https://github.com/wong2/awesome-mcp-servers

• https://mcpmarket.com

• https://mcpservers.org

• https://modelcontextprotocol.io/examples

There’s way more but these are the production-ready ones that aren’t abandoned.

🎯 Configuration Frameworks

Full workflow systems:

SuperClaude
https://github.com/SuperClaude-Org/superclaude
Config framework with specialized commands and methodologies

ContextKit
Systematic 4-phase planning methodology
(listed in awesome-claude-code)

Claude Code Templates
https://github.com/davila7/claude-code-templates
100+ agents, commands, settings - accessible via https://aitmpl.com

AB Method
Spec-driven workflow for large problems
(in awesome-claude-code under workflows)

RIPER Workflow
Structured development with phases
(in awesome-claude-code)

Claude Code PM
Project management workflow
(in awesome-claude-code)

I personally use SuperClaude because it’s flexible, but explore based on your stack.

🔥 Plugins (New Beta Feature)

Anthropic just launched plugins in public beta. Bundles slash commands, subagents, MCP servers, hooks into one-click installs.

Type /plugin in Claude Code CLI to browse.

Plugin Marketplaces:

AITMPL
https://aitmpl.com
100+ resources with nice UI

Every Marketplace
https://github.com/EveryInc/every-marketplace
“Compounding Engineering” philosophy with 17 specialized agents including:

• kieran-rails-reviewer (strict on Rails conventions)

• security-sentinel (security audits)

• performance-oracle

• architecture-strategist

The code review is pretty thorough. If you want production-quality feedback:

/plugin marketplace add EveryInc/every-marketplace

Claude Code Plugins Plus
https://github.com/jeremylongshore/claude-code-plugins-plus
221 plugins across 20+ categories

Anthropic Official
https://github.com/anthropics/claude-code
Feature Dev plugin (what Anthropic uses internally)

CodeGlide Marketplace
https://claudecodemarketplace.com

Marketplace quality varies. Start with verified creators or repos with good GitHub activity.

📝 Useful Slash Commands

Slash commands are shortcuts in .claude/commands/. Here are ones I use:

Git & Version Control:

/commit by evmts
Creates conventional commits
https://github.com/evmts/evmts-monorepo (look in .claude/commands)

/create-pr
Streamlines PR creation
(in awesome-claude-code commands section)

/fix-github-issue
https://github.com/jeremymailen (search their repos)

/fix-pr by metabase
Fixes unresolved PR comments
https://github.com/metabase/metabase (check .claude folder)

Code Quality:

/check
Comprehensive quality checks
(in awesome-claude-code)

/tdd
Test-Driven Development workflow
(in awesome-claude-code)

/security-review
Security audit checklist
https://github.com/anthropics/claude-code (examples)

/clean
Fix formatting, organize imports
(in awesome-claude-code)

Documentation:

/create-docs
Generate docs from code
(in awesome-claude-code)

/update-docs
Maintain doc consistency
(in awesome-claude-code)

The awesome-claude-code repo has 100+ slash commands organized by category.

🎣 Hooks (Automation Scripts)

Hooks run at different workflow points.

TDD Guard by Nizar Selander
Blocks Claude from writing code before tests
(listed in awesome-claude-code hooks section)

CC Notify
https://github.com/dazuiba/cc-notify
Desktop notifications when Claude needs input

TypeScript Quality Hooks by bartolli
ESLint, Prettier, TypeScript compilation
(in awesome-claude-code)

fcakyon Collection by Fatih Akyon
https://github.com/fcakyon
Code quality hooks

Hook SDKs:

• cchooks (Python) - https://github.com/GowayLee/cchooks

• claude-code-hooks-sdk (PHP) - https://github.com/beyondcode/claude-code-hooks-sdk

• claude-hooks (TypeScript) - listed in awesome-claude-code

🎨 Statuslines

claude-powerline by Owloops
https://github.com/Owloops/claude-powerline
Vim-style powerline with themes. This is what I use.

ccstatusline
https://github.com/sirmalloc/ccstatusline
Customizable with model info, git branch, tokens

claudia-statusline
Rust-based with SQLite persistence
(in awesome-claude-code)

claude-code-statusline
https://github.com/rz1989s/claude-code-statusline
4-line statusline with cost tracking

🤖 Subagent Collections

Subagents are Claude instances with specialized expertise.

awesome-claude-code-subagents by VoltAgent
https://github.com/VoltAgent/awesome-claude-code-subagents
100+ specialized agents for different domains

0xfurai collection
https://github.com/0xfurai/claude-code-subagents
100+ domain experts

wshobson/agents by Seth Hobson
80+ curated production subagents
https://github.com/wshobson/agents

Essential subagent types: Code Reviewer, Debugger, System Architect, DevOps Engineer, Test Automation Expert, Security Auditor.

🎓 Skills (New Feature)

Skills dropped a couple weeks ago. They’re markdown files + optional scripts that Claude loads contextually.

Official Skills from Anthropic:

Check /mnt/skills/public/ in your Claude environment:

• docx (Word documents)

• pdf (PDF manipulation)

• pptx (Presentations)

• xlsx (Spreadsheets)

• algorithmic-art (Generative art)

• canvas-design (Visual design)

• artifacts-builder (HTML artifacts)

• mcp-builder (Create MCP servers)

• webapp-testing (Playwright testing)

• skill-creator (Meta-skill)

• theme-factory (Style artifacts)

Simon Willison wrote about this: https://simonwillison.net/2025/Oct/16/claude-skills/

Skills work for any computer task, not just coding.

Community skills repo:
https://github.com/travisvn/awesome-claude-skills
(still early, not many yet)

📦 Other Useful Tools

Claude Hub
Webhook service connecting Claude Code to GitHub
(in awesome-claude-code)

Container Use
https://github.com/dagger/container-use
Development in Docker containers

claude-code-mcp
https://github.com/KunihiroS/claude-code-mcp
MCP server calling local Claude Code

Rulesync
https://github.com/dyoshikawa/rulesync
Convert configs between different AI coding agents

tweakcc
https://github.com/Piebald-AI/tweakcc
Customize visual styling

Vibe-Log
https://github.com/vibe-log/vibe-log-cli Analyzes prompts and generates HTML reports

💡 IDE Integrations

claude-code.nvim
https://github.com/greggh/claude-code.nvim
Neovim integration

claude-code.el
https://github.com/stevemolitor/claude-code.el
Emacs interface

claude-code-ide.el
Full Emacs IDE integration
(search GitHub)

Claude Code Chat
VS Code chat interface
(in awesome-claude-code)

📖 Learning Resources

ClaudeLog
https://www.claudelog.com
Knowledge base with tutorials and best practices

Shipyard Blog
https://shipyard.build/blog
Guides on subagents and workflows

Official Docs
https://docs.claude.com/en/docs/claude-code
Anthropic’s documentation

Awesome Claude
https://github.com/alvinunreal/awesome-claude
Everything Claude-related

🎯 What I Actually Kept After Testing

After all that, here’s what stayed in my setup:

Daily use:

• awesome-claude-code (bookmarked)

• ccusage

• GitHub MCP Server

• Playwright MCP

• claude-powerline

• TDD Guard hook

For specific work:

• claude-code-tools (I use tmux daily)

• SuperClaude framework

• Every Marketplace plugin

• Claude Squad (multiple features)

Thats it. I install others temporarily when needed.

🤔 What Are You Building?

Curious what people are actually using Claude Code for:

• Regular coding projects?

• AI-powered workflows?

• Non-coding automation?

• Team standardization?

• Something else?

Drop your use case. If there’s interest in specific areas I can do focused lists:

• DevOps (Docker, K8s, CI/CD)

• Data science (notebooks, ML)

• Frontend (React, testing)

• Backend (APIs, databases)

If I missed something you use daily, let me know.

Following the amazing response to my original post (450+ of you started using it!), I'm excited to share version 2.0 with significant improvements.

The Problem We're Solving

As your codebase grows, Claude Code starts to struggle - it forgets your patterns, loses track of architecture, and keeps suggesting outdated library methods. This kit solves that by creating an intelligent context management system that keeps Claude Code informed and reliable at scale.

Key Features

1. Multi-Agent Orchestration

Commands like /full-context spawn specialized agents that work in parallel, each focusing on different aspects (security, performance, architecture) while sharing your project context.

2. Automatic Context Management

No more copy-pasting context! The 3-tier documentation system auto-loads the right docs based on task complexity. Simple tasks get foundation docs, complex features load all relevant tiers.

3. External AI Integration

• Context7: Real-time library documentation (no more hallucinated APIs!)

• Gemini Assistant MCP: Architecture consultation and design validation

4. Smart Hooks (New 🎉)

• Security scanner blocks sensitive data in MCP requests

• Context injector ensures all sub-agents & Gemini Assistant MCP know your project

• Optional audio notifications when tasks complete

Example Workflow

# Analyze and plan a complex feature
/full-context "implement real-time collaboration with WebSockets"

# Multi-perspective code review
/code-review "review WebSocket implementation"

# Keep docs in sync
/update-docs "document collaboration feature"

Quick Installation (30 seconds)

Just run this in your terminal:

curl -fsSL https://raw.githubusercontent.com/peterkrueck/Claude-Code-Development-Kit/main/install.sh | bash

The installer will:

1. Download the framework

2. Guide you through interactive setup (choose which components you want)

3. Configure everything automatically

4. Provide links for optional MCP server installations

GitHub: https://github.com/peterkrueck/Claude-Code-Development-Kit

How It Works

The kit creates a structured documentation system that Claude Code automatically uses:

your-project/
├── .claude/
│   ├── commands/              # AI orchestration templates
│   ├── hooks/                 # Security and automation hooks
│   │   ├── config/            # Hook configuration files
│   │   ├── sounds/            # Notification audio files
│   │   ├── gemini-context-injector.sh
│   │   ├── mcp-security-scan.sh
│   │   ├── notify.sh
│   │   └── subagent-context-injector.sh
│   └── settings.json          # Claude Code configuration
├── docs/
│   ├── ai-context/            # Foundation documentation (Tier 1)
│   │   ├── docs-overview.md   # Documentation routing map
│   │   ├── project-structure.md # Technology stack and file tree
│   │   ├── system-integration.md # Cross-component patterns
│   │   ├── deployment-infrastructure.md # Infrastructure context
│   │   └── handoff.md        # Session continuity
│   ├── open-issues/           # Issue tracking templates
│   ├── specs/                 # Feature specifications
│   └── README.md              # Documentation system guide
├── CLAUDE.md                  # Master AI context (Tier 1)
├── backend/
│   └── CONTEXT.md              # Backend context (Tier 2) - create this
└── backend/src/api/
    └── CONTEXT.md              # API context (Tier 3) - create this

What's New in v2.0 🎉

• Enhanced Hooks System: Customizable automation at every Claude Code lifecycle point

• One-Click Installer: No more manual setup - just one curl command

• Subagent Context Injection: All spawned agents automatically receive your project context

• MCP Assistant Rules: Define project-specific coding standards for external AI consultations

Community Feedback Welcome!

This is an evolving framework based on real-world AI development challenges. I'd love to hear:

• What features would help your workflow?

• How are you structuring context for large projects?

• Any integration ideas with other tools?

Feel free share your experience!

Links:

• GitHub Repository

• Original Reddit Post

• LinkedIn (for questions/feedback)

Created a PostToolUse hook system that gives Claude immediate feedback on TypeScript/ESLint violations, helping it learn and follow our team's specific coding standards.

I needed a way to help it understand our complex TypeScript setup. We have strict tsconfig.json files, project-specific ESLint rules, and different type constraints for different parts of the app. Without immediate feedback, Claude can't know that our API types forbid any, or that we use strict: true with noUncheckedIndexedAccess.

Every file edit triggers a quality gate that:

1. Detects project context - Maps files to the RIGHT tsconfig (browser vs Node vs webview)

2. SHA256 caches TypeScript configs - Only rebuilds when configs actually change (95% faster)

3. Exit code 2 blocks the save - Forces Claude to fix issues immediately

4. Auto-fixes the trivial stuff - ESLint/Prettier fixes apply silently

Real Examples from Production

// Claude writes this in src/api/client.ts
const response = (await fetch(url).json()) as any; // ❌ BLOCKED
// Hook output: "Type assertion using 'as any' is not allowed. Use proper typing."

// After feedback, Claude corrects to:
const response = (await fetch(url).json()) as ApiResponse; // ✅ PASSES

// In src/models/user.ts with strict tsconfig
const getName = (user: User) => user.profile?.name; // ❌ BLOCKED
// Hook output: "Object is possibly 'undefined' (noUncheckedIndexedAccess enabled)"

// Claude fixes to:
const getName = (user: User) => user.profile?.name ?? "Unknown"; // ✅ PASSES

The hook respects YOUR project's TypeScript strictness level, not generic defaults.

Before hooks: I'd find 15 as any casts, missing null checks, and wrong import styles. By then, Claude had written 500 lines building on those patterns.

After hooks: Claude gets immediate feedback and course-corrects. It learns our codebase's idioms - no any in API layers, strict null checks in models, specific ESLint rules per directory. The feedback loop makes Claude a better pair programmer who actually follows our team's standards.

Best part: When TypeScript catches a real type mismatch (not just style), Claude often discovers actual bugs in my requirements. "This function expects UserDTO but you're passing User - should I add a transformation layer?"

GitHub: https://github.com/bartolli/claude-code-typescript-hooks

Anyone else hacking on CC tool reliability? What's your approach to keeping this beast on rails?

I go first. Nice sound whenever a tool run is done (ting), and when a response is completed (chime). This really makes me feel good as I know CC is working hard for me 😂 and when it finishes the task (chime), I go back and give it a new one.

What about yours?

Quick pro-tip from a fellow lazy person: You can throw this book of a post into one of the many text-to-speech AI services like ElevenLabs Reader or Natural Reader and have it read the post for you :)

Edit: Many of you are asking for a repo so I will make an effort to get one up in the next couple days. All of this is a part of a work project at the moment, so I have to take some time to copy everything into a fresh project and scrub any identifying info. I will post the link here when it's up. You can also follow me and I will post it on my profile so you get notified. Thank you all for the kind comments. I'm happy to share this info with others since I don't get much chance to do so in my day-to-day.

Edit (final?): I bit the bullet and spent the afternoon getting a github repo up for you guys. Just made a post with some additional info here or you can go straight to the source:

🎯 Repository: https://github.com/diet103/claude-code-infrastructure-showcase

Disclaimer

I made a post about six months ago sharing my experience after a week of hardcore use with Claude Code. It's now been about six months of hardcore use, and I would like to share some more tips, tricks, and word vomit with you all. I may have went a little overboard here so strap in, grab a coffee, sit on the toilet or whatever it is you do when doom-scrolling reddit.

I want to start the post off with a disclaimer: all the content within this post is merely me sharing what setup is working best for me currently and should not be taken as gospel or the only correct way to do things. It's meant to hopefully inspire you to improve your setup and workflows with AI agentic coding. I'm just a guy, and this is just like, my opinion, man.

Also, I'm on the 20x Max plan, so your mileage may vary. And if you're looking for vibe-coding tips, you should look elsewhere. If you want the best out of CC, then you should be working together with it: planning, reviewing, iterating, exploring different approaches, etc.

Quick Overview

After 6 months of pushing Claude Code to its limits (solo rewriting 300k LOC), here's the system I built:

• Skills that actually auto-activate when needed

• Dev docs workflow that prevents Claude from losing the plot

• PM2 + hooks for zero-errors-left-behind

• Army of specialized agents for reviews, testing, and planning

Let's get into it.

Background

I'm a software engineer who has been working on production web apps for the last seven years or so. And I have fully embraced the wave of AI with open arms. I'm not too worried about AI taking my job anytime soon, as it is a tool that I use to leverage my capabilities. In doing so, I have been building MANY new features and coming up with all sorts of new proposal presentations put together with Claude and GPT-5 Thinking to integrate new AI systems into our production apps. Projects I would have never dreamt of having the time to even consider before integrating AI into my workflow. And with all that, I'm giving myself a good deal of job security and have become the AI guru at my job since everyone else is about a year or so behind on how they're integrating AI into their day-to-day.

With my newfound confidence, I proposed a pretty large redesign/refactor of one of our web apps used as an internal tool at work. This was a pretty rough college student-made project that was forked off another project developed by me as an intern (created about 7 years ago and forked 4 years ago). This may have been a bit overly ambitious of me since, to sell it to the stakeholders, I agreed to finish a top-down redesign of this fairly decent-sized project (~100k LOC) in a matter of a few months...all by myself. I knew going in that I was going to have to put in extra hours to get this done, even with the help of CC. But deep down, I know it's going to be a hit, automating several manual processes and saving a lot of time for a lot of people at the company.

It's now six months later... yeah, I probably should not have agreed to this timeline. I have tested the limits of both Claude as well as my own sanity trying to get this thing done. I completely scrapped the old frontend, as everything was seriously outdated and I wanted to play with the latest and greatest. I'm talkin' React 16 JS → React 19 TypeScript, React Query v2 → TanStack Query v5, React Router v4 w/ hashrouter → TanStack Router w/ file-based routing, Material UI v4 → MUI v7, all with strict adherence to best practices. The project is now at ~300-400k LOC and my life expectancy ~5 years shorter. It's finally ready to put up for testing, and I am incredibly happy with how things have turned out.

This used to be a project with insurmountable tech debt, ZERO test coverage, HORRIBLE developer experience (testing things was an absolute nightmare), and all sorts of jank going on. I addressed all of those issues with decent test coverage, manageable tech debt, and implemented a command-line tool for generating test data as well as a dev mode to test different features on the frontend. During this time, I have gotten to know CC's abilities and what to expect out of it.

A Note on Quality and Consistency

I've noticed a recurring theme in forums and discussions - people experiencing frustration with usage limits and concerns about output quality declining over time. I want to be clear up front: I'm not here to dismiss those experiences or claim it's simply a matter of "doing it wrong." Everyone's use cases and contexts are different, and valid concerns deserve to be heard.

That said, I want to share what's been working for me. In my experience, CC's output has actually improved significantly over the last couple of months, and I believe that's largely due to the workflow I've been constantly refining. My hope is that if you take even a small bit of inspiration from my system and integrate it into your CC workflow, you'll give it a better chance at producing quality output that you're happy with.

Now, let's be real - there are absolutely times when Claude completely misses the mark and produces suboptimal code. This can happen for various reasons. First, AI models are stochastic, meaning you can get widely varying outputs from the same input. Sometimes the randomness just doesn't go your way, and you get an output that's legitimately poor quality through no fault of your own. Other times, it's about how the prompt is structured. There can be significant differences in outputs given slightly different wording because the model takes things quite literally. If you misword or phrase something ambiguously, it can lead to vastly inferior results.

Sometimes You Just Need to Step In

Look, AI is incredible, but it's not magic. There are certain problems where pattern recognition and human intuition just win. If you've spent 30 minutes watching Claude struggle with something that you could fix in 2 minutes, just fix it yourself. No shame in that. Think of it like teaching someone to ride a bike, sometimes you just need to steady the handlebars for a second before letting go again.

I've seen this especially with logic puzzles or problems that require real-world common sense. AI can brute-force a lot of things, but sometimes a human just "gets it" faster. Don't let stubbornness or some misguided sense of "but the AI should do everything" waste your time. Step in, fix the issue, and keep moving.

I've had my fair share of terrible prompting, which usually happens towards the end of the day where I'm getting lazy and I'm not putting that much effort into my prompts. And the results really show. So next time you are having these kinds of issues where you think the output is way worse these days because you think Anthropic shadow-nerfed Claude, I encourage you to take a step back and reflect on how you are prompting.

Re-prompt often. You can hit double-esc to bring up your previous prompts and select one to branch from. You'd be amazed how often you can get way better results armed with the knowledge of what you don't want when giving the same prompt. All that to say, there can be many reasons why the output quality seems to be worse, and it's good to self-reflect and consider what you can do to give it the best possible chance to get the output you want.

As some wise dude somewhere probably said, "Ask not what Claude can do for you, ask what context you can give to Claude" ~ Wise Dude

Alright, I'm going to step down from my soapbox now and get on to the good stuff.

My System

I've implemented a lot changes to my workflow as it relates to CC over the last 6 months, and the results have been pretty great, IMO.

Skills Auto-Activation System (Game Changer!)

This one deserves its own section because it completely transformed how I work with Claude Code.

The Problem

So Anthropic releases this Skills feature, and I'm thinking "this looks awesome!" The idea of having these portable, reusable guidelines that Claude can reference sounded perfect for maintaining consistency across my massive codebase. I spent a good chunk of time with Claude writing up comprehensive skills for frontend development, backend development, database operations, workflow management, etc. We're talking thousands of lines of best practices, patterns, and examples.

And then... nothing. Claude just wouldn't use them. I'd literally use the exact keywords from the skill descriptions. Nothing. I'd work on files that should trigger the skills. Nothing. It was incredibly frustrating because I could see the potential, but the skills just sat there like expensive decorations.

The "Aha!" Moment

That's when I had the idea of using hooks. If Claude won't automatically use skills, what if I built a system that MAKES it check for relevant skills before doing anything?

So I dove into Claude Code's hook system and built a multi-layered auto-activation architecture with TypeScript hooks. And it actually works!

How It Works

I created two main hooks:

1. UserPromptSubmit Hook (runs BEFORE Claude sees your message):

• Analyzes your prompt for keywords and intent patterns

• Checks which skills might be relevant

• Injects a formatted reminder into Claude's context

• Now when I ask "how does the layout system work?" Claude sees a big "🎯 SKILL ACTIVATION CHECK - Use project-catalog-developer skill" (project catalog is a large complex data grid based feature on my front end) before even reading my question

2. Stop Event Hook (runs AFTER Claude finishes responding):

• Analyzes which files were edited

• Checks for risky patterns (try-catch blocks, database operations, async functions)

• Displays a gentle self-check reminder

• "Did you add error handling? Are Prisma operations using the repository pattern?"

• Non-blocking, just keeps Claude aware without being annoying

skill-rules.json Configuration

I created a central configuration file that defines every skill with:

• Keywords: Explicit topic matches ("layout", "workflow", "database")

• Intent patterns: Regex to catch actions ("(create|add).*?(feature|route)")

• File path triggers: Activates based on what file you're editing

• Content triggers: Activates if file contains specific patterns (Prisma imports, controllers, etc.)

Example snippet:

{
  "backend-dev-guidelines": {
    "type": "domain",
    "enforcement": "suggest",
    "priority": "high",
    "promptTriggers": {
      "keywords": ["backend", "controller", "service", "API", "endpoint"],
      "intentPatterns": [
        "(create|add).*?(route|endpoint|controller)",
        "(how to|best practice).*?(backend|API)"
      ]
    },
    "fileTriggers": {
      "pathPatterns": ["backend/src/**/*.ts"],
      "contentPatterns": ["router\\.", "export.*Controller"]
    }
  }
}

The Results

Now when I work on backend code, Claude automatically:

1. Sees the skill suggestion before reading my prompt

2. Loads the relevant guidelines

3. Actually follows the patterns consistently

4. Self-checks at the end via gentle reminders

The difference is night and day. No more inconsistent code. No more "wait, Claude used the old pattern again." No more manually telling it to check the guidelines every single time.

Following Anthropic's Best Practices (The Hard Way)

After getting the auto-activation working, I dove deeper and found Anthropic's official best practices docs. Turns out I was doing it wrong because they recommend keeping the main SKILL.md file under 500 lines and using progressive disclosure with resource files.

Whoops. My frontend-dev-guidelines skill was 1,500+ lines. And I had a couple other skills over 1,000 lines. These monolithic files were defeating the whole purpose of skills (loading only what you need).

So I restructured everything:

• frontend-dev-guidelines: 398-line main file + 10 resource files

• backend-dev-guidelines: 304-line main file + 11 resource files

Now Claude loads the lightweight main file initially, and only pulls in detailed resource files when actually needed. Token efficiency improved 40-60% for most queries.

Skills I've Created

Here's my current skill lineup:

Guidelines & Best Practices:

• backend-dev-guidelines - Routes → Controllers → Services → Repositories

• frontend-dev-guidelines - React 19, MUI v7, TanStack Query/Router patterns

• skill-developer - Meta-skill for creating more skills

Domain-Specific:

• workflow-developer - Complex workflow engine patterns

• notification-developer - Email/notification system

• database-verification - Prevent column name errors (this one is a guardrail that actually blocks edits!)

• project-catalog-developer - DataGrid layout system

All of these automatically activate based on what I'm working on. It's like having a senior dev who actually remembers all the patterns looking over Claude's shoulder.

Why This Matters

Before skills + hooks:

• Claude would use old patterns even though I documented new ones

• Had to manually tell Claude to check BEST_PRACTICES.md every time

• Inconsistent code across the 300k+ LOC codebase

• Spent too much time fixing Claude's "creative interpretations"

After skills + hooks:

• Consistent patterns automatically enforced

• Claude self-corrects before I even see the code

• Can trust that guidelines are being followed

• Way less time spent on reviews and fixes

If you're working on a large codebase with established patterns, I cannot recommend this system enough. The initial setup took a couple of days to get right, but it's paid for itself ten times over.

CLAUDE.md and Documentation Evolution

In a post I wrote 6 months ago, I had a section about rules being your best friend, which I still stand by. But my CLAUDE.md file was quickly getting out of hand and was trying to do too much. I also had this massive BEST_PRACTICES.md file (1,400+ lines) that Claude would sometimes read and sometimes completely ignore.

So I took an afternoon with Claude to consolidate and reorganize everything into a new system. Here's what changed:

What Moved to Skills

Previously, BEST_PRACTICES.md contained:

• TypeScript standards

• React patterns (hooks, components, suspense)

• Backend API patterns (routes, controllers, services)

• Error handling (Sentry integration)

• Database patterns (Prisma usage)

• Testing guidelines

• Performance optimization

All of that is now in skills with the auto-activation hook ensuring Claude actually uses them. No more hoping Claude remembers to check BEST_PRACTICES.md.

What Stayed in CLAUDE.md

Now CLAUDE.md is laser-focused on project-specific info (only ~200 lines):

• Quick commands (pnpm pm2:start, pnpm build, etc.)

• Service-specific configuration

• Task management workflow (dev docs system)

• Testing authenticated routes

• Workflow dry-run mode

• Browser tools configuration

The New Structure

Root CLAUDE.md (100 lines)
├── Critical universal rules
├── Points to repo-specific claude.md files
└── References skills for detailed guidelines

Each Repo's claude.md (50-100 lines)
├── Quick Start section pointing to:
│   ├── PROJECT_KNOWLEDGE.md - Architecture & integration
│   ├── TROUBLESHOOTING.md - Common issues
│   └── Auto-generated API docs
└── Repo-specific quirks and commands

The magic: Skills handle all the "how to write code" guidelines, and CLAUDE.md handles "how this specific project works." Separation of concerns for the win.

Dev Docs System

This system, out of everything (besides skills), I think has made the most impact on the results I'm getting out of CC. Claude is like an extremely confident junior dev with extreme amnesia, losing track of what they're doing easily. This system is aimed at solving those shortcomings.

The dev docs section from my CLAUDE.md:

### Starting Large Tasks

When exiting plan mode with an accepted plan: 1.**Create Task Directory**:
mkdir -p ~/git/project/dev/active/[task-name]/

2.**Create Documents**:

- `[task-name]-plan.md` - The accepted plan
- `[task-name]-context.md` - Key files, decisions
- `[task-name]-tasks.md` - Checklist of work

3.**Update Regularly**: Mark tasks complete immediately

### Continuing Tasks

- Check `/dev/active/` for existing tasks
- Read all three files before proceeding
- Update "Last Updated" timestamps

These are documents that always get created for every feature or large task. Before using this system, I had many times when I all of a sudden realized that Claude had lost the plot and we were no longer implementing what we had planned out 30 minutes earlier because we went off on some tangent for whatever reason.

My Planning Process

My process starts with planning. Planning is king. If you aren't at a minimum using planning mode before asking Claude to implement something, you're gonna have a bad time, mmm'kay. You wouldn't have a builder come to your house and start slapping on an addition without having him draw things up first.

When I start planning a feature, I put it into planning mode, even though I will eventually have Claude write the plan down in a markdown file. I'm not sure putting it into planning mode necessary, but to me, it feels like planning mode gets better results doing the research on your codebase and getting all the correct context to be able to put together a plan.

I created a strategic-plan-architect subagent that's basically a planning beast. It:

• Gathers context efficiently

• Analyzes project structure

• Creates comprehensive structured plans with executive summary, phases, tasks, risks, success metrics, timelines

• Generates three files automatically: plan, context, and tasks checklist

But I find it really annoying that you can't see the agent's output, and even more annoying is if you say no to the plan, it just kills the agent instead of continuing to plan. So I also created a custom slash command (/dev-docs) with the same prompt to use on the main CC instance.

Once Claude spits out that beautiful plan, I take time to review it thoroughly. This step is really important. Take time to understand it, and you'd be surprised at how often you catch silly mistakes or Claude misunderstanding a very vital part of the request or task.

More often than not, I'll be at 15% context left or less after exiting plan mode. But that's okay because we're going to put everything we need to start fresh into our dev docs. Claude usually likes to just jump in guns blazing, so I immediately slap the ESC key to interrupt and run my /dev-docs slash command. The command takes the approved plan and creates all three files, sometimes doing a bit more research to fill in gaps if there's enough context left.

And once I'm done with that, I'm pretty much set to have Claude fully implement the feature without getting lost or losing track of what it was doing, even through an auto-compaction. I just make sure to remind Claude every once in a while to update the tasks as well as the context file with any relevant context. And once I'm running low on context in the current session, I just run my slash command /update-dev-docs. Claude will note any relevant context (with next steps) as well as mark any completed tasks or add new tasks before I compact the conversation. And all I need to say is "continue" in the new session.

During implementation, depending on the size of the feature or task, I will specifically tell Claude to only implement one or two sections at a time. That way, I'm getting the chance to go in and review the code in between each set of tasks. And periodically, I have a subagent also reviewing the changes so I can catch big mistakes early on. If you aren't having Claude review its own code, then I highly recommend it because it saved me a lot of headaches catching critical errors, missing implementations, inconsistent code, and security flaws.

PM2 Process Management (Backend Debugging Game Changer)

This one's a relatively recent addition, but it's made debugging backend issues so much easier.

The Problem

My project has seven backend microservices running simultaneously. The issue was that Claude didn't have access to view the logs while services were running. I couldn't just ask "what's going wrong with the email service?" - Claude couldn't see the logs without me manually copying and pasting them into chat.

The Intermediate Solution

For a while, I had each service write its output to a timestamped log file using a devLog script. This worked... okay. Claude could read the log files, but it was clunky. Logs weren't real-time, services wouldn't auto-restart on crashes, and managing everything was a pain.

The Real Solution: PM2

Then I discovered PM2, and it was a game changer. I configured all my backend services to run via PM2 with a single command: pnpm pm2:start

What this gives me:

• Each service runs as a managed process with its own log file

• Claude can easily read individual service logs in real-time

• Automatic restarts on crashes

• Real-time monitoring with pm2 logs

• Memory/CPU monitoring with pm2 monit

• Easy service management (pm2 restart email, pm2 stop all, etc.)

PM2 Configuration:

// ecosystem.config.jsmodule.exports = {
  apps: [
    {
      name: 'form-service',
      script: 'npm',
      args: 'start',
      cwd: './form',
      error_file: './form/logs/error.log',
      out_file: './form/logs/out.log',
    },
// ... 6 more services
  ]
};

Before PM2:

Me: "The email service is throwing errors"
Me: [Manually finds and copies logs]
Me: [Pastes into chat]
Claude: "Let me analyze this..."

The debugging workflow now:

Me: "The email service is throwing errors"
Claude: [Runs] pm2 logs email --lines 200
Claude: [Reads the logs] "I see the issue - database connection timeout..."
Claude: [Runs] pm2 restart email
Claude: "Restarted the service, monitoring for errors..."

Night and day difference. Claude can autonomously debug issues now without me being a human log-fetching service.

One caveat: Hot reload doesn't work with PM2, so I still run the frontend separately with pnpm dev. But for backend services that don't need hot reload as often, PM2 is incredible.

Hooks System (#NoMessLeftBehind)

The project I'm working on is multi-root and has about eight different repos in the root project directory. One for the frontend and seven microservices and utilities for the backend. I'm constantly bouncing around making changes in a couple of repos at a time depending on the feature.

And one thing that would annoy me to no end is when Claude forgets to run the build command in whatever repo it's editing to catch errors. And it will just leave a dozen or so TypeScript errors without me catching it. Then a couple of hours later I see Claude running a build script like a good boy and I see the output: "There are several TypeScript errors, but they are unrelated, so we're all good here!"

No, we are not good, Claude.

Hook #1: File Edit Tracker

First, I created a post-tool-use hook that runs after every Edit/Write/MultiEdit operation. It logs:

• Which files were edited

• What repo they belong to

• Timestamps

Initially, I made it run builds immediately after each edit, but that was stupidly inefficient. Claude makes edits that break things all the time before quickly fixing them.

Hook #2: Build Checker

Then I added a Stop hook that runs when Claude finishes responding. It:

1. Reads the edit logs to find which repos were modified

2. Runs build scripts on each affected repo

3. Checks for TypeScript errors

4. If < 5 errors: Shows them to Claude

5. If ≥ 5 errors: Recommends launching auto-error-resolver agent

6. Logs everything for debugging

Since implementing this system, I've not had a single instance where Claude has left errors in the code for me to find later. The hook catches them immediately, and Claude fixes them before moving on.

Hook #3: Prettier Formatter

This one's simple but effective. After Claude finishes responding, automatically format all edited files with Prettier using the appropriate .prettierrc config for that repo.

No more going into to manually edit a file just to have prettier run and produce 20 changes because Claude decided to leave off trailing commas last week when we created that file.

⚠️ Update: I No Longer Recommend This Hook

After publishing, a reader shared detailed data showing that file modifications trigger <system-reminder> notifications that can consume significant context tokens. In their case, Prettier formatting led to 160k tokens consumed in just 3 rounds due to system-reminders showing file diffs.

While the impact varies by project (large files and strict formatting rules are worst-case scenarios), I'm removing this hook from my setup. It's not a big deal to let formatting happen when you manually edit files anyway, and the potential token cost isn't worth the convenience.

If you want automatic formatting, consider running Prettier manually between sessions instead of during Claude conversations.

Hook #4: Error Handling Reminder

This is the gentle philosophy hook I mentioned earlier:

• Analyzes edited files after Claude finishes

• Detects risky patterns (try-catch, async operations, database calls, controllers)

• Shows a gentle reminder if risky code was written

• Claude self-assesses whether error handling is needed

• No blocking, no friction, just awareness

Example output:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 ERROR HANDLING SELF-CHECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️  Backend Changes Detected
   2 file(s) edited

   ❓ Did you add Sentry.captureException() in catch blocks?
   ❓ Are Prisma operations wrapped in error handling?

   💡 Backend Best Practice:
      - All errors should be captured to Sentry
      - Controllers should extend BaseController
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The Complete Hook Pipeline

Here's what happens on every Claude response now:

Claude finishes responding
  ↓
Hook 1: Prettier formatter runs → All edited files auto-formatted
  ↓
Hook 2: Build checker runs → TypeScript errors caught immediately
  ↓
Hook 3: Error reminder runs → Gentle self-check for error handling
  ↓
If errors found → Claude sees them and fixes
  ↓
If too many errors → Auto-error-resolver agent recommended
  ↓
Result: Clean, formatted, error-free code

And the UserPromptSubmit hook ensures Claude loads relevant skills BEFORE even starting work.

No mess left behind. It's beautiful.

Scripts Attached to Skills

One really cool pattern I picked up from Anthropic's official skill examples on GitHub: attach utility scripts to skills.

For example, my backend-dev-guidelines skill has a section about testing authenticated routes. Instead of just explaining how authentication works, the skill references an actual script:

### Testing Authenticated Routes

Use the provided test-auth-route.js script:


node scripts/test-auth-route.js http://localhost:3002/api/endpoint

The script handles all the complex authentication steps for you:

1. Gets a refresh token from Keycloak

2. Signs the token with JWT secret

3. Creates cookie header

4. Makes authenticated request

When Claude needs to test a route, it knows exactly what script to use and how to use it. No more "let me create a test script" and reinventing the wheel every time.

I'm planning to expand this pattern - attach more utility scripts to relevant skills so Claude has ready-to-use tools instead of generating them from scratch.

Tools and Other Things

SuperWhisper on Mac

Voice-to-text for prompting when my hands are tired from typing. Works surprisingly well, and Claude understands my rambling voice-to-text surprisingly well.

Memory MCP

I use this less over time now that skills handle most of the "remembering patterns" work. But it's still useful for tracking project-specific decisions and architectural choices that don't belong in skills.

BetterTouchTool

• Relative URL copy from Cursor (for sharing code references)

  • I have VSCode open to more easily find the files I’m looking for and I can double tap CAPS-LOCK, then BTT inputs the shortcut to copy relative URL, transforms the clipboard contents by prepending an ‘@’ symbol, focuses the terminal, and then pastes the file path. All in one.

• Double-tap hotkeys to quickly focus apps (CMD+CMD = Claude Code, OPT+OPT = Browser)

• Custom gestures for common actions

Honestly, the time savings on just not fumbling between apps is worth the BTT purchase alone.

Scripts for Everything

If there's any annoying tedious task, chances are there's a script for that:

• Command-line tool to generate mock test data. Before using Claude code, it was extremely annoying to generate mock data because I would have to make a submission to a form that had about a 120 questions Just to generate one single test submission.

• Authentication testing scripts (get tokens, test routes)

• Database resetting and seeding

• Schema diff checker before migrations

• Automated backup and restore for dev database

Pro tip: When Claude helps you write a useful script, immediately document it in CLAUDE.md or attach it to a relevant skill. Future you will thank past you.

Documentation (Still Important, But Evolved)

I think next to planning, documentation is almost just as important. I document everything as I go in addition to the dev docs that are created for each task or feature. From system architecture to data flow diagrams to actual developer docs and APIs, just to name a few.

But here's what changed: Documentation now works WITH skills, not instead of them.

Skills contain: Reusable patterns, best practices, how-to guides Documentation contains: System architecture, data flows, API references, integration points

For example:

• "How to create a controller" → backend-dev-guidelines skill

• "How our workflow engine works" → Architecture documentation

• "How to write React components" → frontend-dev-guidelines skill

• "How notifications flow through the system" → Data flow diagram + notification skill

I still have a LOT of docs (850+ markdown files), but now they're laser-focused on project-specific architecture rather than repeating general best practices that are better served by skills.

You don't necessarily have to go that crazy, but I highly recommend setting up multiple levels of documentation. Ones for broad architectural overview of specific services, wherein you'll include paths to other documentation that goes into more specifics of different parts of the architecture. It will make a major difference on Claude's ability to easily navigate your codebase.

Prompt Tips

When you're writing out your prompt, you should try to be as specific as possible about what you are wanting as a result. Once again, you wouldn't ask a builder to come out and build you a new bathroom without at least discussing plans, right?

"You're absolutely right! Shag carpet probably is not the best idea to have in a bathroom."

Sometimes you might not know the specifics, and that's okay. If you don't ask questions, tell Claude to research and come back with several potential solutions. You could even use a specialized subagent or use any other AI chat interface to do your research. The world is your oyster. I promise you this will pay dividends because you will be able to look at the plan that Claude has produced and have a better idea if it's good, bad, or needs adjustments. Otherwise, you're just flying blind, pure vibe-coding. Then you're gonna end up in a situation where you don't even know what context to include because you don't know what files are related to the thing you're trying to fix.

Try not to lead in your prompts if you want honest, unbiased feedback. If you're unsure about something Claude did, ask about it in a neutral way instead of saying, "Is this good or bad?" Claude tends to tell you what it thinks you want to hear, so leading questions can skew the response. It's better to just describe the situation and ask for thoughts or alternatives. That way, you'll get a more balanced answer.

Agents, Hooks, and Slash Commands (The Holy Trinity)

Agents

I've built a small army of specialized agents:

Quality Control:

• code-architecture-reviewer - Reviews code for best practices adherence

• build-error-resolver - Systematically fixes TypeScript errors

• refactor-planner - Creates comprehensive refactoring plans

Testing & Debugging:

• auth-route-tester - Tests backend routes with authentication

• auth-route-debugger - Debugs 401/403 errors and route issues

• frontend-error-fixer - Diagnoses and fixes frontend errors

Planning & Strategy:

• strategic-plan-architect - Creates detailed implementation plans

• plan-reviewer - Reviews plans before implementation

• documentation-architect - Creates/updates documentation

Specialized:

• frontend-ux-designer - Fixes styling and UX issues

• web-research-specialist - Researches issues along with many other things on the web

• reactour-walkthrough-designer - Creates UI tours

The key with agents is to give them very specific roles and clear instructions on what to return. I learned this the hard way after creating agents that would go off and do who-knows-what and come back with "I fixed it!" without telling me what they fixed.

Hooks (Covered Above)

The hook system is honestly what ties everything together. Without hooks:

• Skills sit unused

• Errors slip through

• Code is inconsistently formatted

• No automatic quality checks

With hooks:

• Skills auto-activate

• Zero errors left behind

• Automatic formatting

• Quality awareness built-in

Slash Commands

I have quite a few custom slash commands, but these are the ones I use most:

Planning & Docs:

• /dev-docs - Create comprehensive strategic plan

• /dev-docs-update - Update dev docs before compaction

• /create-dev-docs - Convert approved plan to dev doc files

Quality & Review:

• /code-review - Architectural code review

• /build-and-fix - Run builds and fix all errors

Testing:

• /route-research-for-testing - Find affected routes and launch tests

• /test-route - Test specific authenticated routes

The beauty of slash commands is they expand into full prompts, so you can pack a ton of context and instructions into a simple command. Way better than typing out the same instructions every time.

Conclusion

After six months of hardcore use, here's what I've learned:

The Essentials:

1. Plan everything - Use planning mode or strategic-plan-architect

2. Skills + Hooks - Auto-activation is the only way skills actually work reliably

3. Dev docs system - Prevents Claude from losing the plot

4. Code reviews - Have Claude review its own work

5. PM2 for backend - Makes debugging actually bearable

The Nice-to-Haves:

• Specialized agents for common tasks

• Slash commands for repeated workflows

• Comprehensive documentation

• Utility scripts attached to skills

• Memory MCP for decisions

And that's about all I can think of for now. Like I said, I'm just some guy, and I would love to hear tips and tricks from everybody else, as well as any criticisms. Because I'm always up for improving upon my workflow. I honestly just wanted to share what's working for me with other people since I don't really have anybody else to share this with IRL (my team is very small, and they are all very slow getting on the AI train).

If you made it this far, thanks for taking the time to read. If you have questions about any of this stuff or want more details on implementation, happy to share. The hooks and skills system especially took some trial and error to get right, but now that it's working, I can't imagine going back.

TL;DR: Built an auto-activation system for Claude Code skills using TypeScript hooks, created a dev docs workflow to prevent context loss, and implemented PM2 + automated error checking. Result: Solo rewrote 300k LOC in 6 months with consistent quality.

TL;DR: I am releasing claude_hooks, a Ruby gem that provides a clean DSL for creating Claude Code hooks instead of wrestling with JSON parsing, STDIN, STDERR and STDOUT handling and infinite back and forth with the documentation.

Hey there!

I've started building a few Claude Code hooks lately and got tired of writing the same boilerplate over and over again. Every single hook needed the same 15+ lines of repetitive error handling, STDIN parsing, and output formatting - it was tiring. So I built claude_hooks, a Ruby library that makes creating hooks more enjoyable.

I feel ruby is a great scripting language for this use case, but I get that it's not for everyone. Still, I hope it'll be helpful to some of you!

Features:

• Clean base classes to inherit from for all hook types (UserPromptSubmit, PreToolUse, PostToolUse, etc.) that will provide:

  • Input helpers to work with the input data (session_id, current_prompt, read_transcript, etc...)

  • Helper methods to manipulate the output, like add_context!(), block_tool!(), etc...)

  • Utility methods like log(), merge_outputs(), ...

• Intelligent output merging when you call multiple hooks from a single entrypoint and need the outputs to be merged into a single output

• Built-in session specific logging that doesn't interfere with Claude's usage of STDOUT / STDERR

• Configuration management via environment variables or config files (or both)

• CLI testing utilities to help with debugging hooks without having to go through Claude Code

• A recommended entrypoint / handler architecture that helps keeping your hooks organized

The gem handles all the STDIN/STDOUT JSON dance that Claude Code expects, helps with error handling, and lets you focus on the actual hook logic instead of plumbing.

I tried to make it handle all the cases I've run into while building hooks for my own workflows, adding tools like output merging, a way to debug hooks, as well as a comprehensive documentation with everything I need not to have to go back to the official documentation.

I'm sure there are bugs lurking around - I built this mostly for myself and it might not cover everyone's needs yet. Please tell me if you find anything broken or if there are obvious features I'm missing!

The README has a bunch of examples and the gem includes 2 very simple sample hooks in the example_dotclaude/ directory.

Contributions are also very welcome!

Cheers!

GitHub: https://github.com/gabriel-dehan/claude_hooks | RubyGems: https://rubygems.org/gems/claude_hooks

You might also want to take a look at my Claude Code status line that monitors your Claude Code usage depending on your plan, it's pretty nifty: https://github.com/gabriel-dehan/claude_monitor_statusline