| name | fpf-variants |
| description | Explore the solution space by generating ≥3 genuinely distinct variants within the chosen method family. Think through alternatives using the portfolio template as scaffolding. |
| argument-hint | [problem-or-decision-context] |
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
# 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 |
