codex/skills/pick-next-shell/SKILL.md
Pick the next shell whose dependencies are satisfied and carry it through planning: expand, refine, self-improve, halt. Use when the user asks to "pick next shell", "next shell", "continue project", "what's next", "next implementation step", or "continue with the plan".
npx skillsauth add tobihagemann/turbo pick-next-shellInstall 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.
Pick the next shell from .turbo/shells/ whose dependencies are satisfied, then carry it through the planning pipeline: expand → refine → self-improve → halt.
At the start, use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:
$expand-shell skill$refine-plan skill$self-improve skillCheck terminal conditions first:
status: done for all — the project is complete; stopdone status — there are unfinished plans; stopIf shells exist in .turbo/shells/, glob .turbo/shells/*.md and read each file's YAML frontmatter. A shell's depends_on entry is satisfied when .turbo/plans/<dep-slug>.md exists with status: done in its frontmatter.
depends_on are all satisfieddepends_onIf there are no candidates (everything is blocked), report which shells are blocked and which dependencies they're waiting on, then stop.
If multiple candidates exist, pick the one with the lowest shell number (from the NN- prefix $draft-shells gives each file). If ambiguous, use request_user_input to let the user choose.
State the picked shell path and its dependencies before continuing.
Workflow state lives at .turbo/workflows/<slug>.md — slug from the picked shell's basename without .md. It pairs one-to-one with the thread's goal. When this run's create_goal attempt succeeds, write the file fresh: Status: active plus this invocation's update_plan list as a checkbox list. When an unfinished goal already exists, mirror into the workflow file its objective names; when it names none, continue without workflow state. Mirror every update_plan call into the file; it holds the pipeline's remaining steps and their statuses. When this run created the goal, run the terminal step in order: mark the final entry completed and mirror it, set Status: closed, mark the goal complete with update_goal, then emit any halt message.
Attempt create_goal with the objective: "Carry the shell at <shell path> through expand, refine, and self-improve, mark the plan ready, and halt after the summary. Workflow state: .turbo/workflows/<slug>.md; mirror every update_plan call into it. Loop state lives under .turbo/loops/. After any context compaction, re-read the workflow file and any active ledger, and continue from the first unfinished entry. Mark this goal complete at the halt that follows the plan-ready summary." If an unfinished goal already exists, an outer workflow owns it; continue without creating one.
$expand-shell SkillRun the $expand-shell skill, passing the shell file path. Capture the resulting plan path for Step 3.
$refine-plan SkillRun the $refine-plan skill with the plan path from Step 2.
$self-improve SkillRun the $self-improve skill to compound planning learnings.
Update the plan's YAML frontmatter to status: ready.
Present a brief summary of the finished plan: the essence of what it builds and the key decisions behind it, short enough to read at a glance so the user does not have to open the full plan file. When the plan delivers value to a user, developer, or operator, also present a short list of stories capturing what that person gains, in the form "As a <persona>, I want <capability> so that <outcome>". Skip the stories only when no beneficiary or outcome can be named, such as a purely mechanical refactor. Fit both to the plan rather than a fixed template.
If this run created a goal in Step 1, mark it complete with update_goal. Then halt with this message:
Plan ready at
<plan path>.This is a good point to
/compactbefore implementing. Then run$implement-plan <slug>to implement. After that, run$pick-next-shellagain for the next shell.
$refine-plan.$implement-plan after an optional /compact.development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".