01Why the skills ship generic
The 16 skills do something the moment you unzip them. xClause will red-line a contract. xSpend will classify a GL export. xRenew will scan your portfolio for renewal deadlines. But notice the word: something. xClause red-lines that contract against a sensible default playbook — a twelve-month liability cap, standard carve-outs, the positions a competent Fortune-500 buyer would hold. It does not red-line it against your playbook, because it has never seen your playbook.
That is deliberate. A skill that shipped with my employer's clause positions baked in would be useless to you. A skill that shipped with no positions at all would be useless to everyone — it would just ask you twenty questions before it could start. So every skill ships with a sensible default and a clearly-marked seam where your reality goes. Closing that seam is a copy-paste job, not a coding job. That is the whole idea: it is how a generic CPO toolkit becomes your CPO toolkit.
02The architecture — defaults you keep, overrides you add
Open any skill folder and you will find the same shape every time. There are three kinds of file, and you only ever touch one of them.
Inside a skill folder
Three kinds of file, one you touch. The skill checks the folder every time it runs — your file wins, the default fills the rest.
The recipe — SKILL.md
The instructions the model follows. You do not touch this. If you find yourself wanting to, that is a signal the skill needs a real change — tell me, do not fork it.
The floor — …-default.yaml
What the skill uses out of the box. xClause ships playbook-default.yaml; xSpend ships taxonomy-default.yaml. You do not touch this either — it is the floor, the thing that makes the skill useful for someone who has done zero setup.
The blank — …-template.yaml
A copy of the default's structure, with every field labelled and explained, waiting for your values. This is your starting point.
Your version — ….yaml
The file with no suffix. When the skill runs, it looks for this file first. If it is there, the skill uses it. If it is not, the skill falls back to the default. There is no build step, no deploy, no code — the folder is the configuration.
You only override what you want
You do not have to recreate the entire default. xClause's default playbook covers twelve clause types. If your legal team only holds strong, non-standard positions on three of them, your playbook.yaml can contain just those three. The skill merges your three on top of the default twelve — your positions win where they exist, the default fills the rest. Partial is not just allowed, it is the intended path.
03Five steps to make a skill yours
Once you have seen the pattern once, every skill in the suite works the same way. Here is the whole loop.
1
Find the template
Open the skill's folder, go into assets/, and find the file ending in -template. It is pre-labelled — every field has a comment explaining what belongs there and why.
2
Copy it, drop the suffix
Copy the template; rename the copy without -template. playbook-template.yaml becomes playbook.yaml. That filename is the signal the skill watches for — get it exactly right and everything after is automatic.
3
Fill in your reality
Replace the placeholder values with yours: your legal entity name, your clause red-lines, your approved-vendor list, your spend categories. Anything you do not have a firm view on, delete the line — the default covers it.
delete what you don't own
4
Drop it back in assets/
Save your file next to the default. Nothing to rebuild, nothing to redeploy, no pipeline to wait on. The next time the skill runs, it finds your file and uses it.
no deploy
5
Smoke-test against the fixtures
Every skill ships a fixtures/sample-inputs.md with three representative inputs. Run one with your override loaded and read the output. Does it sound like your team? Does it cite your positions? If not, the fixture just told you which line of your override to fix.
04What to customize first
You do not need to tune all 16 on day one. Most of the value sits in four files — and two of them are shared across several skills, so the leverage compounds.
1
xClause — playbook.yaml
Your clause red-lines and risk appetite. The single highest-leverage override in the suite — it changes every contract the skill ever touches.
2
xSpend — taxonomy.yaml
Your L1–L4 spend categories. Tune this once and every spend skill downstream — xMaverick, xSavings, xCash — inherits your categories.
3
xMatch — avl.csv
Your approved-vendor list. Shared with xMaverick, which treats anything not on it as candidate off-AVL spend — one file, two skills.
4
xContracts — internal-policies.md
Your policy positions, in plain prose, for the skill to flag contracts against. The quickest win in the suite — it is a text file, not a schema.
05Your afternoon plan
Here is the whole thing as an afternoon. Pick the three skills your team touches most. Copy three template files. Fill in what you actually know — and leave the rest, because the default is genuinely fine for the parts where you do not yet have a strong position. Run each skill against its fixtures and read the output with your team in the room.
By the end of the afternoon you will have a suite that argues your positions, classifies your categories, and sounds like your function. The default got you a tool. The override layer gets you your tool — and nothing about it required an engineer.
Start narrow
Resist the urge to fill in every field on day one. A playbook.yaml with three well-formed clause positions beats one with twelve half-considered ones — the skill is only as sharp as the conviction behind each line. You can always add the fourth next week; the skill picks it up the next time it runs.
"The default is the thing that makes the skill work on day one. The override layer is the thing that makes it worth keeping on day ninety." — A line I keep coming back to
