@skitterbyte/skitterspec-linear 10.8.0 → 12.0.0

package/assets/skills/spec-to-main/SKILL.md

@@ -8,27 +8,29 @@ disable-model-invocation: true
 
 The **intermediate** landing. `/spec-complete` also lands the branch, but then
 verifies every phase, flips the status to Complete, `git mv`s the spec to
-`complete/`, and tears the environment down. **`/spec-to-main` stops after the
-land**: the worktree stays, the spec stays `In Progress`, and you can land again
-as you add commits.
+`complete/`, and tears the environment down.
+**`/spec-to-main` stops after the land**: the worktree stays, the spec stays
+`In Progress`, and you can land again as you add commits.
 
 Use it when a later phase can only be done *after* the current work is on `main` —
 e.g. it needs to run in CI, a deploy pipeline, or a shared test environment that
 builds from `main`. Land what you have, run that step, then come back and finish
-the remaining phases with `/spec-go` and eventually `/spec-complete`.
+the remaining phases with `/spec-next` and eventually `/spec-complete`.
 
 It reuses the **same engine** as `/spec-complete`'s landing (`spec-env integrate`
 — rebase + fast-forward), so it produces identical linear history. Because a
-fast-forward leaves `base == branch`, the operation is **idempotent and
-repeatable**: new commits put the branch ahead of base again, and you can run
-`/spec-to-main` as many times as you like.
+fast-forward leaves `base == branch`, the operation is
+**idempotent and repeatable**: new commits put the branch ahead of base again,
+and you can run `/spec-to-main` as many times as you like.
 
 ## 0. Preconditions — when this applies
 
 - **Isolation must be on** (`specs/.core/env.config.json` exists **and** the spec
-  is on a worktree provisioned by `/spec-go`). If isolation is absent, there is
-  nothing to land — the spec is authored directly on `main` already. Say so and
-  stop.
+  was provisioned by `/spec-start` — a worktree, or its branch in the checkout under
+  `mode: checkout`). If isolation is absent, there is nothing to land — the spec
+  is authored directly on `main` already. Say so and stop. `spec-env integrate`
+  reads `mode` and emits the matching plan; in checkout mode it rebases in place,
+  switches to base and fast-forwards, all in the one repo.
 - **Feature / Bug specs only.** A **Hotfix** (`Type: Hotfix`) is built on a
   release *tag* and cannot fast-forward onto `main` — refuse it and point the user
   at `/spec-complete` (it lands a hotfix via tag + cherry-pick). Check the header
@@ -56,10 +58,10 @@ primary checkout is dirty, or if a *different* spec holds it (release that one w
 
 ## 3. Tests must be green before landing
 
-Don't push red to `main`. Run the project's typecheck and test commands **in the
-worktree**; the suite must be **green**. For a **Bug** spec, confirm the
-originally-failing test now passes. If anything is red, stop and report — landing
-broken code onto `main` defeats the purpose.
+Don't push red to `main`. Run the project's typecheck and test commands
+**in the worktree**; the suite must be **green**. For a **Bug** spec, confirm
+the originally-failing test now passes. If anything is red, stop and report —
+landing broken code onto `main` defeats the purpose.
 
 (Note this is the *worktree* suite. The whole point of this skill is often to run
 a *further* check that only exists on `main` / in CI — that one runs **after** the
@@ -67,8 +69,8 @@ land, in step 5.)
 
 ## 4. Land — rebase + fast-forward
 
-Run `skitterspec spec-env integrate <name>` and run the printed commands **in
-order**:
+Run `skitterspec spec-env integrate <name>` and run the printed commands
+**in order**:
 
 - `git -C <worktree> rebase <base>` — replay the branch onto base.
 - `git -C <mainRepoPath> merge --ff-only <branch>` — fast-forward base.
@@ -89,12 +91,12 @@ and continue — the branch has no commits base doesn't already have.
   `- <YYYY-MM-DD> — Landed intermediate work onto <base> to <run CI / deploy to
   test env / …>; spec stays In Progress.`
 - Do **NOT**: add a State-log row (status doesn't change), flip any phase/status
-  to Complete, `git mv` the spec, or tear down the worktree/stack. **The spec
-  stays `In Progress` and the worktree stays put.**
+  to Complete, `git mv` the spec, or tear down the worktree/stack.
+  **The spec stays `In Progress` and the worktree stays put.**
 - Report: the base branch, the fast-forward result, and the green base test. It
   **never pushes** — mention the user can `git push` the base branch themselves to
   trigger CI / the shared env.
-- Point the way forward: `/spec-go` to continue the remaining phases (you'll keep
+- Point the way forward: `/spec-next` to continue the remaining phases (you'll keep
   committing on the same branch and can `/spec-to-main` again), and `/spec-complete`
   when every phase is genuinely done — it will land the final commits, finalise,
   and tear down.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skitterbyte/skitterspec-linear",
-  "version": "10.8.0",
+  "version": "12.0.0",
   "description": "Spec-driven development for Claude Code, with one-way Linear sync — a superset of @skitterbyte/skitterspec: the base filesystem workflow plus /spec-status · /spec-push and the spec-sync CLI. The repo is canonical; Linear is a generated mirror. Install this OR the base, not both.",
   "keywords": [
     "claude",