================================================================
SPEC PROMPT TEMPLATE
Turn a one-sentence ticket into a testable spec, without
connecting AI to your org.
================================================================

THE RULE, FIRST
  Describe structure. Never paste data.

  Fine:   object and field names, relationships, business rules
          in words, field types, formula logic, thresholds as
          concepts.
  Never:  actual records, customer or contact names, real
          pricing on real deals, exported reports, screenshots
          with data visible.

  Read your company's AI usage policy before you start. If there
  isn't one, assume the stricter version.


----------------------------------------------------------------
STEP 1: DESCRIBE THE SITUATION
Fill this in. Five minutes here is the whole difference between
a usable spec and confident filler.
----------------------------------------------------------------

CONTEXT
Platform: [e.g. Salesforce, standard approval framework, no
          custom code preferred]
Objects involved: [names and how they relate]
Who does this: [role, and their permission level]

THE ASK, AS IT ARRIVED
[paste the ticket verbatim, however vague]

WHAT I ALREADY KNOW
- [constraint 1: a thing that must stay true]
- [constraint 2]
- [what triggers this: a button, a status change, a field edit]
- [what has to come out the other end: a document, a
  notification, a record]

MY CURRENT INSTINCT
[e.g. "formula field over trigger if the logic allows". Say it
so it can be argued with]

WHAT I HAVEN'T DECIDED
[anything you know is unresolved]


----------------------------------------------------------------
STEP 2: INTERROGATE
Paste this immediately after the filled-in scaffold above.
Do not ask for the spec yet.
----------------------------------------------------------------

Before writing anything, interrogate this.

List every question a senior developer would ask before starting
that I haven't answered above. Group them:
  - Business rules I've assumed but not confirmed
  - Edge cases and reversal paths
  - What enforces each constraint (validation, lock, or training
    expectation)
  - Approval and audit gaps
  - Null and fallback cases for anything customer-facing

Then argue against my stated instinct. Give me the strongest case
for the opposite approach.

Do not write the user story yet.

  GOOD OUTPUT: 10-15 questions, several you can't answer.
  BAD OUTPUT:  questions already answered in your scaffold. That
               means your input was too thin, or it ignored it.
               Say so and re-run.


----------------------------------------------------------------
STEP 3: SPLIT THE QUESTIONS THREE WAYS
Do this by hand. It's the judgment that can't be delegated.
----------------------------------------------------------------

  1. BACK TO THE BUSINESS OWNER. Anything about intent or
     policy. Send as a list; you now have a documented reason
     your build hasn't started.

  2. VERIFY IN A SANDBOX. Anything about platform behavior.
     Non-negotiable.

  3. YOUR CALL. Design decisions. Answer them in writing so the
     next person doesn't relitigate it.


----------------------------------------------------------------
STEP 4: ASK FOR THE ARTIFACTS
Only now. Restating the constraints is not optional.
----------------------------------------------------------------

Constraints still binding: [restate them. Long conversations
drop them]
Answered since: [the questions you resolved, with answers]

Now write:
1. The user story, with acceptance criteria specific enough for
   QA to test. Each one a pass/fail statement, not a description
2. The design decision and its reasoning, so it isn't reopened
   later
3. A test plan covering the reversal and null paths


----------------------------------------------------------------
WHERE THIS BREAKS
----------------------------------------------------------------

- It invents platform behavior confidently. Governor limits, what
  a formula field can reference, field-type availability. Every
  platform claim is a hypothesis until a sandbox says otherwise.
- Recent releases are the worst ground. Renamed products and this
  year's features give stale answers.
- It agrees with you. Propose a bad design confidently and you'll
  get help building it. That's what Step 2's counter-argument is
  for.
- It drifts. On anything over an hour, early constraints get
  quietly dropped. See Step 4.

================================================================