@skitterbyte/skitterspec-linear 1.0.0

package/assets/skills/spec-go/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: spec-go
+description: Promote a spec into active development and implement its first phase. Moves the spec from backlog into specs/in-progress/, then builds phase 1 with tests. Targets a spec by name (arg) or the spec currently in context. Use when the user says "/spec-go", "start this spec", "begin implementing <spec>", or "let's build the next phase".
+---
+
+# /spec-go — start (or continue) implementing a spec
+
+## 1. Identify the target spec
+
+- If a name/path is given as an argument, use it.
+- Otherwise use the spec **currently in context** (the one just created or
+  discussed). If neither is clear, ask which spec.
+- Locate it by searching `specs/` (check `specs/backlog/` first, then the other
+  buckets). A spec is a `<name>/` folder whose entry point is `00-overview.md`,
+  with **one file per phase** alongside it (`01-<slug>.md`, `02-…`). Legacy specs
+  may be a bare `<name>.md`, or a `00-overview.md` with inline phases — handle
+  those too.
+
+## 2. Move it into development
+
+**If per-spec isolation is enabled** (`specs/.core/env.config.json` exists) and
+the spec doesn't already have a worktree, provision it **first**, so all the
+housekeeping below lands on the spec's branch and never on `main`:
+
+- Run `skitterspec spec-env up <name>` (the `/spec-env` engine). It adds a git
+  worktree on a branch forked from `main`, and — only when the spec's
+  `> **Stack:**` header is `worktree + docker` — also brings up its Docker stack.
+  Print the worktree path and the opener command it emits.
+- **Trust the worktree for this session.** The engine wrote the printed
+  `trusted:` root into `.claude/settings.local.json` (gitignored) so future
+  sessions trust it automatically — but that file likely won't hot-reload now,
+  so run `/add-dir <trusted root>` before editing into the worktree, or the
+  first edits will prompt.
+- **Do the rest in the worktree**, on the branch: open it (the printed opener, or
+  a fresh Claude session rooted there) or, staying in this session, act on the
+  worktree path with absolute paths / `git -C <worktreePath>`. The spec move,
+  header edits **and** the phase's code all happen on the branch — so the spec's
+  evolution travels with the code it describes and lands in one PR. `main` changes
+  only when that branch merges (at `/spec-complete`).
+
+Then move the spec (in the worktree when isolated, in place otherwise):
+
+- If it isn't already under `specs/in-progress/`, move the whole spec folder
+  there. **Use `git mv`** to keep history:
+  `git mv "specs/backlog/<name>" "specs/in-progress/<name>"`.
+  `mkdir -p specs/in-progress` first if needed.
+- Update the **Status** header in the entry point:
+  `> **Status:** In Progress — Phase 1 (started <YYYY-MM-DD>)`.
+- Set the **Developer** header field if it's still `—`: use `git config user.name`.
+- Append a **State log** row:
+  `| <YYYY-MM-DD> | In Progress | in-progress | <git user.name> |`.
+- **When isolated:** commit the move and **push the branch** now — that records
+  the in-progress state for everyone and fires the tracker's automation (when a
+  ticketing provider is linked).
+
+A spec ideally reaches here as `Ready` (via `/spec-ready`), but `/spec-go` works
+on a `Draft` too — just sanity-check it's well-formed before building.
+
+If the spec is already in `in-progress`, skip the move and implement the **next
+unfinished phase** instead of Phase 1. (When isolated, subsequent `/spec-go` runs
+happen from inside the worktree — where the spec already sits in `in-progress` on
+the branch — and a re-run of `spec-env up` just re-attaches it.)
+
+## 3. Pre-flight — commit prior work, then compact
+
+Before writing any code for this phase, get the workspace and context clean:
+
+- **Confirm the last-worked phase is committed.** Run `git status` and
+  `git log --oneline -5`. The most recently *implemented* phase (not necessarily
+  the numerically previous one) should already be committed. If prior-phase work
+  is still uncommitted, **stop and suggest committing it first** (e.g. via
+  `/commit`) so each phase lands as its own reviewable commit — don't build the
+  next phase on top of an uncommitted one. (Skip if this is the first phase —
+  there's nothing prior to commit.)
+- **Compact, then continue.** Recommend the user run `/compact` now. A fresh,
+  minimal context keeps the phase focused and avoids drift from earlier turns;
+  the spec file on disk is the source of truth, so nothing is lost. Pause for the
+  `/compact`, then implement the phase.
+
+## 3b. Pull from the tracker first (only if a provider is installed)
+
+**Only when a ticketing provider with a `/spec-pull` skill is installed** and the
+spec is linked to the tracker. Otherwise skip this step — no provider means zero
+change to the flow below. Follow the provider's pull steps below (nothing to do
+here without one).
+
+**Only when `specs/.core/linear.config.json` exists** and the spec carries a
+`linear_project_id` in its `00-overview.md` frontmatter. Otherwise skip this
+step — no config means zero change to the flow below.
+
+- **Run `/spec-pull` first.** Bring down anything Linear changed since the last
+  sync (status, priority, discussion-driven fields) so you build against the
+  current shared state, not a stale snapshot. On a conflict it refuses — relay
+  that and let the user resolve before continuing; do not `--force` for them.
+- **Commit the refreshed snapshot** into the feature branch (a small
+  `chore(spec): pull latest from Linear`-style commit) so the frozen spec rides
+  in the PR alongside the code it describes.
+- Linear's GitHub branch/PR automation may now drive status transitions off the
+  branch and PR you pushed in step 2 — expect state to move on the Linear side;
+  keep any manual status edits minimal to avoid fighting it.
+
+## 4. Implement the phase
+
+Identify the **first unfinished phase** from the `00-overview.md` phase index,
+then open its phase file (`0N-<slug>.md`) — that file holds the tasks. Mark it
+started: set the phase-file heading to `🔄` and its `> **Status:**` to
+`In progress`, and flip the matching row in the overview phase index to `🔄`.
+Then build it, following the project rules in `.claude/rules/*.md` and `CLAUDE.md`:
+
+- Work task by task through the phase file. Make focused edits that match
+  surrounding code.
+- Honour the project's conventions (see `.claude/rules/spec-planning.md` and the
+  rules it links).
+- **Tests are part of the phase, not after it.** Create/extend tests for the
+  work, then run the project's typecheck and test commands. Do not declare the
+  phase done until green.
+- Never hardcode dates in tests; never run destructive commands against a real
+  database — use the project's test database only.
+
+## 5. Record progress
+
+- In the **phase file**: tick completed tasks (`- [x]`), flip its heading to `✅`,
+  and set its `> **Status:**` to `Done`.
+- In **`00-overview.md`**: flip the matching phase-index row to `✅`.
+- If anything changed from the plan (a decision, a deviation, a discovered
+  constraint), add a dated **Changelog** entry in `00-overview.md`.
+- If new work surfaced, add it as tasks to the appropriate phase file (or add a
+  new phase file + index row) rather than doing it silently.
+
+## 6. Report
+
+Summarise what was implemented, the test result (quote failures if any), and
+which phase is next. Do **not** `git commit` unless the user asks — finish,
+verify, and wait.

