Add cognitive bias checks to specification workflow

[danielbentes]

Context

Mycelium maps 20+ cognitive biases (confirmation bias, anchoring, Dunning-Kruger, sunk cost) to each development phase and provides explicit bias-check and devil's-advocate skills. BDSK captures assumptions via /assume but doesn't challenge them — assumptions are accepted at face value if a human approves them.

Current State

The /assume skill captures assumptions as structured records with impact levels, but there is no adversarial step that challenges whether assumptions are biased, overconfident, or based on insufficient evidence. The /approve workflow applies approval without questioning the underlying reasoning.

Objective

BDSK should include a mechanism to challenge assumptions and specifications before approval, surfacing potential cognitive biases and blind spots that could lead to incorrect implementations.

Acceptance Criteria

• A /bias-check skill (or step within /specify) challenges behavior specs and assumptions before approval
• High-impact assumptions (impact_level: high or critical) trigger an automatic devil's-advocate review
• The bias check surfaces at least 3 common biases relevant to the specification: confirmation bias, anchoring, and overconfidence
• Bias check results are recorded as metadata or linked artifacts for audit trail
• The /run workflow integrates bias checking before the spec approval gate