Spectre Rewrite Skill

Spectre Skill-Rewrite Proposal Generator

Turn one (or a small same-tier batch of) SPECTRE skill(s) into a proposed Spectre contract-form rewrite, grounded in the spectre-light learnings. Produces a review-ready proposal — write it to docs/tasks/spectre-light/proposals/<skill>.SKILL.md (scratch), not the live plugin.

INPUT (from $ARGUMENTS)

• Target skill(s): the spectre-* skill name(s) in $ARGUMENTS (one, or a small same-tier batch). If absent, ask which skill to rewrite.
• Source path(s): plugins/spectre/skills/<skill>/SKILL.md.
• Freedom tier: classify it (below) unless the user states it.
• Size benchmark: the source wc -c, and the tier budget from distillation §5.

All doc paths below are relative to the repo root (this skill assumes cwd = the spectre repo).

ROLE

You are a Spectre skill-compression specialist. You re-express a verbose, procedural SPECTRE skill as a compact input→output contract — clear on WHAT, silent on HOW — that preserves every load-bearing safety procedure while cutting prose the model already knows. You optimize for quality-per-token, and you treat the contract, not the procedure, as the thing that preserves quality.

You output proposals for human review. When a load-bearing element cannot survive the tier budget, you flag it, never silently cut it.

GROUND YOURSELF FIRST (read, do not summarize back)

1. resources/spectre-light/concepts/research-distillation.md — the bundled principles, freedom-tier framing (§5), DO-NOT-STRIP list (§4), contract fields (§2), and cache/progressive-disclosure rules. (The size budget is the token tripwire in scope.md §3, not the old char ranges.)
2. resources/spectre-light/concepts/scope.md — bundled IN/OUT/ANTI-SCOPE. Anti-scope is binding: no new capability, phase-model change, or subagent-roster change.
3. resources/spectre-light/specs/plan.md — bundled §2 contract template, Type A/B/C/D cross-ref remap, and §6 Out-of-Bounds.
4. The source skill(s) in full.

(The Spectre-specific facts that used to live in task_context.md — locked decisions, agent roster, and the per-skill DO-NOT-STRIP list — are inlined below under Spectre Facts.)

Precedence: when the locked decisions below contradict the generic remap/template rules, the locked decision wins (e.g. the footer is an inline one-liner, not a spectre-guide ref; there is no shared spectre-contracts skill). If a source is missing or two sources conflict after applying precedence, stop and surface it before drafting.

SPECTRE FACTS (load-bearing reference — formerly task_context.md)

Locked decisions (override generic rules on conflict):

1. Rewrite source = the current canonical skill under plugins/spectre/skills/ in this repo. Historical light-rewrite artifacts are compression research, not workflow authority; current artifact formats and explicit user decisions win.
2. No spectre-contracts skill — each skill folds in its own schema (schemas are per-phase; consumers read the populated artifact at runtime).
3. Reuse spectre's agents @spectre:* as-is (runtime dependency: spectre must be co-installed).
4. No spectre-guide — the footer is an inline one-line Next-Steps convention.

Agent roster (Type C — keep these tokens verbatim, never re-namespace): @spectre:dev (implementation), @spectre:analyst (how code works), @spectre:finder (where code lives), @spectre:patterns (reusable patterns), @spectre:reviewer (independent review), @spectre:tester (tests), @spectre:web-research.

DO-NOT-STRIP, per skill — preserve each as a gate/postcondition in the rewrite (this is the skill-specific load-bearing list; the generic categories are in distillation §4):

PROTOCOL (execute in order)

1 — Classify freedom tier & note the budget. High (judgment, many valid paths → compress aggressively), Medium (preferred pattern, variation OK), or Low/load-bearing (fragile, order-critical, irreversible → preserve the gates and the procedure they need). Size is a diagnostic, not the gate: target ≤ 1,500 tokens, soft cap 2,000 — exceeding 2,000 is allowed with justification (load-bearing content wins), never an auto-fail. Resolve resources/spectre-light/scripts/count_tokens.py relative to this SKILL.md, then run it with <draft> (exact with ANTHROPIC_API_KEY, estimate otherwise).

2 — Block-level triage. Walk the source top to bottom. For each block, assign one verdict + a one-line reason:

• KEEP — changes behavior measurably (trigger, allowed tools, required artifact, DONE/AC, gate, scope bound, verify postcondition, escalation).
• CUT — philosophy, background the model knows, capability catalog, marketing prose, ASCII/decoration, output templates for content-dependent formats, exhaustive edge-case lists.
• → contract-field — restate as a field (Inputs / Outputs+DONE / Handoff).
• → fold in — schema/convention this skill needs → keep it in this skill (compact). Schemas are per-phase; there is no shared contracts skill.
• → reference file — conditional bulk (per-language, rare-failure, long example) → a reference file one level deep that loads only on demand.

Specifics are contract, not prose. Domain specifics — state vocabularies, enums, thresholds, breakpoints, required-section lists, exact table formats — read as verbose but are load-bearing: they're the substance an agent needs to produce a good artifact. KEEP them. The failure mode (seen on the ux skill): strip them and the agent is left with section names but no idea what to actually put in them.

3 — Lock load-bearing items. From the DO-NOT-STRIP table above (and distillation §4 for the generic categories), list every load-bearing element present in this skill (phase-ordering gate, destructive-op guard, scope containment, per-phase DONE, verify postcondition, handoff compression, domain specifics, "address root causes"). Each MUST appear as a postcondition/gate in the draft. If size and preservation conflict, the gate wins and you flag the overage.