research
SolidResearches an open-ended question — options, possible solutions, prior art, trade-offs, or how something works — and produces a durable, evidence-backed, adversarially-validated report that recommends an option without committing the team to any artifact. Use when you want to research approaches, weigh options, survey prior art or the state of the art, or understand how something works before committing to a direction — including 'what are my options for X', 'should I use A or B', 'what's the landscape for Y'. Reaches the codebase, the open web, and any material you provide. Does not diagnose a bug, failure, or root cause — use investigate. Does not specify a feature — use plan-a-feature. Does not create or update a coding standard — use coding-standard. Does not compare two concrete artifacts for gaps — use gap-analysis. Does not assess an existing module's architecture — use architectural-analysis. Does not capture feedback on Han's own skills — use han-feedback.
Install
Quality Score: 91/100
Skill Content
Details
- Author
- testdouble
- Repository
- testdouble/han
- Created
- 3 weeks ago
- Last Updated
- today
- Language
- Shell
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
research
Enriches context with researched information from the codebase, the web, and public repositories. Produces a cited research report. Use this Skill to close knowledge gaps before conceptualizing or designing — e.g. from a research prompt generated by /analyze.
research
Investigates codebases with a facts-before-opinions discipline — building a complete factual picture before interpreting what it means for the work ahead. Produces a structured research document saved to disk, split into observations and implications. Use when you need to understand existing code, patterns, dependencies, and constraints. Also use when the user says "research this", "explore the codebase", "investigate", "what does this code do", or "understand the system".
research-brief
Investigate a problem, feature, or project idea and produce a structured research brief with findings, recommended approach, and open questions. Use when the user wants to understand the technical landscape before building — comparing libraries, frameworks, patterns, or approaches. Triggers include "research this", "investigate", "what are the options for", "how should I approach", "what tools exist for", "compare approaches to", "do a deep dive on", "technical research for", or any situation where the user needs to gather information and form a recommendation before committing to an implementation path. Also use when a requirements document or tracked issue exists and needs technical investigation before a spec can be written.
research
Gather facts and context from codebase, docs, and web,... Use when exploring patterns, finding implementations, looking up documentation, or researching before decisions.
architectural-analysis
Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase — including requests to audit module boundaries, check for architectural smells, or inform refactoring decisions. Requires a specific focus area (module, directory, or component) to analyze. Not for creating new project structures, scaffolding, or boilerplates. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for writing documentation or architectural decision records.