solution-candidate-design
Solution Candidate Design
Purpose
Take a validated (or validating) idea and produce a small set of concrete, comparably-scoped solution candidates — not one recommendation. Each candidate is a real option: fork and extend an existing open-source repo, build from scratch with a specific architecture, or compose the product from existing managed services/APIs. Each gets a grounded architecture sketch, stack, effort estimate, and honest tradeoffs, laid out side by side so the user can make the call themselves.
This is the natural step after solution-feasibility-study (and optionally audience-behavior-study) — feasibility asks "should we build this," audience research asks "who for and how do we talk to them," this skill asks "what are the concrete ways we could actually build it." It also works as a direct entry point: a user with an idea and no prior study can jump straight here.
This skill designs and compares candidates. It does not pick a winner, does not write production code, and does not scaffold a repository — hand off to repo-init (and ai-config) once the user has chosen a direction.
Platform Adaptation
Before starting the interview, load the reference file for the current agent environment and follow its tool guidance (shared with repo-init, solution-feasibility-study, and audience-behavior-study):
Prefer the platform's native structured question/input tool over plain chat whenever one exists.