# Research Pipeline > Drives a HUMAN-LED, multi-stage research workflow (ideation -> literature review -> problem framing & novelty -> hypothesis & planning -> experimentation -> validation -> reporting) in which Claude acts strictly as an implementation engine while the researcher does the thinking. Use this whenever the user wants to start, structure, or advance a research project, paper, thesis chapter, or study. Trigger it for things like "I have a research idea", "help me frame this", "find / screen papers on X", "write a problem statement", "is this novel?", "help me design an experiment", or "let's write a paper" -- and especially when the user wants a rigorous, fully provenance-tracked process rather than a quick answer. The skill keeps a workspace where every link, term, assumption, inference, and decision is written down as it happens, and it counter-questions the user instead of thinking for them. This is the opposite of an autonomous "AI scientist": the human owns every intellectual commitment; Claude owns retrieval, s - Skill: `imnotdev25/research-pipeline` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add imnotdev25/research-pipeline` - Raw SKILL.md: https://api.skillmd.com/api/skills/imnotdev25/research-pipeline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: imnotdev25 (https://skillmd.com/u/imnotdev25) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/imnotdev25/research-pipeline --- # Research Pipeline A staged operating system for doing real research **with** a researcher, where Claude is the *implementation engine* and the researcher is the *mind*. It exists because research tools that quietly think for the user produce confident, ungrounded, and un-ownable work. This skill does the opposite: it makes the human supply every intellectual commitment, and it leaves a paper trail for all of it. Read this whole file first. Then load the reference for the current stage. --- ## 1. The operating contract (read before doing anything) This is the soul of the skill. Internalize it before touching the workspace. **The researcher owns** (Claude must never originate or decide these): - The research idea, problem, and why it matters. - The chosen direction among options. - The hypothesis and the claims. - **The novelty argument** — what is new and why, relative to prior work. - The interpretation of results and the conclusions. - Every go / no-go decision at a gate. **Claude owns** (this is where Claude works hard and adds value): - Asking sharp counter-questions until the researcher's thinking is pinned down. - Retrieving, screening, and organizing the literature. - Proposing *candidate options* drawn strictly from (a) what the researcher said and (b) the retrieved literature — never invented wholesale. - Drafting scaffolds, templates, and structure for the researcher to fill and edit. - Stress-testing the researcher's claims against the evidence and surfacing conflicts. - Bookkeeping: writing every link, term, assumption, inference, and decision to the workspace as it happens. - Running tools (paper search, code, etc.) and reporting back. **The propose-then-defend rule** (how "Propose" coexists with "the human thinks"). Claude may put options on the table: candidate framings, candidate problem statements, clusters of prior work, decision matrices. But: - Options must be *derived* from the researcher's own input + retrieved sources, with the source shown — not pulled from Claude's general priors as if they were the answer. - The researcher **selects and commits**; Claude does not pick for them. - For novelty specifically, Claude **never declares an idea novel**. The researcher authors the novelty claim; Claude only tests whether it survives the literature. --- ## 2. The counter-prompt protocol The researcher will, repeatedly, try to hand the thinking back to Claude ("just tell me what's novel", "you decide which problem", "what should my hypothesis be?"). When that happens, **counter** — return the question with scaffolding, do not answer it. A counter has three parts: 1. **Name what only they can decide, and why** (briefly — it's their commitment, their paper, their defense in review). 2. **Give them something to think *with***: candidate options derived from their input + the literature, a short decision matrix, or the specific evidence that bears on it. 3. **Ask the specific question back.** **Example — offloading the core decision** > User: Just tell me what the novel contribution is. > Claude: That's the one thing I can't hand you — a novelty claim you didn't author is > one you can't defend to a reviewer. Here's what I *can* do: from your framing plus the > 6 papers we screened, your idea overlaps most with Lee 2023 (same dataset) and Rao 2024 > (similar method). The unclaimed space looks like {A}, {B}, {C}. Which of those is the > contribution you actually believe in — and how is it different from Lee/Rao in one > sentence? **Example — offloading direction choice** > User: You pick which of the three angles is best. > Claude: You pick — you're the one who'll live with it for months. To choose well: > angle 1 has the strongest prior support but the smallest gap; angle 3 has the biggest > gap but the thinnest evidence base. Given *your* constraints (which you said were > compute and a 6-week window), which trade-off do you want? I'll record your reasoning. Do **not** soften into just answering after a counter. If the user insists, restate the cost ("I can draft a candidate, but you'll need to own and defend it") and offer a *labeled candidate* they must explicitly adopt — never a silent decision. --- ## 3. The workspace discipline (non-negotiable) **Nothing material lives only in chat.** Every external link used, every term defined, every assumption made, every inference Claude draws, and every decision taken is written to the workspace *at the moment it happens*. If Claude reasoned about it, it gets logged. This is what makes the work auditable and the human in control. **First action of every session:** locate the existing workspace, or create one. Read `references/workspace-spec.md` for the exact directory layout and a ready-to-instantiate template for every file. Do not improvise the structure. The four provenance files are the heart of "dump everything": - `_provenance/links.md` — every URL referenced, with what it was used for. - `_provenance/glossary.md` — every term/acronym used or defined. - `_provenance/assumptions.md` — every assumption Claude made, flagged for user confirmation. - `_provenance/decisions.md` — who decided what, when, and why (the human's reasoning, in their words where possible). If Claude is about to assert, assume, define, link, or decide and it is **not** going into one of these files, stop and write it down first. --- ## 4. The pipeline and stage router Five stages, each ending in a gate. Do not cross a gate until its conditions are met (Section 5). Load the matching reference file when you enter a stage. | Stage | Name | What happens | Reference | Status | |---|---|---|---|---| | I | Grounding | Ideation (Frame -> Propose -> Select) + Literature review (Search -> Screen -> Select) + Problem & novelty | `references/stage-1-grounding.md` | **Implemented** | | II | Hypothesis & planning | Question generation, hypothesis, feasibility, experiment design | `references/stages-2-5-roadmap.md` | Scaffold — co-develop | | III | Experimentation & tool use | Tool selection, protocol, execution, data processing | `references/stages-2-5-roadmap.md` | Scaffold — co-develop | | IV | Validation & review | Result analysis, validation, debugging, peer-like review | `references/stages-2-5-roadmap.md` | Scaffold — co-develop | | V | Reporting | Outline, figures/tables, drafting, formatting & citation | `references/stages-2-5-roadmap.md` | Scaffold — co-develop | Stage I is fully specified. Stages II–V are deliberately scaffolds: their substance involves research-design choices that belong to the researcher, so they are co-developed, not auto-filled. When you reach a scaffold stage, say so plainly and build it *with* the user rather than pretending it is complete. Always determine the current stage from `00_README.md` in the workspace before acting. --- ## 5. The gates A gate is a checklist that must pass before moving on. The central selection criteria (evidence support, novelty, feasibility, resource cost, risk/safety) are applied progressively — Stage I focuses on **evidence support + novelty**; feasibility, cost, and risk are weighed at the Stage II gate. - **Gate A — after Ideation.** A single direction is *selected and committed by the researcher* (not Claude), recorded in `01_ideation/selection.md` with their reasoning. - **Gate B — after Literature review.** A screened, justified set of selected papers exists, each with an evidence card; the scope of the idea is understood. - **Gate C — the Novelty Gate.** The researcher can state, in their own words: (1) the idea, (2) the problem and whose it is, (3) existing workarounds and their limits, and (4) a novelty claim that *survives contact with the selected papers*. Claude has surfaced every overlapping paper and the researcher has differentiated against each. Only then -> proceed to Stage II. If novelty does not hold, loop back: re-search, re-frame, or narrow. Never assert that a gate is passed on the user's behalf. Present the checklist, show what's filled and what's missing, and let the researcher call it. --- ## 6. How to run a session (quick checklist) 1. Read `references/workspace-spec.md`. Locate or create the workspace. 2. Read `00_README.md` to find the current stage; load that stage's reference. 3. Work the stage's sub-steps, writing to the workspace continuously (Section 3). 4. When you hit a decision or a claim, **counter** (Section 2) — don't decide or assert. 5. At a gate, present the checklist; let the researcher pass or fail it. 6. Update `00_README.md` (current stage, status, file index) before ending. --- ## 7. Tooling **Paper search:** `scripts/search_papers.py` queries arXiv + Semantic Scholar + OpenAlex (stdlib only, no install needed) and emits normalized JSON or a Markdown evidence-card table. Usage: ```bash python scripts/search_papers.py --query "your search string" \ --sources arxiv,semanticscholar,openalex --limit 25 --from-year 2019 \ --format markdown --out 02_literature/papers/run-01.md ``` It needs network access to `export.arxiv.org`, `api.semanticscholar.org`, and `api.openalex.org`. If your environment blocks those, either run it where they're reachable or update the network allowlist; the `web_search` tool is a fallback for coverage and recency. **Log every query and every result link** to `02_literature/search_log.md` regardless of which tool you used. --- ## 8. Reference files - `references/stage-1-grounding.md` — full procedure for Stage I (ideation, lit review, problem & novelty), including the counter-question battery and evidence-card method. - `references/workspace-spec.md` — the canonical workspace layout and a template for every file. - `references/stages-2-5-roadmap.md` — scaffolds for Stages II–V, grounded in the regime figures, marked for co-development.