Research-Deep 150 Protocol

Core Principle: Research deeply from ALL sources — internal context AND external knowledge. Don't limit yourself to one world.

What This Skill Does

When you invoke this skill, you're researching from TWO worlds:

🏠 INTERNAL (Project Context)

Code — what's already implemented
Git history — why and when things changed
Logs — what actually happened
Config — how things are set up

🌍 EXTERNAL (World Knowledge)

Web search — how others solved similar problems
Documentation — official guidance and specs
Best practices — established patterns
Community — Stack Overflow, GitHub issues, forums

The Two Worlds of Research

🏠 INTERNAL (Project Context)        🌍 EXTERNAL (World Knowledge)
├── Code files                       ├── Web search
├── Git history/blame                ├── Official documentation
├── Comments & inline docs           ├── Stack Overflow / forums
├── Config files                     ├── Blog posts & tutorials
├── Tests (expected behavior)        ├── GitHub issues/discussions
├── Logs (actual behavior)           ├── Best practice guides
└── Project documentation            └── Comparison articles

Key Insight: Most questions need BOTH worlds. Internal tells you "what we have", external tells you "what's possible".

The 150% Research Rule

100% Core: Research from primary relevant sources (internal OR external depending on question)
50% Enhancement: Cross-check with the OTHER world (if started internal → check external, vice versa)

Real-World Research Scenarios

Scenario	Internal Research	External Research
Choosing a library	What's already used? Conflicts?	Comparisons, benchmarks, community health
Legal question	Context, contracts, history	Laws, regulations, precedents
Architecture decision	Current structure, constraints	Patterns, case studies, trade-offs
Bug investigation	Code, logs, git blame	Known issues, similar problems
Performance optimization	Profiling, bottlenecks	Best practices, techniques
Security concern	Current implementation	Vulnerabilities, OWASP, CVEs

When to Use Which Source

🔍 Understanding Existing Code

Question	Best Source	Tools*
"What does this code do?"	Read the code	`read_file`, `grep`
"Why was it written this way?"	Git blame/history	`git log`, `git blame`
"When did this change?"	Git history	`git log --follow`
"What was the original intent?"	Commits + PR descriptions	`git show`, `git log`

🌐 Finding Solutions

Question	Best Source	Tools*
"How do others solve X?"	Web search	`web_search`
"What's the best practice?"	Web + official docs	`web_search`
"Is there a library for X?"	Web + package repos	`web_search`
"What are common pitfalls?"	Web + Stack Overflow	`web_search`

📖 Understanding Context

Question	Best Source	Tools*
"What does this API do?"	Official documentation	`web_search` for docs
"What version is compatible?"	Package docs + changelogs	`web_search`, `read_file`
"How has this evolved?"	Git history	`git log`, `git diff`

*Tool names vary by agent — use equivalent available tools

Tool Abstraction Guide

Different agents have different tool names. Use what's available:

Capability	Claude Code	Codex	Generic
Read files	`read_file`	`view_file`	file reading tool
Search code	`grep`, `codebase_search`	`search`	code search tool
Web search	`web_search`	`search_web`	internet search tool
Run commands	`run_terminal_cmd`	`shell`	terminal/shell tool
Git operations	terminal + git	terminal + git	git via terminal

Rule: Use the tool that achieves the goal, regardless of its name.

Execution Protocol

Step 1: IDENTIFY WHAT YOU NEED

Clarify the knowledge gap:

What exactly do I need to know?
Is this about existing code or new solutions?
Do I need history/context or just current state?

Step 2: SELECT SOURCES

Choose appropriate sources based on need:

Need to understand existing code?
  → Read code + git history + comments

Need to find a solution approach?
  → Web search + best practices + similar projects

Need to debug something?
  → Logs + git blame + error searches

Need to integrate with external system?
  → Official docs + web search + examples

Step 3: GATHER FROM MULTIPLE SOURCES

Minimum 3 sources for important facts:

Primary source (code, official docs)
Secondary source (explanations, tutorials)
Validation source (tests, examples, community)

Step 4: CROSS-VALIDATE

Check for consistency:

Do sources agree?
Are there contradictions?
Which source is most authoritative?

Step 5: SYNTHESIZE

Combine findings into verified knowledge:

Core facts (verified)
Context (understood)
Confidence level (quantified)

Git History: Your Hidden Knowledge Source

Git history is often overlooked but invaluable:

When to Use Git

Situation	Git Command	What You Learn
"Why is this code weird?"	`git blame <file>`	Who wrote it and when
"What was the intent?"	`git log -p <file>`	Changes over time
"When did this break?"	`git bisect`	Which commit caused issue
"What changed recently?"	`git log --since="1 week"`	Recent modifications
"How did this function evolve?"	`git log -p -S "function_name"`	History of specific code

