wicked-garden-classify

You are classifying a prompt into a v11 work-shape archetype. Your output
drives downstream archetype routing for the rest of the session (until
the user changes scope or invokes this skill again).

Runtime

Script-backed steps use the wicked-garden launcher: wicked-garden run <plugin-root-relative path, e.g. scripts/…> [args]. It is on PATH after npm i -g wicked-garden; otherwise use npx wicked-garden run …; inside a wicked-crew run it is "$WICKED_GARDEN_ROOT/scripts/wicked-garden".
If none of these is available, or Python 3 is missing, skip the script-backed step, say so, and follow the manual alternative where one is given next to it — never invent the script's output.
Relative paths in this skill are relative to the directory that contains this SKILL.md.

Why this exists

The v11 hook auto-classifier is a regex + boolean-signal heuristic. It
works for prompts whose vocabulary matches the catalog phrase lists, but
it misses paraphrases and underuses signals. You are a better classifier
than regex. This skill is the path to use the model's full reasoning
on the classification step, then persist the result so the rest of the
session benefits without re-running classification on every turn.

Routing model (council-is-the-router)

This skill is the session router. The former wicked-signals product (a
separate text-in / intent-out classifier) was archived because intent /
work-shape classification is a native model capability — the router is just a
model reading the prompt with full tool access (every tool the seat has), which
is exactly this skill. Read it as one council member making the routing call on
the fast path.

When a routing or decision call is genuinely hard, ambiguous, or high-stakes,
escalate to the multi-model council (wicked-garden-jam → council, worker
wicked-garden-jam-council): multiple independent models deliberate, still with
garden tools for additional processing. The council is the escalation, not a
per-prompt router — convening 20 CLIs on every prompt would be absurd cost.

• Fast path (always on) — the prompt_submit hook emits <wg classify-due />,
  you classify + persist here, the parent turn steers on the persisted archetype.
• Escalation (on demand) — wicked-garden-jam council <question> --options "…".

What the catalog declares

.claude-plugin/archetypes.json defines the work-shape archetypes. Read it
once at the start of this skill. Summary table:

Archetype	Phases	Use when
triage	classify	prompt is genuinely ambiguous; ask for clarification
explore	frame → diverge → converge	open problem space, multiple paths, brainstorm
specify	elicit → structure → validate	requirements / acceptance criteria need writing
decide	brief → options → score → record	2+ viable options, need an ADR
ship	canary → ramp → full → soak	already-built change being rolled out
review	scope → assess → findings → remediate-or-accept	independent assessment of an artifact
incident	triage → investigate → mitigate → resolve → followup	live production failure
build	plan → implement → test → review	implement a feature or fix (most common)
migrate	plan → expand → backfill → cutover → contract	in-place shape change with rollback proof
modernize	discover → extract → blueprint → transform → parity → cutover	port a legacy codebase to a new stack (NOT in-place)

Procedure

1. Read the prompt

What is the user actually asking for? Restate in one sentence in your own
words. If you can't, the prompt is genuinely ambiguous → triage.

2. Pick archetype(s)

Archetypes are NOT mutually exclusive. Pick a SET. Common combinations:

• "implement schema change with backfill" → build + migrate
• "review the auth PR before deploy" → review + ship
• "should we use redis or memcached for sessions?" → decide (and
  possibly build if they want you to also implement it)

Score each match between 0.0 and 1.0. Use these calibration anchors:

• 0.9+: keyword + signal both clear, no ambiguity (e.g. "checkout is
  down 5xx spiking" → incident 1.0).
• 0.7–0.9: clear shape with one or two minor uncertainties.
• 0.5–0.7: archetype matches but the prompt is partial — agent should
  read the playbook and gracefully ask if anything was missed.
• <0.5: too weak; don't return this archetype.

If nothing scores ≥ 0.5, return triage only — that's the signal to ask
for clarification before doing work.

3. Identify signals

Boolean flags that downstream archetypes use to scale rigor. Mark TRUE
only when the prompt clearly implies it:

• blast_radius_high — change affects production traffic / many users / many systems.
• novelty_high — pattern not yet in this codebase.
• state_complexity_high — touches data shape, migrations, persistent state.
• reversibility_low — undoing is expensive (data migrations, destructive ops).
• reversibility_medium_or_low — undoing is non-trivial (config changes, breaking APIs).
• production_impact — production users / systems affected right now.
• compliance_scope — GDPR / SOC2 / HIPAA / PCI surface.
• ambiguity_high — multiple plausible reads.
• spec_ambiguity_high — success criteria are fuzzy.
• scope_unclear — boundary of work is undefined.
• multiple_viable_options — 2+ paths with no obvious winner.
• post_build — change is already implemented; this is about deployment.
• code_change — implementation work involved.
• independent_assessment_needed — someone else's work needs review.

Default any flag you didn't explicitly mark to FALSE. Do not over-tag.

4. Pick intent

Intent is coarser than archetype — used by the hook to gate directive
emission. One of:

• simple-edit — typo, comment, formatting, single-line fix. Hook stays silent.
• feature — most non-trivial work (default for build/migrate/ship).
• rigor — high stakes (compliance, security, blast_radius_high).
• research — exploratory (explore, decide).

5. Persist

Emit a JSON object with the four keys above and pipe to the persist
script. Use this exact shape — extras get dropped:

echo '{
  "intent": "feature",
  "archetypes": [
    {"name": "build", "score": 0.85, "evidence": ["implement keyword + code_change signal"]},
    {"name": "migrate", "score": 0.65, "evidence": ["schema change + state_complexity signal"]}
  ],
  "signals": {
    "code_change": true,
    "state_complexity_high": true,
    "reversibility_low": true
  }
}' | wicked-garden run \
  scripts/classify/persist.py

The script normalises and writes to SessionState. Confirm the response
shows "ok": true, then return control.

6. Persist and return

You are a worker (metadata.role: worker) — your job is to classify, persist, and
return, not to run the work. Do not start executing the playbook inside this unit; the
persisted archetype is what the parent turn resumes on (the prompt_submit
hook's Tier-1 path re-emits the steered <wg archetype=… /> on the next turn
from what you wrote to SessionState). The top archetype's playbook is
skills/archetype/refs/{name}.md. Do not re-run classification mid-session
unless the user explicitly changes scope.

When to skip this skill

• The prompt is a continuation token ("yes", "do it", "lgtm"). The hook
  already short-circuits these.
• The user typed wicked-garden-archetype <name> directly — they
  already classified.
• SessionState already has classified_at set for this session and the
  prompt fits the existing classification. Re-classifying on every turn
  is exactly the cost we're trying to avoid.

Failure modes

• Persist script fails: return the JSON to the user as text and ask
  them how to proceed. Do not invent a workflow.
• Catalog file unreadable: return triage with an explanation. The
  archetype machinery will surface the read error separately.
• Model can't decide between 3+ archetypes: return triage with a note.
  triage's job is to ask. Don't pick at random.