agentleFS
SamuelNDCESamuelNDCE/ai-workbench/skills/worktree-task-pack-verification/SKILL.md

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.

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
  1. Distinctive:

    Every task pack member has: an independent verifier's confirmation (not the executor's own report), a real 2-parent merge commit (or a …

    line 38

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 commit

Cross-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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.