clarify-before-actinglisted

# Clarify Before Acting ## Overview Silent picks impose unwind cost on the requestor when the pick turns out wrong. This skill catches the ambiguity before action, surfaces it as a one-sentence question with named alternatives, and lets the requestor resolve it cheaply before the work commits. The discipline is from the canonical rule [`governance/clarify-before-acting.md`](../../governance/clarify-before-acting.md), which is the source of truth for the full ambiguity-detection taxonomy, the ask-vs-default decision rule, the tool-specific guidance, and the framework-alignment table. This skill is the workflow wrapper: ambiguity detection and the question-formulation format. ## When to Use - The request supports more than one reasonable interpretation, and the implementations would diverge materially. - An external value the request does not pin down is required to proceed (a date, a timezone, a library version, a target branch, an output format, a file path, a permission level, a default behaviour for an edge case). - A project-specific convention must be chosen (whether to bump a per-document version, whether to add a CHANGELOG entry, whether to land on a feature branch or a phase branch, whether tests are required for this kind of change). - A trade-off must be made that the requestor would reasonably want to weigh in on (backwards compatibility vs cleanliness, performance vs readability, breadth-of-fix vs scope-of-PR). - The state of the world is unclear (an unfamilia