---
name: research
description: |
  Deep Research Methodology (8-Step Method) with two execution modes:
  - Mode A (Initial Research): Assess acceptance criteria, then research problem and produce solution draft
  - Mode B (Solution Assessment): Assess existing solution draft for weak points and produce revised draft
  Supports project mode (_docs/ structure) and standalone mode (@file.md).
  Auto-detects research mode based on existing solution_draft files.
  Trigger phrases:
  - "research", "deep research", "deep dive", "in-depth analysis"
  - "research this", "investigate", "look into"
  - "assess solution", "review solution draft"
  - "comparative analysis", "concept comparison", "technical comparison"
category: build
tags: [research, analysis, solution-design, comparison, decision-support]
disable-model-invocation: true
---

# Deep Research (8-Step Method)

Transform vague topics raised by users into high-quality, deliverable research reports through a systematic methodology. Operates in two modes: **Initial Research** (produce new solution draft) and **Solution Assessment** (assess and revise existing draft).

## Core Principles

- **Conclusions come from mechanism comparison, not "gut feelings"**
- **Pin down the facts first, then reason**
- **Prioritize authoritative sources: L1 > L2 > L3 > L4**
- **Intermediate results must be saved for traceability and reuse**
- **Ask, don't assume** — when any aspect of the problem, criteria, or restrictions is unclear, STOP and ask the user before proceeding
- **Internet-first investigation** — do not rely on training data for factual claims; search the web extensively for every sub-question, rephrase queries when results are thin, and keep searching until you have converging evidence from multiple independent sources
- **Multi-perspective analysis** — examine every problem from at least 3 different viewpoints (e.g., end-user, implementer, business decision-maker, contrarian, domain expert, field practitioner); each perspective should generate its own search queries
- **Question multiplication** — for each sub-question, generate multiple reformulated search queries (synonyms, related terms, negations, "what can go wrong" variants, practitioner-focused variants) to maximize coverage and uncover blind spots

## Context Resolution

Determine the operating mode based on invocation before any other logic runs.

**Project mode** (no explicit input file provided):
- INPUT_DIR: `_docs/00_problem/`
- OUTPUT_DIR: `_docs/01_solution/`
- RESEARCH_DIR: `_docs/00_research/`
- All existing guardrails, mode detection, and draft numbering apply as-is.

**Standalone mode** (explicit input file provided, e.g. `/research @some_doc.md`):
- INPUT_FILE: the provided file (treated as problem description)
- BASE_DIR: if specified by the caller, use it; otherwise default to `_standalone/`
- OUTPUT_DIR: `BASE_DIR/01_solution/`
- RESEARCH_DIR: `BASE_DIR/00_research/`
- Guardrails relaxed: only INPUT_FILE must exist and be non-empty
- `restrictions.md` and `acceptance_criteria.md` are optional — warn if absent, proceed if user confirms
- Mode detection uses OUTPUT_DIR for `solution_draft*.md` scanning
- Draft numbering works the same, scoped to OUTPUT_DIR
- **Final step**: after all research is complete, move INPUT_FILE into BASE_DIR

Announce the detected mode and resolved paths to the user before proceeding.

## Project Integration

Read and follow `steps/00_project-integration.md` for prerequisite guardrails, mode detection, draft numbering, working directory setup, save timing, and output file inventory.

## Execution Flow

### Mode A: Initial Research

Read and follow `steps/01_mode-a-initial-research.md`.

Phases: AC Assessment (BLOCKING) → Problem Research → Tech Stack (optional) → Security (optional).

---

### Mode B: Solution Assessment

Read and follow `steps/02_mode-b-solution-assessment.md`.

---

## Research Engine (8-Step Method)

The 8-step method is the core research engine used by both modes. Steps 0-1 and Step 8 have mode-specific behavior; Steps 2-7 are identical regardless of mode.

**Investigation phase** (Steps 0–3.5): Read and follow `steps/03_engine-investigation.md`.
Covers: question classification, novelty sensitivity, question decomposition, perspective rotation, exhaustive web search, fact extraction, iterative deepening.

**Analysis phase** (Steps 4–8): Read and follow `steps/04_engine-analysis.md`.
Covers: comparison framework, baseline alignment, reasoning chain, use-case validation, deliverable formatting.

## Solution Draft Output Templates

- Mode A: `templates/solution_draft_mode_a.md`
- Mode B: `templates/solution_draft_mode_b.md`

## Escalation Rules

| Situation | Action |
|-----------|--------|
| Unclear problem boundaries | **ASK user** |
| Ambiguous acceptance criteria values | **ASK user** |
| Missing context files (`security_approach.md`, `input_data/`) | **ASK user** what they have |
| Conflicting restrictions | **ASK user** which takes priority |
| Technology choice with multiple valid options | **ASK user** |
| Contradictions between input files | **ASK user** |
| Missing acceptance criteria or restrictions files | **WARN user**, ask whether to proceed |
| File naming within research artifacts | PROCEED |
| Source tier classification | PROCEED |

## Trigger Conditions

When the user wants to:
- Deeply understand a concept/technology/phenomenon
- Compare similarities and differences between two or more things
- Gather information and evidence for a decision
- Assess or improve an existing solution draft

**Differentiation from other Skills**:
- Needs a **visual knowledge graph** → use `research-to-diagram`
- Needs **written output** (articles/tutorials) → use `wsy-writer`
- Needs **material organization** → use `material-to-markdown`
- Needs **research + solution draft** → use this Skill

## Stakeholder Perspectives

Adjust content depth based on audience:

| Audience | Focus | Detail Level |
|----------|-------|--------------|
| **Decision-makers** | Conclusions, risks, recommendations | Concise, emphasize actionability |
| **Implementers** | Specific mechanisms, how-to | Detailed, emphasize how to do it |
| **Technical experts** | Details, boundary conditions, limitations | In-depth, emphasize accuracy |

## Source Verifiability Requirements

Every cited piece of external information must be directly verifiable by the user. All links must be publicly accessible (annotate `[login required]` if not), citations must include exact section/page/timestamp, and unverifiable information must be annotated `[limited source]`. Full checklist in `references/quality-checklists.md`.

## Quality Checklist

Before completing the solution draft, run through the checklists in `references/quality-checklists.md`. This covers:
- General quality (L1/L2 support, verifiability, actionability)
- Mode A specific (AC assessment, competitor analysis, component tables, tech stack)
- Mode B specific (findings table, self-contained draft, performance column)
- Timeliness check for high-sensitivity domains (version annotations, cross-validation, community mining)
- Target audience consistency (boundary definition, source matching, fact card audience)

## Final Reply Guidelines

When replying to the user after research is complete:

**Should include**:
- Active mode used (A or B) and which optional phases were executed
- One-sentence core conclusion
- Key findings summary (3-5 points)
- Path to the solution draft: `OUTPUT_DIR/solution_draft##.md`
- Paths to optional artifacts if produced: `tech_stack.md`, `security_analysis.md`
- If there are significant uncertainties, annotate points requiring further verification

**Must not include**:
- Process file listings (e.g., `00_question_decomposition.md`, `01_source_registry.md`, etc.)
- Detailed research step descriptions
- Working directory structure display

**Reason**: Process files are for retrospective review, not for the user. The user cares about conclusions, not the process.