fpf-variants

## What this skill IS This is **creative solution exploration**, not box-checking. You are exploring the solution space — generating diverse alternatives, characterizing trade-offs, identifying stepping stones. The goal is NOT to produce 3 trivially different options — it's to map the landscape of possible approaches. **Work through the template as scaffolding.** Generate variants BY filling the template, not in chat first. ## Prerequisites - PROB-* or ANOM-* exists with acceptance spec - STRAT-* exists with method family bet (T4 required; T3 recommended if available. If missing at T4: invoke `/fpf-sota` first) - CHR-* exists with comparison indicators (if missing: invoke `/fpf-characterize` first) ## Generation guidance **Diversity strategies (pick at least one):** - **Decomposition:** Break the problem into sub-problems, solve each differently - **Analogical:** Import patterns from different domains/stacks - **Constraint relaxation:** What if we dropped constraint X? What becomes possible? - **Inversion:** Solve the opposite problem. What if we optimized for a different indicator? - **Extreme points:** What's the simplest possible? Most sophisticated? Most unusual? **Test for genuine distinctness:** If two variants differ only in a parameter value or minor implementation detail, they are NOT distinct. Distinct means different trade-off profiles — different points on the Pareto front. **Stepping stones matter:** A variant that isn't the best today but opens new search spaces (new tools, new data, new interfaces) has option value. Don't discard it — mark it as a stepping stone. ## Output `.fpf/portfolios/SPORT-${CLAUDE_SESSION_ID}--<slug>.md` ## Format rules (hooks check these patterns) - Variants MUST be labeled `V1`, `V2`, `V3` etc. — as heading (`### V1: name`) or table row (`| V1 |`) - This is required for mechanical validation by hooks ## Constraints (quality bar) - **C1:** Minimum 3 variants — no exceptions - **C2:** Variants must be genuinely distinct (different trade-off profiles, not parameter tweaks) - **C3:** ≥1 variant must be non-obvious (not the incremental improvement everyone would try first) - **C4:** All variants within the method family from STRAT-* (T4 required; T3 can generate variants without formal strategy) - **C5:** NQD per CHR indicators: D_c (eligibility) → Q per indicator (multi-dimensional, not single ordinal) → N, D_p (tie-breakers) - **C6:** Stepping stones identified — non-dominant variants with future option value - **C7:** Active portfolio selected with rationale per acceptance criteria - **C8:** Each variant MUST identify its weakest link (WLNK) — the component, assumption, or dependency that bounds overall quality. If a variant adds components beyond the simplest alternative, state the MONO justification. ## Format ```markdown # Solution Portfolio - **ID:** SPORT-... **Problem:** PROB-... **Strategy:** STRAT-... ## Generation method - Method: (decomposition|analogical|constraint-relaxation|inversion|extreme-points) - Diversity strategy: (how did you ensure genuine distinctness?) ## Variants ### V1: [name] Description. Trade-off profile. - D_c: Pass/Fail - Q: [per CHR indicator — e.g., "latency: Low, maintainability: High, cost: Med"] - WLNK: [weakest link — what component/assumption bounds quality] - N: Low/Med/High - D_p: Low/Med/High ### V2: [name] ... ### V3: [name] ... ## Stepping stones | Variant | Opens what future space | Risk of discarding | ## Active portfolio | Priority | Variant | Rationale | Next action | ```