Open-Source Claude Code Skill Stack: 4 Skills

Most AI content shows you prompts. Screenshots of a clever system message, threads promising that one instruction will change your business. Almost nobody shows you the actual files running a real company, because most of those threads were never attached to one.

Here are mine.

This week I pushed four production skills from my studio’s stack to a public repo: claude-code-skill-stack. These are the working versions. proposal-drafter has shipped real client proposals. weekly-report has fired every Friday at 16:00 for months. invoice-generator hands out sequential invoice numbers with lock-file protection because I once worried about exactly one race condition. And meeting-notes-router carries a post-mortem of its own worst day in its skill file.

Quick context if you’re new here. I’ve run a solo production studio in Taipei for ten years. Over the past two I restructured it into eight AI-run departments using the Solo Stack Method: Signal, Strategy, Skill, Ship. My working hours dropped by about half while project volume doubled. Roughly 70 skills run those departments day to day. These four are the first ones clean enough to publish.

Why publish the files that run my business

Three reasons, in honesty order.

Publishing forces quality. Cleaning proposal-drafter for release surfaced a stale pricing reference and one ship criterion that had quietly stopped being enforced. Nothing exposes soft spots in a skill like preparing it for strangers. Every skill I clean for the repo comes back better than it left.

Stars tell me what to build next. I have 60-plus skills in the private stack and limited cleaning hours. GitHub stars are the cheapest demand signal I know. If the repo sits at 12 stars forever, that teaches me something too.

There’s no moat to protect. These skills are opinionated to my studio: my pricing floor, my proposal structure, my Friday rhythm. You can copy every line and you still won’t have my client list or my ten years of knowing what a nervous client email sounds like. The pattern is the useful part, and patterns spread anyway. Better they spread with my name on them.

The four skills

proposal-drafter

Turns an inbound brief into a first-draft proposal in under five minutes. It’s the full three-file pattern in action: SKILL.md for procedure, strategy.md for judgment, and context/pricing-anchors.md.example for the numbers.

The design decision worth stealing: the ship criteria require cross-referencing every number in the draft against the pricing anchors file. A draft with an unanchored number doesn’t ship, full stop. Language models are dangerously fluent with plausible-sounding prices; a figure 15% below your floor reads exactly as confident as the right one. The anchor check converts “sounds right” into “matches a file I control.”

The documented failure mode: early drafts would blend two service tiers into one quote when a brief was ambiguous. Better prompting didn’t fix it. The anchor cross-reference did, plus an explicit rule that ambiguity gets a question back to me instead of a guess.

weekly-report

The autonomous one. Every Friday at 16:00 it pulls three sources, my time logs, the pipeline file, and the ledger, and compresses the week into one page. I read it Monday morning with coffee.

The design decision worth stealing: an integrity check that the total hours in the summary must reconcile against the per-day logs. If the numbers don’t add up, the report ships with a loud warning block instead of shipping clean. That check is why this skill is allowed to run unattended at all. Autonomy has to be earned, and the currency is a mechanically verifiable output.

The failure mode it guards against is silence. A missing Wednesday log doesn’t make the report crash; it makes the week look lighter than it was, which is worse. Reconciliation turns a quiet gap into a visible one.

invoice-generator

One-shot, on demand. It produces the invoice, assigns the next sequential invoice number, and drafts the client email. It never sends that email. Money-adjacent output always gets a human click in my stack.

The design decision worth stealing: a lock file around the invoice counter. If two sessions run at once, one waits, so invoice #2026-041 can never be minted twice. It’s maybe six lines of logic, deeply boring, and it prevents the single most annoying bookkeeping bug a small studio can create for itself. Steal the boring parts first.

meeting-notes-router

Human-in-the-loop on purpose. Feed it raw meeting notes and it extracts actions, decisions, and open questions, routes each to the right department, then stops. Everything waits for operator review before anything moves.

It didn’t start that way, and the repo says so. An early version auto-sent its routing. One Friday at 6 PM it dumped 40 action items into an inbox in a single burst. Every item was technically correct — and it was still the most hostile thing my own system ever did to me. never_send is now hard-coded in the skill, not a config value, and the post-mortem lives in the repo so the reasoning survives. When you downgrade a skill’s autonomy after an incident, make the downgrade annoying to revert. Config flags get flipped back at midnight by optimists.

The three-file pattern

All four skills follow the same shape, and proposal-drafter shows it most completely:

• SKILL.md holds the procedure: what triggers the skill, the steps, and the ship criteria that define done.
• strategy.md holds the judgment: tone, edge cases, when to stop and ask, what good output looks like.
• context/ holds the facts that change: pricing, anchor rates, client conventions, shipped as .example files with the structure intact and my real numbers stripped.

I learned the hard way that stuffing everything into one file breaks in slow motion. Prices change more often than procedures, so every rate update becomes an edit to your logic file. The file bloats. The agent’s context fills with stale facts. After a while you can’t tell which line is instruction and which is data, and you can never publish any of it, because facts and logic are welded together.

Separation is the entire reason this repo exists. Swap the context/ folder and the same logic runs someone else’s studio. In Solo Stack Method terms, this is the Skill layer done properly: procedure, judgment, and facts in separate files because they change at different speeds.

What’s not in the repo

No client data, anywhere, including test fixtures. No real pricing anchors; you get pricing-anchors.md.example with the structure and placeholder numbers. And none of the other 60-plus skills yet, because most still have hard-coded paths to my machine and assumptions about my folder tree that would break on contact with anyone else’s setup.

What lands next depends on the stars, but two are closest to clean: the client-feedback triage skill, which classifies incoming client messages and drafts replies in my tone, and the quote sanity-checker, which audits a finished quote against my hourly-rate floor. If either sounds useful, the star button is the vote.

If you want to run skills like these instead of reading about them, three doors. Star claude-code-skill-stack; that’s the literal signal for what gets cleaned and published next. Fork claude-skill-starter if you’d rather build your own first; it’s the empty three-file scaffold with the ship-criteria section ready to fill in. And join Solo Stack Studio on Skool for the weekly Q&A, where I walk through skills like these live. If you run a company that wants this installed rather than DIY’d, that’s what the consulting track is for.

FAQ

Can I use these skills directly in my business?

You can install them today, but plan on an editing pass before trusting the output. The procedures in each SKILL.md transfer well; the judgment in strategy.md is calibrated to a solo video studio and will need your voice; the context/ .example files are deliberately empty of my real numbers. Budget an hour per skill to fill in your own pricing anchors, folder paths, and tone rules. The skills that touch money deserve a week of supervised runs before you send any draft without reading it closely.

Why only 4 skills if you run 70+?

Because cleaning is the slow part. My private skills are full of hard-coded paths, client names in test fixtures, and real pricing data. Stripping that out without breaking the skill takes hours per file, and publishing a half-cleaned skill that leaks a client name would cost me more than the repo will ever earn. Four fully cleaned skills that actually run beat forty that almost do. The publication order for the rest is decided by GitHub stars, which is the cheapest honest demand signal I have access to.

Do these work without Claude Code?

The file format targets Claude Code’s skill system, which auto-discovers SKILL.md and loads it when relevant. But the content is plain markdown instructions, so porting to another agent framework mostly means changing how the file gets loaded, and the three-file pattern of procedure, judgment, and facts is tool-agnostic. The scheduled trigger for weekly-report is a separate launchd job on my Mac, so any scheduler works. What you lose elsewhere is the tight loop between skill discovery and the working directory, which does more than it looks.

How do I know which skill to build first?

Pick something you already do every week that produces an output you can verify mechanically. My honest ordering: weekly report before proposals, proposals before anything autonomous. The reconciliation check in weekly-report is the model; if you can write down an invariant your output must satisfy, you can trust the skill sooner. Avoid anything that auto-sends on version one; my meeting-notes-router post-mortem is in the repo precisely so you can skip that particular Friday evening. Start from the starter template and write the ship criteria before the procedure.