package/assets/skills/spec-init/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: spec-init
+description: Bootstrap the spec-driven-development workflow in the current project — create the specs/ lifecycle folders and .core, wire version-control so specs are tracked, verify the spec skills are installed, and add the spec workflow to CLAUDE.md and .claude/rules. Idempotent and safe to re-run. Use when setting up a new project for specs or repairing the setup, or when the user says "/spec-init", "set up specs here", "initialise the spec process".
+---
+
+# /spec-init — set up the spec-driven-development workflow
+
+Bootstrap (or repair) everything this project needs to run the spec lifecycle.
+**Idempotent:** detect what already exists, create only what's missing, and never
+clobber customised content. Finish with a summary of created vs already-present.
+
+> If `@skitterbyte/skitterspec` is installed, `npx @skitterbyte/skitterspec init` does
+> all of the below mechanically. This skill is the manual/repair path and is
+> useful when the package isn't available or you only need to fix part of the
+> setup.
+
+The system is **eight skills**: `spec` (feature), `spec-bug` (bug), `spec-ready`,
+`spec-review`, `spec-go`, `spec-complete`, `spec-cancel`, and this `spec-init`. The lifecycle is
+`backlog → in-progress → complete / cancelled`, with `.core` holding always-apply
+project rules.
+
+## 1. Folders
+
+Create any that are missing; drop a `.gitkeep` into ones that would otherwise be
+empty so git keeps them:
+
+- `specs/.core/` — project rules (always apply; never moved)
+- `specs/backlog/` `specs/in-progress/` `specs/complete/` `specs/cancelled/`
+
+## 2. Version control — keep specs tracked
+
+The whole lifecycle lives in git — **everything under `specs/` is tracked**, so
+the default is simply *no ignore rule excluding it*. Ensure `.gitignore` has no
+`/specs/*` (or similar) entry that would hide spec folders; if one exists and the
+project wants everything tracked, remove it. Confirm with
+`git check-ignore -v specs/.core/<any-file>` — it should print nothing (tracked).
+
+- **`.core` dotfile caveat:** only relevant if a `/specs/*` ignore is
+  (re)introduced — `*` matches dotfiles, so `.core` would need an explicit
+  `!/specs/.core/` negation. With no ignore rule, it's tracked automatically.
+- If the project uses a formatter/linter ignore glob that excludes `specs/**`,
+  decide whether spec markdown should be formatted/linted and adjust accordingly.
+- If a project later wants to **stop** versioning work-in-progress specs, that's
+  a deliberate opt-out (e.g. `/specs/*` + `!/specs/.core/`) — ask first; the
+  default is track-everything.
+
+## 3. Verify the skills are installed
+
+Check each of the eight skills resolves — `.claude/skills/<name>/SKILL.md`
+(project) or `~/.claude/skills/<name>/` (global). List any missing. This skill
+scaffolds the project; it does **not** regenerate skill bodies — missing skills
+must be copied in (e.g. `npx @skitterbyte/skitterspec init`) from a global install
+or a sibling project. If most/all are global, just confirm availability.
+
+## 4. Governing rule (`.claude/rules/spec-planning.md`)
+
+Ensure it exists. If missing, create it documenting:
+
+- the lifecycle skills with their **status** and **folder** (table);
+- the **type** convention — header `> **Type:** Feature|Bug` + filename prefix
+  `feat-`/`bug-` (never `[BUG]` brackets — glob hazard);
+- the **Author** / **Developer** header fields;
+- the **State log** audit table (folder/status transitions), kept separate from
+  the **Changelog** (decisions);
+- the project's concrete typecheck/test commands, and the rule that **every
+  phase ends with creating + running tests**.
+
+Read a sibling spec skill (e.g. `spec`, `spec-go`) for the canonical shapes
+rather than inventing them. If the rule already exists, leave it unless stale.
+
+## 5. CLAUDE.md
+
+Ensure a `## Spec workflow` section exists. If absent, add one with the
+skill table (`Skill | Action | Status | Folder`), the Feature/Bug type note,
+and a pointer to `.claude/rules/spec-planning.md`. Also update the `specs/` entry
+in any project-structure tree to show `.core/` + the four lifecycle folders. If
+the section exists, refresh only stale folder/skill names — don't rewrite it.
+
+## 6. Report
+
+Summarise per area — folders, `.gitignore` lines, tooling-ignore negations,
+skills (present/missing), rule file, CLAUDE.md section — as created / updated /
+already-present, plus the `git check-ignore` result for `.core`. Do **not**
+`git commit` unless the user asks.

