Chapter 25 / 40

Skills library

A skill is a named AI workflow — a short markdown file that describes what the AI should do when called in a specific situation. brief <customer> is a skill. visit-debrief is a skill. The monthly board report is a skill. Each one is a few paragraphs of instructions plus a list of the tools the AI is allowed to call.

Thomas’s deliverable here is the infrastructure for authoring, sharing, and running skills across the team — not a fixed catalog of skills. The team grows the catalog over time, against their actual workflow, using the tools in this chapter. Some skills will be drafted during the engagement as worked examples; the rest are for Rani, Paul, Jack, and anyone who joins later to build as they go.

Status: Blocked — the infrastructure activates once the Framework Desktop is live and the Sodiwin data is flowing to the warehouse.

What a skill looks like

A skill is a markdown file with a frontmatter block — nothing more. The frontmatter names the tier it uses (speed, quality, ensemble), the tools it is allowed to call, and anyone who should approve the output before it is sent. The body is plain prose: the sequence the AI should run every time the skill is invoked.

Three properties follow from this format:

Versioned. Skills live in a git repo. Every change has an author, a timestamp, and a reason. A skill that drifts is a diff to read.
Portable. The same file runs against local models, cloud models, or through Claude.ai. The tier is the contract; the model behind it can be swapped.
Readable. A skill is prose, not code. Rani, Paul, or Jack can read any skill and know what it does — and can edit one without asking Thomas.

How the team invokes a skill

Three paths, same backing files:

Terminal. A short command from the user’s laptop — brief acme-bistro, visit-debrief, followup acme-bistro. Useful in the middle of a workflow, with predictable arguments.
Claude.ai. The team asks in natural language and the matching skill runs through the shared MCP toolset. Useful for exploratory questions that would be awkward to type as a command.
Schedule. The system runs the skill on a timer — morning briefs at 07:00, churn alerts overnight, monthly board report on the first of the month.

One skill is authored once and made available through all three surfaces. The team does not have to decide which mode to build for.

How skills are shared

Skills sit in a git repo the whole team can read and contribute to. A skill proposed by Rani lands as a pull request; Paul or Jack can comment, approve, and merge. The merged skill becomes available to everyone on the next sync.

The same repo holds the tool catalog (what the AI can call — see chapter What the AI can access) and the escalation rules (when a skill is allowed to use the cloud tier). Everything the AI does at Sodimo is one repo away from being reviewed.

What gets authored during the engagement

Thomas authors a small number of skills during the engagement as worked examples, so the team has a template to copy. The set is indicative and can shift against what the team asks for in week 3 or 4:

A pre-call brief (Rani, sales) — the template for any skill that pulls a customer’s recent state into one page.
A collection-letter drafter (Paul, finance) — the template for any skill that drafts text for human approval.
A morning brief (per role) — the template for any scheduled skill that composes a daily email.
A visit debrief (Rani, field) — the template for any skill that turns rough notes into a structured record.

The point of the list is not the list. It is the four shapes — “pull state into a page”, “draft for human approval”, “compose a scheduled email”, “turn rough notes into a record”. Most of what the team will want to build in year one is a variation on one of these.

Dashboard publishing

One skill shape is worth calling out because it unlocks the team’s reporting autonomy.

A team member opens Claude Code against live data, asks for a chart or a view, reviews the result, and publishes it to Cloudflare Pages from the same session. The output is a live internal dashboard at its own URL, readable on phone or desktop, gated to the team. Rani’s idea of a per-rep “Top of Mind” view is the first example.

This is the shape that lets the team own their own reporting without waiting for anyone to build it for them. Every recurring question that deserves its own page becomes a two-minute authoring session, not a ticket.

Heuristics Thomas teaches the team, not enforces in the UI

Two principles belong in the team’s head, not in a UI gate:

Start local, escalate when needed. Most requests should be answered by the speed tier on the Framework Desktop. The quality and ensemble tiers, and cloud escalation, are for the small set of requests where the extra time and cost earn their keep. A skill that always goes to Claude for a morning brief is a skill to rewrite — not a skill to block.

Upgrade the model behind a tier, not the tier in every skill. When a better local model arrives, it replaces the old one inside the tier. Every skill tagged “speed” improves at once. The team does not rewrite skills to chase models.

Both of these are written into how the team uses the stack — the manual is where they land first; the tooling assumes them rather than enforces them.