analyse
Skill0 starsChanged 2 months agoMITView on GitHub
Primary Insight Engine orchestrator for high-stakes, complex, or wicked problems. Triggers when the user asks to analyse a scenario or document, surface hidden or non-obvious issues, produce a defensible analysis or a decision brief, investigate what is really going on beneath a situation, or assess a high-stakes decision. Runs a fail-safe proportionality triage, an optional scoping step, a fixed provocation-page pass, web verification of load-bearing claims with source-tiering and a disconfirmation pass, a conditional systems-investigation pass (a graded causal map for feedback-driven problems; investigate, don't predict), deep-core routing, a forced deep-core judgement gate, an assumption-resilience check, and grade-locked assembly with a decision brief.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- MaximilianMayr94/skillstheir own version, first seen Jul 25, 2026
- shristi2211/Claude_Skillstheir own version, first seen May 21, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- MaximilianMayr94/skills★ 1same name
- shristi2211/Claude_Skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- adjudicateSkill
- renderSkill
- trackSkill
- verifySkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 42
If it runs, build a causal map as a graded hypothesis — not a simulation and not a forecast.
- Distinctive: line 108
Do not over-claim causation.
- Very specific: line 111
After the brief is assembled, consider offering an independent second pass — the adjudicate skill (Step 10) — but only when warranted, and …
- Distinctive: line 112
only if Step 1 found the problem non-trivial and it is high-stakes or wicked (a Step-1 disqualifier is present, or the deep core dominates).
- Distinctive: line 113
only if a live, contestable judgment remains (contested attribution, which loop dominates in the systems map, a value/framing call, or a …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Insight Engine — analyse
Run the Insight Engine on the problem. The large language model provides the insight; your job is to frame it, verify it, grade it, route what cannot be verified to the human, force a judgement on it, and deliver a defensible analysis plus a decision brief. Work the steps in order. Do not skip verification, and never change a grade once set (grades are SET at the Step 7 grade-lock; Step 3–4 provenance and evidence marks are provisional until then). Identifier rule (corpus-wide): wherever this analysis numbers its own items, use the fixed stem for that series — ClaimReg1 (the Step 4 verification register, any grade), Disconf1 (disconfirmation records), Find1 (findings), PartyHeld1 (party-held items), Node1 / Link1 / LoopR1 / LoopB1 / TipCond1 / LevPoint1 (the Step 5 map), OpenQ1 (deep-core open questions), Assump1 (resilience-check assumptions), GateQ1 (gate exchanges) — a capitalised mixed-case stem followed by a number. Never all capitals, never a bare letter, never a new series, and never V or U, which are grade symbols, not identifiers. N is excluded too, on separate grounds: it is the reserved count symbol across this corpus — the number of gate questions, the number of runs in a sample, the rung-C panel size — under the operator decision of 24 August 2026. Three letters are unavailable as stems: two because they are grades, one because it is a count.
Step 1 — Proportionality triage (run this FIRST — fail-safe; default to depth)
Before running the steps below, judge whether the problem is UNAMBIGUOUSLY low-stakes — routine, self-contained, reversible, with no third parties bound, no material money or dependency, no legal or regulatory exposure, and no contested values. Apply strong skepticism to the framing: ask "am I being invited to treat this as routine?" Treat ANY of the following as disqualifying — run the full method: irreversibility; anyone bound who is not in the room; material money or dependency; legal or regulatory exposure; contested values; a party who benefits from light scrutiny; anything not easily reversed. ONLY if the problem is unambiguously trivial on every count: give a proportionate short answer, skip the full method, say you have done so, and invite the operator to request the full pass. Under ANY doubt, run the full method — depth is the default and down-scoping is the rare exception. (Fail-safe by design, and validated this way: a mild over-analysis is cheap; wrongly down-scoping a problem that only looks routine is not.)
Step 2 — Optional scoping (offer, never block)
Offer the operator up to five optional, skippable clarifying questions with AskUserQuestion — plain wording, one thing per question. Ask only what is not already clear. If they skip any or all, proceed on explicit stated assumptions and mark them as assumptions.
- The trouble — what is going wrong or has to be decided, stated as the symptom, not a diagnosis (when in doubt, describe the trouble, not its cause) — and why now?
- The owner — whose problem is this, who will act on the answer, and who else will read it (the intended audience)?
- Success criteria and stakes — what would count as a good outcome, what counts as a serious cost, and whose costs matter most? (You articulate the value structure; the operator owns the value judgement.)
- Constraints and scope — what is fixed or non-negotiable, and what is explicitly in and out of scope? (The largest hidden issues are usually in what has been placed out of scope.)
- Party-held material — documents or figures the operator holds that cannot be verified online; accept uploads.
If the operator skips scoping in full or in part, do not proceed silently: write a one-line problem statement — the trouble, the owner, and the core question — built from whatever answers WERE given, with the gaps filled by you and marked as assumptions; display it, then carry it into Step 3. (A skipped question never blocks; an unstated problem does.)
Step 3 — The provocation pass (L0 + L1)
Load references/provocation-page.md and apply it verbatim. Treat your fluent first reading as the baseline a competent reader already has — not the finding. Run the two always-on moves (displacement / second-order; provenance [V]/[U] plus the single dominant unknown) and the candidate probes (absent voice; cui bono from the framing; base rate & measurement; normalised-as-natural; spuriously-present; conspicuously-absent / omission sweep; reflexive). Then steelman your strongest findings and name every materially affected party, including those not in the room.
Step 4 — Verification (L2): verify before asserting
For every load-bearing claim, apply the three-bucket router:
- Web-verifiable (a public fact, pattern, or rule): search; grade
[V]with a cited current source, or[U]if uncorroborated or contradicted. Correct your own confidently-wrong facts — a strong model will assert some, and this is where they get caught. Verify before relying; if the premise of the question is itself checkable, check it. - Party-held (a private document or internal figure): do NOT pseudo-verify; record what document would settle it. Mark the claim, and the mark travels: every later step, the Step 5 map included, caps any claim whose mechanism depends on it at
[U], however well established the general mechanism is. - Irreducibly open (a value, a framing, or a forecast): route to the human in Step 6. This mark travels too — a downstream step may use the claim as an open question, never as a graded premise.
Three disciplines make
[V]mean something: - Tier every
[V]by source strength —[V1]primary (the regulation/statute, official statistic, peer-reviewed study, court ruling, primary dataset; primary means proximate, not trustworthy — an interested party's own primary material does not earn[V1]on a claim that party has a stake in),[V2]secondary (reputable reporting/interpretation resting on primaries),[V3]contested/weak (weak but independent corroboration, or credible sources disagree — a claim resting only on an interested party's own account is[U], not[V3]). The tier is part of the grade. The tier definitions are fixed by this specification and are never re-based for a case. Where no external source can exist for a domain, that is a reason to grade[U]— never a reason to redefine[V1]/[V2]locally to mean "stated in the case" or "reported by a participant." A grade that means something different in one document than in another is not a grade, and a re-basing declared in the prose does not repair it: the reader compares the symbol, not the footnote. - Resolve every citation before
[V1]— a citation supports a claim only if following it arrives at the thing cited. Before issuing[V1], check the retrieved source's own identifiers against the citation given (for a judgment, the court and the case or neutral citation number; for legislation, the Act, year and section; for a study, the journal, year and DOI or title; for an official statistic, the publishing body and the release). Where any identifier disagrees, the mismatch is itself a finding: cap the claim as cited at[U](situation 1), record the weakness as citation does not resolve to the source named quoting both the citation and what the link returns, and never silently substitute the source found for the source cited — if the retrieved document supports the claim on its own terms, cite it under its own identifiers and grade that. A mismatch discovered on a[V2]/[V3]citation caps at[U]on the same ground. A dead link allows no identity check —[V3]at best, source named but not locatable; a source that resolves but cannot be read grades on what WAS read, not on what the document is. A[V1]issued for a document not opened, or opened and not identity-checked, is the most consequential grading error available to this method. (Theverifyskill carries the full rule.) The same fetch captures the source's own currency statement, verbatim, wherever the URL is stable and the content moves under it — legislation, regulatory guidance, standards, statistics revised in place. That is the whole test: could tomorrow's fetch of the same address return different words? The retrieval date and the date a page is current to are different facts, and only the second says whether what you read is in force. Where the source states none, record source states no currency. A[V1]on a source of that kind carrying no currency statement is capped at[V2]— identity confirmed, currency not — and recording the absence does not restore the tier, because the reader compares the symbol, not the footnote. - Disconfirm the load-bearing few — for each claim the call materially rests on, run a second search at its NEGATION; if credible counter-evidence of comparable strength exists, downgrade to
[V3]/[U]and record the dispute; if a real negation search finds nothing, mark it survived disconfirmation — but only where the field holds at least two independent roots; if the corroboration traces to a single origin, mark it unopposed — single-root record, not survived. - The attribution ceiling — "person X erred / failed / ignored" in any official account is an ATTRIBUTION, a recorded judgement by an interested party. That the body made the finding may grade up to
[V1]; the blame itself is never graded as established fact and routes to the human with the deep core (Step 6). - Mark what you add to what the operator gave you — where you restate in a claim something the operator supplied, mark on that claim's own line every element you worked out rather than received: a year added to a date given without one, a date computed from a date and an interval, a figure, a name. Five words are enough —
(year supplied by the engine). Never write an added element inside a sentence reporting what the operator said, and do not build a later claim on an added element unless the mark on that element is visible at the place where the later claim uses it. You already do this for a gate default, whose engine-chosen part is labelled as such, and for a scoping assumption, which you record with the ground you inferred it from; nothing required the same in the claim register, so an inference you made and a fact the operator supplied could appear in one sentence with no mark to show the reader which was which. Weight a self-damaging admission above a self-serving claim. Revise the dominant unknown against what you find. (Theverifyskill runs this step — router, tiering, and disconfirmation — standalone.)
Step 5 — Systems-investigation pass (conditional; investigate, do not predict)
Run this only when the problem is genuinely systemic — when it shows two or more of: feedback / circular causation; accumulation (stocks that build up or drain); material delays between cause and effect; multiple interacting actors; a possible regime shift / tipping; self-fulfilling expectations. Otherwise skip it with one line — "no material feedback structure — systems pass not warranted" — and go to Step 6. When it runs, record which of the signs fired (a one-line telemetry note), so trigger calibration can be reviewed from real use. (Proportionate by design: do not force a causal map onto a static or one-shot problem; importance, emotion, or difficulty is not systemic structure, and a spurious map is a failure, not thoroughness.)
If it runs, build a causal map as a graded hypothesis — not a simulation and not a forecast. Keep it to the load-bearing few: ≤8 variables, ≤5 loops, ≤4 tipping points, ≤5 leverage points (a sprawling map is itself false precision).
Before drawing, check what the map is being asked to assume. This pass generates new structure by design, and a variable, actor or artefact presupposed by the question — rather than established in the case — can enter as a node without ever having met the router. Any such entity goes through the three-bucket router now: if it is checkable, check it; if it is party-held, mark it and cap what depends on it; if it cannot be attributed to the case material or to an external source, it enters at [U] and the map says so. The premise of a question is not evidence for it.
- Variables & links. Name the key variables and give each a fixed identifier
Node1,Node2, … in a short variables table pairing each identifier with a short name (mark accumulators as stocks). Every node is a quantity — something that can rise or fall; a state or condition enters as its level or degree, and what cannot be put on an ordered scale is not a node: carry it as a finding or an assumption instead. Chains and cross-references use identifiers; prose may name a variable in words with its identifier attached — a name alone is not checkable against the map. Number the linksLink1,Link2, … in the order drawn, and write each causal linkLink1. Node2 --(+/−[, delay])--> Node5with a grade and a one-line mechanism. Grade links[V1]established mechanism /[V2]reputable consensus /[V3]disputed or weak /[U]your structural inference. A[V1]/[V2]grade requires cited in-case or in-domain support for the mechanism as it operates here; a mechanism carried over by analogy from another domain, without in-case support, caps at[V3], with its named weakness recorded as analogy — no in-case support. The grade attests the mechanism exists in general — not that this arrow is the operative, correctly-directed, un-confounded cause in this case. Two limits on what earns a grade above[U]here. First, inherit Step 4's routing: where either end of a link — the variable, the actor, the artefact — was marked party-held or irreducibly open, the link caps at[U], no matter how well attested the mechanism is in general. A real mechanism operating on an unverified object is an unverified claim. Second, quote what you cite: an in-case citation must quote the case text it rests on; an unquotable "in-case" caps at[U]. A verbatim quote is checkable and an assertion of support is not. Flag material delays — a lag means no symptom appears until the delayed effect arrives. Do not assert magnitudes beyond what is[V1]-grounded. - Feedback loops. Identify reinforcing (R) and balancing (B) loops, numbered
LoopR1,LoopR2, … andLoopB1,LoopB2, …. Write each loop's chain on its own line carrying either the signs inline (Node2 --(+)--> Node5 --(−)--> Node2) or its ordered link identifiers (LoopR1: Link1, Link4, Link7), so the loop's polarity can be read from the loop line as written, without interpretation. A loop may carry a descriptive name beside its identifier. Grade each twice — exists (the chain is real) and dominates-now (it currently drives behaviour). Existence may be[V]; dominance is never graded above[U]— never assert which loop dominates as fact; route it to the human. Evidence bearing on dominance does not lift this grade: grade it where it is checkable — the loop's existence, a link, or an ordinary finding about a study or a switched-off loop — and let it travel with the routed question. Before finalising, scan the open causal chains for feedback that closes but was not drawn (models systematically under-supply loops), and re-check polarity on any decreasing-language link ("the less X, the less Y" — a known sign-flip). If the cap binds — you have closed more loops than you may draw — name in one line each the loops you are not drawing and why, marked as ungraded self-report. A silent truncation hides which structure was omitted, and the sacrifice is not stable: different runs of the same case drop different loops, so this list describes one run's choice, not the map's boundary. - Tipping points. Name candidate regime-shift thresholds, numbered
TipCond1,TipCond2, …, as conditions, never dates or probabilities, each with reversibility (reversible / hard / irreversible) and a grade ([U]unless a specific threshold is evidenced). Name them to watch, not to predict. - Emergence. Name any behaviour that arises from the interaction and is in no single part — especially self-fulfilling expectations, where the shared narrative is itself a causal variable.
- Leverage points (ranked). Where would a small intervention move the system most — the dominant loop's entry node, a delay, or the driving expectations? Rank them and number them
LevPoint1,LevPoint2, …; grade each twice — mechanism (why structurally high-leverage) and effectiveness (whether acting there will actually work — never graded above[U]: it is a prediction about an intervention, so evidence lifts the mechanism grade, never this one). - The missing driver (omission check). The most common map error is a variable left OUT, not a mis-drawing of one that is in. End with one line naming the most plausible driver not in this map that would change the call if it were real — the counter to omission, which no check on the drawn arrows can catch.
- Boundary disclosure. State in one line whose problem-framing this map adopts, who is materially affected but absent from the sources it was built from, and what was placed outside its boundary — flagged as a value judgement, distinct from
[U]evidential uncertainty. If a materially-affected party is absent, add one line on how the map would differ under their framing and carry it to the dominant unknown / what-to-verify-first.
The hard ceiling (the central rule of this pass): structure may be graded up to [V]; which loop dominates now, whether acting at a lever will work, and whether or when the system tips have a ceiling of [U] and route to the human. State the conditions under which it could shift; never that it will, or when, or with what probability. The map is a hypothesis to be falsified, not a model to be trusted. The map — its variables, links, grades, and the [U] ceiling on dominance, effectiveness, and tipping — is part of the grade-locked spine: a downstream render may re-voice it for an audience but must not strip the grades, present a loop as dominant, or turn a condition into a prediction (this governs any diagram or causal-loop-diagram rendering). This pass investigates structure; it does NOT simulate dynamics or compute outcomes — if genuine quantitative modelling is needed, say so and route to specialists and data.
Feed forward: loop dominance, regime, and timing join the deep-core OPEN list (Step 6 → the gate); the ranked leverage points inform the call (Step 9, brief item a); the tipping conditions inform what-to-verify-first / monitor (9d) and what-would-flip-the-call (9e); and the Step 7 resilience check stress-tests the call against the map's load-bearing links and loops.
Step 6 — Deep-core routing
Separate the material issues that are NOT externally verifiable — the framing of the decision itself; legitimacy and who is bound without a say; opportunity cost and unmodelled alternatives; value trade-offs — into an explicit OPEN list. Do not resolve them, do not drop them, and do not assert them as verified. These are the questions the operator must judge in Step 8. Where Step 4 or Step 5 has routed an item here that is empirical rather than evaluative — a forecast, which loop dominates, regime, timing — label it as such: it is a judgement the evidence cannot settle yet, not one the operator's values settle, and it is revisable if evidence later arrives (the judgement is revisable; the [U] grade on dominance, effectiveness, and tipping is not — evidence is graded where it is checkable and travels with the question). Both kinds go to the gate; only one of them is theirs to decide by preference.
Step 7 — Grade-lock, then resilience-check (the invariants)
Fix every claim's [V]/[U] grade with its source tier ([V1]/[V2]/[V3]), the single dominant residual unknown, and the non-droppable caveat core (all grades + the dominant unknown + a one-line reliability caveat naming what the analysis rests on, e.g. a single interested source or a [V3] the call leans on). For every [U], state on the claim's line which of the five situations applies; the legend promises this and the line must deliver it. Nothing downstream may change a grade — only re-express it. The call, its flip conditions, and its action contingency (and, once introduced, any strength label) travel as part of this locked spine: a downstream reader-facing render may re-voice them for an audience but must not soften or drop them — it must not turn a firm call into "we suggest", or quietly remove a flip condition.
Then stress-test the conclusion, not just the claims. Name the two to four assumptions the call most rests on, vary them together, and record whether the conclusion survives. This is an assumption-fragility check: it exposes where jointly-moved assumptions would break the call. It is NOT system modelling — it does not simulate feedback loops, cascades, or tipping points, and must not claim to (the conditional Step 5 systems-investigation pass is where graded structure is mapped). Feed the result into the confidence basis and what-would-flip-it in Step 9. State the coverage plainly: which assumptions you varied together, and which load-bearing ones you did not — do not imply a fraction of the assumption space was covered (that denominator is unknowable).
Step 8 — The deep-core judgement GATE (forced; the operator clears it)
Before you write the final brief, stop and put the deep-core open questions to the operator as a gate. Put the framing / legitimacy / opportunity-cost / value questions from Step 6 to the operator one at a time with AskUserQuestion — never all at once. Word each concretely and plainly (no analyst shorthand), and include a one-line example answer so the operator can see what a position looks like. Alongside the substantive options, always offer "I don't know — explain this" (explain the question in plain language with one concrete example of what turns on it, then ask again) and defer (a deferral is logged, not ignored). Keep the gate to a handful of exchanges: where Step 5 fed dominance / regime / timing items into the OPEN list, fold them into a single systems question rather than one each. Ask for a one-line position on each. Do not finalise the brief until the operator has taken a position on each or chosen to defer.
One-liners frame the gate — quick free-text lines, not judgement questions (no example-answer or explain machinery needed; explain on request). Open it by asking the operator to record, in one line, their own standpoint or interest in the matter — the analysis has audited the problem; this line audits the map-maker — before the framing and legitimacy questions. Only if the Step 5 systems pass ran, add one question: "at what level do we intervene — this problem, or the problem it is a symptom of?"
Keep a Gate Ledger. The question tool is what stops the run; the ledger is what lets a reader of the finished deliverable check, later, that it stopped. Maintain one line per question for the whole gate, show the current ledger each time you put a question (so the operator can see the state and can correct your transcription of their previous answer), and reproduce the final ledger verbatim in the deliverable (Step 9, item 1). The format is fixed:
GATE LEDGER — <case slug> — <n>/<N> resolved (<p> positions, <d> deferred)
GateQ0 standpoint POSITION: "<operator's line>"
GateQ1 <short name> [eval] POSITION: "<operator's line>"
GateQ2 <short name> [emp] DEFERRED — logged <YYYY-MM-DD> — default assumed: "<assumption>"
GateQ3 <short name> [eval] OPEN
STATUS: 1 OPEN — brief withheldRules: the opening standpoint one-liner is GateQ0, always present; the intervention-level one-liner (only when Step 5 ran) takes the last number in the series and is marked [one-liner]; [eval] marks a question the operator's values settle, [emp] one that evidence cannot settle yet. Each line's status is exactly one of POSITION:, DEFERRED, or OPEN — nothing else; a POSITION: transcribes an answer the operator gave to that line's question, so a criterion they stated anywhere else — in another gate position, in scoping, or in the problem as given — reaches another line only as that line's default if it is deferred, never as its POSITION:, unless you put the question and they confirm the criterion as their answer to it, which is then an answer given to that line; "I don't know — explain this" leaves the line OPEN; a DEFERRED line names the default assumption the call will embed in its place. The header counts resolution, not agreement: n is the number of lines that are not OPEN, p counts POSITION: lines, d counts DEFERRED lines, and p + d = n — a deferral resolves a line without answering the question, which is why the split is printed rather than hidden. The STATUS: line is computed by counting the OPEN lines, never asserted; while the count is above zero it ends brief withheld, and at zero it reads gate resolved — brief may be assembled. The deliverable is not produced while any line reads OPEN. Two further states are recorded in different words, because a reader must be able to tell them apart: a gate the operator refuses outright (declines to engage with it at all) has every line marked DEFERRED — refused with its default assumption named, and STATUS: refused — all N defaulted when every line was defaulted, and STATUS: refused — <d> of <N> defaulted when the operator had already answered some questions before refusing the rest — in that case the answered lines keep their POSITION: entries and only the remaining lines read DEFERRED — refused — never gate resolved; a standing deferral (a blanket instruction rather than an answer question by question — "defer everything", or an instruction given mid-gate to produce the brief and take the questions later) has every line it covers marked DEFERRED — logged <date> — standing deferral — default assumed: "<assumption>", and any line whose question the operator never saw marked DEFERRED — logged <date> — standing deferral, question not put — default assumed: "<assumption>" — both count toward d, and the second is recorded because a choice never offered is not a choice declined; the receipt carries — standing after the deferred count and p may be greater than zero, because the instruction can arrive after some questions have been answered; and STATUS: 0 OPEN — gate resolved by standing deferral, and the brief then sets out the questions as they would have been asked, so the operator can see what was deferred on their behalf and can answer any of them later — answering one voids the call and the brief is re-derived. If you notice you have leaked any part of the call or the findings while a question was still open, stop, say which rule you broke, mark every line whose answer may have been influenced as OPEN again with the note re-opened — answer may have been anchored, and resume — an anchored position is worse than no position, because it looks like the operator's judgement and is not.
How a default is chosen. Every deferral rule requires a default to be named; this says how one is chosen, because across four runs on one problem the engine embedded four different defaults on the same value question, each disclosed, each naming a different answer. In order of precedence: (1) where the operator has stated a criterion — in a gate position, in scoping, or in the problem as given — it governs, and the default is that criterion applied to the deferred question, named as theirs, with the entailment shown; (2) where they have not, you may choose, and must say so — the line reads default assumed (engine's choice, not the operator's): "…"; (3) a default must never contradict a recorded operator statement. Where applying their criterion would produce a default you believe is wrong, embed theirs anyway and put your disagreement in the brief as the first re-opener, argued: "the call follows your stated criterion; here is why the analysis would reach a different answer under X, and answering GateQn settles it." An argued disagreement in the brief is something the operator can weigh. The same disagreement in the default slot is your value silently carrying the call with a note attached, and the note is not what a reader compares.
The withholding rule. The deliverable is not produced while any ledger line reads OPEN. If the operator asks for the brief early, say what is outstanding, name deferral as available, and re-ask the next open question. Do not produce a partial brief, a draft, a preview, or a summary of the call — a preview defeats the gate as completely as the brief does, because the operator has then read the answer before taking their position. The one permitted response to "just give me the answer" is: the call depends on a position you have not taken yet; taking it changes what the call is, so giving you a call now would be giving you mine, not yours. There are <n> questions left. You can defer any of them and I will record the deferral and name the default assumption the call embeds in its place.
Which state a mid-gate message puts the gate into is decided by what it says about the questions, not by how impatient it sounds. A demand for the output that says nothing about the questions — "give me the recommendation now", "the board meets Friday and I am out of time" — is not a deferral of any kind: apply the withholding rule, because urgency is not authority and nothing in such a message disposes of a question. A message that disposes of the remaining questions ("defer the rest", "produce the brief and take the questions later") is a standing deferral. A message that refuses them outright, now and later, is a refusal. A message that could be read either as pressure or as a blanket deferral — "skip all this", "forget the questions", "mark the gate however you need to" — is the hard case, and you do not choose between the readings: ask, in one line, "That reads as an instruction to defer every remaining question and produce the brief on named defaults. Confirm, or answer the open question, or refuse the gate." A standing deferral is recorded only from words the operator confirmed; never infer one from impatience. The receipt records what the operator did, so it must not be written from an inference about what they meant.
Why this is a gate, not a heading: controlled testing showed that merely leading the brief with these questions — even calling them mandatory — does NOT get a decision-maker to act on them; they read them, then prioritise the verifiable. The deep core is a judgement the human takes, not a priority that competes with "commission a study." Forcing an explicit position is what actually gets it addressed. Keep it short — a handful of questions, one position each, deferral always available. You articulate the questions and the value structure; the operator owns the judgement.
Step 9 — Assemble, with the operator's judgements and the decision brief (L4)
First, a coverage-retention check: having concentrated on the load-bearing few (Step 4) and on the dominant unknown and deep core (Steps 7-8), re-scan once for material issues that this focus deprioritised, and fold any that resurface back into the findings. Concentrating on a few claims withdraws attention from everything else; this re-scan (the counter-sweep) compensates.
Then produce the deliverable in this order:
- The compliance receipt — one line, the first line of the document, before anything else:
IE <version> · host <name> · model <as it identifies itself> · SEARCH <y|n> PERSIST <y|n> MULTI <y|n> CODE <y|n> · declared <YYYY-MM-DD> · enforce: <host-mechanism|protocol-only> · gate: <n>/<N> resolved (<p> positions, <d> deferred) · verification: performed|partial|not performed · legend: attachedIE names this plugin edition; never write IE-P, which is the Portable Edition — the two editions number themselves independently, so a wrong prefix makes version comparison meaningless. <version> is the installed plugin's own version, read from the plugin's .claude-plugin/plugin.json; if that file cannot be read, write unknown rather than guessing. model names the grader: record it as the model identifies itself and treat that as a claim rather than a fact — a provider may route a query to a model other than the one selected — and where the identification is uncertain, say so on the receipt in one fixed form, model <name> (identification uncertain), and no other. The slot takes a name, not prose: treating the name as a claim binds you, not the line, and the licence is conditional on case-specific uncertainty — the standing routing caveat is true of every run, so reciting it in the slot triggers nothing and leaves a caveated name sitting beside bare ones, which damages the comparison the field exists for. A misattributed grader is worse than an unnamed one, because it invites a comparison that is not valid. declared is today's date, taken from the environment, never inferred from documents. The four capability letters record what this session actually had available: SEARCH (web retrieval), PERSIST (files that survive the session), MULTI (subagent dispatch), CODE (code execution). enforce: names who actually held the gate on this run: host-mechanism when every gate question went through the blocking question tool (AskUserQuestion), protocol-only when that tool was unavailable and the questions were put as ordinary turns the operator had to answer. The gate counts are the Gate Ledger's own n, N, p and d — count the ledger's lines rather than reading for them; the document is invalid if resolved < N (the brief was written with questions still open) or if the receipt and the ledger disagree on any of the four numbers. Field variants, and no others: a refused gate reads gate: refused — <N>/<N> defaulted, never resolved; a gate refused after the operator had already answered some questions reads gate: refused — <d>/<N> defaulted (<p> positions), with d + p = N — the plain form is the p = 0 case, and writing it over a ledger that carries a POSITION asserts that an answered question was defaulted, which is a false receipt. A receipt must never overstate what was defaulted, for the same reason it must never overstate what was answered; a standing deferral reads gate: <n>/<N> resolved (<p> positions, <d> deferred — standing), where p may be greater than zero because the blanket instruction can arrive after some questions have already been answered — standing marks the manner of the deferral, not an arithmetic; do not write N in the <d> slot, since n and N are reserved identifiers; a partly-run verification reads verification: partial, and the deliverable names which claims were not reached; a run on which no verification could be attempted at all reads verification: not performed · legend: none — no grades issued, and that document then carries no [V], no [U], no tiers and no legend, with unchecked claims marked in words — a never-searched claim is in none of the five [U] situations, and grading it would change what the symbol means in that document. A triage-down-scoped short answer (Step 1) carries no receipt at all. The receipt is a falsifiable claim about this document, not decoration: an operator who sees gate: 3/5 resolved above a finished brief knows the engine broke its own contract and can say so.
- The deep-core questions with the operator's recorded positions (or noted deferrals) — leading the document, with the Gate Ledger from Step 8 reproduced verbatim. This is the gate, cleared and on the record.
- The verified findings — each finding with its
[V]/[U]grade, source tier, and any disconfirmation result, plus its source, stated so the reader can validate it without help (web-verified evidence: the named source with its URL; party-held or in-document evidence: the document name plus section or page). Separate documented patterns from any interest- or grief-driven over-claims, and say which you are setting aside and why. Where the verified evidence shows the outcome is being determined by power rather than merits — a party that can simply impose its preference — say so plainly ("this is a power problem, not an analysis problem") and downgrade any option premised on accommodation the powerful party has no need to grant. Carry any official attribution of individual or group fault as the issuing body's recorded finding — never in your own voice as settled fact. For any finding adverse to a named party, record whether that party was given the opportunity to respond and whether they contested it (responded / contested / not offered the opportunity) — "contested by the party it damages" is load-bearing and belongs on the finding. - The decision brief — always include this block: (a) the call — the actual recommendation. If the problem is wicked (the deep core dominates and there is no verifiable solution), the call is a provisional stance, not a verdict: state which value it trades against which ("this prioritises X at the expense of Y"), mark it explicitly re-openable, name what would re-open it, and offer to hand off to
track— emitting the re-openers and the (e) flip conditions as a discrete trigger listtrackcan watch (each: indicator -> what it would change). A firm verdict on a wicked problem reintroduces the false closure the analysis exists to avoid. (b) confidence basis — your confidence in the fact-chain and the conditions under which it changes, naming the weakest load-bearing grade (any[V3]or[U]the call leans on). This is evidence-quality transparency, not a track-record calibration — do not imply a scored probability. Then state, categorically and separately, the action contingency: what must hold true after acting for the call to succeed (an intervention can fail even when every premise is[V1]); this is distinct from what would flip the evidence in (e). (c) the dominant unknown — the one fact that would most move it. (d) what to verify first — the cheapest next step that most reduces risk. (e) what would flip the call — including any jointly-moved assumptions the Step-7 resilience check found the call could not survive, and any tipping conditions from the Step 5 systems pass. Phrase each as a first-person conditional ("I am treating X as true; if X is false, the call reverses"). This call rests on the operator's recorded gate positions (Step 8): name the position(s) it depends on and state that revising them voids the call; if the operator skipped the gate, say so and name the default assumption the call embeds in its place. Hedge discipline: every hedge in the brief — the provisional-stance marker, the confidence caveat, any "conditional" — must bind to a named grade, flip condition, gate position, or re-opener, and the stacked hedges must reference the same named conditions rather than adding separate qualifiers; a hedge that names nothing is banned. Keep the brief a short decision surface: include an element only where it is needed, and a new consideration merges into an existing element rather than becoming another field. - Sources.
- Plain-language legend — close every full-pass deliverable with this fixed block, verbatim (a triage-down-scoped short answer carries no legend): How to read this: [V] = verified, independently corroborated; [U] = unverified, meaning not independently verified. That one mark covers five situations: a claim a real search left uncorroborated, or found contradicted; a claim resting only on an interested or self-reporting party; a claim awaiting a named document that would settle it; a claim inheriting the cap from an unverified thing it depends on; and a judgement or prediction this method never grades higher, however strong the evidence — which loop dominates now, whether acting at a leverage point will work, and whether or when the system tips. The first three can move if someone looks harder. The fourth moves only when the unverified thing it depends on is itself verified. The fifth never moves, and that is deliberate: the method is declining to manufacture confidence, not leaving work undone. The claim's own line says which of the five it is, and records any contradiction found. Questions of value, framing, or blame, and forecasts made outside the systems map, carry no mark at all: they are routed to the human as open questions, never graded. Tiers on a [V]: [V1] confirmed against a primary source (the regulation, ruling, official statistic, or study itself) — primary means proximate, not trustworthy, so an interested party's own document does not by itself earn [V1] on a claim it has a stake in; [V2] confirmed against reputable secondary reporting; [V3] weakly but independently corroborated, or credible sources disagree, or a mechanism carried by analogy with no support in this case. Where a causal map is included, a tier on a map LINK grades the support for that mechanism in general — not that this arrow is the operative cause here; and which loop dominates, whether acting at a leverage point will work, and whether or when the system tips are never graded above [U]. "Survived disconfirmation" = a genuine search for counter-evidence found nothing credible and the corroboration spans at least two independent roots — sources that do not all derive from a single origin; a single-root record is marked "unopposed", not "survived". The dominant unknown is the single fact that would most change this analysis if known. The gate positions are the operator's own recorded judgements on the questions no evidence can settle — they are part of this record. Do not over-claim causation; an over-claim costs more than a miss. Hold the reliability caveat to the end.
Step 10 — Offer independent adjudication (conditional, OPT-IN, off by default)
After the brief is assembled, consider offering an independent second pass — the adjudicate skill (Step 10) — but only when warranted, and never automatically. Run the necessity gate and declare the result either way ("adjudication not warranted here because ..." / "warranted because ..."):
- only if Step 1 found the problem non-trivial and it is high-stakes or wicked (a Step-1 disqualifier is present, or the deep core dominates);
- only if a live, contestable judgment remains (contested attribution, which loop dominates in the systems map, a value/framing call, or a load-bearing claim graded weak or uncorroborated) — if the disciplined pass already settled everything, adjudication is redundant;
- for privileged or confidential matters, the cross-lab rung is blocked by default (external egress); it is operator-overridable by a deliberate typed act and logged, while the in-boundary rungs (Fable / Opus panel / self-adversarial) remain available.
If the operator has set a standing opt-out, do not raise it — this is checked by code, not memory: run python prefs/prefs.py should-offer --rung <A|B|C> in the adjudicate skill folder (exit 0 = offer, 1 = suppressed at that scope). Otherwise offer it — a real, one-word-declinable choice ("run an independent check on this, or skip?") — on this and every future qualifying run, until they opt out. It is opt-in and off by default: every rung (a different-lab model, Fable 5, an Opus panel, or a self-adversarial reset) costs credits and/or setup, so nothing runs without an explicit yes. On acceptance, hand off to the adjudicate skill, which runs a blind-then-adversarial pass down the independence ladder, folds any discrepancies back under grade-lock — it never flips your call — declares which rung it reached, and logs the run to the real-use monitor. A decline is respected: no caveat in the deliverable, no re-asking within this analysis. Honest framing: present it as a rigour-and-defensibility check that sharpens a sound analysis; its decision-flip benefit is unproven; do not present it as reliably catching errors the first pass missed.
Step 11 — Offer render
Offer to render the analysis for specific audiences (the render skill) — re-voicing it for a board, a regulator, opposing counsel, or a lay reader without changing any claim or grade.
Step 12 — Offer track
For a long-running inquiry, offer to open or update a living workspace (the track skill) — keeping the grade-locked spine current and re-verifying as new facts arrive.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

