sweep
Skill17 starsChanged 14 days agoMITView on GitHub
Coordinates independent units of work when separate context or parallel execution helps, with findings for read-only reviews and commits for completed changes. Use for /haechi:sweep when a task benefits from splitting into independent units.
21 other projects use a version of this.
Adopted by
Most recently taken up by
- ronniepinnell/caspertheir own version, first seen Nov 8, 2026
- AsiaOstrich/EngramGraphtheir own version, first seen Nov 8, 2026
- venhdev/skillstheir own version, first seen Nov 1, 2026
- AsiaOstrich/universal-dev-standardstheir own version, first seen Nov 1, 2026
- YSAA1/harness-workflowtheir own version, first seen Oct 30, 2026
- MH221B/skillstheir own version, first seen Oct 24, 2026
Used with
Projects with it also use incident, adr and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
JkudjoSkillincident
Production incident response — structured triage, hypothesis tree, safe remediation, incident record
Also in 3 projects that use this
asterkinSkilladr
Create Architecture Decision Records (ADRs) following project standards. Guides template usage, process, and best practices for documenting architecturally significant decisions.
Also in 4 projects that use this
anombyte93Skilldiscover
Phase 1 of the prd-taskmaster pipeline: brainstorm-driven discovery. Delegates to superpowers:brainstorming in Interactive Mode (one adaptive question at a time), or self-brainstorms in Autonomous Mode when no user is present. Intercepts before the brainstorming chain hands off to writing-plans — this skill owns the exit. Extracts constraints, calibrates scale (Solo / Team / Enterprise), and advances the pipeline to GENERATE.
Also in 3 projects that use this
MicrosoftSkilldiagnose
Use to systematically diagnose why scenarios fail — identifies root causes by analyzing agent traces, codebase, and behavioral patterns
Also in 4 projects that use this
nicolasestremSkillbrainstorm
Structured idea generation and solution exploration with systematic analysis.
Also in 4 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 7 projects that use this
Other versions21 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 21
- fallow-rs/fallow★ 5.3ksame name
- simota/agent-skills★ 96same name
- optave/ops-codegraph-tool★ 94same name
- AsiaOstrich/universal-dev-standards★ 84same name
- enapt/SwarmLLM★ 82same name
- iamneilroberts/claude-skills★ 26same name
- leek/agent-skills★ 5same name
- AsiaOstrich/EngramGraph★ 4same name
- YSAA1/harness-workflow★ 3same name
- drewdrewthis/claude-skills★ 2same name
11 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- aboutSkill
- answerSkill
- attack-testsSkill
- audit-experimentSkill
- bugSkill
- ci-watchSkill
- commitSkill
- contextSkill
- delegateSkill
- documentSkill
- evalSkill
- featureSkill
- impact-mapSkill
- implement-workSkill
- mrSkill
- mutation-checkSkill
- perfSkill
- previewSkill
- refactorSkill
- requestSkill
- review-diffSkill
- reviewSkill
- run-experimentSkill
- screen-designSkill
- screen-paritySkill
- setupSkill
- sibling-path-mapSkill
- specSkill
- test-hardeningSkill
- verify-workSkill
- work-graphSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 15 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Order: Use task priorities and dependency order.
“Common” is measured: kept by at least 6 in 10 of the 15 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Sweep
Apply the common work contract within the authorized scope. It owns required implementation, verification, review and completion obligations; this skill supplies methods. Use /haechi:delegate for a bounded worker task when independent execution helps. Existing step names below are compatible delegation entry points, not an exclusive workflow state.
The main session runs this, because agents cannot ask the user, start other agents or commit. The task requirements determine each unit and its dependencies. Common obligations and the selected methods apply to each unit; this procedure coordinates the independent work.
Steps
- Choose units and mode. Delegate units when independence or separate context offers a clear benefit; keep tightly coupled work together. Different files or failures can share one cause; check that before splitting them. Editing units must not write the same files concurrently. Read-only units may inspect shared context but should have distinct review questions. Example for test hardening:
src/utils/formatDate.tsplustest/utils/formatDate.test.tsis one unit. - Order. Use task priorities and dependency order; address relevant risk first.
- Preview material cost. Estimate effort when it affects the user's decision. For test hardening, use mutants per file and test run time. Ask before substantial extra work outside existing authorization; do not repeat an accepted cost decision.
- Run. Parallelize independent units when useful within the available resources. Keep dependent work sequential. Preserve the original acceptance conditions, exact values and shared contracts when writing each job; a shorter brief must not narrow the request. Give the worker the relevant context and let it choose its method. Review each unit as it finishes.
- Record each unit. Editing mode: one local commit per completed, reviewed unit, using the repo's convention and any relevant metric. Read-only mode: return findings and evidence in the conversation; make no edits or commits.
- Resume. Reuse completed findings and checks from the conversation. For editing work, also read
git logfor completed units. Do not create a progress file unless the task needs one.
Report
Report the task outcomes, units completed, units left and why. Compare actual effort with a cost preview when one was useful; no fixed report format is required.
Delegation contracts
These compatible entries identify delegated methods, not an exclusive workflow or a mandatory agent sequence. Packet assembly also supplies the canonical common work contract. The main session fills the named context fields and task-specific acceptance criteria; detailed procedures and principle bodies stay in their referenced files. read-only means repository files remain unchanged; authorized temporary or report outputs must be named separately in artifactPaths.
{
"implement": {
"skills": [
"implement-work"
],
"principles": [
"dry",
"yagni",
"kiss",
"boundary-validation",
"root-cause",
"failing-test-first",
"behavior-tests"
],
"checks": [],
"writeScope": "scoped",
"contextRequired": [
"repository",
"requirements",
"acceptanceChecks",
"ownership"
],
"completion": [
"Report the assigned implement work, its observed results and any remaining scope limitations."
]
},
"attack": {
"skills": [
"attack-tests",
"sibling-path-map",
"mutation-check"
],
"principles": [
"sibling-paths",
"behavior-tests"
],
"checks": [],
"writeScope": "scoped",
"contextRequired": [
"repository",
"requirements",
"changedFiles",
"ownership"
],
"completion": [
"Demonstrate that tests detect the targeted defects without weakening expected behavior."
]
},
"review": {
"skills": [
"verify-work",
"review-diff",
"impact-map"
],
"principles": [
"evidence-levels",
"behavior-tests"
],
"checks": [
"agent-defects",
"sibling-paths",
"dry",
"yagni",
"kiss"
],
"writeScope": "read-only",
"contextRequired": [
"repository",
"requirements",
"base",
"changedFiles",
"priorEvidence"
],
"completion": [
"Report concrete defects with expected and observed behavior and affected consumers.",
"Distinguish passing checks, failures, missing proof and unresolved expectations."
]
}
}Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

