to-proposal

This skill takes the current conversation context and produces a proposal — an argued recommendation for a person to decide on, not a build spec for implementers. That's the line between this and /to-spec: a spec tells an implementer what to build; a proposal persuades a decision-maker what to do and why. Do NOT interview the user — synthesise what you already know from the grilling.

The issue tracker and triage label vocabulary should have been provided to you — run /bootstrap if not.

Process

1. Identify the audience and the ask. Who decides — your manager, a stakeholder, a VP? How hard you argue and how much context you front-load depends on it. State the audience at the top of the draft. If unclear, ask the one question.

2. Ask where it lands. A proposal is a decision document, so its home differs from a spec's. Propose the tracker default and confirm:

   • GitHub → an issue labelled ready-for-human (a proposal is a request for a human decision — the same way /to-spec stamps ready-for-agent by construction).
   • Linear → a Document in an agreed location: an Initiative, a Project, or — if that's the agreed home — an issue labelled ready-for-human. Confirm which before publishing.
   • No tracker adapter (GitLab / local / other) → ask for a plain location, or draft inline and let the user place it.

3. Check for a house format. Read the project/employer CLAUDE.md and any existing proposals in that location for a conventional shape; match it. Otherwise use the template below.

4. Write it for the audience. Lead with the recommendation — the reader should know the ask before the reasoning. Concrete over hedged: real numbers, a before/after, and a snippet or diagram wherever it carries the argument better than prose. Human register — no throat-clearing ("it's worth noting…"), no AI hedging. Stay candid but audience-appropriate: sharpen private snark into a defensible judgement ("that estimate is fantasy" → "the 2-week estimate looks optimistic given X"), keep the judgement.

5. Confirm, then publish. Show the draft. On explicit approval, create it in the agreed location via the tracker adapter. Never publish without approval. The published artefact carries the ask outstanding — there is no separate log.