speclisted

# swarm:spec — write down how a capability actually behaves > Read the `swarm:orchestrate` skill first for the fan-out mechanics (team creation, briefs, blinded verification, monitoring). This skill is the **spec mode**: reverse-engineer a source-of-truth description of how the real code behaves, **document the visual/flow shape with mock-ups when there is a UI**, then validate it against independent agents who describe the same capability blind and against the code's actual behavior. You are specifying: **$ARGUMENTS** **Why this exists:** a good spec is how other agents and people working on the same surface avoid mistakes — inventing flags, UX, or error handling the code does not (or must not) support. The deliverable is a plain-language description of *how the capability behaves*, not a task list for a change. This is a **behavioral spec, not a technical one.** It says what the thing does and how it should behave from the user's intent. It does not prescribe how to implement or code it, and it does not use requirement-contract grammar (no SHALL/SHOULD/MAY, no Given/When/Then scenario blocks). Write it the way a sharp engineer describes a feature to a teammate: the intent, how it behaves today, the sharp cases, and what must not change. ## spec vs plan — don't collapse them | | `/swarm:plan` | `/swarm:spec` (this skill) | |---|---|---| | Question | What **delta** do we build next? | How does this capability **behave today**? | | Shape | proposal + tasks + mock-ups | i