Research
- When to use it
- 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.
- Covers
- Research a question (3)
- Where you decide
- G7 review — research → compare
- Size
- 8 skills · 1 loop · 1 gate, 1 needs a person
An hour to plan and an hour to synthesise, plus however long the research takes a session
npx skilldrop-cli install --pack research
Installs 8 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack research
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install research@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack research --ide cursor
Start here: Turn a vague research request into a plan you can finish
Paste this into your agent:
I need to research whether our 14-person support team should move to a four-day week. Our COO decides by 1 November. I have about 20 hours and can pull ticket data from Zendesk.
- Before you start
- A question you need answered and the decision it feeds; for synthesis, the text of your sources, not just titles
- How to tell it worked
- research-plan writes a plan that opens with the decision, the decider and the date, then gives three to six sub-questions, each with a finding that would change the decision, a method, search strings, and a stopping rule with a budget cap.
- If nothing happens
- If you get a plan built around a decision you didn't give, say who decides what and by when, and run it again. If research-plan does not activate, ask for it by name ("use research-plan").
A typical session
When: You've been asked to look into something before a decision, and you need an answer you can defend, with sources. About An hour to plan and an hour to synthesise, plus however long the research takes.
You bring:
- the decision the research feeds, who makes it, and by when
- the time you have
- the sources you collect: papers, reports, articles or interview transcripts, as text
- any data or observations, if the question is why something happened
-
- You
- Say what decision the research is for, then give it the topic and your time budget.
- You get
- A two-page plan: the precise question, sub-questions with the finding that would change the decision, a method for each, inclusion criteria, search strings, and a stopping rule.
- You decide
- Agree the thresholds before you start, so the findings can't be read to fit.
-
- You
- Hand it the sources you collected, as text, with the plan's question.
- You get
- What the sources support on the question, each claim traceable to its source, with disagreements and echoes made explicit, the sources' own sums checked, labelled estimates where a figure is needed, and the gaps. Ask for a cited literature review to get page-level citations and strength ratings.
-
- You
- If the question is why something happened, give it the observation and the cited findings.
- You get
- A consistency matrix ranking the explanations by the evidence against them, the evidence the ranking rests on, and the next observation that would tell the leaders apart.
- You decide
- Act on the leading explanation, or run the next observation first.
You end with: A decision-led plan, a synthesis that keeps what the sources say apart from everything else, and, for why-questions, a ranked set of explanations with the next test to run.
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.
plan → synthesise → compare [G7]
Compare Research with another pack
Skills in this pack (3)
- 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. Use 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". heavy
- 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. Use 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. standard
- 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. Use 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". standard
Included from core (5)
- 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. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- 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. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- 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." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- 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. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- 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. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard