Use this skill to turn a list of project stack slots (decision categories like "web framework", "test framework", "database") into concrete, version-pinned, security-vetted tool choices. This is the decision stage that comes after identify-stack-slots and before install-stack. Trigger it whenever a user has a slots YAML and needs to pick the actual tools, or says "pick my stack", "choose tools for these slots", "research and recommend my dependencies", "what should I use for each part of my stack", or hands you a slots list to fill in. This skill collects hard preferences, settles the keystone language/framework decision first (presented as a coupled pair when the two are tightly linked, so a downstream pick never silently corners the language), researches each remaining open slot's options and versions in that constraint, gets the user's picks, then pulls the exact version-specific install steps from each chosen tool's official docs, checks known vulnerabilities and recent-release supply-chain threats, and o
Use this skill at the very start of a brand new coding project of any kind (CLI, web app, API service, library, mobile app, desktop app, server, etc.) to figure out the categories of technology decisions the project's stack is composed of. Trigger this whenever a user is kicking off a new project and needs to plan their stack, asks "what do I need to decide" / "help me set up the stack" / "I'm starting a new X project", or whenever you're about to scaffold a project and haven't yet established which decision categories apply. This produces a YAML list of stack "slots" (categories like "web framework", "test framework", "database"), NOT concrete tool picks. The YAML output feeds a later stage that fills each slot.
Use this skill to install and scaffold a project from an approved, version-pinned stack YAML (the output of the decide-stack skill). Trigger it whenever a user has a locked stack file and wants the project actually set up, or says "install my stack", "set up the project from this YAML", "scaffold the project", "run the installs", or hands you a stack file with concrete tools, versions, and install steps. This skill runs real commands on the user's machine: it goes through the stack in install order, runs each tool's official install steps at the pinned version, handles interactive prompts, verifies each step, and continues until the project is fully set up. It does NOT choose tools or research them; that is the separate decide-stack skill.
Use this skill to run the entire stack-it pipeline end to end in one guided pass. It takes a project from nothing to a working, verified, documented tech stack by running each stage skill in order (identify-stack-slots, decide-stack, install-stack, scaffold-and-verify, document-stack), resumes from wherever the project already is, optionally sets up git and commits a checkpoint after each stage, and keeps a running task list so the user can see how much is left. Use it whenever someone wants their whole stack set up rather than just one step. Phrasings like "set up my stack", "set up my whole project stack", "help me start a new project from scratch", "pick, install, and verify my stack", "take me from zero to a working project", "bootstrap my project", or "run the whole stack-it pipeline" should trigger it. It pauses only where it genuinely needs the user (their tool picks in the decide stage, an install confirmation, a stack-fault re-pick, an OK before writing docs) and handles the loop where a broken tool
Watch a pull request's CI to completion and fix any failures in its branch, bounded and cause-only. Use when CI is red on a PR or branch and you want it driven to green ("fix the CI on this PR", "CI is failing, sort it out", "watch the checks and fix what breaks"). Acts on a PR number, URL, or branch you name, or the current branch's open PR if you name none. Also called by the ship-it orchestrator's post-PR phase, one watcher per PR. Not for reviewing code quality (use a reviewer) or fixing local errors with no PR/CI (just fix those directly).
Audit code comments against the user's strict "comments explain non-obvious why, never narrate what the code does" standard, and propose concrete fixes (keep / trim / delete, or clarify the code so the comment is unnecessary). Use this whenever the user asks to review, audit, clean up, sanity-check, or justify comments; whenever they ask "did I follow the comment rules / our comment guidelines"; right after writing or heavily editing code; and before committing or opening a PR. Also use it proactively when you have just generated more than a couple of comments. The caller may restrict the audit to a path, a function/symbol, a glob, "staged", "the branch diff", or "the PR"; if no scope is given, audit only newly written or changed code, never the whole repo.
Implement a single work-unit (a tracker issue or a described task) end to end in its branch: explore, make the smallest correct change, verify, and commit. Use for "implement this issue", "fix issue 123", "make this change and verify it". The implement stage of the ship-it orchestrator, and usable standalone on an issue or a described task. Not for review (use review-and-address), comments (comment-cleanup), or CI (ci-fix).
Configure ship-it for this project. Detects the package manager, verify command, CI system, issue tracker, doc tools, and installed reviewers from the repo, asks only for what it cannot infer, then writes ship-it.config and generates doc-job skills for any docs without a built-in. Use to set up ship-it on a new project ("set up ship-it here", "configure ship-it", "ship-it init") or to reconfigure. Run once per project before using the ship-issues orchestrator.