agent-workflows

Use when the user says they are stepping away and the agent should continue without interactive approvals

Use when an operable application or system needs dogfooding, a bug bash, or a behavior-first readiness gate through realistic user or operator tasks. Not for generic static code review.

Use when the user calls a docs cleanup, a campaign has shipped, or the repo has accumulated narrative, planning, status, handoff, or loop docs whose authoritative content belongs in the standing docs (VISION, BRIEF, SPEC, README).

Use when running e2e tests, debugging test failures, or fixing flaky tests. Covers failure taxonomy, fix rules, and workflow. Never changes source code logic or API without spec backing.

Use when evaluating how shared agent instructions (AGENTS.md, skills) hold up in recorded sessions or bounded representative tasks, then turning evidenced gaps into ratified amendments.

Use when preparing clean, logical git commits from an existing working tree

Use when syncing a feature branch onto the latest origin base branch via git rebase.

Use when fetching and pruning a worktree-based repository, removing stale local branches or worktrees, or fast-forwarding its important branches.

Use when preserving enough task context for another agent or future session to continue without the current conversation

Use when a dev host is overloaded, out of memory, or hitting fork/resource limits and stale localnets, orphaned dev daemons, or leftover containers need to be found and cleared safely

Use when the user asks for hunk notes or a review sidecar for a changeset, or is reviewing your changes in a live hunk session.

Use when the user wants to start or resume an unattended campaign on the current branch from a seed (LANE.md, LOOP.md, or the branch's issue) with an iteration budget, or asks to see the kickoff prompt without running it.

Use when operating on live systems - cutovers, migrations, production config changes, or incident triage

Use when a feature branch or campaign needs an autonomous multi-session loop — the user asks for a LOOP.md or a self-driving plan to finish a branch, says they are stepping away with work in flight, or a session must run or resume a campaign that has a LOOP.md (legacy path .claude/loop.md).

Use when a campaign LOOP.md needs to be checked, compacted, or closed through missionctl, when a legacy loop must be inspected or adopted, or when an outcome spans campaigns or repositories and earns an optional .mission/mission.yaml.

Use when the user asks to rebuild a feature branch into a clean, reviewable git history

Use when the user asks for a sitrep, a status report, or "where are we" — on the current campaign or task, on what all agent sessions are doing, or as a written status update for an outside audience

Use when the user shares a draft prompt or slash-command invocation and asks what to add, whether it is ready, or to tee it up before running it; the draft is reviewed, never executed.

Use when checking deployment health, investigating errors, reading logs, or working with Tiltfiles. Queries Tilt resource status, logs, and manages dev environments.

Use when starting tilt, debugging Tiltfile errors, or bootstrapping a dev environment. Starts Tilt in zmx, monitors bootstrap to healthy state, fixes Tiltfile bugs without hard-coding or fallbacks.

Use when requirements are clear enough to plan and the work spans multiple steps, files, or verification stages

Use when creating or editing a skill and you need it to be discoverable, concise, and native to the target harness

Use when starting dev servers, watchers, tilt, or any process expected to outlive the conversation. Provides zmx session management patterns for long-lived processes.