Feasibility Debate Team

Problem Being Solved

When evaluating a technical design, startup idea, or business decision, the common failure mode is not missing data but one-sided reasoning: supporters only list favorable evidence, critics only flag risks, and the final conclusion lacks a shared table of evidence, trade-offs, and residual risk. The Feasibility Debate Team structures that evaluation so the system stress-tests the same question from both sides instead of producing a single polished answer.

How It Works

The skill assembles a temporary discussion group from three roles:
- Moderator: sets the rules, guides the speaking order, and produces a neutral summary.
- Pro-debater: argues feasibility from market demand, business model, competitive advantage, and timing, while citing concrete data where possible.
- Con-debater: acts as devil’s advocate by surfacing logic gaps, resource constraints, execution difficulty, and competitive threats.

A typical run starts by confirming the debate topic, available materials, and the dimensions the user cares about. It then creates the debate team with team_create, launches the three roles in parallel with task, and waits for their arguments to complete. The final output combines the core pro arguments, key con challenges, a neutral assessment matrix, and an actionable recommendation. The temporary team can be cleaned up with team_delete afterward.

Boundaries And Notes

This skill is best for decisions that benefit from multi-angle reasoning, such as validating a startup idea, choosing between architecture options, or evaluating market entry. It is less useful for pure factual lookups, standard-answer questions, or cases where the user only wants a single voice. The con-debater should raise constructive challenges, the final recommendation should specify next actions, and any weak evidence or unstated assumptions should be called out explicitly.