Researching

Researching Skill

Use when the how is unclear; output is a chosen approach with evidence.

Prerequisites: If what/why is unclear, use discovering skill first.

Quick Reference

When to Use

• Requirements are fuzzy or incomplete
• Multiple plausible approaches exist (spike, proof of concept needed)
• Change affects architecture, API, data, or security

Skip if: obvious bug, trivial change, pattern already exists.

Fast vs Full Track

Is it high-risk?
├── No → Fast Track (default)
└── Yes → Full Track
    ├── Changes public API
    ├── Security/data implications
    ├── Team disagreement
    └── Touches multiple subsystems

Core Rule

Evidence before opinions. Never recommend anything until facts are gathered: what already exists in code, which constraints are real, what decisions were made before. If evidence is missing — label it as assumption and lower confidence.

Quick Rules

• One question at a time while clarifying requirements
• If multiple interpretations exist, clarify before researching
• State assumptions explicitly with confidence (H/M/L)

When to Ask vs Act

Ask (one question at a time; prefer multiple choice) if:

• Multiple interpretations
• Critical context missing
• Answer would change direction

Act (state assumptions + confidence) if:

• Default interpretation is clear
• Request is specific
• Assumptions are easy to verify

Workflow

Fast Track (default)

1. Clarify & Frame — purpose, constraints, success criteria
2. Collect Signals — code, docs, history
3. Options + Decision — 2-3 options, pick one
4. Brief — Problem (1-2 sentences), Decision, Key Risks (1-3 bullets)

Full Track

Research Brief template: Problem & Context → Constraints → Current State → Options Compared → Recommendation → Risks

Stop Conditions

Stop research when:

• Decision criteria are satisfied
• Remaining unknowns won't change the decision
• Next step is prototype/measurement

Best Practices

• Assumptions + Confidence — label assumptions (H/M/L), propose quick validation
• Spike as Research — 30-90 min spike with clear question and success metric
• Checkpoints (Full Track) — after each phase: "Constraints complete? Which risks matter?"

Delegate

• Use explorer subagent to collect evidence from code/docs/history and dependency/workspace structure before comparing options
• Use sequential-thinking MCP for complex trade-off analysis

After Research

Use blueprinting skill to create implementation blueprint.

Pipeline: discovering → researching → blueprinting → implementing → code-review

Common Mistakes

Converted and distributed by TomeVault — claim your Tome and manage your conversions.