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
| Track |
When |
Output |
| Fast (default) |
Standard decisions |
Brief: problem, decision, risks |
| Full |
API/security/multi-subsystem |
Research brief + optional design doc |
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)
- Clarify & Frame — purpose, constraints, success criteria
- Collect Signals — code, docs, history
- Options + Decision — 2-3 options, pick one
- Brief — Problem (1-2 sentences), Decision, Key Risks (1-3 bullets)
Full Track
| Phase |
Focus |
Output |
| 0. Frame |
Problem, non-goals, success criteria |
Constraints |
| 1. Signals |
Code, docs, history |
Current state + assumptions |
| 2. Options |
2-4 approaches with trade-offs |
Comparison |
| 3. Evaluate |
Decide using Phase 0 criteria |
Recommendation + fallback plan |
| 4. Artifacts |
Research brief (always) |
Optional: design doc |
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?"
Common Mistakes
| Mistake |
Fix |
| Recommend without evidence |
Gather facts first, then opinions |
| Single option, no alternatives |
Always 2-3 options with trade-offs |
| Drift into tangential topics |
Stay connected to problem statement |
| Hide uncertainty behind confidence |
State unknowns explicitly |
| Finalize with disputed framing |
Resolve framing first |
1---2name: researching3description: Use when requirements are fuzzy, multiple technical approaches exist, or change affects architecture, API, data, or security4---5
6# Researching Skill
7
8Use when the how is unclear; output is a chosen approach with evidence.
9
10**Prerequisites:** If what/why is unclear, use **discovering** skill first.
11
12## Quick Reference
13
14| Track | When | Output |
15| -------------- | ---------------------------- | ------------------------------------ |
16| Fast (default) | Standard decisions | Brief: problem, decision, risks |
17| Full | API/security/multi-subsystem | Research brief + optional design doc |
18
19## When to Use
20
21- Requirements are fuzzy or incomplete
22- Multiple plausible approaches exist (spike, proof of concept needed)
23- Change affects architecture, API, data, or security
24
25Skip if: obvious bug, trivial change, pattern already exists.
26
27## Fast vs Full Track
28
29```
30Is it high-risk?
31├── No → Fast Track (default)
32└── Yes → Full Track
33 ├── Changes public API
34 ├── Security/data implications
35 ├── Team disagreement
36 └── Touches multiple subsystems
37```
38
39## Core Rule
40
41**Evidence before opinions.** Never recommend anything until facts are gathered:
42what already exists in code, which constraints are real, what decisions were
43made before. If evidence is missing — label it as assumption and lower
44confidence.
45
46## Quick Rules
47
48- One question at a time while clarifying requirements
49- If multiple interpretations exist, clarify before researching
50- State assumptions explicitly with confidence (H/M/L)
51
52## When to Ask vs Act
53
54**Ask** (one question at a time; prefer multiple choice) if:
55
56- Multiple interpretations
57- Critical context missing
58- Answer would change direction
59
60**Act** (state assumptions + confidence) if:
61
62- Default interpretation is clear
63- Request is specific
64- Assumptions are easy to verify
65
66## Workflow
67
68### Fast Track (default)
69
701. **Clarify & Frame** — purpose, constraints, success criteria
712. **Collect Signals** — code, docs, history
723. **Options + Decision** — 2-3 options, pick one
734. **Brief** — Problem (1-2 sentences), Decision, Key Risks (1-3 bullets)
74
75### Full Track
76
77| Phase | Focus | Output |
78| ------------ | ------------------------------------ | ------------------------------ |
79| 0. Frame | Problem, non-goals, success criteria | Constraints |
80| 1. Signals | Code, docs, history | Current state + assumptions |
81| 2. Options | 2-4 approaches with trade-offs | Comparison |
82| 3. Evaluate | Decide using Phase 0 criteria | Recommendation + fallback plan |
83| 4. Artifacts | Research brief (always) | Optional: design doc |
84
85**Research Brief template:** Problem & Context → Constraints → Current State →
86Options Compared → Recommendation → Risks
87
88## Stop Conditions
89
90Stop research when:
91
92- Decision criteria are satisfied
93- Remaining unknowns won't change the decision
94- Next step is prototype/measurement
95
96## Best Practices
97
98- **Assumptions + Confidence** — label assumptions (H/M/L), propose quick
99 validation
100- **Spike as Research** — 30-90 min spike with clear question and success metric
101- **Checkpoints (Full Track)** — after each phase: "Constraints complete? Which
102 risks matter?"
103
104## Common Mistakes
105
106| Mistake | Fix |
107| ---------------------------------- | ----------------------------------- |
108| Recommend without evidence | Gather facts first, then opinions |
109| Single option, no alternatives | Always 2-3 options with trade-offs |
110| Drift into tangential topics | Stay connected to problem statement |
111| Hide uncertainty behind confidence | State unknowns explicitly |
112| Finalize with disputed framing | Resolve framing first |
majiayu000