Skills Architecture¶

The author's own map of the AI skills behind this site: how they fit together, who owns what, how work passes between them, and what stays with the author. Three families share one repository:

• Wiki management (the wild-brewer plugin, run in the Wiki project): capture, intake, media, publish, restructure, rules, health, positioning and release. Private: not released.
• The ingredient suite (run in the Ingredient Studio project): the ingredient-studio router and its specialists, which do the brewing work and are released for download under Skills › Ingredients Studio, plus the ingredient-suite maintainer skill, which checks, documents and packages them and is not released.
• Culture skills (the Cultures Studio; installed at account level, so usable in either project): bottle-dregs-analysis, which plans the isolation of bugs from a bottle's dregs against the Isolation Capability Matrix, critiques the plan as the work proceeds, seeds the culture journey and finally merges the plan into it. A standalone skill, released for download under Skills › Cultures Studio.

The wiki and ingredient families never edit each other's files. They meet at two drop zones in inbox/, and the author approves, pastes and commits everything in between.

Architecture¶

The diagram is wider than the page: scroll sideways to follow it.

%%{init: {"flowchart": {"nodeSpacing": 45, "rankSpacing": 70, "padding": 12}, "themeVariables": {"fontSize": "16px"}}}%%
%% wb:fit 1.8
flowchart LR
    A(["Author"])
    subgraph IS["Ingredient Studio project"]
        R["ingredient-studio<br/>router"] --> ADV["advisory specialist<br/>sensory"]
        R --> SP["process specialists<br/>maillard, treatments"]
        ADV -. "forms, partners" .-> SP
        M["ingredient-suite<br/>maintainer"]
        SK[("skills/")]
        SU[("suite/")]
    end
    subgraph HO["Hand-over: inbox/"]
        IR[("raw/<br/>documents")]
        IREL[("releases/<br/>bundles")]
    end
    subgraph WP["Wiki project"]
        CAP["wiki-capture<br/>wiki-media"]
        INT["wiki-intake"]
        REL["wiki-release-skill"]
        PUB["wiki-publish"]
        GOV["wiki-rules, restructure,<br/>health, positioning"]
    end
    DOC[("docs/ + rules")]
    CF["Cloudflare<br/>live site"]
    subgraph CSG["Cultures Studio (account skill, either project)"]
        BD["bottle-dregs-analysis"]
        WK[("work/<br/>isolation-plans/")]
    end

    A -- "request, go" --> R
    SP -- "design .md<br/>(via designs/)" --> IR
    ADV -- "analysis page .md<br/>(via designs/analysis/)" --> IR
    M -. "checks" .-> SK
    M -. "guide sources" .-> SU
    M -- "suite:release" --> IREL
    A -- "notes, photos" --> CAP
    IR --> INT
    IREL --> REL
    CAP --> PUB
    INT --> PUB
    REL --> PUB
    PUB -- "pages" --> DOC
    GOV -- "rules, moves" --> DOC
    PUB -- "change set" --> A
    A -- "commit, push" --> CF
    A -- "bottle, micrographs,<br/>progress" --> BD
    DOC -. "matrix, procedure,<br/>journey log" .-> BD
    BD -- "plans, critiques,<br/>merge drafts" --> WK
    BD -- "journey seed,<br/>plan and outcome" --> CAP

The router runs two kinds of specialist. Process specialists (Maillard, Treatments) own preparations: designs, doses, process verdicts and batch-log blocks. The advisory specialist (Sensory) owns what an ingredient brings to a living beer, its precedent and its pairings: it runs first, frames the work, carries hazards to their owners and writes no batch-log block. In route R2 the router composes one ingredient analysis page from the sensory, chemistry and treatments sections.

Read it left to right: ideas and requests enter through the router, the capture skills or bottle-dregs-analysis; finished material crosses into the wiki only through inbox/raw/ (documents), inbox/releases/ (skill releases) or wiki-capture (journeys); only wiki-publish writes the final pages; only the author commits and pushes.

bottle-dregs-analysis reads the wiki (the matrix, the isolation procedure, the journey log) but never writes docs/: its plans are committed working files in work/, and anything bound for a journey page goes through wiki-capture.

Who owns what¶

Hand-over points¶

Roles and responsibilities¶

The author's responsibilities¶

