Claude Code Skills Ecosystem
13 custom skills and 4 governance agents that turn a personal vault into an AI-native consulting runtime.
Context
AI is only useful to a consultant if the prompts don't walk out of the door when the consultant does. The first year of daily Claude Code use taught me that the output of a great conversation is a transient artefact. The leverage is in codifying the conversation as a skill the next engagement reuses.
I spent six months turning that observation into a working system: 13 custom Claude Code skills, 4 agents, a shared knowledge schema, and enough governance that the whole thing keeps its integrity as it grows.
Problem
Consulting firms talk about knowledge management the way teenagers talk about college. Everyone agrees it matters. Nobody actually does it.
The practical failures are always the same:
- Knowledge lives in individual heads or scattered prompts.
- Templates drift; yesterday's proposal doesn't quite match today's.
- "Methodology" is a Google Drive folder full of decks.
- AI usage is ad-hoc: each consultant running their own ChatGPT session with their own context and their own invented terminology.
I wanted a system where the act of doing the work produced the reusable asset, not the other way round.
Shape of the solution
Three layers.
flowchart LR V[(Personal vault)] V --> S1[Skills] V --> S2[Agents] V --> S3[Workflows] S1 --> O[Engagement output] S2 --> V S3 --> S1 S3 --> S2
Skills encapsulate a repeatable analytical operation (code review, metadata review, permission analysis, UPN process-mapping, meeting synthesis). Each has a declared input contract, a workflow markdown, and a references folder with vault-linked rules.
Agents enforce the knowledge-management invariants: schema validation, broken-link detection, connection-review, and note processing. They read the vault and keep it coherent.
Workflows chain skills and agents together for bigger jobs. The Salesforce Org Assessment pipeline is one such workflow.
Key design decisions
1. The vault is the source of truth, not a side-effect. Every skill reads its rules from vault reference notes under a unified schema. If I want to update the way metadata descriptions are scored, I edit one markdown note and every skill picks up the change on next run. No forked rule files, no rebuild, no code deployment.
2. Skills declare inputs, workflows, and references as separate concerns.
SKILL.md is a thin entry point (triggers, routing). workflows/*.md hold the execution steps a human or agent can follow. references/*.md hold the underlying rules and rubrics. Skills stay small and replaceable; references accumulate.
3. Agents are read-only or narrowly-scoped.
connection-reviewer and link-checker are read-only auditors. note-processor and schema-validator can write, but only to the single note they're invoked against. There is no agent that rewrites the vault at large. Scope is a safety feature.
4. Everything has a runbook the user can follow manually. Every skill and agent can be invoked by Claude Code. But every skill and agent is also documented such that a colleague without Claude Code access can follow the same logic by hand. The automation is a leverage multiplier, not the only path.
5. Knowledge governance is enforced by tooling, not politeness.
The schema-validator fails a note if type, status, source, or created is missing. The connection-reviewer finds orphan notes and broken wikilinks. The governance rules live in a unified knowledge schema note that gets read by both humans and agents. The vault stays coherent because it's hard to be incoherent on purpose.
Proof
A single invocation of salesforce-code-review against a client's Apex project produces a scored findings report in 30 minutes that used to take 18–31 hours of senior-consultant time. The rules are:
Thirteen skills cover the recurring shapes of my work:
| Skill | Triggers | What it does |
|---|---|---|
salesforce-org-orientation | new client org | harvest → profile → dual-audience summary |
salesforce-code-review | Apex/LWC/Aura review | 34 YAML rules, scored findings |
salesforce-metadata-review | tech debt triage | 30 YAML rules |
salesforce-permission-analysis | similarity matrix export | JTBD-derived target state |
salesforce-mdd | field descriptions | 3 workflows: evaluate, generate, enrich |
elements-field-analysis | Elements export | complexity + deprecation risk |
upn-writer | transcripts/docs | Universal Process Notation diagrams |
jtbd-extractor | research data | opportunity scoring |
meeting-analysis | Fireflies transcripts | SCARF-framed synthesis |
executive-update-generator | weekly reporting | structured leadership updates |
slides-extended | presentations | reveal.js decks from vault |
product-brief-writer | one-page pitches | buy-in before spec work |
obsidian-pkm | vault operations | batch refactor + schema compliance |
Four agents maintain the substrate:
schema-validator: frontmatter conformancelink-checker: broken wikilinks, missing backlinksconnection-reviewer: cross-note relatedness gapsnote-processor: in-place note refactor
What I'd do with a team
The same pattern works inside a company. Take one team's recurring operations, write them as skills (with inputs, workflows, references), put the rule-set in a shared knowledge layer (vault, wiki, or database), and enforce the knowledge-schema invariants with agents.
The point is not to replace people with skills. The point is that a new team-member should never have to rebuild the analysis from scratch. They should inherit the rules, edit them where they're wrong, and produce the same quality output their predecessor did.
Documentation is the asset. Skills are how you keep the documentation honest.