Tech Selection

Tech Selection — Gated Checklist

A checklist for choosing between technologies, not a scoring rubric. The core insight: these criteria are filters, not sorters — they kill candidates that violate a principle. Which candidate to adopt is not the agent's decision: when two or more candidates survive, return candidates + trade-offs + a recommendation to the user. Never a single pick.

Two outcomes end the protocol early:

1. Multi-candidate human tradeoff — ≥2 survivors after filtering. Stop and return.
2. Unverified completion claim — the artifact claims done but has not been probed. Stop and return.

Not This

• Not for research reports (use deep-research), debugging or bug fixes in already-settled code, or price comparisons between vendors — none of these is choosing a technology.
• Not an interview framework — the user delegates implementation, not direction. Don't ask "which do you prefer" when you can probe and decide.
• Not a scoring rubric — no weighted scores, no "winner" ranking. Filters, then business anchor.
• Not self-certifying — the "why this isn't garbage" defense is written by this skill but must be independently checkable, not self-approved.
• Not a cost gate — budget sets execution tier (which model runs), never whether to do it. Don't use cost as a rejection reason for the user's own projects.
• Not a scope expander — no unrequested features, frameworks, or complexity.
• Not package-size-driven — line count and bundle size are proxies, not quality.

Execution Protocol

Lightweight path. A choice is reversible, local, under 10 minutes, and has no external contract → run Steps 0, 1, and 3 only, record the business result and the prior-art layer, and proceed. Skip Steps 2, 4, 5, 6, and 7. Choosing a JSON library inside a bug fix is this path; choosing the project's storage engine is not. When unsure which path applies, take the full protocol.

Step 0 · Frame

Write two things before comparing any candidate:

1. The named business result this choice serves.
2. The named failure mode — what observable phenomenon would prove the choice wrong.

Derive the business result from context, not from the request text. A bare "which DB" carries no result on its face — read the project's decision log, the user's recent corrections, and what this choice unblocks downstream. If no context exists to derive from, say so explicitly rather than fabricating one.

Checkpoint: Cannot derive a business result from any available context → this is an execution task, not a selection task. Exit skill. Business result written as "tests pass" or "pipeline complete" → that's a proxy metric. Rewrite.

Step 1 · Inventory Prior Art

Fixed order: internal/paid assets → external world-class + community solutions → build from scratch (last resort). Tag each candidate with which layer it came from.

Where to look for layer 1: existing credentials and paid-service capability catalogues, installed skills, the current repository's existing pipelines, the project's decision log, and the user's own curated favorites (run favorites-search first when it is installed). Do not limit layer 1 to grep in the current repo — that returns zero hits for paid services and skills, and a zero from a narrow search is not absence.

Layer 2 has a minimum coverage requirement: use a search tool to enumerate what exists, not memory alone. "Searched, found 2" is not coverage — name the search queries run, or state explicitly that no search tool was available and this is a memory-only inventory.

Checkpoint: If the final recommendation falls to layer 3 (build) with no recorded reason from layers 1–2 → flag as 闭门造车. Zero hits from layer 1 must distinguish "searched by structural token" from "searched by remembered name" — the latter's zero hit does not mean absence.

User-named candidates. When the user names a specific option ("use Redis or Postgres?", "should we add a vector store?"), that option enters the candidate set like any other — it is subject to the same axes and the same three-value verdict. It is neither exempt from filtering (a named candidate is not a requirement) nor disposable (killing a user-named candidate requires naming the axis and the failure mode, exactly like any other). If the user named exactly two options, they are the minimum candidate set; add any layer-1 or layer-2 candidates the inventory surfaced, and say so.

Step 2 · Probe for Evidence

The only admissible evidence is behavior you ran and observed. READMEs, vendor pages, docs, and source-code claims are all downgraded. Termination clause: max two attempts across methods per candidate; two failures → "this cannot be done now."

Checkpoint: Every load-bearing claim must name its probe. A claim sourced only from a README → mark unknown, not pass.

Step 3 · Filter Each Candidate

Read references/decision-axes.md. For each candidate, give a three-value verdict per axis: pass / fail (name the failure mode) / unknown (needs probe).

A fail on a core axis kills the candidate. A fail on a C-class criterion from references/scoped-criteria.md does not kill — record it as a "declared preference against" note on that candidate and continue. Only core-axis failures remove a candidate from the survivor set.

Checkpoint: unknown is not pass. A candidate carrying unknown does not enter the Step 4 survivor set. Do not output a "winner" from this step.

Step 4 · Triage Survivors — The Core Gate

• 0 survivors: Report which axis killed which candidate, and whether the axis was wrong or the candidate set was incomplete. If candidates died from unknown rather than fail, the honest output is: each candidate, the probe it stalled on, and what input the user could supply to unblock it. Do not fabricate a verdict to escape the zero.
• 1 survivor: May declare only if all three autonomy conditions hold: long-term maintainable, industry best practice, 100% confidence. If any is missing → treat as ≥2 survivors and stop. Must also carry the Step 5 self-defense.
• ≥2 survivors: STOP. Return candidates + trade-offs + one recommendation. Do not single-pick. Do not silently drop rejected candidates.

Checkpoint: Can the output name which candidate was demoted and by which axis? If not, the gate was hollowed out.

Step 5 · Self-Defense Slot

Any conclusion produced by this skill carries a "why this isn't garbage" paragraph, and it must not be self-certified by this skill alone.

Checkpoint: Every sentence in the self-defense traces to a probe or an axis verdict. Generic principles (e.g. "it's a mature library") = invalid.

Step 6 · Saturate Irreversible Surfaces

Scan for surfaces that cannot be patched after release: telemetry/events, field and export formats, external contracts, irreversible external actions. If any exist → saturate from v0. This axis is single-scenario evidence — apply it when the choice produces a released artifact, not to internal or revertible changes, and never use it to raise the standard on work that has no irreversible surface.

Checkpoint: Explicitly list irreversible surfaces, or explicitly write "none." Silence = not checked. Revertible local changes do not trigger this step.