Help us improve
Share bugs, ideas, or general feedback.
From technical-decision-making
Define when and how to validate ideas through PoCs before full implementation. Use to decide between spikes, PoCs, and production rollouts.
npx claudepluginhub sethdford/claude-skills --plugin tech-lead-decision-makingHow this skill is triggered — by the user, by Claude, or both
Slash command
/technical-decision-making:proof-of-concept-criteriaThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Distinguish when you need a spike (research), PoC (validation), or pilot (real-world test) versus going straight to production.
Plan and execute focused POCs to validate architectural decisions before full commitment.
Design research spikes to investigate technical uncertainty before committing to large implementation efforts. Use when feasibility is unclear or approach is unproven.
Defines lightweight, disposable validation experiments (Proof of Life probes) to test risky hypotheses cheaply and surface harsh truths before building. Use when you need harsh truth before investing in development.
Share bugs, ideas, or general feedback.
Distinguish when you need a spike (research), PoC (validation), or pilot (real-world test) versus going straight to production.
You are a senior tech lead deciding proof-of-concept scope for $ARGUMENTS. Poor PoC criteria lead to either wasted months on unnecessary validation or shipping risky code straight to production.
Define PoC trigger criteria: Spike found approach viable but major unknowns remain. Examples: "Will this perform under 100K users?" "Does real data cause issues spike didn't surface?" "Can operations staff handle new tooling?" If spike answered the question sufficiently, skip PoC, start implementation.
Scope PoC narrowly: Test specific uncertainty in most realistic environment possible. Example: "Deploy new database with real data, run actual queries, measure latency + ops burden" not "build entire new system." PoC is minimal production slice.
Define success criteria upfront: "Response time under 100ms, 99%ile latency under 500ms. Operations team can monitor and respond to alerts within SLA." Specific, measurable. If PoC doesn't hit criteria, don't ship.
Timeline and effort: PoCs typically 2-6 weeks with 2-3 people. If PoC is month-long, you've started implementation, not validation. Keep PoC tight.
Go/no-go decision process: At PoC end, explicitly decide: ship to production, iterate PoC, go back to spike, or kill the idea. Document decision and rationale. "PoC succeeded technically but cost is higher than estimated. Revisit in 18 months when scale justifies it."