# Feature Feasibility Experiment > Designing and evaluating the smallest PoC or experiment that resolves one decision-relevant uncertainty in a Product Feature or Tech Feature. Use when feasibility, compatibility, capacity, integration behavior, or a risky technical premise cannot be established from existing evidence and a bounded experiment can decide the next step. Does not produce production implementation, replace an ADR, or run broad exploratory research without a decision and threshold. - Skill: `robsonkades/feature-feasibility-experiment` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add robsonkades/feature-feasibility-experiment` - Raw SKILL.md: https://api.skillmd.com/api/skills/robsonkades/feature-feasibility-experiment/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: robsonkades (https://skillmd.com/u/robsonkades) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/robsonkades/feature-feasibility-experiment --- # Feature Feasibility Experiment ## Purpose A PoC earns its cost only when its result changes a named decision. This skill turns “try it and see” into a bounded experiment with a falsifiable hypothesis, threshold, evidence, conclusion, and cleanup. ## Workflow 1. **Name one uncertainty.** Trace it to `U-*`, a solution option, `ED-*`, contract, `RISK-*`, or technical premise. State what supported, refuted and inconclusive results change. Reuse existing identifiers or source links; do not invent accepted criteria or authority. 2. **Use existing evidence first.** Repository facts, vendor specifications, prior measurements, or a smaller static check may settle it without a PoC. 3. **Write the hypothesis and threshold before acting.** A result without a predeclared boundary is a useful exploratory observation, but does not validate a pass criterion selected afterwards. Derive the threshold from the decision/requirement, including units, population, window and acceptable uncertainty where relevant; keep an unapproved proposed threshold explicit. 4. **Choose the cheapest valid experiment.** Minimize code, environment, data, duration, and side effects while preserving the condition that matters. Read [Experiment record](references/experiment-record.md) for the required fields. 5. **Separate prototype from production.** Name shortcuts, excluded qualities, disposal plan, and anything the experiment cannot establish. 6. **Run only when authorized and safe.** Prefer isolated/local environments and synthetic or approved data. Do not mutate production, contact external parties, or incur material cost without explicit authority. Reuse authorization already established in the task/session; a template's approval field does not impose another approval round for authorized reversible local work. 7. **Read and preserve evidence.** Record commands, versions, inputs, raw results, repetitions, and anomalies. First verify the experiment exercised the intended condition: zero tests, an unavailable dependency or a broken harness cannot establish feasibility. Separate execution status from `SUPPORTED`, `REFUTED`, or `INCONCLUSIVE`; no valid result means no pass/fail claim. 8. **Feed the result back.** Update or reopen the affected option, decision, contract, risk, depth, and Product question. A conclusion never silently becomes production design. ## Decision rules ```text IF pass and fail would lead to the same decision THEN do not run the experiment. IF the experiment omits the condition that creates the uncertainty THEN it cannot answer the question, however convincing the demo looks. IF a threshold is chosen after seeing results THEN label the result exploratory and run a confirmatory experiment before deciding. IF the result is inconclusive THEN identify the missing discriminator and next useful action. Preserve the unresolved item; mark it an accepted GAP-* only when the appropriate authority actually accepts it. IF prototype code would enter production THEN it becomes a planned RES-* and must satisfy ordinary architecture, security, testing, and review. ``` ## Constraints - One experiment answers one material uncertainty; split independent hypotheses. - Time-boxing limits cost but does not define success. Always state a decision threshold. - Declare validity conditions and stopping rules as well as pass/fail criteria. A timebox exhausted before a valid measurement is inconclusive, not evidence the option is infeasible. - Do not use production data unless its use and handling are explicitly authorized. - Do not claim scalability, reliability, or security beyond the conditions actually exercised. - Do not repair a prototype by silently changing the target JDK, dependency, environment or compatibility requirement. Record the mismatch and test an allowed alternative or new revision. ## Output ```text Experiment EXP-01 Trace <U/ED/CT/RISK/TC IDs> Owner <engineering owner> Execution <planned/not run/running/finished/cancelled; reason if not run> Question <one uncertainty> Decision <what pass, fail, and inconclusive change> Hypothesis <falsifiable claim> Threshold <observable pass/fail boundary> Method <environment, inputs, controls, repetitions, validity and stopping rule> Limits <what this cannot establish> Evidence <EV-* links, commands and raw results> Conclusion <pending before evaluation; then SUPPORTED | REFUTED | INCONCLUSIVE> Consequences <items confirmed, reopened, made stale, or added> Cleanup <disposed artefacts or promoted RES-*> ``` For a request to design an experiment, return the reviewable plan with execution pending; do not invent results. For an authorized execution request, run the bounded experiment and report actual results or the concrete blocker. Preserve reproducible evidence before removing only identified experiment-owned artefacts; never delete unrelated workspace or user data.