The Skills That Build the Tool: How I Taught My AI Partner to Ship Software

The idea had been in my head for almost a year.

In March 2025, I'd built a tiny Electron app — just a TipTap editor in a drawer, maybe 6 files total. No AI, just me hacking on a weekend. An Electron prototype to scratch an itch: "what if there was a writing tool that understood LitRPG?" I got as far as a basic editor and a sidebar, stared at the mountain of work ahead, and shelved it.

Ten months later, a friend sent me a 7-day guest pass for Claude Code. I had no plans to build a product — I just wanted to see what AI-assisted development felt like. So I dusted off the idea and built vibe-writer: a React prototype with character stats, a template inserter, chapter management. 47 source files in a week — more than I'd built in the previous attempt's entire lifetime.

By day three, I was hooked. Not on the prototype — on the process. The speed of going from idea to working code was unlike anything I'd experienced in my career. By day seven, when the guest pass expired, I'd already sketched out what would become AxiomWeaver. I signed up for the $100/month Claude subscription that night.

Both prototypes were disposable. The realization wasn't: the tool I'd shelved because it was too ambitious for one person was suddenly possible.

But in those first weeks, everything was improvised. I'd describe a feature, Claude would help me build it, and we'd move on. No consistency. No memory of how we'd solved similar problems before. Every session started from scratch.

By month two, I had 15 specialized skills — reusable prompts that turn Claude into different personas with different jobs, guardrails, and workflows. A developer skill. An auditor skill. A ticket writer. A test engineer. A blog writer. Even a skill that evolves the other skills based on what's working and what isn't.

All on that same $100/month subscription. I hit usage limits occasionally, but the skills themselves — by making interactions more efficient and focused — balanced that out.

Here's how the library evolved and what I learned building it.

What a skill actually is

A skill is a markdown file that gives Claude a specific persona, context, and set of rules for a particular job. When I invoke /developer, Claude doesn't just "help me code." It activates a Conservative Senior Developer persona that:

Follows the project's CLAUDE.md standards (naming, file limits, error handling)
Runs a UX checkpoint before any user-visible change
Knows which dependency licenses are acceptable (MIT, Apache-2.0, BSD, ISC only)
Understands when it's being called from within the implementation loop and extends its behavior accordingly

It's the difference between "Claude, help me write this function" and "Claude, you are a senior developer working on this codebase with these standards, this ticket, and this context — go."

The core four

The first skills I built were the ones I needed every day:

Developer. The implementation workhorse. Writes code, follows standards, checks with me before building anything user-visible. Conservative by default — it won't get clever unless I ask it to.

Ticket Writer. Translates my half-formed ideas into structured Linear issues with acceptance criteria, dependencies, and accessibility requirements. It thinks like a user empath — anticipating needs and mentally testing features before they're built.

Auditor. Reviews diffs like a senior staff engineer. Auto-fixes medium and above severity issues, files Linear tickets for cosmetic stuff. Includes a WCAG accessibility checklist and license check for new dependencies. The auditor has caught real bugs that would have shipped.

Implementation Loop. The orchestrator. Picks up a Linear ticket, invokes the developer to build it, runs tests, creates a PR, invokes the auditor to review it, then runs session metrics. 15 steps, automated. This is the skill that turned me from "a developer using AI" into "a developer with a system."

The support crew

As patterns emerged, I built more targeted skills:

Hotfix. A fast-track bug fix that skips the full ceremony — no implementation plan, no auditor, no dependency graph updates. But it has guardrails: more than 3 files touched? Schema changes? Uncertain root cause? The skill tells you to stop and use the full loop instead. And it enforces test-first even in fast-track mode.

SDET. A test engineering persona that analyzes coverage, cross-references E2E tests against manual test cases, and creates Linear issues for gaps. I used this to build out 23 Playwright E2E tests covering the import pipeline.

Bug Writer. I describe a bug in plain English. The skill determines severity and priority itself (I explicitly told it not to ask me — I'd always say "high"), locates the affected code, and files the Linear ticket. If it's critical, it recommends invoking /hotfix next.

Tech Writer. Maintains two documentation layers: human-readable docs and agent-optimized docs (bare facts, tables, max 50 lines). The agent docs have a source-reference comment linking back to the human original. When I ship a feature, the tech writer syncs both layers.

Dead Code. Sweeps for orphaned components, unused imports, unreferenced CSS, dead backend code. Conservative — it only auto-removes things with zero references. Anything that might be dynamically referenced gets flagged but preserved. Runs the full test suite after removals.

The meta layer

The two skills I'm proudest of aren't about building features at all.

Session Efficiency. Runs at the end of every ticket and logs what happened — tool calls, rework cycles, search iterations. But it tracks both sides: agent patterns (how many searches to find the right file?) and human patterns (did I give an ambiguous prompt that caused rework?). Each pattern is tagged as agent, human, or collaborative. The tone guidance says "frame as collaborative optimization, never criticism." Over time, this data shows me where the process is leaking time.

Evolve. This is the skill that modifies the other skills. It reads session metrics, sprint notes, and recent work patterns, then proposes changes: split a skill that's doing two jobs, merge skills that overlap, trim rules nobody follows, add guardrails for repeated mistakes. It enforces a 60-line max per skill — if a skill grows beyond that, it's doing too much. Evolve requires my explicit approval before changing anything.

A system that improves itself. That's the part that still feels like science fiction.

What the numbers say

The activity log for project-codex tells the story:

800 tickets created across 2 months
275 tickets completed
303 pull requests merged
497,770 lines added
15 skills in the library
One developer. One $100/month AI subscription.

I don't say this to brag. I say it because these numbers shouldn't be possible for one person, and the skill library is why they are. Each skill removes a category of friction. The implementation loop alone — from ticket pickup to PR merged with audit — used to take me a full evening of manual work. Now I invoke /imp-loop TIN-492 and stay in flow.

The real insight

The skills aren't about making Claude smarter. Claude is already smart. The skills are about making me more consistent.

Without the developer skill, I'd sometimes skip the UX checkpoint and build the wrong thing. Without the auditor, I'd merge code with accessibility gaps. Without session-efficiency, I'd never notice that half my rework came from ambiguous prompts.

The skill library is a system for working well with AI — not a system for replacing the developer. I still make every architectural decision. I still review every line of code. I still decide what to build and why. The skills just make sure the collaboration follows a process instead of vibing it every time.

If you're building with AI

You don't need 15 skills to start. You need one: a developer persona that knows your project's standards and checks with you before building. Start there. Add more when you notice yourself repeating the same instructions across sessions.

The key principle: a skill is a captured decision about how to work. Every time you find yourself saying "no, not like that — like this," that's a skill waiting to be written.

If you're curious about the tool this system built, check out AxiomWeaver. Or come talk about AI-assisted development on Discord — I'm genuinely interested in how other solo devs are building their own systems.