@skitterbyte/skitterspec-linear 12.0.0 → 14.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/MIGRATION.md +296 -10
- package/README.md +32 -2
- package/assets/claude-md-section.md +38 -2
- package/assets/commands/spec-connect.md +2 -2
- package/assets/commands/spec-live.md +2 -2
- package/assets/core/SETUP.md +21 -3
- package/assets/core/env.config.json.example +7 -3
- package/assets/core/env.config.md +90 -30
- package/assets/core/linear.config.md +58 -0
- package/assets/hooks/review-gate.js +141 -0
- package/assets/review/page.html +1787 -0
- package/assets/rules/spec-planning.md +250 -10
- package/assets/rules/spec-reports.md +321 -0
- package/assets/skills/spec/SKILL.md +33 -5
- package/assets/skills/spec-bug/SKILL.md +172 -9
- package/assets/skills/spec-cancel/SKILL.md +98 -21
- package/assets/skills/spec-claim/SKILL.md +114 -0
- package/assets/skills/spec-complete/SKILL.md +94 -25
- package/assets/skills/spec-diff/SKILL.md +678 -0
- package/assets/skills/spec-hotfix/SKILL.md +172 -11
- package/assets/skills/spec-init/SKILL.md +56 -7
- package/assets/skills/spec-linear-setup/SKILL.md +55 -1
- package/assets/skills/spec-list/SKILL.md +218 -0
- package/assets/skills/spec-next/SKILL.md +419 -7
- package/assets/skills/spec-push/SKILL.md +32 -8
- package/assets/skills/spec-review/SKILL.md +40 -5
- package/assets/skills/spec-reviewed/SKILL.md +258 -0
- package/assets/skills/spec-start/SKILL.md +386 -106
- package/assets/skills/spec-status/SKILL.md +24 -2
- package/assets/skills/spec-sync/SKILL.md +40 -4
- package/assets/skills/spec-to-main/SKILL.md +28 -6
- package/package.json +11 -7
- package/src/cli.js +1808 -89
- package/src/env/building.js +143 -0
- package/src/env/commitcmd.js +108 -0
- package/src/env/config.js +58 -9
- package/src/env/hooks.js +117 -0
- package/src/env/provision.js +54 -15
- package/src/env/proxy.js +34 -1
- package/src/env/render.js +3 -12
- package/src/env/resolve.js +295 -9
- package/src/env/review.js +1536 -0
- package/src/env/serve.js +573 -0
- package/src/env/teardown.js +13 -6
- package/src/init.js +150 -1
- package/src/vendor/linear/api.js +104 -1
- package/src/vendor/linear/cli-sync.js +854 -17
- package/src/vendor/linear/config.js +8 -0
- package/src/vendor/linear/credentials.js +94 -0
- package/src/vendor/linear/doctor.js +35 -0
- package/src/vendor/linear/identity.js +105 -0
- package/src/vendor/linear/mcp.js +26 -0
- package/src/vendor/sync-core/index.js +6 -2
- package/src/vendor/sync-core/src/compare.js +49 -3
- package/src/vendor/sync-core/src/normalize.js +30 -0
- package/src/vendor/sync-core/src/push.js +11 -1
- package/src/vendor/sync-core/src/write.js +38 -0
- package/LICENSE +0 -21
|
@@ -6,6 +6,11 @@ disable-model-invocation: true
|
|
|
6
6
|
|
|
7
7
|
# /spec-sync — the repo-wide Linear sync operations
|
|
8
8
|
|
|
9
|
+
> Stay silent while this runs — speak only to ask something you cannot answer
|
|
10
|
+
> yourself, or to report a failure at the moment it happens. Read
|
|
11
|
+
> `.claude/rules/spec-reports.md` before reporting; it defines the block this
|
|
12
|
+
> skill ends with.
|
|
13
|
+
|
|
9
14
|
`/spec-push` and `/spec-status` cover **one spec**. This skill covers everything
|
|
10
15
|
**repo-wide**, and is the answer to a bare "run spec-sync" — which is not itself
|
|
11
16
|
a command.
|
|
@@ -34,12 +39,18 @@ In a project that installs the Linear superset the binary is
|
|
|
34
39
|
|---------------|-----|
|
|
35
40
|
| bare `/spec-sync`, "what's linked?", "how much is mirrored?" | `linked` |
|
|
36
41
|
| "what states / projects does the workspace have?" | `states`, `projects` |
|
|
42
|
+
| "what specs are there?", "what's in the backlog?", "what is Jane on?" | `list` — or hand to `/spec-list` |
|
|
37
43
|
| "did the mirror survive the push?" | `verify <spec> --stored <file>` |
|
|
38
44
|
| "link this spec to KEY-1 by hand" | `stamp <spec> --issue KEY-1` |
|
|
39
45
|
| "mirror the whole backlog / every complete spec" | `apply --all <bucket>` — **confirm first** |
|
|
40
46
|
| "is the team key stale?", "did Linear get renamed?" | `retarget` |
|
|
41
47
|
| "what ticket am I on?", writing a commit | `ref` |
|
|
42
48
|
| "what shipped in this release?" | `released` |
|
|
49
|
+
| "move the shipped tickets on", "what's on test?" | `stage` — dry run unless `--apply` |
|
|
50
|
+
| "is any of this wired up?", "why isn't sync working?" | `doctor` — scaffold, isolation, tracker and key in one |
|
|
51
|
+
| "set my Linear key", "am I authenticated?" | `credentials <status\|set\|unset>` |
|
|
52
|
+
| "who am I in Linear?", "why is it assigning the wrong person?" | `whoami` — `--set` for a shared or bot key |
|
|
53
|
+
| "who's on this team?", "find Jane's user id" | `users <name-or-email>` |
|
|
43
54
|
| push one spec, or "what would push?" | **defer** — see below |
|
|
44
55
|
|
|
45
56
|
**With no argument, run `linked`.** It is the repo-wide overview, it is
|
|
@@ -74,6 +85,14 @@ pnpm exec skitterspec-linear spec-sync projects [--via api|mcp] [--json]
|
|
|
74
85
|
- **`states` / `projects`** reach the workspace. `states` also reports the
|
|
75
86
|
**transport** (`api` when a key is set, else `mcp`), which is the honest way to
|
|
76
87
|
answer "how is this talking to Linear?".
|
|
88
|
+
- **`list`** is the read side of the mirror: every spec issue Linear holds,
|
|
89
|
+
joined to the local spec folder that owns it. Unlike `linked`, it asks LINEAR
|
|
90
|
+
what exists rather than the repo — which is the only way to see a spec started
|
|
91
|
+
on a branch this checkout has not got. Scope is the live states by default
|
|
92
|
+
(`--all`, `--state <name>`, `--in-progress`, or `--next N` for the top of the
|
|
93
|
+
backlog in Linear's own order), and `--mine` / `--by <user>` filter by
|
|
94
|
+
assignee. **`/spec-list` is the front door** — hand over to it for anything
|
|
95
|
+
beyond a bare listing; it carries the MCP path and the offline degradation.
|
|
77
96
|
|
|
78
97
|
## 4. `verify` — check what the tracker actually stored
|
|
79
98
|
|
|
@@ -120,7 +139,7 @@ not the same risk:
|
|
|
120
139
|
|
|
121
140
|
A repo adopting Linear reports "N to create" for every unlinked spec, so an
|
|
122
141
|
unconsidered `--all` can mint dozens of sub-issues. Get the counts first — run
|
|
123
|
-
`linked` to see what is unlinked, or `spec-sync
|
|
142
|
+
`linked` to see what is unlinked, or `spec-sync plan <spec>` per spec for exact
|
|
124
143
|
numbers — then show the user something like:
|
|
125
144
|
|
|
126
145
|
```
|
|
@@ -195,6 +214,23 @@ so and asks you to confirm the key rather than guessing.
|
|
|
195
214
|
|
|
196
215
|
## 9. Report
|
|
197
216
|
|
|
198
|
-
Relay the engine's output
|
|
199
|
-
re-run it themselves.
|
|
200
|
-
|
|
217
|
+
Relay the engine's output **above the block**, and name the subcommand you ran
|
|
218
|
+
**in full**, so the user can re-run it themselves.
|
|
219
|
+
|
|
220
|
+
End with the block defined in `.claude/rules/spec-reports.md`. That file carries
|
|
221
|
+
the shape; this section carries only what is specific here.
|
|
222
|
+
|
|
223
|
+
**Verdicts**
|
|
224
|
+
|
|
225
|
+
- `✅` — the subcommand did what it says.
|
|
226
|
+
- `⚠️` — it ran, with something worth knowing — a partial result, a warning it
|
|
227
|
+
printed, a degradation it fell back to.
|
|
228
|
+
- `❌` — it wrote some objects and failed on another. Say what exists now.
|
|
229
|
+
- `⏸` — it refused: no config, an unvalidated state list, a bad argument.
|
|
230
|
+
Nothing was written.
|
|
231
|
+
|
|
232
|
+
**Fields:** `Tracker` · `Follow-ups` · `Next`
|
|
233
|
+
|
|
234
|
+
`Tracker` says what changed in Linear **and that the repo is unchanged** — it is
|
|
235
|
+
the source of truth either way, and a report that omits the second half reads as
|
|
236
|
+
though a sync had edited the repo.
|
|
@@ -6,6 +6,11 @@ disable-model-invocation: true
|
|
|
6
6
|
|
|
7
7
|
# /spec-to-main — land the branch on main, keep the spec open
|
|
8
8
|
|
|
9
|
+
> Stay silent while this runs — speak only to ask something you cannot answer
|
|
10
|
+
> yourself, or to report a failure at the moment it happens. Read
|
|
11
|
+
> `.claude/rules/spec-reports.md` before reporting; it defines the block this
|
|
12
|
+
> skill ends with.
|
|
13
|
+
|
|
9
14
|
The **intermediate** landing. `/spec-complete` also lands the branch, but then
|
|
10
15
|
verifies every phase, flips the status to Complete, `git mv`s the spec to
|
|
11
16
|
`complete/`, and tears the environment down.
|
|
@@ -93,10 +98,27 @@ and continue — the branch has no commits base doesn't already have.
|
|
|
93
98
|
- Do **NOT**: add a State-log row (status doesn't change), flip any phase/status
|
|
94
99
|
to Complete, `git mv` the spec, or tear down the worktree/stack.
|
|
95
100
|
**The spec stays `In Progress` and the worktree stays put.**
|
|
96
|
-
-
|
|
97
|
-
**never pushes** — mention the user can `git push` the base branch themselves to
|
|
101
|
+
- It **never pushes** — say the user can `git push` the base branch themselves to
|
|
98
102
|
trigger CI / the shared env.
|
|
99
|
-
-
|
|
100
|
-
committing on the same branch and can `/spec-to-main` again), and
|
|
101
|
-
when every phase is genuinely done — it will land the final
|
|
102
|
-
and tear down.
|
|
103
|
+
- `Next` points the way forward: `/spec-next` to continue the remaining phases
|
|
104
|
+
(you'll keep committing on the same branch and can `/spec-to-main` again), and
|
|
105
|
+
`/spec-complete` when every phase is genuinely done — it will land the final
|
|
106
|
+
commits, finalise, and tear down.
|
|
107
|
+
|
|
108
|
+
End with the block defined in `.claude/rules/spec-reports.md`. That file carries
|
|
109
|
+
the shape; this section carries only what is specific here.
|
|
110
|
+
|
|
111
|
+
**Verdicts**
|
|
112
|
+
|
|
113
|
+
- `✅` — the branch is on the base and the base is green.
|
|
114
|
+
- `⚠️` — landed, with something worth knowing.
|
|
115
|
+
- `❌` — the rebase conflicted, or the base went red after the fast-forward.
|
|
116
|
+
Quote it; the repo is mid-something and that is what the reader needs.
|
|
117
|
+
- `⏸` — a dirty worktree, red tests, or no spec to land. Nothing moved.
|
|
118
|
+
|
|
119
|
+
**Fields:** `Branch` · `Tests` · `Landed` · `Follow-ups` · `Next`
|
|
120
|
+
|
|
121
|
+
**No `Spec` field, deliberately.** This skill changes no status and moves no
|
|
122
|
+
folder, and a `Spec` line here would read as though it had. The spec stays
|
|
123
|
+
`In Progress` and the worktree stays standing — if that needs saying, the
|
|
124
|
+
verdict clause says it.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@skitterbyte/skitterspec-linear",
|
|
3
|
-
"version": "
|
|
4
|
-
"description": "Spec-driven development for Claude Code, with one-way Linear sync
|
|
3
|
+
"version": "14.0.0",
|
|
4
|
+
"description": "Spec-driven development for Claude Code, with one-way Linear sync \u2014 a superset of @skitterbyte/skitterspec: the base filesystem workflow plus /spec-status \u00b7 /spec-push and the spec-sync CLI. The repo is canonical; Linear is a generated mirror. Install this OR the base, not both.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"claude",
|
|
7
7
|
"claude-code",
|
|
@@ -25,14 +25,18 @@
|
|
|
25
25
|
"MIGRATION.md"
|
|
26
26
|
],
|
|
27
27
|
"engines": {
|
|
28
|
-
"node": ">=
|
|
28
|
+
"node": ">=22.13"
|
|
29
29
|
},
|
|
30
30
|
"dependencies": {
|
|
31
31
|
"prompts": "^2.4.2"
|
|
32
32
|
},
|
|
33
|
+
"scripts": {
|
|
34
|
+
"prepare": "node ../../scripts/build-dist.js skitterspec-linear",
|
|
35
|
+
"prepack": "node ../../scripts/build-dist.js skitterspec-linear"
|
|
36
|
+
},
|
|
33
37
|
"repository": {
|
|
34
38
|
"type": "git",
|
|
35
|
-
"url": "git+https://github.com/
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
}
|
|
39
|
+
"url": "git+https://github.com/SkitterByte/skitterspec.git",
|
|
40
|
+
"directory": "packages/skitterspec-linear"
|
|
41
|
+
}
|
|
42
|
+
}
|