package/assets/skills/spec-pull/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: spec-pull
+description: Pull a spec's linked Linear project into the local spec (Linear → repo), three-way aware. Applies remote-only fields; refuses to clobber local edits on a conflict unless --force (which backs up the local side first). Fetches Linear over MCP and runs `skitterspec spec-sync pull`. Opt-in — needs specs/.core/linear.config.json. Use when the user says "/spec-pull", "pull from Linear", "sync Linear changes down", or "update this spec from Linear".
+---
+
+# /spec-pull — bring Linear changes into the spec
+
+Linear → repo. Applies fields Linear changed since the last sync (status,
+priority, labels, and co-authored fields), rewrites the committed base, and
+stamps `last_synced_at`. It **refuses** to overwrite a local edit that conflicts
+with a Linear edit unless you pass `--force`.
+
+**Opt-in**: only runs when `specs/.core/linear.config.json` exists. If absent,
+tell the user how to enable Linear sync and stop.
+
+## 1. Identify the target spec
+
+Use the argument, else the spec in context; ask if unclear.
+
+## 2. Fetch the Linear project
+
+- Read `linear_project_id` from `00-overview.md` frontmatter; if missing, the
+  spec isn't linked — stop and point at `/spec`.
+- Discover the Linear MCP project-read tool at runtime. If Linear isn't
+  connected, relay the fix and stop — **do nothing destructive**.
+- Call it and write the project JSON to a temp file.
+
+## 3. Run the engine
+
+```
+skitterspec spec-sync pull <spec> --remote <tempfile> [--force]
+```
+
+- **No conflict** — the engine applies remote-only fields to the local snapshot,
+  rewrites the base, and stamps the sync. Body fields with no local home yet are
+  reported as `deferred` (apply them by hand from Linear if needed).
+- **Conflict** (a co-authored field changed on both sides) — the engine
+  **refuses** and lists the fields. Relay that; do not force on the user's behalf.
+- **`--force`** — only when the user explicitly asks. Remote wins after the engine
+  backs up the local side under `sync.backupDir` (the reflog). Relay the backup
+  path.
+
+## 4. Report
+
+Relay the git-like summary (applied / deferred / conflicts / backup / base). If
+fields were applied, remind the user to review and commit the refreshed snapshot.

