The spec interrogation prompt

Three blocks, in order, with no explanation attached. The reasoning behind them is in the full playbook. This page is for when you’ve read that once and now want the text.

---

The rule that comes first

Describe structure. Never paste data.

Object and field names, relationships, business rules in words, field types, thresholds as concepts: fine. Actual records, customer names, real pricing on real deals, exported reports, screenshots with data visible: never.

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

---

1. The scaffold

Fill this in before you ask for anything. Five minutes here is the 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]

---

2. The interrogation prompt

Paste this after the filled-in scaffold. 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: ten to fifteen questions, several of which you can’t answer.

Bad output: questions whose answers are already in your scaffold. That means your input was too thin, or it ignored it. Say so and re-run.

---

3. The artifacts prompt

Only after you’ve answered what you can and sent the rest to your business owner.

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

Restating the constraints is not optional. On anything longer than an hour, things established early get quietly dropped.

Download all three → Plain text, with the failure modes. No signup.

---

When it breaks

It skips to the spec anyway. The last line of block 2 is doing that work. If it still jumps ahead, paste the scaffold again in a fresh conversation rather than arguing with it in this one.

Every question it asks is already answered in your scaffold. Your scaffold was too thin, or it ignored it. Either way, say that plainly and run it again.

It states a platform limit with total confidence. Governor limits, what a formula field can reference, what a managed package exposes. Treat every platform claim as a hypothesis until a sandbox says otherwise. The reasoning is usually sound. The specific limits often aren’t.

Not on Salesforce? Change the object names. The three blocks are identical on NetSuite, SAP, Workday, ServiceNow, and the rest.