1.2 Learn my work.

Why it exists

Repeatable work needs a known method, useful examples, and a clear quality bar, otherwise AI improvises each run and the participant re-teaches the same lesson weekly. The hardest part is not the steps; it is the judgment the participant does not know they have. That is what the incident questions extract.

Questions

1. Which recurring job are we documenting?
2. What triggers the job?
3. What inputs are required?
4. Which sources must be checked first?
5. What are the normal steps, in order?
6. Which decisions require human judgment?
7. Tell me about a time this job went subtly wrong and only you would have caught it. What did you notice? What had you seen before that told you?
8. Tell me about a time a step everyone assumes is necessary turned out not to be, or a skipped step that caused real trouble later.
9. Which exceptions commonly occur?
10. Where should exceptions be routed?
11. What should happen when required information is missing?
12. What is the expected output?
13. What format should the output use?
14. What does an acceptable output look like? (Show a real past example if one exists.)
15. What does an unacceptable output look like? (A real one, ideally, what was wrong with it?)
16. What are five observable acceptance checks?
17. Does this procedure cross two or more owners or tools? (If yes, the procedure gets a swimlane, not prose.)
18. Who owns the procedure?
19. Who reviews the output?
20. How long should review take?
21. How should corrections change the procedure version?
22. What three representative cases should test the procedure?

Build prompt

Using the interview answers, create a reusable workflow procedure.

Use this fixed page anatomy: action title (states the outcome); TL;DR strip
(one line, when to use, what it produces); purpose / when to use / when NOT to
use; steps (checklist for routine verification, numbered for sequential work,
swimlane if the flow crosses two or more owners or tools); key questions (the
interview questions that regenerate this page); acceptance checks (the five
observable checks); metadata bar (owner, version, review date, source interview,
expected time and difficulty); from-the-field example, one real use in my
words, including the subtle-failure incident and what caught it.

Include one acceptable and one unacceptable example, described precisely enough
to evaluate real output. Separate approved facts / proposed rules / assumptions /
unanswered questions / evidence needed; mark assumptions unconfirmed. Quote my
words in the example.

Test

Run three representative cases, including one exception:

1. Normal case. Owner scores the output against the five acceptance checks. Pass if all five are met, or the correction is logged and the procedure version bumps.
2. Edge case drawn from Q7’s subtle-failure incident. Pass if the check that would have caught it is now in the acceptance list and fires.
3. Exception case. Pass if the exception reaches the named destination instead of being forced through the normal steps.

Done

Depth by stage

Starter: one procedure for the intake workflow, prose format. Intermediate: a second only after the first passes its test twice. Expert: swimlanes for any cross-owner flow, versioning begun. Frontier: procedures join the portability run; a procedure that only works in one tool is logged as a portability gap.