Idea Honing
Turn an idea into a saved, implementation-ready spec through a focused interrogation loop.
User Input
Use ask_user_question for every blocking question in the interrogation loop. Pass one concise question, likely options when useful, allowFreeform, and a decisive recommendation. Do not ask in plain chat unless the tool is unavailable.
Workflow
- Identify the idea, target product area, and desired output. If the user has not provided enough to start, use
ask_user_question for the one missing seed detail.
- Interview the user relentlessly, one question at a time, until the spec is unambiguous enough to implement.
- For every question:
- Call
ask_user_question exactly once.
- Ask exactly one question.
- Include your recommended answer in the tool's
recommendation field.
- Prefer decisive defaults over open-ended brainstorming.
- If the answer can be discovered from the repository, inspect the code/docs instead of asking.
- Resolve dependencies between decisions in order. Do not jump ahead to low-level details before core constraints are settled.
- Keep a running mental spec and update it after each answer.
- When enough decisions are resolved, tell the user you are ready to write the spec and use
ask_user_question for confirmation only if there is a meaningful unresolved product choice. Otherwise proceed.
- Save the spec as markdown in the repository.
- Run the
revdiff skill against the saved spec (--only <spec-path>; add --untracked for a new file). Process captured annotations and update the spec when needed.
- Report the created file path and any remaining open questions.
Question Order
Cover these areas as needed, skipping anything already answered or discoverable:
- Problem and user
- Goal and non-goals
- Success criteria
- User flows
- Data model and persistence
- API/contract changes
- UI/UX behavior
- Edge cases and failure states
- Security, privacy, and permissions
- Compatibility, migration, rollout
- Test/verification plan
- Implementation milestones
Spec Location
Default location:
- If this repository has
docs/implementation/, save to docs/implementation/<kebab-case-title>-spec.md.
- Otherwise save to
docs/<kebab-case-title>-spec.md.
- Create the directory if needed.
If a related spec already exists, update it instead of creating a duplicate.
Spec Template
---
Created: YYYY-MM-DD
Status: Draft
Owner: TBD
---
# <Spec Title>
## Summary
<One-paragraph summary.>
## Problem
<Problem and why it matters.>
## Goals
- <Goal>
## Non-goals
- <Non-goal>
## Users and Use Cases
- <User/use case>
## Proposed Behavior
<Concrete behavior and flows.>
## Requirements
### Functional
- <Requirement>
### Non-functional
- <Requirement>
## Data and Contracts
<Data model, persistence, API, schema, and contract impacts.>
## UX Notes
<Screens, states, copy, accessibility, and edge cases.>
## Rollout and Migration
<Rollout, backwards compatibility, migration, feature flags.>
## Test Plan
- <Verification step>
## Open Questions
- <Question, or `None`.>
Behavior Rules
- Be direct and skeptical.
- Ask one question at a time via
ask_user_question.
- Each question must include a recommended answer.
- Do not produce the final spec until the important branches are resolved.
- Do not ask questions that repository inspection can answer.
- The final output is a saved file, not just chat text.
1---2name: idea-honing3description: Relentlessly interview the user to sharpen a vague idea into an actionable implementation spec, then save that spec to the repository. Use when the user wants to refine an idea, stress-test a concept, build a spec, write a PRD, or says "hone this idea", "grill me", "turn this into a spec", or similar.4---56# Idea Honing78Turn an idea into a saved, implementation-ready spec through a focused interrogation loop.910## User Input1112Use `ask_user_question` for every blocking question in the interrogation loop. Pass one concise `question`, likely `options` when useful, `allowFreeform`, and a decisive `recommendation`. Do not ask in plain chat unless the tool is unavailable.1314## Workflow15161. Identify the idea, target product area, and desired output. If the user has not provided enough to start, use `ask_user_question` for the one missing seed detail.172. Interview the user relentlessly, one question at a time, until the spec is unambiguous enough to implement.183. For every question:19 - Call `ask_user_question` exactly once.20 - Ask exactly one question.21 - Include your recommended answer in the tool's `recommendation` field.22 - Prefer decisive defaults over open-ended brainstorming.23 - If the answer can be discovered from the repository, inspect the code/docs instead of asking.244. Resolve dependencies between decisions in order. Do not jump ahead to low-level details before core constraints are settled.255. Keep a running mental spec and update it after each answer.266. When enough decisions are resolved, tell the user you are ready to write the spec and use `ask_user_question` for confirmation only if there is a meaningful unresolved product choice. Otherwise proceed.277. Save the spec as markdown in the repository.288. Run the `revdiff` skill against the saved spec (`--only <spec-path>`; add `--untracked` for a new file). Process captured annotations and update the spec when needed.299. Report the created file path and any remaining open questions.3031## Question Order3233Cover these areas as needed, skipping anything already answered or discoverable:34351. Problem and user362. Goal and non-goals373. Success criteria384. User flows395. Data model and persistence406. API/contract changes417. UI/UX behavior428. Edge cases and failure states439. Security, privacy, and permissions4410. Compatibility, migration, rollout4511. Test/verification plan4612. Implementation milestones4748## Spec Location4950Default location:5152- If this repository has `docs/implementation/`, save to `docs/implementation/<kebab-case-title>-spec.md`.53- Otherwise save to `docs/<kebab-case-title>-spec.md`.54- Create the directory if needed.5556If a related spec already exists, update it instead of creating a duplicate.5758## Spec Template5960```markdown61---62Created: YYYY-MM-DD63Status: Draft64Owner: TBD65---6667# <Spec Title>6869## Summary7071<One-paragraph summary.>7273## Problem7475<Problem and why it matters.>7677## Goals7879- <Goal>8081## Non-goals8283- <Non-goal>8485## Users and Use Cases8687- <User/use case>8889## Proposed Behavior9091<Concrete behavior and flows.>9293## Requirements9495### Functional9697- <Requirement>9899### Non-functional100101- <Requirement>102103## Data and Contracts104105<Data model, persistence, API, schema, and contract impacts.>106107## UX Notes108109<Screens, states, copy, accessibility, and edge cases.>110111## Rollout and Migration112113<Rollout, backwards compatibility, migration, feature flags.>114115## Test Plan116117- <Verification step>118119## Open Questions120121- <Question, or `None`.>122```123124## Behavior Rules125126- Be direct and skeptical.127- Ask one question at a time via `ask_user_question`.128- Each question must include a recommended answer.129- Do not produce the final spec until the important branches are resolved.130- Do not ask questions that repository inspection can answer.131- The final output is a saved file, not just chat text.
aneviaro