stax: Skill for Claude Code

stax-dev

Run a bounded, evidence-carrying pipeline for one scoped stax change:

context/worktree → plan → implement → review + verify → repair (maximum 2) → optional benchmark → release

The harness may create a task worktree during triage. Only stax-release-manager may commit, push, or submit after the gates. Nothing in this workflow may merge or undraft a PR.

Run Contract

Resolve the project root dynamically with git rev-parse --show-toplevel; never assume a personal path. Create a unique run directory at <project-root>/_workspace/<run_id>/. These files are transient evidence and must not be committed:

context.md
plan.md
implementation-pass-0.md
review-pass-0.md
verification-pass-0.md
implementation-pass-1.md   # only after first repair
review-pass-1.md
verification-pass-1.md
implementation-pass-2.md   # only after second repair
review-pass-2.md
verification-pass-2.md
benchmark.md
release.md

Use pass 0 for initial implementation and passes 1 and 2 for the only permitted repair attempts. Every agent receives the project root, run directory, user request, approved plan, current pass, and paths of all prior artifacts it needs. Persist agent output to the named artifact when the agent cannot write it directly.

0. Context and Worktree Triage

Read AGENTS.md and inspect git status, the current branch/worktree, stax worktree ll, and stax ll. Record the request, project root, current branch, parent, worktree decision, pre-existing changes, and applicable instructions in context.md.

• Continue in the current checkout only when it is already a dedicated task worktree on the intended stacked branch.
• If the checkout is shared, trunk, or belongs to unrelated work, create or select a dedicated stax task worktree without moving, deleting, stashing, or overwriting user changes. Re-resolve the project root inside it.
• Stop for user direction if branch ownership, parentage, or unrelated dirty changes cannot be resolved safely.