← Back to Document management · project planning pack
See how it helps
Focused technical research
Narrows technical research to a decision with real constraints, existing capabilities and a manageable set of viable alternatives.
research-problem-framing-candidate-discovery
Agents using this skill
When is it useful?
Use it when choosing an algorithm, library or architecture and broad searching has produced too many weak candidates.
What does it help you do?
- Defines decision constraints and early disqualification criteria.
- Audits existing code capabilities before looking externally.
- Narrows solution classes to ranked candidates instead of link lists.
Try asking this
Find a search approach fitting our existing stack, license limits and dataset. Start with our existing search implementation and one representative query set. Reject candidates violating hard constraints before spending time on deeper benchmarks.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Research Problem Framing & Candidate Discovery
Technical research only creates value when it answers a concrete engineering decision. Start every investigation by locking down the decision criteria and checking what the host project already has.
Workflow
- Frame the decision contract upfront:
- Extract from the brief (or define concisely if unstated):
- Problem statement: What exact capability, bottleneck, or integration gap needs solving?
- Must-have constraints: Runtime/language compatibility (e.g., Node/TS, Python, Rust, browser/SSR), performance bounds, offline/local-first requirements, and security posture.
- Hard disqualifiers (dealbreakers): Incompatible licenses (e.g., AGPL/SSPL or missing license), mandatory paid cloud lock-in, native C++ build toolchains where pure JS/WASM is required, or abandoned security-critical dependencies.
- Extract from the brief (or define concisely if unstated):
- Audit the host codebase first:
- Inspect the repository's existing dependencies, internal utilities, and architecture before searching externally.
- Frequently the cleanest solution is an already-installed package, a built-in runtime API, or a 40-line extension of an existing module.
- Search across all four solution classes:
Never limit discovery to "which npm/PyPI package has the most stars". Gather candidates across:
- Direct libraries / SDKs: Focused packages that solve the specific problem.
- Reference implementations & production repos: How established open-source projects implement the mechanism internally.
- Standard protocols & specifications: RFCs, W3C/IETF specs, or wire protocols that can be implemented directly.
- Scoped in-house implementation: What it would take to write and test a small, zero-dependency module ourselves.
- Run a fast triage pass before deep-diving:
- Filter the initial candidate list (10–20 items) down to 2–4 finalists within minutes by checking:
- License presence and compatibility.
- Package manifest (
package.json,Cargo.toml,pyproject.toml) for runtime target and transitive dependency weight. - Whether the core feature actually exists in code rather than on a "Roadmap" section of the README.
- Stop expanding the search once decision-grade candidates are identified.
- Filter the initial candidate list (10–20 items) down to 2–4 finalists within minutes by checking:
Anti-Patterns to Avoid
- Popularity-driven selection: Choosing a 30k-star framework wrapper over a 500-star standards-compliant library without inspecting code quality or fit.
- Unbounded link-dumping: Returning a list of 15 URLs with one-sentence summaries instead of narrowing to ranked, verified finalists.
Included files 1
SKILL.md