research-patterns
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:
- Official documentation — language docs, framework docs, RFCs
- Authoritative GitHub repos — reference implementations, official examples
- Stack Overflow — accepted answers with high votes, verify currency
- 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
More from akaszubski/autonomous-dev
git-github
Git workflow and GitHub collaboration patterns including conventional commits, branch naming, PR workflow, and gh CLI usage. Use when creating commits, branches, or pull requests. TRIGGER when: git commit, branch, PR, pull request, merge, gh cli. DO NOT TRIGGER when: code implementation, testing, documentation without git operations.
26library-design-patterns
Two-tier design, progressive enhancement, non-blocking patterns, and security-first architecture for Python libraries. Use when creating or refactoring Python libraries. TRIGGER when: library design, module architecture, reusable component, two-tier. DO NOT TRIGGER when: simple scripts, config files, documentation-only changes.
26scientific-validation
Scientific method for validating claims with pre-registration, power analysis, statistical rigor, and Bayesian methods. Use when testing hypotheses, running experiments, or validating claims from papers. TRIGGER when: validate, hypothesis, experiment, backtest, evidence, statistical test. DO NOT TRIGGER when: routine coding, config changes, documentation, non-experimental tasks.
24state-management-patterns
JSON persistence, atomic writes, file locking, crash recovery, and state versioning patterns. Use when implementing stateful libraries or features requiring persistent state. TRIGGER when: state persistence, atomic write, file locking, crash recovery, checkpoint. DO NOT TRIGGER when: stateless utilities, pure functions, config reads, documentation.
22code-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 new code, debugging, refactoring without review context.
22api-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: internal library code, CLI tools, non-HTTP interfaces.
22