AI Agent Workflow
Agent-workflow requests are usually about choosing the smallest repeatable loop
that keeps the agent effective: start the session cleanly, keep repo work
grounded, use the right execution surface, and recover quickly when context or
tooling drifts. Keep the entrypoint focused on workflow triage and load the
references only when the user needs exact command recipes or deeper patterns.
When to use this skill
- Set up a clean daily workflow for Claude Code, Codex, Gemini CLI, or a
mixed-agent toolchain
- Recover from context overload, bad session hygiene, or tool sprawl
- Decide how to split work across chat, shell, MCP, worktrees, and multiple
agents
- Choose a practical repo-delivery loop for edit, test, review, and PR work
- Improve runtime verification habits, especially when a live browser or app
matters
Prefer a narrower sibling skill when the main job is more specific:
git-workflow for branch, commit, rebase, push, and PR coordination
agent-configuration for hooks, permissions, skills, plugins, and project
instruction files
playwriter when browser or runtime verification should use the live browser
session
clawteam, omg, omx, or ohmg when the user explicitly wants an
orchestrated team workflow rather than a general operating loop
Instructions
Step 1: Classify the workflow request before prescribing commands
Sort the request into one or two primary lanes:
- session-control: startup, context reset, prompt hygiene, resume, handoff
- repo-delivery: inspect, edit, test, verify, commit, PR
- tools-and-runtime: shell vs MCP vs browser vs extension surface
- multi-agent: delegation, worktrees, role split, synthesis
Ground the workflow with the active agent surface, current repo state, and the
pain point that is slowing the user down. Do not dump a universal command list
before the workflow lane is clear.
Step 2: Choose the smallest operating loop that fits
Use these defaults unless the environment proves otherwise:
- start with the lightest loop that can finish the job safely
- keep read-only inspection cheap before switching to edits or broad tool use
- prefer one bounded branch or worktree per meaningful change lane
- keep browser verification explicit when runtime behavior matters
- recover from context drift by resetting or handing off, not by piling more
instructions into the same polluted session
Step 3: Pull the matching reference, not the whole package
Load only the reference that matches the user's job:
references/session-and-context-management.md for startup, reset, resume,
handoff, and context hygiene
references/repo-delivery-and-runtime-loops.md for shell, test, PR,
worktree, and live-verification workflow patterns
references/mcp-and-multi-agent-patterns.md for MCP usage, delegation,
specialist routing, and cross-agent orchestration
Step 4: Keep workflow advice grounded in the actual surface
Before recommending a loop, confirm the relevant runtime facts:
- which agent or CLI is active
- whether the job is read-only, implementation, review, or verification
- whether a repo, remote, branch, or running app is already in play
- whether the browser or runtime check should use
playwriter instead of a
fresh headless browser
Do not prescribe worktree, PR, MCP, or multi-agent flows as generic defaults
when the task is small enough to finish directly.
Step 5: Verify the workflow result
After choosing or applying the workflow, verify with the smallest relevant
checks:
- repo state or branch state if the workflow touched code
- test or build status if the workflow included implementation
- browser or runtime checks when the workflow claims behavior changed
- explicit next owner or handoff state when the loop is not fully local
Do not claim the workflow is improved until the post-action state matches the
intended operating lane.
Examples
Example 1: Recover a polluted session
Input:
My agent session is getting slow and confused. What workflow should I use to
reset without losing useful context?
Expected shape:
- classifies this as a session-control problem first
- recommends reset, resume, or handoff tactics instead of piling on prompts
- preserves only the context needed for the next bounded task
Example 2: Pick a repo-delivery loop
Input:
What is a good daily workflow for using Claude or Codex to inspect code, make a
change, run tests, and open a PR without the session getting messy?
Expected shape:
- picks a compact inspect-edit-verify-commit loop
- uses worktrees or branches only when the scope justifies them
- includes verification before PR creation
Example 3: Decide between shell, MCP, and browser surfaces
Input:
I can use shell tools, MCP servers, or browser automation. How should I decide
which workflow to use for a task?
Expected shape:
- distinguishes read-only shell work from external-service or runtime needs
- keeps MCP or browser usage scoped to tasks that actually benefit from them
- routes live browser verification to
playwriter when the active session
matters
Example 4: Split a multi-agent task
Input:
I want one agent researching, another implementing, and another validating.
What workflow keeps that from turning into chaos?
Expected shape:
- classifies this as a multi-agent workflow problem
- recommends bounded ownership, artifact handoff, and synthesis checkpoints
- avoids parallelizing work that is still on the critical path
Best practices
- Start from the actual bottleneck, not a memorized command catalog
- Keep the primary loop small: inspect, act, verify, summarize
- Use worktrees and multi-agent splits only when they reduce contention or
waiting
- Prefer live-browser verification via
playwriter when runtime behavior
matters
- Reset or hand off polluted context instead of dragging stale assumptions
forward
- Keep detailed command recipes and platform-specific examples in references
so the entrypoint stays compact and triggerable
References
1---2name: agent-workflow3description: Plan and improve day-to-day AI coding-agent workflow across Claude Code, Codex, Gemini CLI, and MCP-heavy repos: session startup, context recovery, fast repo loops, runtime verification, worktree use, and multi-agent handoffs. Use when the user wants a practical operating workflow, even if they ask in shorthand like shortcuts, session reset, agent setup, MCP usage, parallel agents, or better daily flow. Triggers on: agent workflow, productivity, context management, session recovery, worktree, MCP, multi-agent.4---56# AI Agent Workflow78Agent-workflow requests are usually about choosing the smallest repeatable loop9that keeps the agent effective: start the session cleanly, keep repo work10grounded, use the right execution surface, and recover quickly when context or11tooling drifts. Keep the entrypoint focused on workflow triage and load the12references only when the user needs exact command recipes or deeper patterns.1314## When to use this skill1516- Set up a clean daily workflow for Claude Code, Codex, Gemini CLI, or a17 mixed-agent toolchain18- Recover from context overload, bad session hygiene, or tool sprawl19- Decide how to split work across chat, shell, MCP, worktrees, and multiple20 agents21- Choose a practical repo-delivery loop for edit, test, review, and PR work22- Improve runtime verification habits, especially when a live browser or app23 matters2425Prefer a narrower sibling skill when the main job is more specific:2627- `git-workflow` for branch, commit, rebase, push, and PR coordination28- `agent-configuration` for hooks, permissions, skills, plugins, and project29 instruction files30- `playwriter` when browser or runtime verification should use the live browser31 session32- `clawteam`, `omg`, `omx`, or `ohmg` when the user explicitly wants an33 orchestrated team workflow rather than a general operating loop3435## Instructions3637### Step 1: Classify the workflow request before prescribing commands3839Sort the request into one or two primary lanes:4041- session-control: startup, context reset, prompt hygiene, resume, handoff42- repo-delivery: inspect, edit, test, verify, commit, PR43- tools-and-runtime: shell vs MCP vs browser vs extension surface44- multi-agent: delegation, worktrees, role split, synthesis4546Ground the workflow with the active agent surface, current repo state, and the47pain point that is slowing the user down. Do not dump a universal command list48before the workflow lane is clear.4950### Step 2: Choose the smallest operating loop that fits5152Use these defaults unless the environment proves otherwise:5354- start with the lightest loop that can finish the job safely55- keep read-only inspection cheap before switching to edits or broad tool use56- prefer one bounded branch or worktree per meaningful change lane57- keep browser verification explicit when runtime behavior matters58- recover from context drift by resetting or handing off, not by piling more59 instructions into the same polluted session6061### Step 3: Pull the matching reference, not the whole package6263Load only the reference that matches the user's job:6465- `references/session-and-context-management.md` for startup, reset, resume,66 handoff, and context hygiene67- `references/repo-delivery-and-runtime-loops.md` for shell, test, PR,68 worktree, and live-verification workflow patterns69- `references/mcp-and-multi-agent-patterns.md` for MCP usage, delegation,70 specialist routing, and cross-agent orchestration7172### Step 4: Keep workflow advice grounded in the actual surface7374Before recommending a loop, confirm the relevant runtime facts:7576- which agent or CLI is active77- whether the job is read-only, implementation, review, or verification78- whether a repo, remote, branch, or running app is already in play79- whether the browser or runtime check should use `playwriter` instead of a80 fresh headless browser8182Do not prescribe worktree, PR, MCP, or multi-agent flows as generic defaults83when the task is small enough to finish directly.8485### Step 5: Verify the workflow result8687After choosing or applying the workflow, verify with the smallest relevant88checks:8990- repo state or branch state if the workflow touched code91- test or build status if the workflow included implementation92- browser or runtime checks when the workflow claims behavior changed93- explicit next owner or handoff state when the loop is not fully local9495Do not claim the workflow is improved until the post-action state matches the96intended operating lane.9798## Examples99100### Example 1: Recover a polluted session101102Input:103104```text105My agent session is getting slow and confused. What workflow should I use to106reset without losing useful context?107```108109Expected shape:110111- classifies this as a session-control problem first112- recommends reset, resume, or handoff tactics instead of piling on prompts113- preserves only the context needed for the next bounded task114115### Example 2: Pick a repo-delivery loop116117Input:118119```text120What is a good daily workflow for using Claude or Codex to inspect code, make a121change, run tests, and open a PR without the session getting messy?122```123124Expected shape:125126- picks a compact inspect-edit-verify-commit loop127- uses worktrees or branches only when the scope justifies them128- includes verification before PR creation129130### Example 3: Decide between shell, MCP, and browser surfaces131132Input:133134```text135I can use shell tools, MCP servers, or browser automation. How should I decide136which workflow to use for a task?137```138139Expected shape:140141- distinguishes read-only shell work from external-service or runtime needs142- keeps MCP or browser usage scoped to tasks that actually benefit from them143- routes live browser verification to `playwriter` when the active session144 matters145146### Example 4: Split a multi-agent task147148Input:149150```text151I want one agent researching, another implementing, and another validating.152What workflow keeps that from turning into chaos?153```154155Expected shape:156157- classifies this as a multi-agent workflow problem158- recommends bounded ownership, artifact handoff, and synthesis checkpoints159- avoids parallelizing work that is still on the critical path160161## Best practices1621631. Start from the actual bottleneck, not a memorized command catalog1642. Keep the primary loop small: inspect, act, verify, summarize1653. Use worktrees and multi-agent splits only when they reduce contention or166 waiting1674. Prefer live-browser verification via `playwriter` when runtime behavior168 matters1695. Reset or hand off polluted context instead of dragging stale assumptions170 forward1716. Keep detailed command recipes and platform-specific examples in references172 so the entrypoint stays compact and triggerable173174## References175176- `references/session-and-context-management.md`177- `references/repo-delivery-and-runtime-loops.md`178- `references/mcp-and-multi-agent-patterns.md`179- [Claude Code docs](https://code.claude.com/docs/)180- [OpenAI Codex docs](https://developers.openai.com/codex/)181- [Gemini CLI docs](https://google-gemini.github.io/gemini-cli/docs/)