problem-validation
The system shouldn't just solve problems, it should say which ones are worth it. This skill is the upstream orchestrator: before building, it validates that the problem is real, that it's worth solving, and that the solution would hold up. Composed from the other two skills + gstack.
When
Before any non-trivial build/investment/pivot. If someone says "let's build X" → first ask
"is the problem behind X real, frequent, and worth it?". If it's a vague idea → first
gstack:spec to make it concrete, then validate.
Pipeline (3 stages, human gate between the important stages)
1. Does the problem exist? → [[focus-group]]
Brings the user's voice on the problem, not the solution. Typical mode: focus group + 1:1 interviews. Questions: does the problem really exist? how much does it hurt? how do people solve it today? Output: the problem is real/imagined, with evidence (quotes, disagreements, kill-signals). If the problem doesn't hold up here → STOP. You just saved a useless build.
2. Is it worth it? → prioritization rubric
If there are multiple candidate problems, score each (1-5) and make the trade-off explicit:
| Criterion | Question |
|---|---|
| Severity | how much does it hurt when it happens? |
| Frequency | how often does it happen / how many people? |
| Reachability | can I actually reach and serve the people who have it? |
| Strategic fit | is it within my mission/unique leverage? (for Roberto: disability/inclusion, Fight the Stroke) |
| Willingness | would they pay / change behavior? (from the focus-group) |
| Cost of being wrong | if I attack the wrong problem, how much do I lose? |
Low score on Reachability or Fit → usually a no, even if Severity is high. Don't sum blindly: make visible where the risk lies.
3. Would the solution hold up? → [[premortem]]
On the winning problem + the proposed solution, launch the premortem: "it's 6 months from now, the solution has failed, why?". Exposes assumptions and produces the revised plan + checklist.
Leverage gstack (don't duplicate)
gstack:spec— turns vague intent into an executable spec before validating.gstack:office-hours— YC-style pressure on the business/go-to-market after validation.gstack:plan-ceo-review/plan-eng-review— once validation becomes a plan. This skill sits upstream (is the problem worth it?); gstack helps downstream (how to execute it).
Output
~/.roberdan-os/reports/problem-validation-<topic>-<date>.md (host-neutral home — not one CLI's own directory):
- Clear recommendation: build / don't build / refine first — with the why.
- Evidence from the focus-group, prioritization table, premortem synthesis.
- The irreducible truth: what's the real thing to decide (first-principles style /
@socrates).
Notes
- Bias-to-kill: this skill's default is skeptical — it's more valuable to say "not worth it"
than to confirm. Compose it with
@socrates(irreducible truth) and@board(red-team). - It's simulation + framework: guides the decision, doesn't make it (human gate).
- Every stage it orchestrates delegates: model, effort and context per [[model-selection-policy]] (mid class by default; the orchestrating session, not the executors, is what may be frontier).
- Voice/decision "as Roberto" → composes with the twin ([[twin]]).