spec-setup

spec-setup

Learn this project's rules once, save them, and let every other spec-* skill reuse them. Team rules live in a config file the team can review and change — never in the skills themselves.

Where the config lives

.spec-driven.yml, found by walking up from the current directory (stop at the home folder). The first one found wins.

A multi-repo config only applies inside the repos it lists. If the current repo sits under that folder but isn't listed, treat it as having no config (ask whether to add it).

Step 1 — Detect before asking

Read, don't guess. Collect a draft of every field in references/config-template.yml:

1. Layout.
   • Inside a git repo with workspace markers (pnpm-workspace.yaml, workspaces in package.json, turbo.json, nx.json, lerna.json, go.work, [workspace] in Cargo.toml, several apps/*/packages/*/services/* with their own manifests) → monorepo; list the packages.
   • Not inside a git repo, but sibling folders are git repos → candidate multi-repo. Group them by remote owner (git remote get-url origin) and show the groups — the user picks which repos belong together. Never assume every folder in the parent belongs. Always also ask whether repos in other folders belong (e.g. ~/clients/billing). Check each path is a git repo, and store paths inside the workspace as relative and paths outside it as absolute.
   • The repos of one workspace can live in unrelated places (/Projects/frontend, ~/Work/backend, /srv/database). Put the config in their shared parent folder, or in ~/.spec-driven/<name>/ when that parent would be the home folder or /. Then record it in ~/.spec-driven/workspaces.json ({"<config path>": ["<repo path>", …]}) so every repo can find it.
   • The user can override the detected layout. If they choose multi-repo from inside one repo, the workspace folder defaults to that repo's parent, with the current repo pre-selected. If they choose monorepo, ask for the package folders. Never write a multi-repo config with no repos.
   • Otherwise → single.
2. Existing written rules. CLAUDE.md, AGENTS.md, CONTRIBUTING.md, PR templates, .github/workflows. Anything stated there is a strong default — quote it back to the user.
3. Tracker. Ticket keys in recent branch names and commit subjects (STP-123, #45, ENG-91), Jira/Linear links in PR templates or docs, whether GitHub Issues are enabled (gh repo view --json hasIssuesEnabled).
4. Git, per repo. Default branch (git symbolic-ref refs/remotes/origin/HEAD or gh repo view --json defaultBranchRef); integration branches (staging, develop, pre-prod); which branch recent PRs targeted (gh pr list --state merged --limit 20 --json baseRefName); the pattern of the last ~20 remote branch names; the commit style from git log -30 --format=%s.
5. Commands, per repo/package. package.json scripts plus the lockfile's package manager, Makefile, pyproject.toml/tox.ini, Cargo.toml, go.mod, composer.json, CI workflow steps (CI is often the most truthful source). Dev URL from the dev script, .env.example, or framework defaults.