Indie developers don't have departments. Planning, implementation, QA, release, marketing — it's all you.

But Claude Code has Skills: drop a procedure file (SKILL.md) in a folder and it becomes a /command. I used that to turn my development environment into a one-person software company — 11 general-purpose skills plus a set of project-specific ones, running for several months now.

This post is the org chart, plus the design rules that only became visible after operating it for a while: name collisions, a single source of truth for real numbers, and least privilege.

What you'll learn

  • The actual structure of 11 Skills treated as "departments"
  • The two-layer setup (general vs. project-specific) and the name-collision trap
  • The "single source of truth for facts" pattern — no hard-coded numbers in skills
  • Where to start if you have zero skills today

The short version: a Skill is a procedure manual, not a smart subordinate

What I understood only after months of use:

  • A Skill is really a procedure manual for a specific situation. The AI doesn't get smarter; it gets consistent — the same quality of steps every time
  • Value comes from recurring, routine work (release, bug triage, article drafting). Skill-ifying a one-off task never pays back
  • And exactly like a company, the more departments you have, the more the rules matter — naming, permissions, how data is held. The design rules in the second half turned out to be the real asset

The org chart: 11 general-purpose Skills

These live in ~/.claude/skills/ (user level — available in every project). Think of them as head office.

Department Skill Job
General affairs (setup) /setup-project Turn a project into a "company" in one command: generate CLAUDE.md, facts file, hooks, CI scaffold
Planning /spec Interview me and write a specification
Engineering /scaffold Generate feature scaffolding that matches the existing architecture
QA /diagnose /gen-tests Systematic root-cause analysis / generate tests mimicking existing test style
Quality & i18n /ui-audit /i18n /compat-check UI review / sync translation keys / assess whether a DB or API change breaks the version currently shipped
Release /release Version bump, collect diffs, release notes, update records — all at once
Marketing /promo /sns ASO/SEO proposals / social media copy
HR /create-skill The skill that makes skills. Finds routine work worth automating, audits existing skills for rot

The interesting one is HR (/create-skill). Once "this is the third time I've done this — make it a skill" and "has this skill gone stale since the implementation changed?" are themselves skills, the company starts to grow and repair itself.

Two layers: head office (general) and the shop floor (project-specific)

Skills live in two places:

  • User level ~/.claude/skills/ — general procedures used everywhere (the 11 above)
  • Project level .claude/skills/ — procedures that need project-specific knowledge

This site (AppVillage) has a dedicated /new-article skill for drafting posts. Morphica, my AI photo-style app, has 11 project skills of its own: /debug, /release-prep, /db-migration-check, and so on. The general /diagnose and Morphica's /debug do the same job, but the project one carries that project's error taxonomy and file map — so the rule is project skill wins when the purpose overlaps.

The trap: same name, user level wins

Here's the behavior that bites in practice: a user-level skill with the same name takes precedence and silently hides the project-level one. Accidentally create a general skill called debug, and Morphica's /debug becomes unreachable.

My fix is a reserved-name registry — a list of every project skill name plus the names Claude Code itself and plugins use, with an explicit "never name a general skill any of these." /create-skill appends to the registry automatically whenever it creates a project skill. In company terms, it's the naming standard.

Single source of truth: never write numbers into a skill

The other pillar is the facts file (docs/project_facts.md).

Revenue, downloads, URLs, campaign IDs — write these "real numbers" directly into skills or docs and a stale copy survives somewhere after every update. So:

  • All facts live in one file, and every skill reads from it (no memorizing, no hard-coding)
  • Only /release has write access. Every other skill is read-only
  • In a project with no facts file, skills add a one-line "consider running /setup-project" and continue by reading the code — they never block

Separating read and write is the same idea as an accounting department. With a single update path for numbers, marketing copy and social posts are always built from current facts.

Least privilege: don't hand Write to a skill that only reads

Each skill declares the tools it may use via allowed-tools. Review-and-report skills like UI audit or bug triage get no file-write permission.

This is less about runaway AI and more about freezing each skill's role at the design level. The diagnostics department doesn't start patching code on its own — I read the report and decide what to request. Like a separation of duties, clearer boundaries make each piece of work more predictable.

Version-control the whole company

~/.claude/ itself is a private git repo. Every change to a skill or a rule gets committed immediately.

Skills aren't written once; you keep correcting the procedure as you use them. The change history becomes the company's improvement log, and moving to a new machine is one clone.

A day in the life — including this article

Starting a new project looks like this:

/setup-project   → CLAUDE.md, facts file, hooks in one go   (incorporate the company)
/spec            → spec out the feature                      (planning meeting)
/scaffold        → scaffolding that fits the existing code   (start engineering)
/gen-tests       → tests                                     (QA)
/release         → release notes, records                    (ship)
/promo /sns      → announcement copy                         (marketing)

And the Japanese original of this very article was drafted via AppVillage's project skill /new-article. A company-profile post that comes out of the company's own workflow — slightly recursive, but it's a real example of routine work being skill-ified and the loop actually running.

Where to start: your first skill

You don't need 11. The way to grow it:

  1. Pick one task you explain the same way every time — release or bug triage are safe bets
  2. Write the steps as bullets in SKILL.md — five lines is fine. Grow it by using it
  3. Review after three uses — whatever you corrected in conversation goes back into the skill text
  4. Add rules once it multiplies — naming, permissions, data references. That's when it becomes a company

Takeaways

  • Claude Code Skills let an indie developer build "departments." The substance is manuals for recurring work
  • Structure is 11 general skills (head office) + project skills (shop floor), two layers. Same-name collisions resolve to user level, so manage reserved names
  • The operating pillars are a single source of truth for facts (only /release writes) and least privilege (no Write for read-only skills)
  • Keep ~/.claude/ in git — the history becomes an asset, and the company moves with you

Doing everything alone is what indie development is. Thinking everything through from scratch every time isn't. Start with one department.

Part of a series on AI-driven indie development from Japan. Japanese original: Claude Codeを「ひとり開発会社」にする. Related in English: I Built and Submitted an iOS App in One Day With Claude Code — the templated process described there is this company at work. More: Village Gazette in English.