do-research

name	do.research
description	Plan and execute checkpointed deep research for technologies, concepts, papers, or complex questions. Use when the user asks for deep research, a literature review, evidence synthesis, or a durable research note in their DeepOrbit vault.

Deep Research

Produce evidence-backed research while preserving progress in a Markdown plan. Runtime-native goals, trackers, or subagents may accelerate the work but are never required.

1. Establish context

1. Run deeporbit --vault "<vault>" rag "<topic>" to find related notes. If the CLI is unavailable, inspect 20_Projects, 30_Research, and 40_Wiki directly.
2. Read 99_System/Prompts/Research_Sources.md when it exists.
3. Identify the question, intended depth, existing knowledge, related project, and output language from deeporbit.json.
4. Ask only for choices that materially change the research.

2. Create a checkpoint plan

Write 90_Plans/Plan_YYYY-MM-DD_Research_<Topic>.md:

---
deeporbit_workflow: 1
workflow_id: research-<date>-<slug>
status: active
topic: <topic>
---

# Research Plan: <Topic>

## Goal
<Decision or understanding this work must enable>

## Existing knowledge
- Related notes: [[...]]
- Related project: [[...]]

## Checklist
- [ ] Search primary and official sources
- [ ] Search independent secondary sources
- [ ] Compare claims and record contradictions
- [ ] Draft the main research note
- [ ] Extract durable atomic concepts
- [ ] Verify citations, links, and completeness

Let the user review the plan when the scope is broad, expensive, or ambiguous. Otherwise continue.

3. Execute with checkpoints

• Work through the checklist in dependency order and mark each item immediately after it succeeds.
• Continue in the same turn while context and tool limits allow.
• If interrupted, reread the plan and resume at the first unchecked item.
• When the runtime exposes a Goal or Task Tracker, attach the plan's goal to it. Never store the only copy of progress in runtime state.
• Do not use external self-invocation extensions, headless loops, or completion-promise polling.

Prefer primary sources. For current facts, browse and cite. Record sources beside supported claims and state uncertainty or disagreement explicitly.

4. Write durable outputs

• Main note: 30_Research/<Area>/<Topic>/<Topic>.md
• Atomic concepts: 40_Wiki/<Category>/<Concept>.md
• Supporting files: 30_Research/<Area>/<Topic>/assets/

Use frontmatter at line 1 with type, created, area, tags, and status. Put related links in a final ## Related Reading section, not frontmatter. Keep atomic concepts focused.

5. Verify and finish

Before setting the plan to status: complete:

• Every checklist item is checked.

• Major claims have working sources.

• Contradictions and limitations are visible.

• Output files exist at the planned paths.

• Wikilinks resolve or are intentionally marked as future concepts.

• Set author: ai in frontmatter for every note you create; switch to author: mixed when substantially rewriting a human-authored note. Authorship lives in frontmatter only — never add visible badges. Link the result from today's Daily Note. Open the main note using do.obsidian-open; inability to launch Obsidian is non-fatal.