zirkel

Pins down an ambiguous output format, style, tone, or schema by anchoring it to 2-5 concrete input/output examples instead of more prose. Use when prose keeps under- or over-specifying the target shape: when the target cannot be described in words, is non-standard, or involves subtle tone or layout choices, or when a zirkel-solve stage output shape is fuzzy.

Scopes an ambiguous task before any work begins — restates it with defaults made explicit, lists known facts (flagging low-confidence ones), and surfaces the interpretation forks that could send the work the wrong way. Use when a task's phrasing supports multiple reasonable interpretations, success criteria aren't stated, or scope is underspecified: "what exactly do you want here", "before I start, let me pin this down", a vague one-line request, or the first phase of zirkel-solve.

Breaks a scoped problem or selected approach into a 2-5 stage pipeline, each stage with an explicit input contract, output contract, and dependsOn list, and derives the parallel-safe wave grouping from the dependency graph. Use when a task is big enough to need staging with clear hand-offs between steps: "break this into steps", "what's the pipeline here", "map the stages", "what depends on what", or the Decompose phase of zirkel-solve.

Scores an already-drafted artifact 1-5 against explicit numbered criteria and selectively revises only the criteria that fall at or below threshold, leaving what already works untouched — then reports exactly what changed. Use when a draft exists and needs targeted iteration rather than a rewrite: "score this against these criteria and fix what's weak", "revise selectively", "which parts fall short", "iterate on this draft", or the Revise phase of zirkel-solve.

Explores multiple genuinely-distinct approaches to a scoped problem in parallel, scores each on Feasibility/Impact/Risk, and selects a winner — so the work does not anchor on the first idea. Use when a task has more than one viable approach and picking the first that comes to mind would be a mistake: "what are our options here", "don't just do the obvious thing", "weigh a few approaches", "explore alternatives", or the Explore phase of zirkel-solve.

Checks that every factual claim in an answer or artifact is traceable to a specific source — a file:line, a URL, or explicitly-flagged prior knowledge — and refuses to assert anything beyond what's actually verified. Use whenever an answer, summary, or report makes assertions that need grounding rather than recall: "cite your sources", "don't make this up", "ground this in the actual transcript/code/docs/data", a number or metric that must trace back to where it came from, "verify before asserting", or a factual-claim-heavy stage of zirkel-solve.

Works a problem whose next action can only be chosen after seeing the last result — a Reasoning / Action / Observation loop where each observation determines the next step. Use when the sequence of tool calls cannot be planned upfront: "figure out why X is happening", "trace this through the system", "I don't know where the problem is, go find it", open-ended debugging or discovery, or an Execute stage of zirkel-solve whose steps are unknown at the start.

Answers a question that turns on entity/dependency/causal structure by extracting indexed relationship triples and traversing them hop by hop, citing the triple index at every hop. Use when the answer requires following a chain through named entities and relationships: "how does A affect D through the chain", "trace the dependency path", "who reports to whom", "what causes what here", multi-hop "why" questions, or a zirkel-solve stage that needs graph traversal. Not for deriving a repository's real import/module graph from source — "map this repo's architecture", "show me the real module boundaries", "map stages and wires" belong to befund-stage-map, which parses imports per language and writes the stage graph other skills consume. Use this skill only to reason over a relationship graph whose entities are already established, in code or any other domain.

After zirkel-explore-branches has selected a winner, synthesizes a hybrid that combines strengths from 2-3 branches — but only presents it if it actually beats every source branch on at least one axis. Use when a single winner leaves value on the table and you want the best of several: "can we combine the best of these approaches", "what if we merged A and B", "the winner's good but I liked X from the runner-up". Runs strictly AFTER branch selection, never as a substitute for it.

Optimizes the exact wording of an instruction/prompt for a recurring task using APE — generates one candidate per framing, scores them against real test cases, and critiques the winner. Use when a prompt will be reused and its wording matters: "tune this prompt", "find the best wording for this instruction", "optimize this system prompt", "which phrasing works best", with representative test cases available. Not for one-off prompts with no test cases.

Matches reasoning effort to concrete failure-mode signals by climbing a 4-rung ladder — zero-shot, Chain-of-Thought, Self-consistency, or PAL (code offload) — and applies Multimodal-CoT first when the input has an image or diagram. Use when a task shows a real risk of a silent reasoning error: multi-step arithmetic, a single-correct-answer puzzle where a wrong early assumption is costly, a precision-critical calculation, or an image/diagram input. Not for well-trodden single-step questions.

Runs the full zirkel pipeline — Clarify -> Explore (conditional) -> Decompose -> Execute -> Revise — for a task that is complex/ambiguous AND needs staged decomposition AND carries real ambiguity or multiple viable approaches worth weighing. Use when a request is too big or too underspecified to answer in one shot: "solve this properly", "work through this step by step", "this is complex, break it down and do it", or any multi-faceted task where jumping straight to an answer would anchor on the wrong interpretation or approach. Not for simple, well-specified, single-step tasks.

After a zirkel-solve pipeline finishes, produces a compact written record for handoff, PR comment, or documentation — 7 sections (6 if Explore did not run) covering what was asked, assumed, weighed, run, produced, revised, and NOT done. Use when a finished multi-stage run needs to be captured: "summarize what we did", "write this up for the PR", "hand this off", "document the run", after zirkel-solve completes.

Checks exactly ONE named assumption against real evidence in at most 3 steps and reports one outcome: confidence raised (>=90), reading changed, or still unresolved. Use to resolve a single load-bearing uncertainty — typically a blocking entry surfaced by zirkel-clarify-scope: "verify this one assumption", "is it actually true that X", "check this before we rely on it". For multiple uncertainties, invoke once per uncertainty — the step budget is never shared.