A senior engineer's Claude Code skills stack tells you more about their engineering values than their resume does. I got pulled into this topic by a former Amazon and Microsoft engineer shipping a product called BookZ.AI, who walked through the eight-skill stack running his one-person operation. Watching it, I realized the interesting question wasn't "should I copy his stack." It was "what does my own stack say I actually believe?" So instead of reviewing his list secondhand, I opened ~/.claude/skills on my machine and audited what's really installed, what earned its slot, and where his stack and mine converge. The convergence turns out to be the whole story.
The claim worth testing
The promise behind any skills stack is the same: raw Claude Code is a brilliant generalist with three chronic failure modes. It skips steps unless you insist, it forgets everything between sessions, and it doesn't close loops, meaning it writes code without confirming the code actually works in the running system. A good stack is not a pile of productivity hacks. It's one surgical fix per failure mode. Curating my agent skills marketplace, where I maintain 53 vetted skills across 20 categories, taught me to evaluate every skill against that standard: which specific failure does this close? If the answer is vague, the skill is context-window ballast.
Here's my stack, grouped by the failure mode each layer closes.
Layer 1: Discipline, the skill that makes the rest matter
The foundation of my setup is the Superpowers plugin's workflow family: brainstorming before any creative work, written plans before implementation, and test-driven development enforced as a sequence rather than suggested as a virtue. The TDD skill is the one with teeth. Tests are written first and must fail before implementation exists; a test that never failed is flagged as a false green. That single mechanism kills the most expensive AI-coding failure I know: code that compiles, looks plausible, and doesn't do what you asked.
The BookZ.AI engineer's stack has Superpowers at its base too, and that's no accident. Every serious practitioner I compare notes with converges on some discipline layer first. I wrote a full review of the Superpowers plugin if you want the mechanics; the compressed verdict is that I use it for everything touching production and skip it for throwaway scripts, where the ceremony costs more than it saves.
Alongside it I keep a tdd skill and a triage skill for bug intake, plus grill-me, which does for requirements what TDD does for code: it interrogates my assumptions before work starts instead of after it's wasted.
Layer 2: Architecture, the pressure that survives speed
AI writes code five to ten times faster than I do, which means it accumulates architectural debt five to ten times faster too. The counterweight in my stack is Matt Pocock's improve-codebase-architecture skill, installed from his skills repo, which reads a codebase through the deep-modules lens: find clusters of shallow modules whose interfaces are as complex as their implementations, and propose consolidations. It's the only skill I run on a schedule rather than on demand, and I've written up what it surfaced on my own Laravel codebase separately.
The reason this layer is non-negotiable for a senior engineer specifically: juniors feel codebase rot slowly, seniors are accountable for it immediately. A skill that applies steady architectural pressure scales with your shipping rate in a way that quarterly refactoring sprints never did.
Layer 3: Verification, closing the loop the demos skip
The gap between "the agent wrote the feature" and "the feature works" is where most AI-shipped code quietly dies. My stack closes it with browser automation: the Playwright plugin drives a real browser against the running app, clicks the flows, reads the DOM, and screenshots failures. For UI changes on my own site, that loop runs at desktop, tablet, and mobile widths, because my own verification rules demand all three. The CLI-style invocation is more token-efficient than a persistent browser session for the common write-verify-iterate loop, which matches what I found when I tested Playwright with Claude Code in depth.
I also keep diagnose in this layer, a skill for structured debugging that forces hypothesis-before-fix, which sounds obvious and is routinely skipped by both humans and models under deadline pressure.
Layer 4: The distribution layer most engineers refuse to install
Here's the part of the BookZ.AI stack I expected to dismiss and ended up agreeing with hardest: the marketing skills. His pack handled SEO audits and content; he credits it with taking his product from zero to its first thousand users, a number I can't verify and report as his claim.
What I can verify is my own usage. Thirteen of the skills on my machine are SEO skills, a family covering audits, content, schema, hreflang, sitemaps, programmatic pages, competitor analysis, and technical checks. They exist because I operate a multilingual site with hundreds of posts across six locales, and every one of those skills automates a check I used to do by hand or, more honestly, used to skip. The engineering insight buried in this layer: distribution work is exactly as automatable as engineering work, made of repeatable audits, structured outputs, and verifiable claims. Engineers who treat marketing as beneath their stack are leaving the most compounding automation on the table. My breakdown of running SEO checks as Claude Code routines shows this layer in production.
Layer 5: Continuity and the meta-layer
Two smaller layers round out the stack. Continuity: the handoff skill packages a session's state so the next session, or the next machine, resumes without context archaeology, which I covered in my multi-session handoff workflow. For a stack that runs across a laptop, a desktop, and cloud sessions, this is the difference between compounding progress and Groundhog Day.
And the meta-layer: skill-creator and write-a-skill, the skills that build other skills. The trigger for using them is mechanical. When I notice myself typing the same five-sentence prompt across multiple sessions, that repetition is a skill announcing it wants to exist. Half the skills in my directory started life as a repeated prompt, including the design-review skill impeccable and my theme-scaffolding tool theme-factory.
What the overlap between his stack and mine proves
Lay the two stacks side by side and the surface differences are real: he runs a Telegram bridge for remote control, I use Claude's own remote sessions; he wires Jira and Sentry into a ticket-fixing pipeline, my equivalent is leaner because I'm my own QA department. But the structure is identical. A discipline layer at the bottom. A browser-verification loop. A memory or continuity mechanism. A distribution pack. A meta-layer for making new skills.
That structural convergence, arrived at independently by people with different products and different histories, is the strongest evidence I can offer that the layers are the right abstraction. The specific skills are swappable. The failure modes they close are not.
The equally important pattern: both stacks are small. Eight skills for him; my actively used set is about a dozen despite more being installed. Every skill loads context, and context is the scarcest resource in the system. The stack question is a curation question, which is why my honest advice mirrors what I do at the marketplace: install slowly, demand that each skill close a named failure mode, and delete what you wouldn't miss. My starter recommendation is three slots: a discipline skill, a browser-verification skill, and a continuity skill. Add the rest only when a real failure demands it.
My agent skills marketplace exists to spare you the trial-and-error phase of this exact audit: every layer above has vetted options there, with named authors and linked source repos. Take the three-slot core, run it two weeks, and let your own failures pick the rest.
