My Current Claude Code Setup and How I Use It

Claude Code is my daily driver. Making use of the Max plan, I enjoy writing code and am doing it faster than ever before.

While everybody can use Claude Code and produce code with it, I have noticed that the quality of your input and the way you use the tool dictate whether the output is actually scalable. Smaller projects can be vibe-coded with ease by anyone. But once you work on something larger, a skilled and structural approach is what makes LLMs truly useful.

Planning Matters, but Not Blindly

Planning is important. That said, I have found that the built-in planning mode of Claude makes a lot of mistakes when you blindly accept its suggestions. It tends to spit out a plan early, and if you just go with it, you often end up course-correcting halfway through.

Recently I came across the /grill-me skill by Matt Pocock. This one changed how I approach planning entirely. Instead of letting Claude draft a plan and nodding along, /grill-me flips the dynamic. It interviews you relentlessly about every aspect of your plan, walking through each branch of the design tree and resolving dependencies between decisions one by one. For each question, it provides a recommended answer, and if something can be answered by exploring the codebase, it does that instead of asking you.

I fired it off yesterday and went 33 questions deep to get a thorough co-understanding of the feature I had to build. By the end of it, both Claude and I were fully aligned on what needed to happen, with no ambiguity left. I encourage you to try it.

Test-Driven Development That Actually Works

Matt has more skills published, and /tdd is another one I reach for regularly.

LLMs often mess up writing tests. The typical failure mode is that they look at the existing code and write tests that satisfy the current implementation rather than testing what the code should actually do. The tests pass, but they are brittle and coupled to internals. Refactor something and they break, even when the behavior has not changed.

The /tdd skill tackles this by enforcing a vertical slice approach. Instead of writing all tests first and then all implementation (horizontal slicing), it works in small cycles: write one test, write just enough code to make it pass, then move on to the next behavior. Each cycle builds on what was learned from the previous one.

The flow looks like this:

1. Plan the behaviors to test and confirm the interface
2. Tracer bullet -- write a single test for the first behavior (red), then minimal code to pass it (green)
3. Incremental loop -- repeat for each remaining behavior, one test at a time
4. Refactor -- only after all tests pass, extract duplication and clean up. Never refactor while red.

Each test should describe behavior, use the public interface only, and survive internal refactoring. This forces both you and the LLM to think about what the code should do rather than how it currently does it.

Exploring Architectural Improvements

I have also been using the /improve-codebase-architecture skill. This one takes a different angle. Instead of working on a specific feature, it explores your codebase looking for architectural improvement opportunities.

The core idea is borrowed from John Ousterhout's "A Philosophy of Software Design." It looks for shallow modules -- components where the interface is nearly as complex as the implementation -- and identifies opportunities to deepen them. Deep modules have simple interfaces that hide complex implementations, which makes them more testable and easier to work with.

The skill walks through a multi-step process. It starts by organically exploring your codebase, looking for friction points: concepts scattered across many files, tightly coupled modules, functions extracted purely for testability, or components that are hard to test. It then presents a list of candidates, and once you pick one, it spins up multiple sub-agents to generate radically different interface designs. You pick the one that fits best, and it files a refactor RFC as a GitHub issue.

What I like about this approach is that it does not just point out problems. It gives you concrete options and lets you decide what to act on.

What Else is Out There?

Matt's skill repository has even more options. There is /write-a-prd for creating product requirement documents through an interactive interview, /prd-to-plan for converting those into phased implementation strategies, /request-refactor-plan for creating detailed refactor plans with small commits, and several others.

I am curious to explore more of these. If you come across any interesting skills or have built your own, let me know.