Runs an automated sweep to drain a task queue, building and committing tasks one by one.

Install

mkdir -p .claude/skills/sweep && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17571" && unzip -o skill.zip -d .claude/skills/sweep && rm skill.zip

Installs to .claude/skills/sweep

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Drain this repo's .agent/tasks/ queue autonomously and run-to-completion, taking EACH task to a ship-ready bar — claim a 00_todo/ task (`coop tasks claim`), build it, gate it green, self-review it against the .agent/rules KB and every hat, ITERATE until clean, COMMIT it on its own, then `coop tasks done` — without quitting early. Arms the Stop-hook sentinel. Use to "work all the tasks" / drain a backlog / run an unattended sweep.
433 charsno explicit “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Advanced

Key capabilities

  • →Claim tasks from the 00_todo/ queue
  • →Build and gate each task to a ship-ready bar
  • →Self-review changes against house rules and AGENTS.md
  • →Iterate on tasks until clean and ready for commit
  • →Commit each task individually with a focused message
  • →Archive completed tasks to 99_done/ or block to 50_blocked/

How it works

The skill autonomously processes tasks from a queue, claiming each one, building it to a ship-ready state, self-reviewing against defined rules, and committing it. It repeats this cycle until the task queues are empty.

Inputs & outputs

You give it
A repository with tasks in .agent/tasks/00_todo/
You get back
An empty 00_todo/ and 10_in_progress/ with committed changes

When to use sweep

  • →Draining a project backlog
  • →Running unattended task sweeps
  • →Automating repo maintenance tasks

About this skill

/sweep — drain the queue to a ship-ready bar, one commit per task

Run the work loop to completion. Claude scopes the queue Stop hook above to this skill's lifetime; runtimes with a persistent goal/tracker use that too. Scope: this repo's .agent/tasks/ (a task is a folder; its state is its directory — coop tasks lists and moves them).

Be agentic. Each task is taken to a ship-ready bar: built, gated, then self-reviewed from every angle it touches and iterated until clean — and only then committed, on its own. The bar is not "it compiles"; it's "I'd defend this in review from every hat and it breaks no house rule." The house rules are the spine: this repo's AGENTS.md and the worked examples in .agent/kb/rules/. Build to them, then check the diff against them.

1. Prepare

  • Set the runtime's persistent goal/tracker when it exists: do not stop until every scoped task is committed and archived or properly blocked, and both 00_todo/ and 10_in_progress/ are empty.
  • Read AGENTS.md in full (the gate and the contract), .agent/tasks/README.md, and every .agent/kb/rules/*.md (the taste KB). If coop is on PATH, run coop tasks; otherwise inspect the queue state directories directly to announce the open 00_todo/ count.

2. The loop — claim the next task, repeat until 00_todo/ and 10_in_progress/ are empty

  1. Claim — if coop is on PATH, run coop tasks claim <id>; otherwise move the task folder from 00_todo/ to the existing 10_in_progress/ directory yourself. Do this first, so a parallel agent won't grab it. For a task already in 10_in_progress/, read its state.md, log.md, claim and current diff. Resume your continuing assignment; reconcile an older claim with the user's current direction. Do not take over a separate worker's active task.
  2. Build — wear the hats; obey AGENTS.md, match .agent/kb/rules/ and the surrounding style exactly. A short written plan suffices for routine specified work; /spec for a non-obvious or cross-owner change. /verify-api before uncertain APIs.
  3. Verify the changed boundaries — focused happy/denial-path checks while iterating; use the repo's actual owner checks; prose needs no runtime or broad process/race suite. Run broad free checks once on the completed executable candidate; unknown/shared/build inputs require broad proof. Keep pending campaign proof explicit before archiving a slice. Honor the repo's validation rules. Retain failed or missing evidence honestly; do not require exhaustive upstream certification merely to review a new feature.
  4. Self-review the diff without waiting for slow gates, from every angle it touches — correctness, security / abuse path, UX, tests (including the failure path), docs, readability — against the house rules. Fix what you find; iterate until you'd defend it. Review and test results jointly determine readiness; a green test does not replace review or vice versa. Use one independent reviewer for substantive work, two for consequential architecture/security decisions, and self-review for spelling or fully specified mechanical edits.
  5. Commit — one focused commit for this task; keep log.md (the what + why) current.
  6. Final snapshot — after the commit, refresh state.md in 10_in_progress/: preserve the useful summary and traps, set Status to complete, and set Next action to none.
  7. Done — as the final filesystem action, if coop is on PATH run coop tasks done <id>; otherwise move the task folder to the existing 99_done/ directory yourself. A finished task is moved, never deleted — leave it in 99_done/; never run coop tasks rm (pruning the archive is the human's call). Blocked instead? Fill in decision.md (question · why it is blocked · options · recommendation), then use coop tasks block <id> when available or move the folder to the existing 50_blocked/ directory yourself.
  8. Spot unrelated work? Use the proposal route supplied by the current run when there is one. Otherwise capture ready work in 00_todo/: use coop tasks add when coop is on PATH, or create a self-contained task folder there. Only genuinely large or unscoped work goes to xx_backlog/ (coop backlog add when available, or the same folder fallback). Then return to the current task.

3. Finish

  • When 00_todo/ and 10_in_progress/ are empty, run a completeness pass: re-check every task you moved to 99_done/ against git log — relevant checks/review green and a commit exists. Run pending campaign-wide checks before declaring the requested outcome finished. Reopen anything that doesn't hold up with coop tasks claim <id> when available, or move it back to 10_in_progress/, and go again.
  • Report: tasks shipped, anything parked in the backlog or 50_blocked/, gate status.

When not to use it

  • →When the goal is to stop before all tasks are complete
  • →When the quality bar is only 'it compiles'
  • →When ignoring house rules or AGENTS.md

Limitations

  • →Requires adherence to AGENTS.md and .agent/rules/
  • →Does not stop until 00_todo/ and 10_in_progress/ are empty
  • →Each task must be taken to a ship-ready bar

How it compares

This skill enforces a rigorous, iterative build-gate-review-commit cycle for each task, ensuring a high-quality, ship-ready outcome, unlike simply building or committing without thorough self-review.

Compared to similar skills

sweep side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
sweep (this skill)03moNo flagsAdvanced
run-nx-generator55moReviewIntermediate
upgrading-expo36moReviewIntermediate
bump-go-dependencies15moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry