to-speclisted

# To Spec Synthesize established intent into one canonical GitHub Spec Issue. Do not restart a requirements interview. The Issue is the only requirements source of truth; this skill creates no implementation tickets or repository Spec copy. ## 1. Bind the tracker and evidence Read the root `AGENTS.md` or `CLAUDE.md` and require one unambiguous `tracker: github` under `## verbs`. If it is absent or conflicts, invoke `setup-verbs` and stop until configuration is resolved. Derive `owner/repo` from the Git remote and verify authenticated GitHub access. Collect confirmed decisions, inspect only repository surfaces needed for real vocabulary, constraints, and test commands. Search open Issues for the same outcome; if a canonical Spec already exists, return it instead of publishing a duplicate. Completion: every factual implementation or testing claim is supported by the conversation or inspected repository; unresolved facts go in Further Notes. ## 2. Draft the complete Issue Use `[Spec] <outcome>` and exactly these top-level sections: 1. `## Problem` 2. `## Solution` 3. `## User Stories` 4. `## Implementation Decisions` 5. `## Testing Decisions` 6. `## Out of Scope` 7. `## Further Notes` Cover each affected actor and material failure/edge state in User Stories, using `As a / I want / so that` where it clarifies acceptance. Implementation Decisions name settled seams and constraints, not task breakdowns. Testing Decisions propose the highest practical seam first: 1. existi