refine-ticket

Refine ticket

The Refine phase of Refine → Plan → Act: turn a raw ticket — or an idea to brainstorm — into a validated requirements document a fresh session can plan from. Analysis only — it defines what must be true when the work is done, never how to build it, and never touches code.

An idea is a ticket that doesn't exist yet: treat the user's words as the ticket text, and grill to shape the idea itself — goal, in vs out of scope — before closing the branches that block implementation.

What, not how — but verified against the code

You cannot define the "what" in a vacuum. Every requirement must be checked against the actual code, config, and design — a ticket may be stale, ambiguous, contradicted by the codebase, or depend on upstream work that isn't implemented yet (e.g. a prerequisite ticket still open). Reading the code here is for validating requirements, not for designing the solution.

Golden rule: never guess — ask

• Anything determinable by reading the code, resolve by reading the code — never ask the user about it.
• Anything not determinable from ticket + code, ask — never fill the gap with a plausible assumption.
• Local environment state (config files, DB contents, env vars) describes only the machine it's on — never assume it matches the environment where the reported behaviour occurred; ask the user to confirm such values.
• Treat "this probably works like X" as a question, not a fact. Keep "I confirmed X", "the ticket claims X", and "I assume X" distinct; the latter two never become the first without evidence.
• Before declaring something missing, broaden the search — "not found under the name the ticket used" is not "not present".
• Verify both sides of an integration: if a requirement relies on another layer behaving a certain way, open that layer and confirm it.

Grill to resolve every branch

After gathering and code-verifying, grill the user — interview relentlessly, never guessing what they could clarify — to close every remaining decision: