---
name: sociotechnica-org/william-draft-skill-md
source: https://app.decimal.ai/s/sociotechnica-org-william-draft-skill-md@2/SKILL.md
source_sha256: a535a27e3def
---

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.

2. **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`.

3. **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.

4. **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.

5. **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.

6. **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.