Prompt Modifiers
Agent Handoff Brief Mode (Modifier)
A modifier that changes how an audit runs when you paste it in alongside one.
- Best for
- Appending to any audit so its findings become a brief another agent or engineer can execute without this session's context — each finding as a task with the exact files, the expected change, the acceptance check that proves it, and the test or command to run, ordered by dependency and severity, with the constraints that must not be violated (branches, conventions, things not to touch), the verification the executor must perform before claiming done, the record they must leave, and what to do when a task turns out to be wrong
- Use when
- Findings will be worked by a different agent, a parallel worktree, or a teammate who did not see the audit; a report ended with a list of issues and nobody could tell where to start; an executor fixed the symptom because the task did not state the root cause; work was claimed done without the proof the audit expected; or several tasks touched the same files and collided
Append this to any other prompt to turn its findings into a brief that another agent or engineer can execute without this conversation.
You are operating in Agent Handoff Brief Mode. The base prompt's report is produced first, unchanged. Then its findings are rewritten as a brief for an executor who has the repository and nothing else: no memory of this session, no access to the auditor, and no licence to interpret.
Modified Behavior
- One task per root cause: Each task names the finding it closes, the root cause (not the symptom), the files and lines involved, the expected change in plain words, and what must not change. Findings that share a cause become one task with every location listed.
- Acceptance check per task: Each task states the check that proves it is done: the test to add or run, the command and expected output, the request and expected response, or the capture to produce. A task without a provable check is not handed off; it goes to a questions list.
- Order and dependencies: Tasks are ordered by dependency first, then severity, then size. Tasks that touch the same files are sequenced or merged so parallel executors do not collide; the brief says which tasks may run in parallel.
- Constraints stated once: Branch and worktree rules, commit conventions, gates to run before pushing, files and areas not to touch, conventions the code must follow, and anything the executor must ask before doing (migrations, deletions, external calls, secrets).
- Verification before done: The executor must run the acceptance check, run the project's own gate, and record the evidence in the commit or the task record before claiming completion. Claims without evidence are not accepted.
- Record and escalation: The executor leaves a record per task (what changed, the check's output, anything skipped and why). When a task is found to be wrong, impossible, or larger than described, the executor stops that task, records why, and continues with independent tasks rather than improvising a different change.
- Questions list: Anything the audit could not resolve (ownership decisions, product choices, findings without a provable check) is listed as a question with the person or decision needed, not folded into a task.
What This Mode Does Not Change
The audit's findings, severities, and evidence stand as reported; the brief adds no findings and drops none without saying so. Combined with other modifiers, their rules on scope and evidence apply to the audit; this mode governs only the handoff.
When Not to Use
Do not use this mode when the auditor will do the work in the same session, when findings are proposals rather than defects, or when the executor lacks the access the tasks need; say so and stop at the report.
Output Format
After the base report, a section titled Handoff Brief:
Constraints (one block). Tasks:
| Order | Task | Closes finding | Root cause | Files | Expected change | Acceptance check | Parallel-safe |
|---|
Verification and record rules (one block). Questions (one line each with who decides).
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.