Decision Board

Render a single-file HTML board from a JSON spec, wait for the user to pick, read the result. Then apply the picks — write the doc, file the PRs, update configs, whatever the choices imply.

This skill only handles the picking step. Extracting decisions and judging trade-offs happens before; applying choices happens after.

When to use this skill

The trigger is structural fit, not domain and not count. In order of importance:

1. Same option shape across items. Every item is one-of-N over options that share fields (label, optional cost / preview). If each item needs a custom shape, prose is better.
2. Preview is worth seeing. The user benefits from looking at each option's preview side-by-side rather than reading prose. If a single sentence captures the choice, inline Q&A is faster.
3. One person, one sitting. Solo decision-making, not async review.

Item count is the weakest signal — roughly 5–30 is the typical sweet spot, but a well-structured 4-item case can still earn the board while a 10-item bag of unrelated questions doesn't. Fit beats count.

If the structural fit doesn't hold, push back and suggest a different format.

Workflow