How One Dev Used Hooks, Skills, and PM2 to Make Claude Code Reliable at Scale

What happened

A developer on r/ClaudeAI (https://reddit.com/r/ClaudeAI/comments/1oivjvm/claude_code_is_a_beast_tips_from_6_months_of/) described six months of heavy use of Claude Code to refactor ~100k LOC into a modern 300-400k LOC stack. The post is a practical playbook: auto-activating Skills with TypeScript hooks, a disciplined dev-docs workflow, PM2-backed backend debugging, and a small army of specialized agents and slash commands. The result: far more consistent outputs from Claude and far fewer review cycles.

Core components

1) Skills Auto-Activation via Hooks

Problem: Skills sat unused unless explicitly invoked. The author built a UserPromptSubmit hook that inspects the user’s prompt and pre-injects a clear “🎯 SKILL ACTIVATION CHECK” so Claude sees the relevant skill before it processes the prompt. A Stop Event hook runs after responses to add self-check reminders.

Config: central skill-rules.json with keywords, intent regexes, path and content triggers.
Skills were split into a compact main SKILL.md (<500 lines) plus resource files for progressive disclosure, reducing token usage by about 40–60%.

2) Dev-docs + Planning System

Planning mode plus a strategic-plan-architect agent creates three canonical files per major task: plan, context, tasks. Slash commands (/create-dev-docs, /dev-docs-update) automate creation and upkeep so Claude can be “reminded” of the accepted plan even after context compaction.

3) PM2 for backend debugging

Running backend microservices under PM2 allows Claude to read logs (pm2 logs), restart services, and autonomously triage crashes rather than the human copy/pasting logs.

4) Hook pipeline to prevent regressions

Post-edit hooks log edited files. A Stop hook runs repo builds, surfaces TypeScript errors (auto-fix agent if many errors), and a Prettier formatter runs automatically. An Error Handling Reminder provides non-blocking guardrails such as Sentry and repo patterns.

5) Agents, scripts and slash commands

Specialized agents (build-error-resolver, code-architecture-reviewer, auth-route-tester) and utility scripts attached to skills (for example, test-auth-route.js) let Claude use ready tools instead of reinventing them.

Why this matters

Okay, let’s pause for a second. Large codebases plus LLM partners expose two consistent failure modes: (a) model amnesia or inconsistent adherence to patterns, and (b) noisy stochastic outputs that require lots of human triage. The author’s system turns implicit patterns into explicit, auto-loaded context and inserts automated QA hooks so mistakes are detected immediately. That changes the operator model from “watch Claude and fix later” to “let Claude surface issues and fix them fast.”

Context and broader trends

Progressive disclosure of skills (compact SKILL.md plus resources) aligns with Anthropic guidance and is key for token efficiency.
Similar patterns appear in other developer-centered LLM workflows (Cursor rules, spec-kit mentions in comments): map contextual files to rule bundles so the LLM sees only what it needs.
PM2 as a managed process supervisor is a practical way to give an LLM access to live logs, addressing a recurring pain point across many AI-assisted dev setups.

My takeaways from this post:

Plan before coding: use planning mode and produce a small set of reproducible docs (plan/context/tasks).
Keep Skills lean and modular: main file <500 lines, resource files for deep material.
Use hooks to make skills reliable: trigger skill context before prompt processing and run QA hooks after edits.
Automate builds and formatting after edits: catch issues immediately instead of discovering them in later reviews.
Expose logs and processes to the model carefully: PM2 is a pragmatic option for enabling log-based debugging.

Final note

This is a battle-tested, pragmatic workflow rather than a theoretical one. If you manage a nontrivial codebase and use an LLM assistant, the overhead of setting up rules, hooks and agents pays back in fewer review cycles and more predictable outputs. Remember that there is often another side to the story: tools differ, teams differ, and trade-offs exist, but if consistency and QA are your problem, this post provides a high-value blueprint to try.