auditable-run
Auditable run
Design a task-specific execution workflow for a large migration, an ambitious multi-part change, or work the user will review after stepping away. This skill begins only after product, scope, safety, and one-way user decisions are settled. An explicit full-autonomy grant can settle a reversible preference through a default: apply it, explain it fully, and say in plain words what the user could tell you to do instead. The user answers in their own words. Never offer a shorthand token to type back. User-named gates, missing authority, safety decisions, and irreversible choices still require the user. For any decision that remains open, use wayfinder when installed. Otherwise write the unresolved question, known facts, options, consequences, and recommendation, then stop for the user.
Subagents may communicate with each other, but no agent may communicate with a person. Repeat that sentence verbatim in every child prompt. No agent may post, send, reply, or comment through external services. Internal delegation and local tool use are allowed within the user's scope.
A. Frame the run
State these before implementation:
- A falsifiable definition of done.
- The rough number of units and expected effort.
- Known blockers and confirmation that no one-way user decision remains open.
- A rigor level expressed as checks and artifacts.
Proceed with reversible local exploration. Pause once before a multi-hour run so the user can correct the framing, unless the user has already granted autonomy for that run. Do not treat the framing or that grant as authority for external actions.