Tech Selection Research

Research a technology or framework for product R&D decisions. The goal is not a generic overview. The goal is a decision-ready output with evidence, tradeoffs, ADR draft, and validation plan.

Use This Skill For

• Researching a single technology or framework for adoption

• Comparing 2-4 candidate options for a project

• Producing an ADR draft for architecture or framework selection

• Defining a PoC plan and validation checklist

• Producing a trend update for an already adopted technology

Do Not Do

• Do not invent benchmark numbers

• Do not recommend based only on popularity

• Do not ignore migration cost or team capability

• Do not give an absolute answer when key project constraints are missing

Workflow

1. Frame The Decision

Convert "research X" into a decision statement:

• What is being chosen?

• For which product or engineering context?

• New build or brownfield migration?

• What are the hard constraints: language, cloud, compliance, hiring, timeline?

If constraints are missing, make minimal assumptions and label them explicitly.

2. Choose Mode

Pick the lightest mode that matches the request:

• Quick Scan : one technology, fast assessment

• Shortlist Comparison : 2-4 candidates

• Decision Pack : decision-ready report + ADR + PoC

• Trend Update : latest releases, roadmap, upgrade risks

Quick Scan Workflow

Skip weighted matrix and ADR. Output:

• Technology positioning and history

• Fit / not-fit summary for the given context

• Radar classification: Adopt / Trial / Assess / Hold

• Key risks (top 3-5)

• Verdict: worth shortlisting or not, with reasoning

Shortlist Comparison Workflow

Use steps 1, 3, and 4 from the main workflow. Output:

• Candidate landscape (full universe, then scored shortlist)

• Unified dimension comparison table

• Exclusion rationale for dropped candidates

• Recommended shortlist with brief justification per option

Decision Pack Workflow

Follow the full workflow (steps 1-6). This is the default for any non-trivial selection.

Note: Decision Pack consumes 40-60% of the context window (loading references, multiple WebSearch/WebFetch calls, generating a 300-400 line report). If your current session already has substantial conversation history, run /clear first or start a new session to avoid mid-report context compression.

Trend Update Workflow

Skip candidate landscape and weighted matrix. Focus on delta since last assessment. Output:

• Recent releases, breaking changes, deprecations

• Roadmap / RFC / proposal summary

• Maturity change vs last assessment (radar shift)

• Community sentiment changes or emerging concerns

• Upgrade or replacement risks

• Whether the current adoption decision still holds

3. Use Source Hierarchy

Use sources in this order:

• Official docs, release notes, roadmap, RFCs, maintainer material

• Foundation or standards bodies, major engineering blogs, InfoQ, Thoughtworks

• Community tutorials only for supplemental explanation

When current information matters, verify with current sources. Distinguish:

• Verified fact

• Inference from sources

• Requires PoC or benchmark validation

For source rules and evidence labels, read references/source-hierarchy.md .

4. Evaluate On Standard Dimensions

Use the standard dimensions unless the user provides their own:

• Business fit

• Architecture fit

• Team capability fit

• Delivery speed

• Runtime and scalability

• Operability and observability

• Security and compliance

• Ecosystem maturity

• Migration cost

• Long-term evolution

Dimension definitions and scoring guidance are in references/evaluation-framework.md .

Before scoring, map the broader competitor universe. If the space includes multiple paradigm-level alternatives, do not compare only one or two obvious products. Make explicit:

• the full candidate universe worth mentioning

• the scored shortlist

• why some important alternatives were not fully scored

5. Produce Decision Outputs

Default output should contain:

• Executive summary (include radar classification: Adopt / Trial / Assess / Hold)

• Decision context and assumptions

• Candidate landscape

• Evidence-based comparison

• Recommendation with "recommended when" and "not recommended when"

• Risks, unknowns, and tradeoffs

• Community negative feedback and criticism

• Non-fit scenarios

• Important cautions before adoption

• PoC plan

• ADR draft

• Tracking plan

Output structure and ADR template are in references/output-templates.md .

6. Use The Matrix Script When Helpful

If you have structured scores, use:

python3 "$CLAUDE_SKILL_DIR/scripts/build_decision_matrix.py" <input.json>

$CLAUDE_SKILL_DIR is set automatically by Claude Code to the skill's root directory. If running outside Claude Code, substitute the absolute path.

The script expects JSON with weights and options . See the script docstring for shape.

Important Guardrails

• Every recommendation must include:

• Why it fits

• Why it may fail

• What must be validated next

• Every performance or cost claim must cite a source or be marked needs PoC

• Keep alternatives visible. Do not analyze only the named tool if realistic substitutes exist

• Brownfield decisions must include migration and rollback considerations

Language

• Top-level section headings: use English exactly as defined in the output template

• Body content and sub-headings: follow the user's input language

• Evidence labels (Verified , Inference , Needs PoC ): always in English

Output Location

Save the report in the current working directory with the naming pattern: {technology}-decision-pack-{yyyy-mm-dd}.md

For Quick Scan, use {technology}-quick-scan-{yyyy-mm-dd}.md . For Trend Update, use {technology}-trend-update-{yyyy-mm-dd}.md .

Files To Read

• Read references/evaluation-framework.md for scoring dimensions and ATAM-style tradeoff prompts

• Read references/source-hierarchy.md for source priority and evidence labeling

• Read references/output-templates.md for the decision-pack structure, ADR template, and PoC template