/research-patterns
4-phase research methodology: codebase recon, targeted web search, deep source analysis, and evidence synthesis. Use when investigating patterns, evaluating libraries, or analyzing best practices. TRIGGER when: research, investigate, evaluate options, compare libraries. DO NOT
$ npx -y skills add akaszubski/autonomous-dev --skill research-patterns --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/research-patterns
Context preview
The summary Claude sees to decide when to auto-load this skill.
4-phase research methodology: codebase recon, targeted web search, deep source analysis, and evidence synthesis. Use when investigating patterns, evaluating libraries, or analyzing best practices. TRIGGER when: research, investigate, evaluate options, compare libraries. DO NOT
SKILL.md
research-patterns.SKILL.mdname: research-patterns
description: "4-phase research methodology: codebase recon, targeted web search, deep source analysis, and evidence synthesis. Use when investigating patterns, evaluating libraries, or analyzing best practices. TRIGGER when: research, investigate, evaluate options, compare libraries. DO NOT TRIGGER when: implementation tasks, bug fixes, routine code changes."
allowed-tools: [WebSearch, WebFetch, Read, Grep, Glob]
Research Patterns Enforcement Skill
Ensures every research task follows a consistent, evidence-based methodology. Used by the researcher and researcher-local agents.
4-Phase Research Methodology
Every research task MUST follow these phases in order.
Phase 1: Codebase Recon
- Grep/Glob for existing patterns that relate to the task
- Identify what the codebase already does (avoid reinventing)
- Note file locations, naming conventions, architectural patterns
- Document existing test patterns for the area
Phase 2: Targeted Web Search
- Formulate 2-3 specific search queries
- Include the current year in queries for freshness (e.g., "JWT best practices 2026")
- Search for official documentation first
- Search for known issues or CVEs if security-related
Phase 3: Deep Fetch Top Sources
- Fetch the top 2-3 most relevant results
- Extract specific code examples, configuration snippets, or API references
- Note version numbers and compatibility requirements
- Record URLs for citation
Phase 4: Synthesis with Gap Analysis
- Compare findings against existing codebase patterns
- Identify gaps between current implementation and best practices
- Produce structured recommendations with tradeoffs
- Flag risks and unknowns explicitly
---
Source Hierarchy
When sources conflict, prefer in this order:
1. **Official documentation** — language docs, framework docs, RFCs 2. **Authoritative GitHub repos** — reference implementations, official examples 3. **Stack Overflow** — accepted answers with high votes, verify currency 4. **Blog posts / tutorials** — cross-reference with official docs
Every recommendation MUST include at least one URL source.
---
HARD GATE: Research Output
**FORBIDDEN**:
- Recommending an approach without citing sources
- Using "I think" or "I believe" without supporting evidence
- Skipping codebase search (Phase 1) and jumping straight to web
- Single-source recommendations — minimum 2 sources for any recommendation
- Presenting opinions as facts
- Ignoring existing codebase patterns in favor of greenfield approaches
**REQUIRED**:
- Minimum 3 sources cited across the research output
- Existing codebase patterns identified first (Phase 1 before Phase 2)
- Tradeoffs stated for every recommendation (pros AND cons)
- Structured output in the format below
- Version/date noted for all external sources
- Risks section with at least one identified risk
---
Required Output Format
{
"findings": "Summary of what was discovered",
"sources": [
{"url": "https://...", "title": "...", "relevance": "..."},
{"url": "https://...", "title": "...", "relevance": "..."},
{"url": "https://...", "title": "...", "relevance": "..."}
],
"existing_patterns": [
{"file": "path/to/file.py", "pattern": "description", "reusable": true}
],
"recommendations": [
{
"approach": "description",
"pros": ["..."],
"cons": ["..."],
"effort": "low/medium/high"
}
],
"risks": [
{"risk": "description", "mitigation": "how to handle", "severity": "low/medium/high"}
]
}---
Anti-Patterns
BAD: Vague "best practice" without citation
"The best practice is to use dependency injection."
No source, no context, no tradeoffs. Useless as research output.
GOOD: Cited recommendation with tradeoffs
"Dependency injection is recommended by the Python Packaging Guide
(https://packaging.python.org/...) for testability. Tradeoff: adds
indirection that can make debugging harder for small projects."
BAD: Ignoring existing codebase patterns
Recommending a completely new auth library when the codebase already uses a working pattern. Always check what exists first.
BAD: Single-source echo chamber
Reading one blog post and presenting its opinion as the definitive answer. Cross-reference with at least one other source.
GOOD: Multiple sources with synthesis
"Three sources agree on token rotation (RFC 6749 Section 10.4,
OWASP Cheat Sheet, and the existing auth.py pattern at line 42).
The codebase already implements refresh tokens; recommend extending
rather than replacing."
---
Cross-References
- **security-patterns**: Security-specific research requirements
- **architecture-patterns**: How research feeds into architecture planning
Read more
name: research-patterns description: "4-phase research methodology: codebase recon, targeted web search, deep source analysis, and evidence synthesis. Use when investigating patterns, evaluating libraries, or analyzing best practices. TRIGGER when: research, investigate, evaluate options, compare libraries. DO NOT TRIGGER when: implementation tasks, bug fixes, routine code changes." allowed-tools: [WebSearch, WebFetch, Read, Grep, Glob]
Research Patterns Enforcement Skill
Ensures every research task follows a consistent, evidence-based methodology. Used by the researcher and researcher-local agents.
4-Phase Research Methodology
Every research task MUST follow these phases in order.
Phase 1: Codebase Recon
- Grep/Glob for existing patterns that relate to the task
- Identify what the codebase already does (avoid reinventing)
- Note file locations, naming conventions, architectural patterns
- Document existing test patterns for the area
Phase 2: Targeted Web Search
- Formulate 2-3 specific search queries
- Include the current year in queries for freshness (e.g., "JWT best practices 2026")
- Search for official documentation first
- Search for known issues or CVEs if security-related
Phase 3: Deep Fetch Top Sources
- Fetch the top 2-3 most relevant results
- Extract specific code examples, configuration snippets, or API references
- Note version numbers and compatibility requirements
- Record URLs for citation
Phase 4: Synthesis with Gap Analysis
- Compare findings against existing codebase patterns
- Identify gaps between current implementation and best practices
- Produce structured recommendations with tradeoffs
- Flag risks and unknowns explicitly
---
Source Hierarchy
When sources conflict, prefer in this order:
1. **Official documentation** — language docs, framework docs, RFCs 2. **Authoritative GitHub repos** — reference implementations, official examples 3. **Stack Overflow** — accepted answers with high votes, verify currency 4. **Blog posts / tutorials** — cross-reference with official docs
Every recommendation MUST include at least one URL source.
---
HARD GATE: Research Output
**FORBIDDEN**:
- Recommending an approach without citing sources
- Using "I think" or "I believe" without supporting evidence
- Skipping codebase search (Phase 1) and jumping straight to web
- Single-source recommendations — minimum 2 sources for any recommendation
- Presenting opinions as facts
- Ignoring existing codebase patterns in favor of greenfield approaches
**REQUIRED**:
- Minimum 3 sources cited across the research output
- Existing codebase patterns identified first (Phase 1 before Phase 2)
- Tradeoffs stated for every recommendation (pros AND cons)
- Structured output in the format below
- Version/date noted for all external sources
- Risks section with at least one identified risk
---
Required Output Format
{
"findings": "Summary of what was discovered",
"sources": [
{"url": "https://...", "title": "...", "relevance": "..."},
{"url": "https://...", "title": "...", "relevance": "..."},
{"url": "https://...", "title": "...", "relevance": "..."}
],
"existing_patterns": [
{"file": "path/to/file.py", "pattern": "description", "reusable": true}
],
"recommendations": [
{
"approach": "description",
"pros": ["..."],
"cons": ["..."],
"effort": "low/medium/high"
}
],
"risks": [
{"risk": "description", "mitigation": "how to handle", "severity": "low/medium/high"}
]
}---
Anti-Patterns
BAD: Vague "best practice" without citation
"The best practice is to use dependency injection."
No source, no context, no tradeoffs. Useless as research output.
GOOD: Cited recommendation with tradeoffs
"Dependency injection is recommended by the Python Packaging Guide (https://packaging.python.org/...) for testability. Tradeoff: adds indirection that can make debugging harder for small projects."
BAD: Ignoring existing codebase patterns
Recommending a completely new auth library when the codebase already uses a working pattern. Always check what exists first.
BAD: Single-source echo chamber
Reading one blog post and presenting its opinion as the definitive answer. Cross-reference with at least one other source.
GOOD: Multiple sources with synthesis
"Three sources agree on token rotation (RFC 6749 Section 10.4, OWASP Cheat Sheet, and the existing auth.py pattern at line 42). The codebase already implements refresh tokens; recommend extending rather than replacing."
---
Cross-References
- **security-patterns**: Security-specific research requirements
- **architecture-patterns**: How research feeds into architecture planning
A harness that wraps Claude Code with enforcement, specialist agents, and alignment gates to deliver consistent, production-grade software engineering outcomes.
Repo: akaszubski/autonomous-dev
Other skills on autonomous-dev.
- /api-design
REST API design best practices covering versioning, error handling, pagination, and OpenAPI documentation. Use when designing or implementing REST APIs or HTTP endpoints. TRIGGER when: API design, REST endpoint, HTTP route, OpenAPI, swagger, pagination. DO NOT TRIGGER when:
Open skill - /api-integration-patterns
Subprocess safety, GitHub CLI integration, retry logic, authentication, rate limiting, and timeout handling. Use when integrating external APIs or CLI tools. TRIGGER when: subprocess, gh cli, API call, retry logic, rate limiting, authentication. DO NOT TRIGGER when: internal
Open skill - /architecture-patterns
File-by-file architecture planning with ADR format, dependency ordering, and testability gates. Use when designing system architecture or creating ADRs. TRIGGER when: architecture plan, system design, ADR, file breakdown, component design. DO NOT TRIGGER when: simple config
Open skill - /code-review
10-point code review checklist covering correctness, tests, error handling, type hints, naming, security, and performance. Use when reviewing PRs or evaluating code quality. TRIGGER when: code review, PR review, review checklist, code quality check. DO NOT TRIGGER when: writing
Open skill - /content-allocation
One topic, one home. Routes content to its canonical store (CLAUDE.md, PROJECT.md, MEMORY.md, docs/, memory/) and audits for duplication. TRIGGER when: auditing CLAUDE.md/PROJECT.md/MEMORY.md sizes, deduplicating docs, applying the content-allocation pattern to a new repo,
Open skill - /debugging-workflow
Systematic debugging methodology — reproduce, isolate, bisect, fix, verify. Use when diagnosing failures, tracing errors, or investigating unexpected behavior. TRIGGER when: debug, error, traceback, stack trace, bisect, breakpoint, failing test, unexpected behavior. DO NOT
Open skill

