skills/synthesize/SKILL.md
Use when distilling the through-line gist of one or more sources — the spine, argument, tension, or recurring frame running through a set of documents, notes, research, or transcripts, OR across the ideas within a single rich piece — into a few concise paragraphs. Triggers: "synthesize", "what's the through-line/gist", "extract the insight", "pull these together". Not for faithful summary or condensation that covers what a source says, nor for comparisons or catalogs where enumeration is the deliverable.
npx skillsauth add ahgraber/skills synthesizeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Distill the through-line of one or more sources — a set of documents, or the ideas within a single rich piece — into a short, spine-led gist: a few tight paragraphs built around a spine drawn from the material, where support is insight on its own and the reader is pointed to the source, not served a copy.
Inform the user when invoking this skill by name: synthesize.
Two modal failure modes pull against this and both reassert at draft time, even after a spine is chosen — defeating them is the whole job, not a one-time setup step:
A spine is an internal organizing frame — a constraint, a claim, a recurring metaphor, or a tension — that the material carries: one source among several states it and the rest support it, or one thread runs through the ideas of a single piece.
It must come from the material, not be imposed over it (stages of grief, a narrative arc).
See references/finding-the-spine.md.
good-prose, electively, after the gist exists.references/finding-the-spine.md.Steps 1b (validation with teeth) and 2 (the no-spine branch) are where this skill earns its keep.
Read references/finding-the-spine.md before running steps 1–3 — the validation verdicts and the no-spine branch live there; running them from memory loses the teeth.
The user always drives — they can override at any fork, guaranteed by transparency and reversibility, not by the agent stopping for sign-off at every step. The kind tag on each workflow step marks which is which: GATE steps stop for the user before acting; the rest narrate and proceed, reversible by the user's next turn. Surface every consequential choice (the spine, the no-spine fallback, the grounding-pass offer) before acting on it; never commit to a spine silently.
The spine is the single most expensive thing to get wrong — everything downstream hangs off it — so step 3 gates even when there is one obvious candidate.
Read references/audit-failure-modes.md for detection cues and fixes; repair each in place.
The list below is an index, not the procedure — the cues that catch each mode live in the reference.
Standalone — no built-in gather or polish steps, and no automatic handoffs.
The user or agent may electively run mcp-research (gather sources) before, or good-prose (polish prose) after.
references/finding-the-spine.md — distill vs. validate modes, validation with teeth, the no-spine branch, source-earns-its-place.references/audit-failure-modes.md — each failure mode with detection cues and repairs.development
Use when the user wants rigorous, non-sycophantic editorial feedback on a draft, essay, blog post, or argument through back-and-forth dialogue — pressure-testing thesis, structure, argument, clarity, tone, and evidence. Triggers: "be my sparring partner", "pressure-test this draft", "poke holes in my argument", "is this ready to publish", "sharpen this post", "where is this weak". Not for one-shot copyediting, proofreading, or ghostwriting.
development
Use when writing or reviewing tests in any language, or diagnosing a suite that is slow, brittle, or hard to read. Triggers: "write tests", "how should I test this", "what kind of test", "test is flaky/fragile", "should I mock this", "test is hard to read". For Python-specific guidance see `python-testing`.
development
Use when writing, debugging, or explaining Strudel live-coding music patterns — mini-notation syntax, pattern functions (fast/slow/every/off/stack), synth/sample selection, audio effects, scale/chord/voicing API, or EDM production recipes. Triggers: "write a Strudel pattern", "how do I make a bassline in Strudel", "what does .every() do", "strudel drum beat", "strudel chord voicing", any Strudel code question.
development
--- name: debugging description: Use when a bug, test failure, build break, regression, flaky test, or unexpected behavior appears — before proposing or attempting fixes. Triggers: "why is this failing", "this test broke", "something's wrong", "help me debug", "it works on my machine", mysterious stack traces, intermittent failures. Not for: writing new features, reviewing working code, or routine refactors. --- # Debugging Random fixes waste time and create new bugs. Symptom patches mask root