Git Evidence Patterns

bash

# Who wrote this line and why?
git blame path/to/file.js

# What changed in this file and why?
git log -p --follow path/to/file.js

# Find when a specific line was added
git log -S "specific code" --oneline

# What happened around a date?
git log --since="2024-01-01" --until="2024-02-01"

Web Search: Your External Brain

Web search is essential for:

Best practices and patterns
How others solved similar problems
Library/API documentation
Error message solutions
Community knowledge

Effective Web Search Patterns

"How to [specific task] in [language/framework]"
"[error message] solution"
"[library name] best practices"
"[problem] vs [alternative] comparison"
"[technology] production tips"

Output Format

When using Research-Deep 150:

🔬 **Research-Deep 150 Complete**

**Question:** [What we needed to know]

**🏠 Internal Research:**
- 📁 Code: [what we found in codebase]
- 📜 Git: [what history revealed]
- 📋 Context: [relevant project facts]

**🌍 External Research:**
- 🌐 Web: [what we found online]
- 📖 Docs: [official documentation]
- 💡 Best Practices: [established patterns]

**Synthesis:**
[Combined understanding from BOTH worlds]

**Recommendation:** [What to do based on research]

**Confidence:** [X]%
**Sources agree:** [Yes/Partial/No]
**Gaps:** [What we still don't know]

Evidence Quality Levels

Level	Sources	Confidence
Strong	3+ agreeing sources, primary data	90-100%
Good	2-3 sources, mostly agree	75-89%
Moderate	1-2 sources, some assumptions	50-74%
Weak	Single source or contradictions	<50%

Operational Rules

NEVER SINGLE SOURCE: Important facts need 3+ sources
USE ALL AVAILABLE: Code, git, web, docs — use what's relevant
CONTEXT MATTERS: Choose sources based on what you need to know
GIT IS GOLD: History often explains the "why"
WEB FOR PATTERNS: Others have solved your problem before
CROSS-VALIDATE: Sources should agree or explain why not
QUANTIFY CONFIDENCE: State how sure you are and why

Examples

❌ Without Research-Deep

Question: "Which date library should we use?"
AI: "Use moment.js, it's popular" (outdated advice)
Result: Chose deprecated library, had to migrate later

✅ With Research-Deep 150

Question: "Which date library should we use?"

🔬 Research-Deep 150:

🏠 Internal Research:
- 📁 Code: Currently using native Date, some formatting issues
- 📋 Context: Need timezone support, bundle size matters
- 📜 Git: Previous attempt with moment.js reverted (too heavy)

🌍 External Research:
- 🌐 Web: "best javascript date library 2024"
- 📖 Docs: Compared date-fns, dayjs, luxon
- 💡 Best Practices: moment.js deprecated, modern alternatives exist

Synthesis:
- moment.js is deprecated (external confirms)
- We tried it before, too heavy (internal confirms)
- date-fns: modular, tree-shakeable, good for bundle size
- dayjs: moment-like API, small size
- luxon: best for complex timezone work

Recommendation: dayjs for simple needs (2KB), date-fns for complex (modular)

Confidence: 92%

✅ Legal Question Example

Question: "Can we use this image in our product?"

🔬 Research-Deep 150:

🏠 Internal Research:
- 📁 Found image in /assets/hero.jpg
- 📜 Git: Added 2 years ago, no license info in commit
- 📋 Context: Used on marketing page

🌍 External Research:
- 🌐 Reverse image search: Found on Unsplash
- 📖 Unsplash license: Free for commercial use, no attribution required
- 💡 Best Practice: Still good to keep license record

Recommendation: Safe to use. Document source in assets README.

Confidence: 95%

Failure Modes & Recovery

Failure	Detection	Recovery
Internal only	No external perspective	Add web search, docs
External only	Ignoring project context	Check code, git, configs
Guessing	No sources cited	Stop, research properly
Outdated info	Old articles, deprecated advice	Check dates, find current sources
One world bias	Only looking at one side	Deliberately check the other world

Relationship to Other Skills

Skill	Focus
goal-clarity-150	WHAT we need to know
research-deep-150	WHERE to find answers (internal + external)
deep-think-150	HOW to reason about findings
impact-map-150	WHAT the findings affect

Remember: Most questions need BOTH worlds. Internal context tells you "what we have and why". External knowledge tells you "what's possible and what others learned". Deep research combines both for complete understanding.

Search AI Tools

research-deep-150

Install this agent skill to your Project

SKILL.md