Prompt guidance: distinguish `[STATUS]` lines from `TaskCreate`/`TaskUpdate` calls

Problem

Agent prompts use two progress mechanisms — [STATUS] lines and the TaskCreate/TaskUpdate task list — but when to use which isn't documented in one place. basic-integration uses both; audit deliberately uses [STATUS] + the audit ledger and forbids task calls (audit/description.md: "Do not call TaskCreate / TaskUpdate / TaskGet / TaskList"). We should document the distinction and ship one reusable blurb.

When to use which

TaskCreate / TaskUpdate — the task list (durable plan).
Use when the work has distinct stages the user should follow as a plan with lifecycle. Create the list up front in a single TaskCreate (don't wait for a perfect plan), refine with further TaskCreate/TaskUpdate as understanding sharpens, and drive it with TaskUpdate: in_progress on start, completed on finish. Titles broad and job-oriented — not file/path/symbol specific.

[STATUS] — the live banner (transient activity).
Use for moment-to-moment "Working on …" narration within a stage. Emit a plain-text line prefixed [STATUS] before each phase/sub-step. Cheap, ephemeral, no lifecycle — the harness intercepts it and updates the spinner.

One or both:

• Multi-stage flow with a task pane → use the task list for the stage backbone and [STATUS] for sub-step narration (basic-integration).
• Flow whose progress is already tracked another way (e.g. a ledger) → skip task calls entirely, use [STATUS] only (audit).
• Trivial/single-step work → neither.

Transportable blurb

## Task list

As soon as you have a rough sense of the work, **call `TaskCreate` immediately** — before reading any reference file or starting analysis — so the task pane isn't empty. It's fine if the first list is incomplete: seed it with the high-level items you can infer, then call `TaskCreate` again (or `TaskUpdate` to refine existing items) every time your understanding sharpens. Use `TaskUpdate` to mark an item `in_progress` when you start it and `completed` when you finish. Keeping the list current matters more than getting it right on the first call.

Keep task titles broad and job-oriented — describe the purpose or area of work (e.g. "Planning the migration", "Wiring up auth", "Writing tests"), not the specific files, paths, or symbols involved. Adjust the names to the user's project and context.

## Status

Before beginning each phase or sub-step, emit a plain-text line with the exact prefix `[STATUS]`:

[STATUS] Checking project structure

The harness intercepts these and updates the "Working on …" banner. Use them freely — they are cheap. Use `[STATUS]` for transient activity; use the task list for the durable plan of stages. If progress is already visible through another mechanism (a ledger, etc.), skip the task list and use `[STATUS]` only.

Source references

• wizard/src/lib/agent/commandments.ts — the shared task-list commandment
• context-mill/llm-prompts/basic-integration/1.0-begin.md — "Task list" + "Status" sections (uses both)
• context-mill/transformation-config/skills/audit/description.md — "Live activity — [STATUS]" (uses [STATUS] + ledger, no task calls)

Start by comparing the shared task-list guidance in wizard/src/lib/agent/commandments.ts with the Task list and Status sections in context-mill/llm-prompts/basic-integration/1.0-begin.md and context-mill/transformation-config/skills/audit/description.md. Add one reusable blurb that clearly distinguishes durable task stages from transient [STATUS] activity and documents when to use either, both, or neither.