--- name: init description: "Set up the current project (new or existing) with spec-kit and jit-speckit: one task = one issue = one branch = one PR, security checks on every commit, push and PR, and best-practice defaults sized by complexity level (lite, standard, full)." argument-hint: "[lite|standard|full]" disable-model-invocation: true --- # Set up a project with jit-speckit 1. **Tools.** Check `git`, `gh` and `specify`. - If `specify` is missing, offer to install spec-kit (the version jit-speckit is tested with): `uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v1.2.5`. If `uv` is missing too, point to https://docs.astral.sh/uv/ and stop. - If `gh auth status` fails, ask the user to run `! gh auth login` and stop. - If `gh repo view` fails, there is no GitHub repository yet, and issues and PRs need one: ask its name and visibility and offer `gh repo create --private --source . --remote origin` (`--public` for a public one; `git init -b main` first if there is no git repo). On no, go on without steps 4 and 5, and say that `/speckit-tasks` stops at creating the issues until there is one. 2. **Level.** Use the argument if it is `lite`, `standard` or `full`. If the project already has `.specify/extensions/jit/jit-config.yml`, this is an update: keep its `level:` and skip the question. Otherwise ask with these options, recommending one from what the repo shows: - **lite**: prototype, solo. `feat/*` → `main`, secret checks on commit and push, core defaults. - **standard** (default): a product, maybe a small team. Adds `develop`, CI, a security CI gate, Dependabot and the security baseline. - **full**: production with several environments. Adds `staging`, SAST in CI, CODEOWNERS, SECURITY.md, a release workflow, a threat model per feature, and required analysis. Recommend **full** for deploy or infra code, payments, personal data, or more than 2 active contributors (`git shortlog -sn --since=6.months | wc -l`); **lite** for an empty repo or experiment; otherwise **standard**. 3. **Setup.** From the project root run `bash "${CLAUDE_PLUGIN_ROOT}/bin/setup.sh" . --level `. Add `--no-branches` if the user doesn't want `develop`/`staging` pushed to `origin`. On failure, show the output and stop. When it refuses because `this plugin copy is , the project is at `, show that line as is and suggest `/reload-plugins` (this session runs an older copy of the plugin); add `--downgrade` only when the user asks to take the project back to the older version. 4. **GitHub settings** (every level). Read the visibility with `gh repo view --json visibility -q .visibility`. Offer each one, explain it in one line, and run it only on yes: - Rebase merges off, so a task PR never lands as several commits and one revert removes it: `gh api -X PATCH repos/{owner}/{repo} -F allow_rebase_merge=false`. - On lite, merge commits off too (squash only: each task PR is one commit on `main`): `gh api -X PATCH repos/{owner}/{repo} -F allow_merge_commit=false -F allow_squash_merge=true -f squash_merge_commit_title=PR_TITLE -f squash_merge_commit_message=PR_BODY`. Standard and full keep merge commits for the promotion PRs (`develop` → `main`); their task PRs are squashed by convention. - Only when the visibility is `PUBLIC` (both are free there): - Secret scanning with push protection: `gh api -X PATCH repos/{owner}/{repo} -f 'security_and_analysis[secret_scanning][status]=enabled' -f 'security_and_analysis[secret_scanning_push_protection][status]=enabled'` (the brackets are quoted, so zsh does not expand them). - Private vulnerability reporting, so the `SECURITY.md` contact works: `gh api -X PUT repos/{owner}/{repo}/private-vulnerability-reporting`. - On a `PRIVATE` or `INTERNAL` repo, say in one line instead: secret scanning with push protection needs GitHub Secret Protection, and private vulnerability reporting is for public repos. If GitHub refuses one, say so plainly and continue. 5. **Branch protection** (standard and full). Offer it only once the checks are green on the base branch (`gh run list --branch `). The gates read the whole history and every lockfile, and `enforce_admins` binds the owner too, so a finding that is already there would leave the setup PR red with no way to merge it. Until they are green, skip this step and say that running `/jit-speckit:init` again offers it, and that docs/security.md ("When a gate is red") says how to get there. Otherwise explain it in one line, and run it only on yes: - Branch protection on the base branches, requiring a pull request and the checks to pass: `gh api -X PUT repos/{owner}/{repo}/branches//protection` with `required_status_checks`, `enforce_admins: true`, `required_pull_request_reviews` and `restrictions: null`. - **Check names are job names, not workflow names.** GitHub matches each required check to a job's `name:`, or to the job's key when it has no name. Read them from the generated `.github/workflows/ci.yml` and `security.yml` (for example `rust`, `Secrets (gitleaks, full history)`). Never use `CI` or `Security`: no job reports under those names, so every PR would wait forever. Leave `Dependencies (osv-scanner)` out: it fails on any open advisory in the tree, so a new one would refuse every unrelated PR, and each Dependabot fix too. It stays a visible check on every PR and runs weekly. - **Approvals:** 1 on full, 0 on standard. On full with a single contributor (`git shortlog -sn | wc -l` is 1), say that requiring 1 approval would block their own PRs, and offer 0 until a second person joins. On a private repo it needs a paid GitHub plan. If GitHub refuses, say so plainly and continue: the local hooks and the CI gate still apply. 6. **Next.** If the repo already has code, run `/jit-speckit:adopt` now. For a new project, tell the user to run `/speckit-constitution`. 7. Summarize in four lines: the level, the files created, updated or kept, the GitHub settings and protections enabled, and the next command. If the script said the git hooks are "not active in this clone yet", repeat the command it gave; if it said "add these lines to it", repeat those lines and where they go: without either, nothing checks commits locally. A machine-wide `core.hooksPath` stays in charge: never replace it. If it said a workflow "never runs on a task PR", repeat that line: until that branch is added, the project's own CI does not check task PRs. 8. **Offer to commit it**, in one question: "Commit this on `chore/jit-speckit-` and open the PR into ``?" (the version is `version:` in `.specify/extensions/jit/extension.yml`; `` is `base_branch:` in `jit-config.yml`, or when that is `auto`, `develop` on standard and full and the default branch on lite). Task branches start from `` and scripts read the level from the tree, so the setup has to land there, on an update too: anywhere else, the next branch loses `.specify` and the git hooks, or keeps the old version. The default branch gets it at the next promotion. On yes: `git fetch origin`, then `git switch -c origin/`, taking the setup along (if git refuses because the two branches differ in those files, say so, and stop: run `/jit-speckit:init` again from ``). Stage **by name** only what the setup wrote (`.specify`, `.claude/skills`, and each file the script listed as created or updated; never `git add -A`), commit `chore: jit-speckit (level )`, push, and open the PR with `gh pr create --base ` and a two-line body saying what moved and that nothing else changed. It is a small fix: no spec, no issue; the hooks and CI still apply. Then `/jit-speckit:adopt` (step 6) runs on that branch. If `origin/` does not exist yet (the script said a branch is "not created yet"), there is no PR to open: tell the user to commit, push the default branch and run `/jit-speckit:level `. On no: leave it uncommitted for the user to review, and say so, and that its PR goes into ``.