claude/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 TaskCreate to create a task for each step:
/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 AskUserQuestion to let the user choose.
State the picked shell path and its dependencies before continuing.
/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.
Then halt with this message:
Plan ready at
<plan path>.Planning context is likely full, and the plan is comprehensive enough to continue fresh. Run
/clear, then/implement-plan <slug>to implement. After that, run/pick-next-shellagain for the next shell.
/refine-plan./implement-plan in a fresh session.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".