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:

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]]).