1. Approve before work starts. The router and the maintainer propose and wait for "go"; the Opus-level wiki skills ask before continuing on a smaller model.
2. Own the shared records. Paste the blocks the skills emit, then run the checker they name.
3. Trigger the hand-overs. "send to the wiki", suite:release, "release the bundle", then suite:released once committed.
4. Review, commit and push. Every change set arrives with a commit message; nothing reaches git or the live site otherwise.
5. Keep the tools current. Reinstall the wild-brewer plugin after its source changes, and re-upload bottle-dregs-analysis as an account skill after each release; connect the repo root in each project.
6. Keep the matrix current. Set Status and Held when kit arrives or runs out; ask for a matrix review when a live plan should take the change into account.
7. Choose the session model (below) and start one job per session.
8. Empty inbox/attic/ when happy: superseded files and bundles wait there because no skill deletes.
9. Keep personal details out of anything bound for docs/ or a zip. The privacy patterns and the scrub rules catch known ones; the author is the last check.

Guardrails every skill shares¶

• The rules files are read first and win over any skill.
• git is read-only; nothing is deleted; inbox/raw/ and inbox/releases/ are never edited.
• Deterministic gates decide, not the model: wb.py check, wb.py release-verify, the intake fidelity diff, suite_check.py --full, and the privacy patterns (the suite's list is a superset of the wiki's, and the check says so if not).
• A generated page is changed only at its source; the wiki hands changes back rather than editing.

Wiki skills at a glance¶

Culture skills at a glance¶

Typical flows¶

• New bottle or plating round: wiki-capture → wiki-media → wiki-publish.
• Bottle with an isolation plan: bottle-dregs-analysis Mode 1 (plan v1) → Mode 2 as needed (critiques, plan v2 …) → Mode 3 when you proceed (wiki-capture → wiki-publish) → progress through wiki-capture, citing plan steps → Mode 2 against the journey log → Mode 4 when banked or closed (wiki-capture → wiki-publish).
• Finished write-up: drop it in inbox/raw/ → wiki-intake → wiki-publish.
• Ingredient design to the wiki: router (proposal, "go") → specialist design in designs/ → "send to the wiki" → wiki-intake → wiki-publish.
• Ingredient analysis to the wiki: sensory:1 (scope) → R2 on the brief → designs/analysis/<id>.md → "send to the wiki" → wiki-intake (a new version keeps the URL) → wiki-publish.
• Skill change: suite:change or an edit in skills/ → suite:check → suite:docs when the guide is affected. Release later.
• Skill release: suite:check --full → suite:release → wiki-release-skill (Path A) → wiki-publish → commit → suite:released.
• Guide fix only: edit suite/docs/ → suite:release --docs-only → Path A.
• Standalone skill (not in the suite, e.g. bottle-dregs-analysis): change it in skills/ with a changelog → wiki-release-skill (Path B: copy to skills-src/, scrub, zip) → wiki-publish → commit → re-upload the account skill.
• Section getting crowded: wiki-health → wiki-restructure (generated pages it touches go on the hand-back list).
• Changing how things are done: wiki-rules, then wiki-health.

Choosing the model¶

Model and effort matter most for the skills that change many pages or publish something that cannot be recalled. The table reflects the Claude line-up in September 2026.

The four Opus skills check which model is running and ask before continuing on a smaller one.

On the ingredient side the same logic applies: the router and the specialists do chemistry and safety reasoning, so run designs, critiques and debriefs on Opus 5 at high effort, and the sensory scope and profile too (research breadth and evidence grading); the ingredient-suite maintainer's checks and builds are deterministic scripts, so Sonnet 5 is enough unless a skill change itself needs chemistry judgement. bottle-dregs-analysis reads micrographs, researches the beer and weighs route trade-offs: run Modes 1 and 2 on Opus 5 at high effort; Modes 3 and 4 only transcribe from the plan and the journey, so Sonnet 5 is enough.

Hints¶

• Choose the model when you start the session. Skill frontmatter sets a model too, but it only takes effect when you type the skill as /wiki-…; when Claude picks the skill from your wording, the session model runs.
• Chains run on one model. capture → media → publish uses the session model throughout, so pick for the hardest step.
• One job per session. A fresh session for each bottle, document or restructure beats one long mixed session.
• Give it everything up front: the journey or page ID, dated notes, labelled photos, and what you want out.
• Ask for a dry run first on anything that touches many pages: "/wiki-restructure Split technical into maillard and acids topics. Dry run only: show the target tree, move table, link rewrites and rules changes, and apply nothing." wiki-rules works the same way ("impact analysis only").
• Trust the gates, not the model. wb.py check, the intake fidelity diff and the privacy patterns catch mistakes whichever model ran.

Under the bonnet: tools/wb.py¶

And suite/scripts/ (ingredient suite, not shipped)¶

Local preview on Windows: .venv\Scripts\zensical serve, then open http://localhost:8000.