/taste-pass

Taste Pass (reference - read inline by both propagation doors)

You are running a taste pass: loved tweaks have accrued, and this offers a victory lap that spreads proven taste to other surfaces. This file owns the whole brain - the offer gate, the scout, the selection, the handoff to `/craft:mockup`, and the pacing. Both doors (the tweak-close door and the session-start ripe line) read THIS file inline and execute it; neither invokes it via the Skill tool (a Skill-tool call ends the turn and control never returns - see `.claude/rules/skill-invocation-chain-breaks.md`; `craft-mockup.md` Step 3 is the inline-read precedent).

**Guiding rule (do not violate): bookkeeping bends to creativity, never the reverse.** The scout POINTS; the making is fully `/craft:mockup`'s; the ledger just remembers.

The offer gate

The victory-lap offer fires only when BOTH hold:

ENABLED=$(grep -m1 '^taste_pass_enabled:' "${CRAFT_PROJECT_ROOT:-.}/.craft/settings.yaml" 2>/dev/null | sed 's/^taste_pass_enabled:[[:space:]]*//')
THRESHOLD=$("${CLAUDE_PLUGIN_ROOT}/hooks/scripts/taste-pass-state.sh" effective-threshold 2>/dev/null || echo 3)
COUNT=$("${CLAUDE_PLUGIN_ROOT}/hooks/scripts/count-loved-tweaks.sh" "$THRESHOLD" 2>/dev/null || echo 0)

• `taste_pass_enabled` is not `false` (absent or true both pass - the default is on), AND
• `COUNT` >= `THRESHOLD`.

The gate passes the threshold to the counter so the count early-exits (it never needs the exact total, only "is it ripe"). If the gate does not pass, say nothing and do nothing - there is no offer.

**Same-day quiet is designed:** a tweak loved the same calendar day as the last accepted pass does not count until the next day (`created > last_asked`, strict). You just ran a pass; the loop stays quiet on purpose rather than re-offering the moves you already spread.

The offer itself is ONE ignorable line, never an AskUserQuestion - notebook conventions:

> "That's [N] loved tweaks now - want a victory lap? I'll look for other surfaces that could use the > same taste. Otherwise moving on."

The scout

On accept, find the spots that could inherit the loved taste. Default move: **screenshot the loved surface and the candidate surfaces and compare by eye** (needs a running app plus browser tooling - `craft:browser` or the chrome-devtools MCP). Rank candidates as siblings (same component family) and vibe-cousins (different surface, kindred feeling). The scout POINTS, never prescribes - it names where the taste could spread and one seed move for each, and hands the making to `/craft:mockup` unchanged.

Find generously. The taste filter is downstream: the user prunes the list, then the real mockup render decides. Divergence is a feature to spread, so:

• NO tokens/locked gate on discovery - a surface that breaks the current tokens is still a candidate.
• NO `style-analyzer`, NO new agent, NO subagent - the scout is the orchestrator, vibe-driven, eyes

and taste. The alchemist lives downstream, inside mockup.

**Graceful degradation (no live app / no browser tooling):** when there is no running app or no browser channel, the scout DEGRADES - it points from component and structure by reading the code, and says so plainly:

> "I can't see it live, so I'm pointing from the code - boot the app if you want a visual compare."

Accepting the victory lap is NEVER a dead end. Pointing from code is a smaller move, not a failure.

Selection

Present the ranked list and take the pick **conversationally** - any, some, or all. This is plain text, NOT an AskUserQuestion (a widget between the user and their taste kills the flow). "The first two", "all of them", "just the profile cards" are all valid. The user prunes; you carry forward only winners.

Handoff - one notebook todo per winner, one shared family

Each winner becomes ONE notebook todo, all sharing a family tag (e.g. `taste-<origin-slug>`), so the family travels together. Create the todo skeleton, then append the dossier body to the returned path:

TODO_PATH=$("${CLAUDE_PLUGIN_ROOT}/hooks/scripts/notebook-capture.sh" todo "<target surface> - spread <origin>'s taste" \
  --tags="<family>" --source='"[[<origin-tweak>]]"')

`--source` is written verbatim, so pass the origin as a QUOTED wikilink - `"[[<origin-tweak>]]"` - which is valid YAML and renders as a two-way link for any wiki-aware reader, while still grepping clean for craft's own tooling. Then append the A6 dossier body to `$TODO_PATH` with Write, under these headings:

## Target
[the surface this todo targets - where the taste should land]

## Taste-print
[the felt principle / emotional target / move family carried from the origin tweak]

## Fit read
[how the move fits this neighborhood - siblings, conventions, what adapts]

## Divergences
[where this surface may want to diverge from the seed - noted, never forced]

## Run
Hand to /craft:mockup when ready - fully open; the seed is a starting point, not a spec.

The dossier is prose, not schema - its only consumer is `/craft:mockup`'s overridable Brief, which wants rich human-readable context. Do NOT add structured frontmatter for taste-print/fit/divergences.

**Lineage:** the todo's `source: "[[<origin-tweak>]]"` carries the origin forward. When a winner is later handed to `/craft:mockup`, pass that origin into the mockup launch so the mockup record stamps it at creation (see `mockup-inline.md`) - that is how a button that snowballs into a whole page still traces home.

The march

After selection, offer to start immediately - this is NOT deferral:

> "Start with the first one in `/craft:mockup`? Or 'trust you, go' and I'll march the whole family."

• **"start with the first"** -> hand winner 1 to `/craft:mockup`, fully open, one at a time.
• **"trust you, go"** -> march the family tag in order, each its own open mockup session.

Live progress is an ephemeral Task rail; the todos are the durable backing. Do NOT create the mockups here - each winner goes to `/craft