| name | stay-busy |
| description | Use when the user invokes /stay-busy, asks to keep a manager/orchestrator/subagents busy, complains that an agent is waiting too much, or when an active delegate-manager-to-subagents workflow is about to idle despite safe evidence-producing follow-on work. Generates parallel workstreams with blocked fallbacks, ask-only boundaries, and required artifacts. Stay busy by producing evidence, not by creating motion. This is manager/orchestrator anti-idle behavior, not general productivity. |
Stay busy
Big picture
One-line principle: when stuck, find a solution. When the manager has
no obvious next plan task, the answer is more dispatched work, not idle.
Finish the obvious comes first. This skill is layered on top of the
"Finish the obvious" core philosophy in docs/REPO_STYLE.md. If a plan
task, in-flight workstream, or open verification step still has obvious
next actions, the manager takes those FIRST. stay-busy fires only after
the obvious queue is empty. See ## Finish before expanding for the gate
that enforces this, and Workflow step 2 for where the gate runs.
The failure this skill prevents: the manager spends a few minutes making a
plan, then sits idle for hours or days. A short task gets finished and the
manager stops, even though the user wanted continued exploration.
This skill exists to inflate scope by roughly two orders of magnitude when
the user is away from the keyboard, overnight or across several days. They
are going to bed, stepping out, or running a session unattended, and they
want to wake up to finished artifacts, not a queue of pending questions to
answer.
Success = completed work the user can read on returning. Failure = a stack
of "should I do X?" prompts, or a milestone declared done while obvious
follow-on testing was skipped.
Four anchor activities, named by the user, define the work stay-busy
generates:
- Write up results. Synthesize completed runs into reports that compare,
summarize, or rank. Long-form (25-100 page) reports are a valid single
workstream when enough evidence has accumulated to synthesize.
- A/B (or A/B/C/D) testing. Run methodologies, configurations, or
alternative implementations side by side and report the comparison.
- Side-quest experiments. Launch subagents to explore tangents that may
inform future work, labeled
SIDE QUEST.
- Audit the codebase. Read-only correctness, style, contract, and coverage
sweeps producing inspectable artifacts.
Default workstream shape in away-mode is expansive, not small. "Small,
concrete recovery task" is wrong when the user is asleep. The right shape
is a test suite spanning N methodologies, a stress matrix across M
configurations, an audit covering K subsystems, a screenshot gallery
across V viewports.
Two failure modes to prevent:
- Passive waiting. Manager idles, asks the user "what next?", or marks the
milestone done while obvious follow-on testing remains. Especially bad
while the user is away: morning inbox of pending questions.
- Reckless motion. Manager invents busywork, expands scope into
architecture changes, weakens tests, or edits production code to make
red turn green.
Every rule below maps to one of those two failure modes. See
references/big_picture.md for the full
lifecycle diagram, the worked overnight example, the composition map with
sibling skills, and the mapping to the core philosophies in
docs/REPO_STYLE.md.
Core principle
Stay busy by producing evidence, not by creating motion. When the
delegate-manager-to-subagents workflow would otherwise idle, this skill
generates safe, parallel, evidence-producing workstreams with explicit
blocked fallbacks and a final handoff contract.
Supporting rules:
- Busy is invalid unless it produces evidence or removes a blocker.
- If the next safe action is implied by the plan, current failure, current
milestone, or acceptance criteria, take it. Document the assumption and
continue. (Operational form of the "Finish the obvious" core philosophy
in
docs/REPO_STYLE.md.)
Vocabulary contract
stay-busy uses the manager's vocabulary so output composes natively with
delegate-manager-to-subagents.
| Concept | Term |
|---|
| Atomic unit | task |
| Parallel grouping | workstream |
| Doer | subagent |
| Verb | dispatch |
| Status label: complete, no concerns | DONE |
| Status label: complete but reviewer should inspect a flagged artifact | DONE_WITH_CONCERNS |
| Status label: blocked by missing information (not a hard boundary) | NEEDS_CONTEXT |
| Status label: blocked by a hard boundary | BLOCKED |
| Annotation (not a status): optional evidence-producing side project work | SIDE QUEST |
SIDE QUEST is a task-level annotation, not a workstream status. A side
quest task still carries one of the four status labels above.
When to use
- User asks to keep manager/orchestrator/subagents busy.
- User asks the manager to stay productive over a multi-day stretch.
- User is stepping away from the keyboard (going to bed, leaving for the
day, running unattended) and wants finished artifacts on return.
- Project blocked but safe parallel work exists.
- User complains agent is waiting too much.
- End-of-turn, when the next response would otherwise be "waiting for
guidance" AND an active
delegate-manager-to-subagents plan is in flight
AND a safe next workstream exists.
Trigger phrases to watch for in your own draft response: "standing by",
"waiting", "what next", "let me know if", or any sentence offering the user
obvious options instead of continuing.
When not to use
- Project genuinely complete AND no deferred testing or exploration of
value remains.
- User asked for one targeted change.
- High-risk migration, deletion, contract amendment requested.
- Outside
delegate-manager-to-subagents workflow.
- Current milestone near closure and only final verification or handoff
remains. Finish the milestone first, THEN propose follow-on workstreams.
stay-busy must not be used to avoid finishing.
Finish before expanding
This gate runs before every stay-busy invocation, and before any tier
bump or scope expansion described in the sections that follow:
- Inspect every already-running or paused workstream in the current plan.
- If a workstream needs only verification, documentation, or final
handoff, queue THAT workstream first.
- Do not launch new workstreams when existing workstreams can be closed.
- Staying busy must not create abandoned partial work.
This is the "Finish the obvious" core philosophy from
docs/REPO_STYLE.md applied to the stay-busy lifecycle. Away mode,
Manager decision authority, Tier signals, and Workstream scale all
apply ONLY after this gate is clean.
Away mode
When the user signals they are stepping away (sleeping, leaving,
unattended session), workstream defaults shift. Away mode does NOT
bypass ## Finish before expanding: if obvious in-flight work remains,
finish that first; the expansion below applies only after the obvious
queue is empty.
- Default workstream scope widens: prefer expansive multi-methodology
suites over small concrete recovery tasks. A "small, concrete recovery
task" is the wrong shape when the user is asleep.
- Default tier jumps one level (small -> medium, medium -> large, large
-> stress). The cap "defaulting to 10 on a small project is wrong" does
not apply in away mode.
- Suppress confirmation-seeking. Any question that does not change
architecture, contract, deletion, or broad production behavior is
settled by the manager using a documented assumption. The morning
inbox should contain finished artifacts, not pending questions.
- Prefer the four anchor activities from
## Big picture: writeups,
A/B testing, side-quest experiments, codebase audits.
- Long-form reports (25-100 pages) are a valid single-workstream output
when the project has accumulated enough evidence to synthesize. Format
follows repo language: TypeScript repos render HTML to PDF with
Playwright screenshots embedded as visual evidence; Python repos write
Markdown per
docs/MARKDOWN_STYLE.md. See
references/workstream_templates.md
report-workstream section for templates.
- Every workstream must finish to an inspectable artifact the user can
read on return. No "in progress, ask me when you wake up" handoffs.
Manager decision authority
The manager is the decision-maker for everything that does not cross an
ask-only boundary (see
references/boundaries.md). When in doubt, the
manager decides, documents the reasoning in the workstream artifact, and
continues. Stalling on user input is failure.
- React to findings without asking. A surprising A/B result, a failing
edge case, an unexpected log pattern -- the manager dispatches a
follow-up workstream (re-run with variance, vary the input, isolate the
cause) rather than messaging the user. The answer to a surprise is more
evidence.
- When two options exist and neither crosses an ask-only boundary, the
manager picks one based on the project's stated priorities, records the
choice and the runner-up in the workstream report, and proceeds. A
defaulted choice plus written reasoning is worth more to the user on
return than a pending question.
- "Do more testing" is the default response to uncertainty about a
finding. If the result might be noise, queue a variance run. If the
result might be input-specific, queue a sweep. If a methodology looks
promising, queue a comparison against the incumbent.
- The status labels (
DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT,
BLOCKED) and the artifact-path requirement are how the manager stays
trustworthy across an unattended stretch -- they let the user audit
decisions on return. They are the manager's own paper trail, not a
checklist to satisfy.
Default-to-safe-work rules
- If a decision is already given, execute it.
- If a safe default exists, take it.
- If one workstream blocks, dispatch another workstream.
- Do not say "default in 2 minutes" unless the default actually executes.
- Do not ask user to choose between obvious next steps unless the choice
changes architecture, contract, deletion, or broad production behavior.
- Do not stand by unless there is truly nothing safe, useful, or
plan-defined to do.
- Do not seek confirmation on clear options, stop at task boundaries,
detour into unrelated housekeeping, or chase side bugs that do not block
gates -- all are forms of passive waiting.
Situation to action
| Situation | Action |
|---|
| A task finishes | Dispatch next unblocked task from the plan |
| A check fails | Fix the failure, rerun the check |
| A background agent runs | Prepare review checklist, next brief, file list, or test plan; do not wait silently while safe parallel work remains |
| A non-blocking issue appears | Document it, continue current milestone |
| A real blocker appears | Stop and ask with 2 to 3 concrete options |
Workstream scale
Pick a tier from project signals (plan length, active workstream count,
recent diff size). Emit exactly that many workstreams.
- Small project: 2-3 workstreams.
- Medium project: 4-6 workstreams.
- Large project: 7-10 workstreams.
- Stress/reliability or explicit long-running request: 10+ workstreams,
only when the user asks for long-running work.
Defaulting to 10 on a small project is wrong at the keyboard. Away-mode
lifts the cap (see ## Away mode).
Tier signals
| Project signal | At-keyboard tier | Away-mode tier |
|---|
| Plan has 1-5 tasks; one milestone | small (2-3) | medium (4-6) |
| Plan has 6-15 tasks; one or two milestones | medium (4-6) | large (7-10) |
| Plan has 16+ tasks or multi-day request | large (7-10) | stress (10+) |
| Explicit "keep busy for N days" or "going to bed" | stress (10+) | stress (10+) |
Side quest discipline
SIDE QUEST is allowed only when it produces useful evidence, demos,
stress tests, reports, or diagnostics related to the active project.- Side quests MUST be labeled
SIDE QUEST in the TaskList.
- Side quests must not be confused with production-ready work.
- Random busywork side quests are forbidden.
Stale-workstream cleanup
When more than N workstreams are open (N = upper bound of the current
tier), emit a workstream status table:
| workstream | status | next action |
|---|
| A | DONE | close, write changelog entry |
| B | active | (no action) |
| C | BLOCKED | ask-only boundary or blocked fallback path |
| D | abandoned | delete or absorb into workstream E |
| E | needs cleanup | finalize evidence artifact |
Cleanup-table values combine the four canonical task-status labels with
two workstream-level lifecycle values (active, abandoned,
needs cleanup). The four canonical labels (DONE,
DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED) remain authoritative
for individual tasks; the cleanup table aggregates per workstream.
Workstream taxonomy
Full prompt templates and per-type artifact requirements live in
references/workstream_templates.md.
Types:
- audit workstream
- implementation workstream
- test workstream
- screenshot and evidence workstream
- report workstream
- cleanup workstream
- benchmark/profiling workstream
- failure investigation workstream
- alternative prototype workstream
- regression/bisect workstream
- stress and clutter workstream
- next-iteration push workstream
Blocked-fallback contract
Every workstream includes an explicit blocked fallback before dispatch.
Examples:
- If generator fails, hand-author 10 stress scenes.
- If Playwright blocks, produce static screenshots and document the
blocker.
- If a production seam blocks, continue with read-only audit and tests.
Boundaries
Ask-only boundaries, allowed-without-asking actions, and the metric-gaming
forbidden list live in references/boundaries.md.
Evidence artifact requirement
Every task handoff produces both:
- a status label from
DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or
BLOCKED, and
- an inspectable artifact path (file path, screenshot path, JSON path,
report path, command-log path, or before/after metric record).
This is how the manager stays trustworthy across an unattended stretch:
the user, on return, can audit any decision by reading the artifact.
"I looked into it" handoffs leave nothing to audit and are redispatched
per delegate-manager-to-subagents status handling.
Breadth before convergence
For uncertain problems, fan out multiple prototypes, hypotheses, scene
classes, best-case and worst-case galleries. Do not force a single plan
too early.
Standard output template
Emit this every time. Replace every <...> placeholder with a
project-specific value before dispatching.
Do not idle. Dispatch these workstreams now.
Active workstreams:
A. <workstream name> - <task> - artifact: <type> - blocked fallback: <if blocked>
B. ...
Blocked only by:
- <hard boundary 1>
Allowed without asking:
- <items from allowed list pulled in for this project>
Ask only for:
- <items from ask-only list pulled in for this project>
Final handoff must include:
- tasks dispatched
- files changed
- tests run
- screenshots or evidence artifacts
- metrics before/after
- blockers
- next workstream already started
What the skill must not do
- Invent fake progress.
- Push high-risk changes without approval.
- Hide uncertainty.
- Start broad migration just to stay busy.
- Spam tiny tasks.
- Create endless planning documents.
- Override explicit user instructions.
- Let "busy" replace "useful".
Handoff to manager
stay-busy emits a TaskList of workstream-shaped tasks plus the
output-template message, then returns control to
delegate-manager-to-subagents for dispatch. Skill is a generator, not an
executor. Task text passes verbatim to subagents per the manager's
task-text-discipline rule.
Workflow
- Confirm active
delegate-manager-to-subagents plan and idle state.
- Run finish-before-expanding: list active workstreams; if any need
verification, documentation, or final handoff, queue them first.
- Pick workstream-scale tier from project signals.
- Select workstream types from the taxonomy that fit current project
state. Pull prompt templates from
references/workstream_templates.md.
- Attach a blocked fallback to each workstream.
- Build TaskList: one task per workstream entry, with status-label and
artifact-path requirements stated verbatim.
- Emit the standard output template with
Ask only for and
Allowed without asking lists pulled from
references/boundaries.md.
- Return control to
delegate-manager-to-subagents.
