musterd-io
@musterd-io Organization
Public Skills
comms
by musterd-io
How a team speaks in public, and the evidence every public word rests on — messaging, launch narrative, release notes, press, public docs and READMEs, UI-copy specs, positioning and GTM proposals, user research synthesis, charts, pitch decks, investor and accelerator writing. Use for any writing that leaves the repo, any figure that carries a number, any claim about users or the market, and any UI-copy spec handed to the designer. Enforces the brand voice, the canonical glossary and one evidence gate; per-craft procedures live in references/.
security-portable
by musterd-io
The security role's playbook for threat modeling, security review, authorized testing, validating and rating findings, handling secrets, fixing vulnerabilities, and reviewing dependencies and releases. Use when a team asks for security evidence or a security decision.
observer
by musterd-io
The observer role — a read-only member who watches team state (roster, board, goals, reports, the event stream) and turns it into digests and dashboards for a named reader. It holds no lanes and sends no messages. Use when you hold the observer role, or when asked to summarize how a team's work is going without taking part in it.
planner
by musterd-io
The planner role — the member who turns a pitched idea into work a team of agents and humans can build. Ask a few questions that change the plan, post one plan the team can accept in a minute, then declare the goal, open every lane at once and route each to the right member. Use when you hold the planner role and someone pitches an idea, or when asked to plan work for the team.
designer
by musterd-io
The designer role — the member who owns what people see (product UI, live and real-time views, the marketing site, command-line output, design files) and judges every visual change before it ships. Use when designing or changing any surface a person sees, writing a spec or tokens for an implementer, capturing and checking a UI, reviewing someone else's UI for acceptance, or checking accessibility, motion or the performance budget of a page.
steward
by musterd-io
The steward role — the member who keeps the team's declared record honest against what actually shipped. That means the roadmap, decision statuses and documentation prose, checked against merged work and code, corrected in small draft changes with evidence on both sides. Use when you hold the steward role, when reconciling a roadmap or decision status with what shipped, or when a document may have drifted from the code.
courier
by musterd-io
The courier role — the member who moves team material between the team's machines and networks (files, artifacts, datasets) when git and the sync surface are the wrong carrier, and refuses what should not move. Use when you hold the courier role and a teammate asks for something carried, or when you need something moved and must find who can do it.
security
by musterd-io
The security role — the member who owns the team's application-security evidence (threat models, authorized scans, validated findings, private disclosure, the smallest defensible fix, and honest posture claims). Use when threat-modeling a system or a change, reviewing code or a workflow for security, running or reading a scanner, judging whether a finding is real and how severe, handling a leaked secret, reviewing a new dependency or the release pipeline, or writing anything public about security.
building-a-role-skill
by musterd-io
How to build or rebuild the skill a musterd role carries, by one measured method — read the charter and sources, research the craft, survey upstream skills under a licence check, write a lean core with references, evaluate with and without the skill graded blind, fix and re-run, and have a holder of the role accept it. Use when creating a custom role's skill, rebuilding an existing one, or deciding whether a role's skill is good enough to ship.
platform
by musterd-io
The platform role — the member who touches running infrastructure (service lifecycle, restarts, refreshes, deploys, shared checkouts, migrations), supervises the automated actors that touch it, and is who the team routes infrastructure trouble to. Use for diagnosing an outage or a slow or wedged service, restarting or refreshing a shared service, deploying, running or reviewing a migration, supervising automation, designing health checks, or verifying a fix is live.
<role>
by musterd-io
<What the member holding this role does, and when to use this skill. One or two sentences; name the kinds of work it covers so a harness knows when to load it.>
claims-ledger
by musterd-io
When a claim someone put on the record turns out to be wrong, the correction mints one entry — who claimed it, who caught it, through which channel, how long it stood, what it cost. Minted by the corrector riding an act they are already performing, never by a sweep; no bare rates, ever; and self-correction scores best. Use when a team keeps being confidently wrong, when you want to know whether review catches anything, or before building any "quality" metric over people.
capture-rough-explore-once
by musterd-io
How to take a half-formed idea from somebody and not ruin it — capture the raw text verbatim with deterministic cleanup only, then one explorer at a time asking one decision-blocking question that only the submitter may answer, ending in one exhaustive brief that becomes an ordinary unowned work item. Ships a checker that refuses a seed which arrived pre-judged. Use when building an intake path, or when good ideas keep arriving and dying.
controls-in-force
by musterd-io
Every guard you believe is protecting you carries the date someone last watched it work, whether it has ever actually caught anything, and an honest answer to "would it have caught the incident that motivated it?" — with a hundred-line checker that fails the build when the evidence goes stale. Use when adopting a guard you did not write, when a gate has been green a suspiciously long time, or when someone cites a control as satisfied.
docs-that-catch-drift
by musterd-io
Docs go stale for four specific reasons, and each has a structural fix — one doc one job, one fact one home, and "checker, not generator" — enforce the structure where it is mechanical and refuse to produce the prose where it is judgement. Ships a drift-checker for documented file trees with deliberately no --fix. Use when adopting docs conventions, when a doc has accumulated strikethroughs, or before writing a tool that generates documentation.
skill-home-and-provenance
by musterd-io
Where a reviewed skill lives when more than one agent harness has to read it, and what you owe an upstream you adapted. Use when adding a skill to a repo, when the same guidance has started to exist in two places, or when vendoring skill material from someone else's repository.
hooks-that-reach-the-model
by musterd-io
A hook that runs and a hook whose output the model actually sees are different facts, and most harnesses only tell you the first. The per-harness reachability table with a falsifier per row, the house style that keeps a hook from breaking someone's turn, and a canary that measures your own harness instead of trusting a table. Use when wiring any agent-harness hook, when an injected reminder is being ignored, or when a hook "works" and nothing changes.
definition-of-done
by musterd-io
What "done" has to mean before anyone says it — docs, traces and an eval as peers of tests, landed verified against the trunk rather than assumed, and a second party claiming it back. Use when finishing a task, defining a team's done, or when "done" and "merged" have started to drift apart.
a-finding-is-not-a-fix-request
by musterd-io
A review finding is REQUIRED only if the spec would have demanded it before anyone opened the diff — discovery adds information, not obligation. Four categories earn a block; everything else is a note that routes to the board under the finder's name, and complying with an out-of-scope REQUIRED is the failure mode, not the polite option. Use when reviewing a change, when a review has grown the work, or when a reviewer and an author are stuck.
seat-workspace-identity
by musterd-io
Give every agent its own workspace with its own git identity, so "who wrote this commit" is answerable without asking anyone — and know the exact line where that goes wrong, because repo-local git config is shared across work trees and the last one written owns everybody's commits. Ships a checker that tells a scoped identity from a shared one. Use when running more than one agent on a repo, when commits carry the wrong author, or when setting up agent workspaces.
the-team-agreement
by musterd-io
The charter above the loop — the human is a member who sometimes wears an approver hat, not an approver who sometimes participates; relationships are stances that shift hourly, never stored autonomy levels; notification is the mechanism, not a nicety; roles are aptitude, not authority; and write work stays with whoever is accountable for it. Use before adopting an agent-coordination practice, when designing who may do what, or when a team has quietly become one person approving things.
pre-registered-watch
by musterd-io
A measurement that takes days is a pre-registered question with an owner and a death date — not a recurring sweep nobody reads. States the falsifier, the population, and what voids its own window before collection starts; cannot be renewed in place; and "nobody looked" is a recorded outcome. Use when a claim is about a rate or a recurrence, when installing a cron job or a dashboard, or when a decision rests on a snapshot of something that moves.
mast-checklist
by musterd-io
Read your own multi-agent coordination log against the failure shapes that research has catalogued — broadcast-journalling, unanswered requests, one-sided threads, silent participants — with a screen that names where to read rather than scoring you. Cites the taxonomies it draws on instead of paraphrasing them. Use after running a multi-agent setup for a while, when coordination feels busy but nothing closes, or before claiming a team is working.
emitted-is-not-published
by musterd-io
Storing a teammate's prose so their teammates can read it is the product; publishing it is a separate act with its own permission. Structural fields ship pseudonymised per release, prose bodies are omitted by default, consent is per-author and fails closed — and there is deliberately no scrubber, because regex PII-stripping over free prose gives false safety. Use before releasing a dataset, opening a corpus, or sharing anything a colleague wrote without meaning it for strangers.