File the Workflow, Not the Conversation

Fade in:

The second reviewed success belongs in a file

One reviewed run may depend on tacit context. After a second reviewed success, compare the runs and document the sequence, constraints, and human decisions that produced the accepted output shape. The result is ready for a fresh-session test, but it is not yet trusted team procedure.

1. Choose a pass with two reviewed successes. Start with self-coverage: a bounded task the team has run at least twice and whose outputs a writer reviewed. Wait to document prediction scoring, outline stress tests, panel reads, or condensing until each has also produced two reviewed results. Name the stable goal and the human decision the output supports. Put production-specific exceptions in projects/[production]/project-instructions.md.

   Document criteria the team has already reviewed. An agent finishing the run does not approve its output.

2. Reconstruct the decision logic, not the transcript. Ask the agent to identify what had to be known, what happened in what order, what was prohibited, and where a person chose the next move:

   The Writer

   (to the agent)

   PROPOSE only. Compare the reviewed runs in projects/return-visit/coverage/2026-07-03-draft-2.md and projects/return-visit/coverage/2026-07-10-draft-3.md. Report whether workflows/self-coverage.md and workflows/README.md exist. Preview the workflow’s full proposed contents in chat, or a minimal diff if it exists. Include goal, named inputs, ASK-only steps, output shape, approval point, and stop conditions. Do not create or change files. Wait for a separate APPLY instruction naming the target.

   You should get: an in-chat preview whose goal, inputs, modes, output, approval point, and stop conditions can be checked. Next: find hidden memory such as “as discussed,” “the usual files,” or “use the standard rubric.”

3. Strip away conversational debris. Delete greetings, retries, abandoned wording, and details that belong only to the completed production. Keep the sequence, constraints, definitions, evidence requirements, and decision gates that made the pass trustworthy. Replace “as discussed” with the actual rule and “the usual material” with named paths. If the purpose of a step cannot be stated, the procedure is not ready for team use.

4. Make every dependency and mode explicit. Name each required file with an exact path or a placeholder such as [target-draft-path], [rubric-path], or [reviewer-profile-path]. State what happens if one is missing, stale, contradictory, or unreadable. Begin every numbered step with ASK, PROPOSE, or APPLY. ASK reads and reports without file changes; PROPOSE previews in chat without file changes; APPLY changes only files named in a writer-approved instruction.

5. Design the output before polishing the instructions. “Up to three concerns supported by citations, with evidence, inference, and conflict separated” can be checked; “helpful coverage” cannot. Say whether the run reports in chat or writes to an approved path, where the writer decides, and what the run must never change. A one-page workflow should support one decision and one output shape. Split it when either changes.

   One-page workflow anatomy

   GOALfind cited concerns before the writer approves a draft

   USE / NOTuse for preflight coverage; do not revise or predict notes

   INPUTStarget draft path · rubric path · reviewer-profile path

   STEPSnumbered; each begins ASK, PROPOSE, or APPLY

   OUTPUTin-chat coverage with citations and separated reasoning

   APPROVALwriter chooses whether a cited concern merits revision

   STOPstop for missing or unreadable input, or expanded scope

   STATUSowner, version, trust status, last-tested production and date

6. Test for hidden context. The author of a workflow is the worst person to spot what it assumes. Before saving it as trusted, ask for an adversarial read:

   The Writer

   (to the agent)

   ASK only. Review the in-chat preview proposed for workflows/self-coverage.md. List each missing path, undefined term, hidden assumption, or unclear mode. Do not rewrite the preview or change any file.

   You should get: a cited list of missing or ambiguous instructions. Next: correct the preview, approve it, apply only the named workflow files, then test the saved file in a fresh session.

   After the writer approves the preview, use a separate APPLY instruction naming workflows/self-coverage.md and workflows/README.md; no other file may change. Save the approved procedure under workflows/. In workflows/README.md, record its goal, owner, version, and status: trusted, untrusted, or retest required. Inspect both diffs before trusting the workflow.

   Ready when

   In a fresh session, a second writer can identify the goal, required files, prohibited actions, output shape, stop conditions, and approval point from the workflow before running a step.

Cut to:

Run the workflow by name

Once a procedure passes the fresh-session test, run it by filename and target. The workflow states the reviewed method; the request names this production’s draft. The agent must still stop at every documented approval point and before any unapproved file change.

Guardrail. Repeatability is not correctness. A procedure can reproduce a bad judgment perfectly, and consistent output is not evidence that the underlying criterion is sound. Keep approved sources, explicit uncertainty, writer judgment, and periodic fresh-session tests in the process. The writer retains authorship and approval.

Fade out.