grillmester-to-spec

name	grillmester-to-spec
description	Use only after the user explicitly selects To Spec to turn an already resolved conversation or design into a concise engineering specification; do not interview or reopen decisions.

To Spec

OpenCode v1: Backticked grillmester-* names below are skill IDs, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.

Synthesize what is already resolved into one durable engineering specification. Do not run a new interview, invent missing choices, or create a spec when a single actionable issue already carries the work.

Start only after the user has explicitly selected grillmester-to-spec in the current conversation. Relevance or a prior recommendation is not selection.

Discover tracker context from consumer-owned instructions, issue templates, contributor documentation, and read-only GitHub metadata. A dedicated adapter file is optional. Drafting may continue without one; publishing must stop when the target repository, write authorization, or required metadata is unresolved.

1. Establish the source

Use the current conversation, the active issue or plan, relevant maintained domain documentation, and only the decisions that constrain this work. Explore the repository when needed to verify the current state and existing test seams.

Stop and return to the planning conversation when the problem, outcome, scope, or a material user-owned choice is unresolved.

2. Draft the specification

Prefer the highest existing test seam and the fewest seams that can prove the outcome. Give the issue a functional, plain-language title. Start with the change and its value so a product lead or designer can understand the work without reading technical detail. Write only what implementation and review need:

## In short

<one or two sentences: who or what benefits, what changes, and why it matters>

## Acceptance criteria

- [ ] <externally verifiable behavior>

## Locked decisions

- <decision and the constraint it creates>

## Implementation context

- <relevant current state, technical boundary, risk, or integration seam>

## Proof

- <test seam and required evidence>

## Non-goals

- <explicit boundary>

## Dependencies

- <team, system, or ticket dependency, or none>

Include user stories only when they clarify genuinely different actors or behaviors; never force technical work into “As a …” prose. Put implementation context after the human-readable opening, but retain the evidence, constraints, risks, integration seams, and proof an implementer or agent needs. Avoid file inventories, repeated decision rationale, speculative future work, and exhaustive implementation prose. Inline a small schema, type, or state-machine fragment only when it carries a decision more precisely than prose.

3. Confirm and publish

Present the complete draft and proposed tracker metadata. Publish only after explicit human authorization. Apply only labels and relationships established by consumer evidence or live metadata, then read the published issue back and verify it.

A specification does not imply issue decomposition. Recommend grillmester-to-issues only when several independently deliverable slices need durable tracking.