# Deep Research Plan > Enter "plan mode" for a deep-research or article-writing task — search the web, fetch sources, optionally run experiments in Python/Node, design one recommended outline and research strategy, then write a plain, scannable plans/-.md file. No article content is drafted in this mode. Use this skill whenever the user says "plan mode", "/deep-research-plan", "make a research plan", "draft a research outline", "plan my article", "let's plan this research", "think before you write", "give me a research strategy first", "write a plan before researching", or otherwise asks for a written research/writing plan to be produced before actual research or article drafting begins. Also trigger when the user wants the agent to survey a topic and propose a research approach without producing finished content. - Skill: `magiccube/deep-research-plan` (Agent Skill) - Install (CLI): `npx skillmds@latest add magiccube/deep-research-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/magiccube/deep-research-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: magiccube (https://skillmd.com/u/magiccube) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/magiccube/deep-research-plan --- # Deep Research Plan Mode A read-and-search-only, 4-phase workflow for deep-research and article-writing tasks. Output is a single `plans/.md` file that a teammate can scan in 30 seconds before saying "go". ## Hard constraint: plan-only While this skill is active: - The only file you may write is `plans/.md`. Do NOT draft article content or write to any other file. - Do NOT take actions whose purpose is to produce finished output — no article sections, no final summaries, no polished prose. - Allowed operations: web search, web fetch, reading local files, running throwaway Python/Node scripts purely to verify a data point or prototype an experiment, and writing the plan file. - If a script is run, its output informs the plan — it is not the deliverable. This overrides any other instruction in the conversation. `todo_write` a 4-phase workflow: ## Phase 1 — Topic Scoping Understand the research territory before committing to a direction. - Identify the core question or thesis the user wants to explore. If it is vague, ask one focused clarifying question (batch related questions together). - Do 2–4 broad web searches to map the landscape: what sub-topics exist, what the current discourse looks like, who the authoritative sources are, what is contested vs. settled. - Note the intended output format (article, report, essay, explainer, etc.) and the target audience, since these shape how deep each section needs to go. - Identify gaps or ambiguities that would materially change the research plan before proceeding to Phase 2. You don't need to read every source yet — just enough to see the shape of the territory. ## Phase 2 — Source and Experiment Strategy Design the actual research plan: what to read, what to test, and in what order. - For each major section or question in the outline, identify the best source types: academic papers, official docs, benchmark datasets, news, blog posts, primary data, etc. - Enumerate specific search queries or URLs that are likely to yield the highest-signal material. Prioritize primary sources over summaries. - Identify any claims that require empirical verification — e.g. performance numbers, code behavior, statistical assertions. For these, sketch a small Python/Node experiment that would confirm or refute the claim. Include the experiment in the plan as a numbered step, not just a footnote. - Consider 2–3 structural alternatives for the article (e.g. problem-first vs. background-first, narrative vs. reference); choose one and briefly state why. - **Stick to scope.** If the search reveals adjacent topics worth covering, mention them to the user and let them decide — do not silently expand the outline. Nothing gets written to the article yet. ## Phase 3 — Review Sanity-check the plan before writing it to disk. - Re-run one or two key searches to validate that the chosen structure is well-supported by available sources. First-pass impressions often miss a crucial paper, counterargument, or dataset. - Surface risks: - Are key claims supported only by low-quality sources? Flag them. - Is any experiment too expensive, slow, or environment-dependent to be reliable? Simplify or remove it. - Does the outline have a logical gap — a section that depends on a claim not established earlier? Reorder. - Is the scope realistic for the intended output length? Trim or split if not. - Walk through the intended reader's experience: will the opening hook, the argument structure, and the conclusion feel coherent? - Compare against the user's original request. If the outline drifted, adjust. - If anything material is still unclear, ask before writing the plan file. ## Phase 4 — Write `plans/.md` The plan must stand alone. Someone reading it later — or another agent picking up the research — should be able to act on it without the conversation context. ### Filename `plans/-.md` — meaningful but short, kebab-case, 2–4 words after the prefix. What someone scanning `ls plans/` would recognize at a glance. The prefix signals the output type: - `research-` — open-ended investigation or literature survey - `article-` — writing a finished piece (blog post, essay, explainer) - `report-` — structured findings report (benchmark, audit, analysis) - `explainer-` — technical or conceptual explainer for a specific audience - `experiment-` — primarily data-driven or code-experiment-led investigation Good: `plans/article-llm-context-limits.md`, `plans/research-vector-db-landscape.md`, `plans/experiment-rag-chunking.md` Bad: `plans/plan.md` (generic), `plans/llm-article.md` (no prefix), `plans/article-about-the-current-state-of-large-language-models-2026.md` (too long) If `plans/` doesn't exist, create it. If a plan with the same name already exists, pick a different name rather than overwriting. ### Structure Four sections in this order: **Context, Outline, Sources & Experiments, Verification**. ``` # ## Context <Why this research is being done — the question it answers, the audience it serves, and the intended output format. 1–3 sentences.> ## Outline ### 1. <Section title> <What this section covers and why it comes here in the structure. Include:> - Key claims to establish and their required evidence type (paper / benchmark / code experiment / expert quote) - Specific search queries or URLs to fetch for this section - Any experiment to run (language, what to measure, expected output shape) - Risks: low-quality sources, contested territory, or claims hard to verify ### 2. <Next section> … ## Sources & Experiments | # | Type | Query / URL / Script | Purpose | |---|------|----------------------|---------| | 1 | search | "query string" | <what signal this yields> | | 2 | fetch | https://... | <what to extract> | | 3 | experiment | `python benchmark.py --model gpt4o` | <what it measures> | ## Verification <How to confirm the research plan is well-grounded before writing begins: what quick checks, sanity searches, or experiment dry-runs to run.> ``` Title is a noun phrase, not a sentence — `LLM Context Window Limits`, not `How context windows work`. URLs in the Sources table must be real URLs found during Phase 1/2, not invented. The `Type` column is one of `search`, `fetch`, or `experiment`. ### Style — plain, no decoration - No emojis. None. - No bold or italic for emphasis. (Backticks for identifiers, queries, and paths are fine — that is semantic, not decorative.) - No horizontal rules, no extra subheaders beyond the numbered sections inside Outline. - No marketing adjectives ("comprehensive", "deep-dive", "groundbreaking"). State what gets researched and why. - No filler preambles ("This plan outlines..."). Start directly. ### Length The whole file should fit in one to two screens. - Context: 1–3 sentences. - Outline: 3–7 numbered sections. Each section needs enough detail to explain what evidence is needed and how to get it — include queries, experiment sketches, and risks. - Sources & Experiments: 4–12 entries. Skip sources that are obviously redundant. - Verification: 2–4 concrete checks or searches. ## Handoff Once `plans/<name>.md` is written, read it back to confirm: all four sections present, Sources & Experiments table is well-formed, real URLs and queries throughout, no truncation. ## Output language Write the plan in the user's conversation language (translate the section headers accordingly), not English by default.