package/assets/skills/spec-push/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: spec-push
+description: Push a spec's local content up to its linked Linear project (repo → Linear), three-way aware and ownership-respecting. Never pushes pull-owned fields or local-only sections; aborts if Linear moved since the last sync unless --force (which backs up the remote side first). Runs `skitterspec spec-sync push` then applies the blessed writes over MCP. Opt-in — needs specs/.core/linear.config.json. Use when the user says "/spec-push", "push to Linear", "sync my spec up to Linear", or "update the Linear project from this spec".
+---
+
+# /spec-push — send spec content up to Linear
+
+Repo → Linear. Sends the fields the repo owns/co-authors (description, phases,
+tasks per config) up to the linked project. It **never** writes `pull`-owned
+fields (status/priority/labels) or `localOnlySections`, and it **aborts** if
+Linear moved since the last sync (pull first) unless you `--force`.
+
+**Opt-in**: only runs when `specs/.core/linear.config.json` exists. If absent,
+tell the user how to enable Linear sync and stop.
+
+## 1. Identify the target spec
+
+Use the argument, else the spec in context; ask if unclear.
+
+## 2. Fetch the Linear project
+
+- Read `linear_project_id` from `00-overview.md` frontmatter; if missing, stop
+  (link via `/spec` first).
+- Discover the Linear MCP tools at runtime (project read **and** update). If
+  Linear isn't connected — or the update tool is missing — relay the fix and stop,
+  **writing nothing**.
+- Call the read tool and write the project JSON to a temp file.
+
+## 3. Run the engine (the guard)
+
+```
+skitterspec spec-sync push <spec> --remote <tempfile> --out <mergedfile> [--force]
+```
+
+- **Refused** (`remote-moved` / `concurrent-write` / conflict) — relay the message
+  and **stop**. Do not write to Linear. Suggest `/spec-pull` first.
+- **OK** — the engine has confirmed it's safe, rewritten the base, and stamped
+  `last_synced_at`. Its summary lists the `written` fields (and any `skipped`
+  because they're not pushable).
+- **`--force`** — only when the user explicitly asks. Local wins after the engine
+  backs up the remote side under `sync.backupDir`. Relay the backup path.
+
+## 4. Apply the blessed writes to Linear
+
+Only when step 3 returned OK: for each `written` field, call the Linear update
+tool with that field's local value (e.g. `description` → the project description).
+The engine has already vetted the change and moved the base — so if a Linear
+write fails, re-run `/spec-pull` to reconcile rather than retrying blindly.
+
+## 5. Report
+
+Relay the git-like summary (written / skipped / backup / base) plus which Linear
+fields you updated.

package/assets/skills/spec-ready/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: spec-ready
+description: Mark a Draft spec as Ready — confirm it's groomed (no unresolved open questions, phases and per-phase tests defined, decisions captured) and flip its status to Ready so it's a candidate for /spec-go. Stays in specs/backlog/. Targets a spec by name (arg) or the spec in context. Use when the user says "/spec-ready", "this spec is ready", or "mark <spec> ready to start".
+---
+
+# /spec-ready — promote a Draft spec to Ready
+
+A grooming gate between authoring (`/spec`, status `Draft`) and implementation
+(`/spec-go`, status `In Progress`). It does **not** move the spec — it stays in
+`specs/backlog/`; it only confirms quality and flips the status to `Ready` so
+you can see at a glance which backlog specs are good to start.
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate the spec folder under `specs/backlog/`. Entry point is its
+  `00-overview.md`; phases are separate files (`01-<slug>.md`, `02-…`) listed in
+  its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Check it's actually ready — don't rubber-stamp
+
+Review the spec against the readiness bar. If any of these fail, **stop and tell
+the user what's missing** rather than marking it Ready:
+
+- **Open questions resolved** — the `## Open questions` section is empty or
+  reads "None". Unresolved branches mean it isn't ready.
+- **Decisions captured** — the chosen solution and key trade-offs are recorded.
+- **Phased with clear tasks** — work is broken into phases, and **every phase in
+  the `00-overview.md` index has a matching phase file** (`0N-<slug>.md`) with
+  verb-first `- [ ]` tasks granular enough for one session. No index row without
+  a file, no orphan file without an index row.
+- **Tests baked into every phase** — each phase file ends with a
+  create-and-run-tests task (a phase isn't done until green).
+- **Concise and current** — no stale/contradictory sections.
+
+Offer to fix small gaps inline if the user wants; otherwise leave it `Draft`.
+
+## 3. Mark Ready
+
+- Set the **Status** header in the entry point:
+  `> **Status:** Ready (<YYYY-MM-DD>)`.
+- Append a **State log** row: `| <YYYY-MM-DD> | Ready | backlog | <git user.name> |`
+  (no folder change — Ready stays in `backlog`).
+- Optionally add a **Changelog** note if grooming changed anything substantive.
+
+## 4. Report
+
+Confirm it's Ready and note it stays in `backlog` until `/spec-go` picks it up.
+If you blocked it, list exactly what needs resolving first.

package/assets/skills/spec-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: spec-review
+description: Re-validate an existing spec against the current codebase — detect drift (renamed/removed files, changed APIs, tasks already done in code, stale decisions), grill where a decision is needed, and update the spec so it's relevant again. Targets a spec by name (arg) or the spec in context. Use when the user says "/spec-review", "is this spec still accurate", "this spec has gone stale", or before picking up an old backlog spec.
+---
+
+# /spec-review — bring a spec back in sync with the codebase
+
+Specs rot: the code moves on while a spec sits in the backlog or pauses
+mid-build. This skill re-validates a spec against the **current** code and
+rewrites the stale parts so it's safe to act on. It plans only — it does not
+implement anything (that's `/spec-go`).
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate the spec folder under `specs/` (any bucket). Entry point is its
+  `00-overview.md`; read it **and every phase file** (`01-<slug>.md`, `02-…`)
+  listed in its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Validate against the codebase — evidence first
+
+Read the spec, then check every claim it makes against the real code. Don't
+trust the spec's own wording — verify:
+
+- **Referenced things still exist.** Grep/read for each `file:line`, module,
+  function, route, model, type, or symbol the spec names. Flag anything renamed,
+  moved, or deleted.
+- **Tasks already done.** For each `- [ ]`, check whether the code already
+  implements it (it may have landed via other work). Tick `- [x]` what's done.
+- **Decisions still valid.** Re-check each `## Decisions` entry against the
+  current architecture and `.claude/rules/*.md`. Flag any that now conflict with
+  how the codebase actually works (a changed convention, a superseded approach).
+- **New constraints.** Note rules/patterns introduced since the spec was written
+  that it must now honour (e.g. a new required field, a new error type, a new
+  pattern the rest of the code now follows).
+- **Backward compatibility.** Re-confirm the planned API/schema changes are still
+  additive/safe given the current code (see the project's compatibility rules).
+
+## 3. Grill only where a decision is needed
+
+Where the drift forces a choice (the old approach no longer fits, a referenced
+thing is gone, scope is now ambiguous), grill the user like `/spec` Phase A —
+**one question at a time, with a recommended answer** — but scoped tightly to
+the drift. Don't re-litigate decisions that still hold. If you can resolve it by
+reading the code, do that instead of asking.
+
+## 4. Update the spec
+
+- Rewrite stale **Decisions** / **Solution overview** in `00-overview.md` and
+  stale **tasks** in the phase files so they match the current code and the
+  resolved questions. Add/remove tasks within a phase file; add a new phase by
+  creating a `0N-<slug>.md` file **and** a matching overview index row, or drop a
+  dead phase by removing both. Keep the index and files in sync; **preserve
+  completed `[x]` history**.
+- Tick tasks already satisfied by the code; re-open `## Open questions` for
+  anything still undecided.
+- Add a dated **Changelog** entry summarising the review (e.g. `- <date> —
+  Reviewed vs codebase: retargeted Phase 2 onto X, dropped Y (removed), ticked Z
+  (already done)`).
+- **Status:** if drift is minor, leave status as-is. If a `Ready` spec needs real
+  re-grooming, knock it back to `Draft` (set `> **Status:** Draft` and append a
+  **State log** row).
+
+## 5. Report
+
+Summarise the drift found, what you changed, any questions still open, and
+whether the spec is now safe to `/spec-go` (or needs `/spec-ready` again). Do
+**not** `git commit` unless the user asks.

package/assets/skills/spec-status/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: spec-status
+description: Show a spec's sync status against its linked Linear project — a read-only, git-status-style per-field divergence (local-only / remote-only / conflict / in-sync). Fetches the Linear project over MCP and runs `skitterspec spec-sync status`. Changes nothing. Opt-in — needs specs/.core/linear.config.json. Use when the user says "/spec-status", "is this spec in sync with Linear", "what's diverged from Linear", or "show spec sync status".
+---
+
+# /spec-status — show a spec's divergence from Linear
+
+Read-only. Prints, per field, whether the spec and its linked Linear project have
+diverged since the last sync — the `git status` of the hybrid sync. Writes
+nothing to either side.
+
+This skill is **opt-in**: it only runs when `specs/.core/linear.config.json`
+exists. If it's absent, tell the user to copy `linear.config.json.example` →
+`linear.config.json` to enable Linear sync, and stop.
+
+## 1. Identify the target spec
+
+Use the spec named as an argument, else the spec **currently in context**. If
+neither is clear, ask which spec.
+
+## 2. Fetch the Linear project (read-only)
+
+- Read the spec's `linear_project_id` from `00-overview.md` frontmatter. If it's
+  missing, the spec isn't linked yet — say so and stop (link it via `/spec`).
+- Discover the connected Linear MCP tools at runtime (the project-read tool). If
+  Linear isn't connected, relay "connect the `linear` MCP server" and stop — do
+  nothing else.
+- Call the project-read tool for that id and write the returned JSON to a temp
+  file (e.g. under the OS temp dir).
+
+## 3. Run the engine
+
+```
+skitterspec spec-sync status <spec> --remote <tempfile>
+```
+
+The engine does the three-way compare (local vs Linear vs the committed base) and
+prints each diverged field with its classification and sync direction. Without
+`--remote` it falls back to a local-vs-base comparison (still read-only).
+
+## 4. Report
+
+Relay the engine's summary verbatim, then offer the natural next step:
+`/spec-pull` for remote-only changes, `/spec-push` for local-only, and — for a
+`conflict` — resolve locally or use `--force` (which backs up the losing side).
+Never write anything from this skill.

package/bin/skitterspec-linear.js

@@ -0,0 +1,26 @@
+#!/usr/bin/env node
+'use strict'
+
+/**
+ * The Linear-provider distribution's bin — a superset of the base CLI.
+ *
+ * `spec-sync …` is handled here (the provider engine seam); every other command
+ * (`init`, `update`, `spec-env`, `--help`, …) delegates to the base CLI unchanged.
+ */
+
+const { run } = require('../src/cli.js')
+const { specSync } = require('../src/vendor/linear/cli-sync.js')
+
+async function main(argv) {
+  const [cmd, ...rest] = argv
+  if (cmd === 'spec-sync') {
+    await specSync(rest)
+    return
+  }
+  await run(argv)
+}
+
+main(process.argv.slice(2)).catch((err) => {
+  console.error(`skitterspec-linear: ${err.message}`)
+  process.exit(1)
+})

package/package.json

@@ -0,0 +1,38 @@
+{
+  "name": "@skitterbyte/skitterspec-linear",
+  "version": "1.0.0",
+  "description": "Spec-driven development for Claude Code, with Linear hybrid-sync — a superset of @skitterbyte/skitterspec: the base filesystem workflow plus git-like /spec-status · /spec-pull · /spec-push and the spec-sync CLI. Install this OR the base, not both.",
+  "keywords": [
+    "claude",
+    "claude-code",
+    "spec-driven-development",
+    "sdd",
+    "skills",
+    "scaffold",
+    "linear"
+  ],
+  "license": "MIT",
+  "author": "Reuben Greaves",
+  "type": "commonjs",
+  "bin": {
+    "skitterspec-linear": "bin/skitterspec-linear.js"
+  },
+  "files": [
+    "bin",
+    "src",
+    "assets"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "dependencies": {
+    "prompts": "^2.4.2"
+  },
+  "scripts": {
+    "prepack": "node ../../scripts/build-dist.js skitterspec-linear"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/skitterbyte/skitterspec.git"
+  }
+}