init git:20261106.65bef12A

Immutable. This exact content never changes and is served at /api/v1/blob/cd1cd4d3fddfb83a.

---
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.
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 <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 <plugin>, the project is at <project>`, 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 protections** (standard and full). Offer each one, 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/<branch>/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.
     - **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.
   - Private vulnerability reporting (full, or any public repo), so the `SECURITY.md` contact
     works: `gh api -X PUT repos/{owner}/{repo}/private-vulnerability-reporting`.
   - 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`.

   Some of these need a public repo or a paid GitHub plan. If GitHub refuses, say so plainly and
   continue: the local hooks and the CI gate still apply.
5. **Next.** If the repo already has code, run `/jit-speckit:adopt` now. For a new project, tell
   the user to run `/speckit-constitution`.
6. Summarize in four lines: the level, the files created, updated or kept, the 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: without it, nothing checks commits locally.
7. **Offer to commit it**, in one question: "Commit this on `chore/jit-speckit-<version>` and open
   the PR?" (the version is `version:` in `.specify/extensions/jit/extension.yml`). On yes: switch
   to that branch from the current one, 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 <version> (level <level>)`, push, and open a PR with 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 5) runs on that branch. On no: leave it
   uncommitted for the user to review, and say so.