Turn a Vague Ticket into a File-Level Implementation Plan

Tier: Foundation · Workflow area: Feature development

This playbook uses AI to front-load that discovery: ticket in, reviewed file-level plan and question list out, before any code is written.

When to use

• •
  A ticket is one to three sentences of intent with no acceptance criteria.
• •
  Estimation: you need a defensible size and risk call in 15 minutes.
• •
  Handing work to a junior engineer or a coding agent and you want the plan reviewed first.

Skip it for genuinely trivial changes (copy tweaks, config bumps) where planning ceremony costs more than the change.

Prerequisites

• •
  The ticket text and any linked context (Slack thread, screenshot, related tickets).
• •
  An assistant with codebase context (IDE assistant with workspace context, or terminal agent in the repo).
• •
  Knowledge of your team's conventions for plans — even just "bullet list in the ticket comment".

The workflow

1. 1.

   Extract the questions before the plan. Resist asking for a plan immediately:

   Copy

   Here is a ticket for our Node/Express + Postgres service:
   "Customers should be able to be deleted but we still need their order
   history - soft delete?"
   
   Do NOT write a plan yet. First list:
   1. Every ambiguity a developer must resolve (behavior, not implementation).
   2. Edge cases the ticket ignores (e.g., active subscriptions, GDPR/DPDP
      erasure requests, unique email constraint on re-signup).
   3. Questions to ask the product owner, ranked by how much the answer
      changes the design.
   

2. 2.

   Answer what you can, flag the rest. Reply inline with your own answers ("soft delete via deleted_at; erasure requests are a separate flow; email must be reusable"). Anything you cannot answer goes to the ticket owner now — that message is the highest-leverage output of this playbook.

3. 3.

   Request the file-level plan. With ambiguities pinned:

   Copy

   Now write an implementation plan against this repo. Format:
   - Steps in dependency order, each naming the exact files to create/modify.
   - For each step: what changes, and how it is tested.
   - DB migration steps separated from code steps, with rollback notes.
   - A "risks" section: what could break existing behavior
     (queries missing a deleted_at filter is the classic one).
   Search the codebase first; do not invent file paths.
   

4. 4.

   Red-team the plan. One more pass catches most planning bugs:

   Copy

   Critique your own plan as a skeptical senior reviewer. Where is it
   underspecified? Which steps would you refuse to estimate? What existing
   code (list files) queries the customers table and now needs a filter?
   

5. 5.

   Edit and post. Cut steps you disagree with, re-order for your deploy reality, and post the plan plus open questions on the ticket. The plan is yours the moment you post it — "the AI planned it" is not a defense in retro.

Tool variants

• IDE assistant with workspace context (Copilot Chat, Cursor): best when file-level accuracy matters; it can actually search the repo before naming files.
• Terminal agent (Claude Code and similar): use plan/read-only mode; strongest at verifying which files really exist and which queries touch the table.
• Plain chat assistant: works if you paste the schema and key file list first; treat its file paths as suggestions to verify, not facts.

Verification

• •
  Every file path in the plan exists (spot-check with your file finder) or is explicitly marked "new file".
• •
  The risk section names at least one concrete existing behavior at risk — a plan with "no risks" was not grounded in the repo.
• •
  The product owner confirmed, or explicitly deferred, each open question before you started coding.
• •
  Estimate derived from the plan's step count, not gut feel.

Pitfalls

• Plan-first prompting. Asking for a plan before surfacing ambiguities gets you a confident plan for the wrong feature. Questions first, always.
• Invented file paths. Ungrounded assistants fabricate plausible structure. Ground in the repo or verify by hand.
• Over-planning. Ten minutes of prompting for a two-line change. Match ceremony to risk.
• Skipping the human answer step. If you let the model resolve product ambiguities itself (step 2), you have automated guessing, not planning.

Restricted-environment variant

Ticket text usually contains no source code, so most restrictions do not apply to steps 1-2 — run them in any approved chat tool. For steps 3-4 (which need repo context):

• •
  Use the client-approved assistant inside their environment, or
• •
  Paste only the schema (table names, columns) and a directory listing rather than code — enough for a credible file-level plan in most CRUD services, or
• •
  Run steps 3-4 with a local model (Ollama) and accept that you will verify file paths manually.

Strip customer names, real emails, and incident details from ticket text before pasting into any hosted tool.

Success criteria

• •
  Plan plus open-questions posted on the ticket within 20 minutes of picking it up.
• •
  At least one ambiguity you would previously have discovered mid-code was resolved before coding.
• •
  The implementation followed the plan, or the plan was consciously amended — no silent drift.
• •
  A reviewer or PM said some version of "this was easy to review".