Research pack reference

Every skill in the Research pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

Take a question from vague to answered: plan the research around the decision it serves, synthesise the sources with every claim cited, and rank rival explanations by the evidence against them.

Skills

hypothesis-comparison

Compare rival explanations for an observation with analysis of competing hypotheses (ACH) — list the hypotheses and the evidence, build a consistency matrix (consistent / inconsistent / neutral), rank hypotheses by how little evidence contradicts them rather than how much supports them, name the diagnostic evidence and the linchpins, and say which next observation would tell the leaders apart.

Tier heavy · v0.1.5 · SKILL.md · skill page

Use it when the user asks "why did X happen", "which explanation fits the evidence", "what's really causing this", wants to stop arguing over a favourite theory, or says "compare these hypotheses", "competing explanations", "ACH".

Needs: Python 3 for its scripts (standard library only).

A good result:

• At least four rival hypotheses, including a measurement one, each a sentence that could be false.
• Evidence rows are observations with a source, including at least one absence where one exists. Nothing in the matrix is evidence the user didn't supply, except rows tagged [assumption].
• The ranking is by inconsistency. The write-up never argues for a hypothesis by counting its C ratings.
• Non-diagnostic evidence is named and set aside, not used as support.
• Linchpins are named and checked: the rows whose removal changes the leader, with where each came from.
• The conclusion carries a confidence word and a reason, and stays tentative when one row holds it up.
• The next observation discriminates between the top two, with the result each one predicts.

Hands off to: research-plan when the matrix has too little diagnostic evidence to separate the leading hypotheses.

Not for:

• Choosing between technologies, vendors or approaches for the future — this ranks explanations, not options
• Market or competitive position, SWOT, Five Forces — strategy-analysis
• Planning what evidence to collect before you have any — research-plan
• Summarising what a set of sources says — source-synthesis
• Reviewing someone's written argument for weak spots — doc-critique
• Writing up an incident's timeline and causes once they're known — postmortem-generator

research-plan

Turn a vague research question into a research plan — the decision the research serves, the precise question and sub-questions, what finding would change the decision, a method per sub-question (desk research, interviews, data pull, experiment), source types with inclusion and exclusion criteria, ready-to-run search strings, a stopping rule for when you have enough, and the deliverable. Starts by asking what decision the research is for.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it when the user says "I need to research X", "help me scope this research", "how should I investigate…", "what should I look into before deciding…", or wants a research or discovery plan.

A good result:

• The plan names the decision, who makes it, and the date. Every sub-question traces back to it.
• The question is precise: population, intervention or topic, comparison, timeframe.
• Each sub-question has a "would change the decision" finding, written before research starts, with a threshold where one makes sense.
• Each sub-question has a method, a scope, an owner and a time, and the method is the cheapest one that can answer it.
• Inclusion and exclusion criteria are explicit for desk research: dates, geography, population, source type.
• Search strings are ready to paste, with synonyms and where to run them.
• There is a stopping rule with both a sufficiency test and a budget cap.
• Nothing in the plan states findings. It doesn't present a guess at the answer as known.

Hands off to: source-synthesis when the sources in the plan have been collected; requirements-interview when interviews are a method in the plan and the interviewees are stakeholders.

Not for:

• The sources are already collected and need summarising — source-synthesis
• Ranking rival explanations for something that already happened — hypothesis-comparison
• Writing the interview scripts for stakeholders — requirements-interview
• A strategy framework such as SWOT or Five Forces on a market — strategy-analysis
• Turning a messy thread into a brief for another skill — brief-intake

source-synthesis

Answer a question from a set of sources the user supplied — papers, reports, articles, interview notes, emails — saying only what the material supports, labelling anything that comes from elsewhere where it appears, counting a source that repeats another once, and giving a labelled estimate when the user needs a figure the sources don't settle. Written in the length and format the user asked for; a full cited literature review only when that is the ask.

Tier standard · v0.2.1 · SKILL.md · skill page

Use it when the user hands over several sources and asks to "synthesise these", "what do these papers say", "pull together what we know", "literature review", or "where do the sources agree and disagree".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Nothing reads as coming from the sources that doesn't. Every outside input is marked as outside in the sentence where it appears; no gap is filled from memory.
• Echoes are counted once. A figure repeated by a second source is traced to its origin.
• The sources' own sums are checked, and any that don't add up are named.
• The answer opens the reply and fits the requested size and format.
• A needed figure gets a worked, labelled estimate with its range and what would settle it, not a refusal.
• Findings are no stronger than their sources. Hedges, approximations and confounds survive; hearsay stays hearsay.

Hands off to: hypothesis-comparison when the findings point to several rival explanations for the same observation.

Not for:

• Deciding what to research, which sources to look for and when to stop — research-plan
• Ranking rival explanations for something that happened — hypothesis-comparison
• Turning one thread or transcript into a brief for another skill — brief-intake
• Pulling decisions and action items out of meeting notes — decision-log
• A market or competitor analysis with a framework — strategy-analysis
• Reviewing a document someone else wrote — doc-critique

Loops

research

Take a question that turns on why something happened to an answer the evidence can carry: a plan tied to the decision it serves, a synthesis of the sources with every claim cited, and rival explanations ranked by how little evidence contradicts them, with a gate that sends the work back for the observation that would tell the leaders apart.

Cap: 3 returns before BLOCKED. LOOP.md

Included from core

Installed with this pack. Details: Core pack reference.

• brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.
• context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.
• council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."
• doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.
• output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.

Edit this page on GitHub · View source