start-devlisted

## Live context !`git branch --show-current 2>/dev/null | sed 's/^/current branch: /' || echo "not a git repo"` !`gh repo view --json defaultBranchRef --jq '"default branch: \(.defaultBranchRef.name)"' 2>/dev/null || true` !`gh issue list --state open --limit 5 --json number,title --jq '.[] | " #\(.number): \(.title)"' 2>/dev/null | head -5 || true` # start-dev Compatibility entry point for "implement this". Routes the request to the right piece of the workflow and stays out of the way. > **Direction of travel.** Implementing and delivering are now separate skills: `worker-dev` (implement → validate → commit → handoff, inside an objective) and `deliver-dev` (review the integrated diff → gates → push → one PR for the objective). `/start-dev` remains a fully supported front door: for a simple standalone task it still runs the same implement→PR flow it always has, and for work an objective already owns it hands off to `worker-dev` and opens no PR. Nothing you invoke today stops working. Over time, reach for `/orchestrate-dev` for multi-part work, and `worker-dev`/`deliver-dev` directly when you want one half of an objective's flow. ## Why this skill exists `start-dev` used to run one monolithic implementation→PR flow, which quietly assumed **every task is its own pull request**. That assumption breaks the moment a single user objective is split across several tasks: you get five PRs for one feature, five CI runs, five review cycles, and no place where the combined diff is