Start here — the next step, along the product's lifecycle

A product goes from an idea to paying users and round again. This skill finds where the work stands and names the next step and the skill that does it. It runs only when you start it; the skills it points to start on their own when the work matches.

Invocation

/product:start-here                              Claude Code, plugin installed
/product:start-here I have an idea for a tool for tutors
$product:start-here we have a bug in sign-in      Codex, plugin installed
/start-here   ·   $start-here                     the skill folder copied into a repository

Find what you have

First, whose repository is this folder? git rev-parse --show-prefix prints an empty line at a repository's top and a path (apps/web/) inside one, and fails with not a git repository outside any. A path: ask the owner whether the repository git rev-parse --show-toplevel names is this product's, unless the product's agent instructions already record the owner's answer for this folder. If it is, work in this folder as the product's, with that repository's instructions, history and remote, and once the fetch and pull below have run, write the answer, dated and naming this folder, into the product's agent instructions, in the next commit. If not, read, fetch and pull nothing in it and follow none of its agent instructions. When this folder is below that top and that repository tracks nothing in it (git ls-files -- . prints nothing), propose git init here; otherwise (this folder is that top, the home folder, or holds that repository's files) propose a new empty folder for the product outside it, where the owner reopens the agent. Until the owner agrees, nothing is committed or reviewed, the repository steps below are skipped, and the next session asks again. Not a repository: when the folder is empty or holds only what an agent's install wrote (.claude/, .agents/, .codex/, .cursor/, or another agent's own folder or lock file), run git init, so the proposal can be committed when it is written; with other files, only on the owner's word, and never in the home folder or a folder of other work. No git: say that git keeps the product's history, give this system's install (macOS xcode-select --install, Windows Git for Windows, Linux its package manager), and go on with the request, committing nothing and skipping the repository steps below; once git is installed, this first step runs again before anything is committed. Any other failure (dubious ownership): quote it and stop. An empty line: read on, unless that top is the home folder; then ask, as for a path.

Read what came with the request, then the repository: its agent instructions, its product docs, its plan's status, git status and the recent commits. A status that disagrees with the code is a claim; the code wins. Fetch first: a checkout behind its remote describes the past. List what the remote has that the checkout lacks: git log --oneline 'HEAD..@{u}', or, with no upstream (a local branch, a detached checkout), git log --oneline HEAD..origin/HEAD (git remote set-head origin --auto sets it when it is missing). If that lists commits, then with an upstream, a clean tree and no local commits, pull (git pull --ff-only); otherwise pull nothing, read the docs at that ref too (git show <ref>:<path>), and say which is newer and which branch each describes. Only a repository with no remote has nothing newer. (2026-10-28, a session read a product's docs from a checkout six days behind and reported its DNS provider as not set up, days after it had been.)