AFK Prompt
Write a prompt for a fresh Claude instance that runs unattended. Nobody will answer questions or course-correct, so the prompt trades brevity for explicitness — the opposite bias from live-prompt.
Step 1: pick (or vet) the tasks
If the user asks which tasks fit, or names candidates, vet each against:
- Decision-free: the task description contains every decision; nothing left that needs the user's taste or approval. Tasks with open UX/architecture questions are out.
- Self-verifiable: the instance can check its own work (gates, tests, device screenshot) without the user.
- Bounded: investigation tasks are fine if "write findings and close" is an acceptable outcome; open-ended repro hunts on intermittent bugs are not.
If the tracker has an agent-ready tag/label, filter by it first. Batching 2-3 small tasks into one instance is good — sequential, one claim/implement/close cycle each.
Step 2: write the prompt
- AFK declaration first: "Work through these autonomously — I'm AFK." Then per task: invoke beads skill, claim, read, implement, close.
- Per-task block: gist, known file paths, and what done looks like.
- Environment, explicitly: which device/emulator to verify on, how to reach it, and what NOT to touch. Never let the instance guess the verification environment — name it ("connected physical device via agent-device; do NOT boot the emulator"). State account/login if the app needs one.
- Scope walls: name sibling tasks/areas it must not start, and read-only zones ("check apps/api but do NOT change backend code").
- The escape hatch — always include: "If a task turns out to need a decision from me, bd note what's blocking and move on to the next task rather than guessing." For investigations: define the fallback close ("if X turns out false, write findings via bd note and close as investigation-complete").
- Gates + commits: quality gates per task, separate commit per task, commit format.
- End report: "Report at the end: gist only — what changed, what you found, screenshot paths. No full code blocks."
Rules
- Length: ~15-25 lines is fine — explicitness beats brevity when nobody's watching. Past that, move detail into the beads tasks via bd note.
- Conditional branches beat optimism: write "if A then ship, if B then note+close" rather than assuming the happy path.
- Order tasks cheapest-first so a wedged later task doesn't eat the easy wins.
- Don't leak the user's global preference file into the prompt; project-level workflow facts only.
Examples
See EXAMPLES.md for a real two-task AFK prompt and the environment-guessing failure it teaches.
1---2name: afk-prompt3description: Write a copy-paste prompt that hands one or more tasks (usually beads issues) to a fresh Claude instance to run autonomously while the user is away — no questions, no waiting for input. Includes picking which tasks are safe to run unattended. Use when the user says they're going AFK (shower, lunch, errand, overnight), asks "which tasks can just run without me", or wants an autonomous/batch prompt. For attended sessions the user will steer, use the live-prompt skill instead.4---56# AFK Prompt78Write a prompt for a fresh Claude instance that runs unattended. Nobody will answer questions or course-correct, so the prompt trades brevity for explicitness — the opposite bias from live-prompt.910## Step 1: pick (or vet) the tasks1112If the user asks which tasks fit, or names candidates, vet each against:1314- **Decision-free**: the task description contains every decision; nothing left that needs the user's taste or approval. Tasks with open UX/architecture questions are out.15- **Self-verifiable**: the instance can check its own work (gates, tests, device screenshot) without the user.16- **Bounded**: investigation tasks are fine if "write findings and close" is an acceptable outcome; open-ended repro hunts on intermittent bugs are not.1718If the tracker has an agent-ready tag/label, filter by it first. Batching 2-3 small tasks into one instance is good — sequential, one claim/implement/close cycle each.1920## Step 2: write the prompt21221. **AFK declaration first**: "Work through these autonomously — I'm AFK." Then per task: invoke beads skill, claim, read, implement, close.232. **Per-task block**: gist, known file paths, and what done looks like.243. **Environment, explicitly**: which device/emulator to verify on, how to reach it, and what NOT to touch. Never let the instance guess the verification environment — name it ("connected physical device via agent-device; do NOT boot the emulator"). State account/login if the app needs one.254. **Scope walls**: name sibling tasks/areas it must not start, and read-only zones ("check apps/api but do NOT change backend code").265. **The escape hatch — always include**: "If a task turns out to need a decision from me, bd note what's blocking and move on to the next task rather than guessing." For investigations: define the fallback close ("if X turns out false, write findings via bd note and close as investigation-complete").276. **Gates + commits**: quality gates per task, separate commit per task, commit format.287. **End report**: "Report at the end: gist only — what changed, what you found, screenshot paths. No full code blocks."2930## Rules3132- Length: ~15-25 lines is fine — explicitness beats brevity when nobody's watching. Past that, move detail into the beads tasks via bd note.33- Conditional branches beat optimism: write "if A then ship, if B then note+close" rather than assuming the happy path.34- Order tasks cheapest-first so a wedged later task doesn't eat the easy wins.35- Don't leak the user's global preference file into the prompt; project-level workflow facts only.3637## Examples3839See [EXAMPLES.md](EXAMPLES.md) for a real two-task AFK prompt and the environment-guessing failure it teaches.
thatmike1