1 Starter.

What you build, in order.

1. 1.0 Choose one workflow

   Workflow brief with baseline; Readiness radar and binding constraint.

2. 1.1 Know me

   How I operate, one page; Workflow context brief with a Never-do block.

3. 1.2 Learn my work

   Workflow procedure with acceptance criteria; One acceptable and one unacceptable example.

Gate: One real run, human-reviewed, recorded.

Both lanes.

The interview engine, and the evidence log.

The Master Interview Engine

Every interview in Part II runs on the engine below. Version 2.0 keeps the v1 discipline (one question at a time, no invented facts, no unearned claims) and adds the evidence-based question design the research supports.

Why the questions work this way

• Critical incidents beat hypotheticals. “What would you do if the output were wrong?” gets a guess. “Tell me about the last time this workflow went wrong, walk me through exactly what happened” gets the workaround, the rework, and the real constraint. Breakdowns are where the gaps live.
• Constraint-sequenced questions surface priorities. Ending a build with “If AI could only fix one thing in this workflow this quarter, which one?” forces the ranking that open questions never produce.
• Guesses never become facts. An interviewer who fills silence with plausible detail is building a system on fiction. Unknowns are marked as unknowns, with the evidence needed to resolve them.
• The participant’s own words go into the artifact. Quotes are traceability. They are also the anti-Barnum rule: a document built from your actual phrasing cannot flatter you generically, and every profile-style document must include at least one specific, unflattering, concrete finding. Could this paragraph describe anyone? If yes, delete it or ground it.
• Follow-ups only when the answer changes the artifact. The core interview rule from v1, unchanged: if an answer would not change a decision, output, permission, source, or test, do not ask it merely because a template has a blank field.

The engine prompt

You are my Cypress Command build interviewer.

Your job is to help me create [ARTIFACT NAME] for [WORKFLOW NAME].

Rules:
1. Ask one question at a time. Wait for the answer.
2. Prefer critical-incident questions over hypotheticals: "Tell me about
   the last time X went wrong. Walk me through exactly what happened."
   Use hypothetical framing only when no real incident exists.
3. Where useful, sequence constraints: remove one, add one, then ask me to
   compress ("If this could only fix one thing this quarter, which one?").
4. Ask follow-up questions only when the answer would materially change
   the artifact. If it would not change a decision, output, permission,
   source, or test, do not ask it.
5. Work from my real situation, not a generic example.
6. Do not invent facts, dates, owners, permissions, sources, or
   requirements. Never turn a guess into a fact.
7. If I answer "I don't know," propose a reasonable draft choice and label
   it UNCONFIRMED with the evidence needed to confirm it.
8. Separate approved facts, proposed rules, assumptions, unanswered
   questions, and evidence needed.
9. Quote my own words back into the artifact wherever a claim is made.
   Every material claim must trace to something I said, decided, or
   demonstrated in this interview.
10. Anti-Barnum rule: every profile- or identity-style artifact must
    contain at least one specific, unflattering, concrete finding.
    If a sentence could describe anyone, delete it or ground it.
11. Identify missing information that could create a wrong output or an
    unsafe action, and say so explicitly.
12. When you have enough information, draft the artifact in the required
    format, ending with its if-then implementation intention.
13. End with a short review list: what I must confirm, what must be
    tested, and how the artifact will be used next.
14. Do not claim the capability works until the real test has passed and
    one real use is recorded.

Begin with the most important question.

Entry
- Date:
- Workflow:
- Capability / artifact used (with version):
- Owner:
- Reviewer:
- Intended use:

Effort (the measurement metrics)
- Minutes per run (total, start to finish):
- Review minutes:
- Corrections made (count and one-line cause each):
- Error / rework: none | description:
- Baseline comparison: minutes per run vs. intake baseline; rework rate trend:

Outcome
- Result: accepted | accepted-with-corrections | rejected | failed
- Failure or exception (what happened, where it stopped):
- Stale-source error? (record used, effective date, what it should have been):
- Permission or boundary issue? (what was attempted, what stopped it):
- Security event? (finding, drill, or incident reference):

Forward
- Artifact change required? (which, proposed version bump):
- Next improvement:
- Implementation intention still accurate? yes | revised to:

Month:
- Runs per capability:
- Average minutes per run vs. baseline:
- Average review minutes vs. baseline:
- Error/rework count and top cause:
- One correction that made the system better: