Worktree Task-Pack Verification
Skill1 starsChanged 4 months agoMITView on GitHub
Verification discipline for multi-task work packs dispatched across isolated git worktrees. One independent verification agent per worktree, a full dual-stack gate before any merge, and explicit stall detection. Use whenever you dispatch a numbered task pack (T1, T2, T3...) to run in parallel worktrees.
In this repository25 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- braindump-autoSkill
- braindumpSkill
- Capability Claim GroundingSkill
- Derived Figure AuditSkill
- design-review-loopSkill
- Dictation Garble CatcherSkill
- Discord Todo OpsSkill
- Full Account Security AuditSkill
- Large Task Session SplitSkill
- Personal Dashboard StyleSkill
- Pre-Push Secret ScanSkill
- Project Design DocSkill
- Public Repo Leak RetractionSkill
- repo-hygieneSkill
- Repo Index Drift CheckSkill
- Safe Section DeletionSkill
- Session HandoffSkill
- Skill Overlap AuditSkill
- superbraindumpSkill
- ui-change-visual-verifySkill
- Verify, Don't TrustSkill
- Windows Process Restart (Safe)Skill
- Windows Shell Tool SelectionSkill
- Zombie Process SweepSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
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 38
Every task pack member has: an independent verifier's confirmation (not the executor's own report), a real 2-parent merge commit (or a …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Worktree Task-Pack Verification
Extends verify-dont-trust to the specific shape of dispatching many tasks across isolated worktrees and merging the results back.
Why this exists
Real, logged failure modes from exactly this pattern:
- A task can be genuinely finished, correct, well-tested code, and just sit uncommitted because the session stopped mid-task with no visible error.
- A task can report "merged cleanly" while the commit is provably single-parent and never touched the target branch.
- Two independent tasks can each compile fine in isolation and only break when merged together (e.g. two branches independently claiming the same enum slot).
Procedure
1. Dispatch one independent verification agent per worktree, not the same agent that did the work grading its own output. Each verification agent reads the real commits/diffs directly and runs its own gate. It does not trust the executor's self-report.
2. Check for silent stalls before assuming a task "isn't done":
git status --porcelain # uncommitted-but-real work sitting there
git log -1 --format="%cd" # staleness of the last commitCross-reference against whether any process tied to that worktree path is still alive. A stalled-but-complete task should be finished and committed centrally, not re-run from scratch.
3. Never trust a "merged cleanly" claim: apply verify-dont-trust check #1 (git show -1 --format=%P, git merge-base --is-ancestor) to every task pack member before treating it as integrated.
4. Run the full gate on the merged tree, not just each worktree individually. Per-worktree tests passing does not guarantee the merged result is clean. Run the complete build+test suite for every affected stack (e.g. cargo test --workspace + npm run check && npm run build && npm run test) after merging, not before.
5. Resolve real merge conflicts by regenerating, not hand-merging, where possible (e.g. a lockfile conflict from two branches adding different dependencies: regenerate from the manifest rather than manually reconciling the lockfile diff).
6. When multiple independently-dispatched verification agents surface the exact same gap or the exact same false claim, treat that as a strong signal. Investigate immediately rather than assuming coincidence.
Done-when
Every task pack member has: an independent verifier's confirmation (not the executor's own report), a real 2-parent merge commit (or a clean fast-forward), and a full green gate on the post-merge tree.
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.

