Tech Deep Dive

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Firstp1ck
• Source: Firstp1ck/pi-coding-agent-forge
• License: MIT

Install and usage instructions live in the source repository linked above.