In Part 1, I talked about why we need guardrails for AI development. Now let's build them.
Fair warning: this isn't some comprehensive installation guide. The Claude Code docs cover that well enough. This is about the thinking behind the setup, the decisions, the structure that works, and why I built it this way.
(Want my complete setup with all the commands? Comment and I'll drop a link to the repo)
The Stack (And Why I Didn't Overthink It)
Before we get into the Claude Code magic, here's what you'll need:
- Node.js - Claude Code runs on it, and most modern dev tooling expects it.
- GitHub CLI - This is non-negotiable. Claude Code integrates perfectly with gh, and it's the difference between "create a PR manually through the web UI like a caveman" and "Claude handles the entire git workflow autonomously."
- Claude Code itself - npm install -g @anthropic-ai/claude-code. That's it. No ceremony.
The installation itself is straightforward - Node.js from nodejs.org, Claude Code via npm. Standard stuff. What's more interesting is why this stack matters for autonomous workflows.
The GitHub CLI handles all the git plumbing - creating branches, opening PRs, managing issues. Claude Code is the engine that reads your project, executes commands, and makes changes. Your command structure? That's what keeps Claude from deciding to rewrite your entire auth system when you asked it to fix a button colour.
That's the stack. Simple, effective, keeps Claude on a leash.
The GLOBAL_STANDARDS File: Your AI's Rulebook
Remember that Lincoln quote about sharpening the axe? This is where you do it.
The GLOBAL_STANDARDS.md file lives in ~/.claude/ and gets referenced by every project. Think of it as the framework that Claude Code has to follow. My file is about 200 lines, and it's saved me from countless hours of cleaning up Claude's mess.
I didn’t start with a perfect 200-line standards document. I started with around 20 lines of “don’t be a dickhead” guidance. The rest came from Claude doing stupid shit and me adding rules afterwards.
The standards file is me dealing with the problems as they happen, instead of hoping Claude magically figures out what I want. Every time something goes sideways, I write it down. Every time I catch myself thinking "why the fuck did it do it that way?" - a new rule.
What goes in it:
Core principles: SOLID, DRY, YAGNI, DDD. Not because these are sacred laws, but because they're MY defaults. Claude needs to know how I think, not guess based on whatever training data it has.
Code organisation standards: file naming conventions, folder structure, how to handle errors, where configs go. Boring? Yes. Essential? Absolutely.
Language-specific patterns: For me that's TypeScript strict mode, React functional components with hooks, no class components unless there's a bloody good reason. And yes, I know hooks have been the standard since 2019, but Claude sometimes still tries to generate class components because apparently it learned React from 2017 tutorials.
The bit everyone forgets: What NOT to do. "Don't introduce new dependencies without asking." "Don't refactor working code unless that's the explicit task." "Don't get clever with abstractions."
Examples:
Every time Claude does something stupid, I add a rule. That's how the file evolves. It's not some grand architectural document I spent weeks planning - it's a living record of "here's what went wrong and here's how to not do it again."
The alternative is doing what I used to do - just accepting that AI tools occasionally generate shit code, shouting at it – trying to understand why, spending hours cleaning it up, and then watching it make the same mistakes next week. That's exhausting. Writing down "don't do this" once is way less effort than fixing it repeatedly.
Building Commands That Actually Work
Commands in Claude Code are just markdown files. Simple, right? Wrong.
The difference between a command that works and one that goes wild is in the structure. Let me show you with the command I use most: /SHIP.
The full command is ~400 lines because it's very explicit about what to do at each stage. But that's the point - no ambiguity means fewer "creative interpretations."
At each stage (PLAN, BUILD, TEST, REVIEW), Claude pauses and shows me what it's done - the plan it created, the commits it made, the test results. I review, approve, or give feedback before it continues. It's less "watch AI code for you" and more "AI does the grunt work, you make the decisions."
Why it's structured this way: PLAN comes first - always. Force Claude to think before typing. No plan, no build. Each step has explicit checkpoints where I can approve, revise, or cancel. Testing isn't optional - UI changes get Puppeteer tests; business logic gets unit tests, no exceptions. And before any PR gets opened, Claude checks its own work against the standards file, physically ticks off a checklist.
What I learnt the hard way:
Early versions of this command didn't have the PLAN step. Claude would just start coding immediately. When it worked, it was brilliant. When it didn't, I had no reference point to course-correct because there was no plan to check against.
The self-review step came after Claude shipped code that technically worked but violated half my standards. You've got to remember that you're basically talking to a very academic student with no real-life experience. Pushing it to constantly check its work, review itself against what we've already discussed, and physically tick off a checklist keeps it in line a lot more.
Context: The Bit That Makes It Actually Work
Here's what most people miss when they talk about autonomous AI workflows: context gathering. This is the difference between Claude blindly generating code and Claude actually understanding your codebase.
I figured this out the hard way. Early versions of my workflow, Claude would generate perfectly valid React code that had nothing to do with how I'd built the rest of the application. Different naming conventions, different patterns. Technically correct, completely inconsistent.
It's as if you joined a new team and started writing code before you'd read any of the existing codebase. Sure, you can write working code - but it won't fit.
Scratchpads are Claude's working memory. Every time you run /plan, it creates a scratchpad file in scratchpads/issue-[number]-plan.md. That file contains the entire thought process - what contracts are needed, what files to create, edge cases to handle, testing strategy.
But here's the clever bit - those scratchpads don't just disappear after the task is done. They sit there. Next time Claude works on something similar, it searches them. "Have I solved authentication before?" "How did we handle form validation last time?" Instead of starting from zero every single time, it's building up actual knowledge of your codebase.
It's like having documentation that is for once, kept up to date because it's generated as part of building features, not as an afterthought nobody bothers with.
Past PRs are pattern recognition. When Claude starts planning a new feature, it searches through your recent merged PRs. Not to copy code - to understand patterns. "How did we structure the last repository?" "What was the approach for error handling in the last API endpoint?"
This surprised me. I expected Claude to just look at the current state of the code. Turns out, looking at the history of how features were built is way more useful. It sees the patterns, the decisions, the "we did it this way because of X" context that doesn't exist in the final code.
Related files are semantic search. Claude doesn't just look at files you mention. It searches your codebase for conceptually related files. Working on a user profile feature? It'll find other user-related files even if they're not explicitly mentioned in the issue.
It understands the domain structure, not just the file names. Which matters because half the time I don't remember every file that touches a particular feature. Claude searches, finds the related bits, and references them in the plan. Saves me having to play "grep detective" through my own codebase.
This is why the PLAN stage is non-negotiable. That's when all this context gathering happens. Claude reads the issue, searches scratchpads, checks past PRs, finds related files, and THEN creates a plan. By the time it starts building, it's got the full picture.
Without this, you're just getting generic AI code that might work but doesn't fit your codebase. With it, Claude's writing code that looks like you wrote it, because it's learned from everything you've already built.
The difference is the same as someone who's worked on your codebase for six months versus someone who just read the README. One of them knows why things are the way they are. The other is guessing.
Setting Up a New Project
Once you've got your global config sorted, project setup is straightforward:
- Create the repo (I use GitHub CLI: gh repo create project-name --public --clone)
- Add a project-specific CLAUDE.md - this is where project context lives
- Create .claude/commands/ for any project-specific commands
- Add a .claudeignore - keep Claude out of node_modules, .git, build artifacts
- Create a scratchpads/ directory - this is Claude's working memory
The project CLAUDE.md is where you put the brief, architecture decisions, anything Claude needs to know about THIS specific project. Think of global config as "how to write code" and project config as "what we're building."
The scratchpads directory is where Claude stores all its plans. Over time, this becomes a knowledge base of how features were built, what decisions were made, what problems were encountered. It's like having documentation that actually stays up to date because it's generated as part of the build process.
Does It Actually Work?
Theory is nice. Let's see it in practice.
When I run /SHIP issue-123, here's what happens:
- Claude reads the GitHub issue
- Searches scratchpads and past PRs for context
- Creates a detailed plan and waits for my approval
- Creates a feature branch and implements the solution
- Runs tests (generates new ones if needed)
- Self-reviews against the standards checklist
- Opens a PR
Time breakdown: ~10-15 minutes total for a moderate feature. My involvement? About 2 minutes reviewing and approving at each checkpoint.
If Claude misunderstands the issue, I catch it at the PLAN stage before any code is written. If the implementation goes sideways, the REVIEW step catches standards violations. If tests fail, the workflow stops - no PR gets created with failing tests. At any checkpoint, I can give feedback and Claude iterates.
Progress not perfection. It's still way better than "vibe coding" and hoping for the best.
What's Next
You've got the setup. You've got the commands. You've got the guardrails. More importantly, you understand why context gathering is the secret sauce that makes autonomous workflows actually work.
In Part 3, I'll walk through building a real project with this workflow - from project brief to working MVP. You'll see where it shines, where it struggles, and how to course-correct when Claude gets ideas above its station.
For now, set it up. Try it. Break it. Add your own commands. Make it yours.
And if Claude goes rogue? Well, that's what the approval checkpoints are for.
Want the full setup? Comment "SETUP" below and I'll share the repo with all my commands, standards file, example project structure, and those scratchpad templates that make context gathering work.
I'm Mike Nash, an Independent Technical Consultant who's spent the last 10+ years building software, leading engineering teams, and watching the industry evolve from WebForms to AI-powered development.
These days I help companies solve gnarly technical problems, modernise legacy systems, and build software that doesn't fall over. I also apparently write blog posts about shouting at AI tools.
Want to chat about AI workflows or consulting?
Connect with me on: LinkedIn or comment below.
Top comments (0)