plugins/yx/skills/work/SKILL.md
Pick up ready leaf yaks and implement them — dispatch subagents in isolated worktrees, then merge back to main
npx skillsauth add mattwynne/yaks workInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You orchestrate; subagents implement. Each leaf yak gets its own worktree and branch. When the subagent finishes and verification passes, you merge back to main.
The golden rule: Neither you nor your subagents may modify main's working tree.
When invoked with arguments (e.g., /yx:work fix auth bug), use those to identify which yak to work on.
Always announce: "I'm using /yx:work to implement leaf yaks in isolated worktrees. I'll merge back to main once verification passes."
Use when:
Don't use when:
/yx:map first)/yx:prepare first)The key: This skill provides structure; the project provides standards. Always check CLAUDE.md or project docs for verification requirements.
Neither you nor your subagents may modify main's working tree. Main is for merging finished branches only.
Why: Keeps main clean, prevents conflicts, makes rollback simple, enforces trunk-based development.
Always verify before starting:
yx show "yak name" --format json — if missing/vague, STOP and tell user to use /yx:prepareGood context includes: what needs doing, why it matters, what "done" looks like, and any constraints.
Step 1: Mark as WIP
yx start "yak name"
Step 2: Create Worktree
yx show "yak name" --format json # Get the slug/ID (e.g., "fix-auth-bug-a1b2")
git worktree add .worktrees/<yak-slug> -b <yak-slug>
Step 3: Dispatch Subagent
const yakContext = await getYakContext("yak name")
const prompt = `${yakContext}
Implement this yak. Commit when done. Follow any conventions in CLAUDE.md or project docs.`
await subagent({
agent: "claude",
task: prompt,
cwd: `.worktrees/<yak-slug>` // Work in isolated worktree
})
The subagent reads context as spec, implements, commits. You don't interfere — just wait.
Step 4: Review Subagent Output
When subagent returns: read what it did, check commits, verify it addressed acceptance criteria. If stuck:
yx tag "yak name" @needs-human
# Add question to context, pick another leaf
Step 5: Run Verification
cd .worktrees/<yak-slug>
npm test && npm run lint # Adjust to project (cargo test, pytest, etc.)
# Check CLAUDE.md for project-specific requirements
If verification fails: dispatch subagent again with failure info, or tag @needs-human. Do not merge failing branches.
Step 6: Merge to Main
cd <back to main>
git checkout main
git merge --ff-only <yak-slug> # Rebase first if main has moved
git push origin main
Step 7: Clean Up
git worktree remove .worktrees/<yak-slug>
git branch -d <yak-slug>
Step 8: Mark Done
yx done "yak name"
Work on multiple leaves in parallel if they're independent (don't touch same files or depend on each other).
Step 1: Identify Independent Leaves
Use yx list to find ready leaves. Check context to ensure:
Dependent examples (work sequentially): "Add migration" + "Use new schema", "Refactor auth" + "Add auth tests"
When in doubt, work sequentially.
Step 2: Create Worktrees
yx start "yak 1"
git worktree add .worktrees/<slug-1> -b <slug-1>
yx start "yak 2"
git worktree add .worktrees/<slug-2> -b <slug-2>
Step 3: Dispatch in Parallel
await subagent({
tasks: [
{ agent: "claude", task: yakPrompt1, cwd: `.worktrees/slug-1` },
{ agent: "claude", task: yakPrompt2, cwd: `.worktrees/slug-2` }
]
})
Step 4: Verify and Merge Each
Review output, verify, merge, clean up, mark done (same as single workflow). If conflicts arise: merge first, rebase second, dispatch subagent again if needed.
Tag when: context unclear, subagent stuck, verification fails unexpectedly, design question arises.
When encountering tagged yak: "This yak is tagged @needs-human. Question: [from context]. Answer now or pick a different yak?"
To add tag:
yx tag "yak name" @needs-human
yx context "yak name" <<'EOF'
[Existing context]
## Open Question
[What's blocking progress]
EOF
To remove after answer:
yx context "yak name" <<'EOF'
[Updated context with answer]
EOF
yx tag "yak name" --remove @needs-human
Complete lifecycle for a single yak:
# 1. Verify yak is ready
yx list # Find leaf yaks
yx show "yak name" --format json # Get slug and check context
# 2. Start work
yx start "yak name" # Mark as WIP
git worktree add .worktrees/<slug> -b <slug>
# 3. Implement (via subagent in worktree)
# [Subagent works, commits changes]
# 4. Verify
cd .worktrees/<slug>
npm test && npm run lint # Or project-specific commands
cd <back to main>
# 5. Merge
git checkout main
git merge --ff-only <slug> # May need rebase first
git push origin main
# 6. Clean up
git worktree remove .worktrees/<slug>
git branch -d <slug>
# 7. Mark done
yx done "yak name"
cwd to worktree path, never cwd: "."yx start before creating worktreeOnce you've completed one or more leaf yaks, present the status:
Completed yaks:
- yak name (merged in <commit-hash>)
- another yak (merged in <commit-hash>)
Updated yak tree:
[show yx list output]
Remaining ready leaves:
- other yak (context: brief description)
Next steps:
1. Continue with remaining leaves
2. Use /yx:map to discover more work
3. Use /yx:prepare if any yak needs clearer specs
What would you like to do?
| Action | Command |
|--------|---------|
| List leaf yaks | yx list (look for leaves) |
| Check yak details | yx show "yak name" --format json |
| Mark as WIP | yx start "yak name" |
| Create worktree | git worktree add .worktrees/<slug> -b <slug> |
| Dispatch subagent | subagent({ agent, task, cwd: ".worktrees/<slug>" }) |
| Verify work | cd .worktrees/<slug> && npm test (or project tests) |
| Merge to main | git merge --ff-only <slug> |
| Remove worktree | git worktree remove .worktrees/<slug> |
| Delete branch | git branch -d <slug> |
| Mark done | yx done "yak name" |
| Tag needs-human | yx tag "yak name" @needs-human |
| Remove tag | yx tag "yak name" --remove @needs-human |
/yx:map — Discover work structure and create yak tree/yx:prepare — Flesh out a yak with detailed specs and acceptance criteria../docs/yak-workflow.dot — High-level workflow showing when to use each skillworktree-flow.dot — Visual diagram of the worktree workflow (if exists)testing
Use when writing or reviewing Gherkin features, especially after discovering examples or edge cases that reveal a new business rule
databases
Use when running yx commands that create, modify, or delete yaks outside of real project work — provides an isolated temp environment
documentation
Use when starting work on a yak - sets up an isolated git worktree, reads yak context, and guides the full cycle from claiming through merge and cleanup
development
Use when planning work by approaching goals and discovering blockers, before creating comprehensive plans