tech-deep-dive

name	tech-deep-dive
description	Agents should invoke this skill when choosing or evaluating libraries, frameworks, tools, platforms, models, databases, APIs, or architectures for a use case. Produces criteria scoring, ecosystem assessment, and recommendations.

Technology Deep Dive

Evaluate and compare technologies for specific use cases.

If the requesting agent provides a fixed output contract, keep this evaluation process but deliver the final result in the requested structure instead of the default markdown sections below.

Depth and sources per candidate

Depth	When to use	Minimum distinct sources per candidate
Standard	Typical pick-one or compare-a-few decision	≥ 3 (e.g. official docs + registry + one independent benchmark or reputable article)
Deep	High impact, contentious options, or regulatory/security-sensitive choice	≥ 8 across docs, issues, benchmarks, adoption signals, and primary references

If sources fall short, say so explicitly under each candidate and in the recommendation — do not pad with duplicate pages from the same site.

Parallel evaluation

• After Step 2, plan one stream per candidate (or per evaluation axis if fewer round-trips: e.g. all “license + maintenance” queries in one batch, then all “performance” queries).
• Run streams in parallel when the runtime allows: batch web_search / web_fetch per candidate rather than finishing A completely before starting B.
• Merge only in Step 4 — scoring tables and narrative per candidate should be complete before the side-by-side comparison; resolve contradictions during merge.
• Optional: delegate worker-sized shards (one candidate, fixed headings) via subagents when OpenClaw supports it; the lead turn owns Step 4–5.

Evaluation Criteria

Score each technology on these dimensions (1-5 scale):

Criterion	What to Assess
Fitness for purpose	Does it solve the actual problem? How well?
Maturity	Stable releases, battle-tested, production users
Ecosystem	Documentation, community, plugins/extensions, examples
Maintenance health	Recent commits, release cadence, maintainer count
Performance	Benchmarks, known performance characteristics
API quality	Ergonomics, type safety, error handling, learning curve
Integration	Compatibility with current stack (Rust, TS, Python)
License	OSS license compatibility, commercial restrictions

Process

Step 1 — Define the Decision

What exactly are we choosing? What problem does it solve?

**Decision:** Which [category] to use for [purpose] in [project/context]
**Constraints:** [Must support X, must be OSS, must work with Y]
**Current approach:** [What we're doing now, if anything]

Step 2 — Identify Candidates

• Search package registries (crates.io, npm, PyPI)
• Check "awesome-*" lists on GitHub
• Search for comparison blog posts and benchmarks
• Check official documentation recommendations

Step 3 — Evaluate Each Candidate (parallel streams)

For each candidate, produce the block below. Gather evidence in parallel across candidates (see Parallel evaluation), then fill each block before Step 4.

For each candidate:

### [Library Name]

**Version:** X.Y.Z | **License:** MIT | **Stars:** 5.2k | **Last release:** 2026-01-15

**Scores:**
| Criterion | Score | Notes |
|---|---|---|
| Fitness | 4/5 | Covers 90% of use case, missing X |
| Maturity | 5/5 | v3.x, used by [notable projects] |
| Ecosystem | 3/5 | Good docs, small community |
| Maintenance | 4/5 | Monthly releases, 3 maintainers |
| Performance | 4/5 | [benchmark reference] |
| API quality | 5/5 | Excellent types, good error handling |
| Integration | 4/5 | Works with our stack, minor adaptation needed |
| License | 5/5 | MIT, no restrictions |

**Strengths:** [What it does well]
**Weaknesses:** [Where it falls short]
**Risk factors:** [Maintenance, breaking changes, vendor lock-in]

Step 4 — Compare (merge)

Synthesize parallel streams into one view. Side-by-side comparison table:

| Criterion | Option A | Option B | Option C |
|---|---|---|---|
| Fitness | 4/5 | 3/5 | 5/5 |
| Maturity | 5/5 | 4/5 | 2/5 |
| ... | ... | ... | ... |
| **Total** | **33/40** | **28/40** | **30/40** |

Step 5 — Recommend

## Recommendation

**Pick: [Option A]**

**Rationale:** [Why this is the best fit given the constraints]
**Trade-offs:** [What we give up by not choosing alternatives]
**Migration path:** [If switching from current approach, what's involved]
**Risk mitigation:** [How to handle the identified risks]

---

Scout skill — Technology evaluation and comparison · P1 parallel + source floors: 2026-04-10