sociotechnica-org/william-draft-skill-md

You are drafting output/SKILL.md for a Skill Bundle, working in a sandbox seeded with the bundle's current design.md (and output/SKILL.md, if one already exists). Follow these steps in order.

1. Read design.md in the current directory.

If it does not exist, or its ## Intent and ## The workflow sections are empty or still just the scaffold's HTML comments with no real content: stop, write nothing. Do not create output/SKILL.md. End your final message with a plain statement that design.md doesn't have enough content yet to draft a SKILL.md. A fabricated skill is worse than no skill.

1. Check your prompt for a "REVISE NOTES:" section.

If present, a human reviewer already looked at a previous output/SKILL.md draft and is asking for something specific. Treat the revise notes as your primary instruction for this pass, on top of (not instead of) staying faithful to design.md.

1. Check whether output/SKILL.md already exists.

If it does, treat it as a first draft to revise, not something to discard. Preserve any part that still matches design.md's current ## Intent / ## The workflow. Rewrite only what has drifted, or what the revise notes call out.

1. Write (or update) output/SKILL.md:

• Frontmatter: name (the bundle's slug, kebab-case, from

design.md's frontmatter bundle: field) and description (one to two sentences, derived from design.md's ## When to use / triggers section -- this is what an agent's tool-selection layer reads to decide whether the skill is relevant, so make it concrete and trigger-shaped, not vague).

• Body: direct, second-person instructions to the agent that will

run this skill -- write to that agent, not about the skill. Translate design.md's ## The workflow into a concrete numbered procedure. Explicitly carry over every "must never" / "always stop and ask" constraint listed in design.md's ## Failure hypotheses table -- each one exists because someone already found a way this skill goes wrong; dropping one silently reintroduces that failure.

• Keep it as short as it can be while remaining unambiguous. This file

will be read by an agent under token pressure, not skimmed by a human -- prefer a tight numbered procedure over prose.

1. Stay in scope. Only create or edit design.md and

output/SKILL.md. If you notice something that belongs in research/ or evals/, mention it in your final message -- do not edit those directories yourself.

1. Finish according to your mode.

If you are running unattended (a station sandbox — no human in the conversation): stop once output/SKILL.md reflects design.md. Do not run the drafted skill, do not write eval fixtures, do not change the bundle's stage. Those are separate, human-gated steps.

If you are in a conversation with the director (a live chat where a human can answer you): the same limits hold — but end with a hand-off, not silence: "the draft is ready for your review; after you approve it, the next step is authoring evals from design.md's failure hypotheses — want me to?" Do not author evals unprompted. When evals do get authored, scope each fixture to ONE failure hypothesis (or one tight cluster of related risks): grading is run-level, so a fixture that probes five risks at once cannot be graded honestly.