/craft-style

name: craft-style
description: Builds a personal output style on hush's frame — the user's voice on the surface, hush's silence-and-structure mechanics copied verbatim underneath. Manages its own creations: lists them alongside stock Hush and edits them. A mechanical verifier confirms every invariant survived. Activation is hush:pick-style's job — it owns the swap that makes a style bind. Only the stock Hush style is benchmarked — crafted styles are unmeasured.
when_to_use: Trigger when the user wants a personal or custom output style built on hush, wants to edit a crafted style, says "make me a hush style", "hush but robotic", "craft a style", "custom output style", or invokes /hush:craft-style.
argument-hint: "[voice description]"
allowed-tools: Read, Write, Edit, Glob, Bash, PowerShell, AskUserQuestion

hush:craft-style

Builds and manages output styles the user owns: their voice, hush's machinery. The mechanics that make hush cheap — silence between tool calls, one structured final message, the hard caps — are copied byte for byte. The voice around them is rewritten to the user's taste.

1. Take stock

Crafted styles carry the sentence `Unmeasured variant of Hush.` in their frontmatter description — that is how this skill recognizes its own work. `node "${CLAUDE_PLUGIN_ROOT}/scripts/list-styles.js"` walks every styles folder and marks them `source: "crafted"`, each with its name and path. Stock is the only other entry on that shelf; hush ships no other voice.

Also read the frontmatter of `${CLAUDE_PLUGIN_ROOT}/output-styles/hush.md` and note whether the `force-for-plugin: true` line is present.

Then route:

• **No crafted styles found** → go to step 2 and create one.
• **Crafted styles found** → ask the user (AskUserQuestion) what to do, listing every crafted style by name and destination alongside `Hush (stock, benchmarked)`: create a new style, or edit one of the listed. A request to switch goes to `hush:pick-style`, which owns the whole shelf.
• **That same JSON reports `restoredOverTakeover: true`** → a plugin update wrote over the style that was active. Say so and offer step 5 before anything else.

2. Gather three inputs

From the invocation arguments, or by asking:

• **Voice** — how the style should sound, in the user's words ("robotic", "pirate", "extremely dry British"). When editing, gather what should change instead.
• **Name** — a short style name, and not `Hush`, which stock answers to; derive one from the voice if the user doesn't care.
• **Destination** — `~/.claude/output-styles/` (every project) or `<project>/.claude/output-styles/` (this project only). Default to user-level.

The filename is the kebab-cased name plus `.md`. If that file already exists and wasn't picked for editing in step 1, show its path and ask before overwriting.

3. Assemble the style

Read `${CLAUDE_PLUGIN_ROOT}/output-styles/hush.md` — everything below refers to its sections.

Frontmatter:

---
name: <Name>
description: <one line in the user's voice>. Unmeasured variant of Hush.
keep-coding-instructions: true
---

The description must end with the exact sentence `Unmeasured variant of Hush.` — step 1 depends on it, and step 4 refuses a style without it. `force-for-plugin` stays out — activation adds it.

**Write the whole file in the voice.** Every section, top to bottom: the silence rules, the caps, the what-stays-whole rules, the pre-send pass. When the voice needs an extra push — a distant register, a weak first draft — open the file with one line above the opening rule: `Core persona: <the voice in one sentence>.` Write that sentence as the speaking behavior itself, its register and signature markers named — "speaks every report in full, heavy pirate dialect, peppered with 'Arrr!'" — because a described behavior gets enacted where a role name alone sits inert. The reply comes out in the register the file is written in, so the sections that stay in stock's plain English are the ones that decide how the reply sounds. This single choice is the difference between a style that speaks in the voice and one that only names it.

What has to come through the rewrite intact, everywhere in the file:

• every number, at its exact value
• every `inline code` span and every `**bold**` span, character for character
• every listed item, one for one
• one paragraph for each paragraph — reword a rule, never drop it
• at least 60% of stock's word count in each section step 4 checks — tighten, never gut
• the first line above the first heading, and every `## ` heading text
• verbatim: the paragraph about the `[hush ...]` notes and hook reminders

Step 4 checks the numbers, the spans, the listed-item counts, the paragraph counts and the word floor inside `Quiet while you work`, `The note at the end`, `Shape` and `What stays whole` — and, file-wide, the frontmatter, the opening rule, every `## ` heading, the core phrases and the verbatim telemetry paragraph. The prose around those anchors is yours to get right.

`Shape` is guarded like the rest, so the file-link form, the backtick rule, the one-bold-mark rule and the table and numbered-list rules all have to reach the rewrite. A voice that drops the link form costs the reader the one thing the answer test showed hush winning on.

Then three things, in this order:

1. **Put the redo line in the pre-send pass at the file's end.** Tell the model to read the finished message back and put it in the voice before sending, naming the two or three substitutions the voice turns on — `be` for is and are, `ye` for you, `-in'` for every -ing. A voice given as a step to carry out at write time reaches the reply; a voice merely described sits in the file. Anchor every substitution to something each reply contains: a function word anchors itself, and a particle or interjection anchors to a position — the first line and the last line each end in `nya~`. Write the position, not "where it falls natural" — a technical answer offers no natural place