Oleksandr Bezdieniezhnykh
7.9 KiB
name, description, category, tags, disable-model-invocation
| name | description | category | tags | disable-model-invocation | |||||
|---|---|---|---|---|---|---|---|---|---|
| research | 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" | build |
|
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.mdandacceptance_criteria.mdare optional — warn if absent, proceed if user confirms- Mode detection uses OUTPUT_DIR for
solution_draft*.mdscanning - 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.