@codyswann/lisa 2.341.4 → 2.341.6
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/all/copy-overwrite/scripts/lisa-work-item.mjs +14 -5
- package/dist/core/upstream-evidence-manifest.js +3 -3
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/skills/lisa-setup-linear/SKILL.md +13 -6
- package/plugins/lisa/commands/setup/linear.md +1 -1
- package/plugins/lisa/skills/lisa-setup-linear/SKILL.md +14 -7
- package/plugins/lisa-agy/commands/lisa/setup/linear.md +1 -1
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-agy/skills/lisa-setup-linear/SKILL.md +14 -7
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/commands/lisa/setup/linear.md +1 -1
- package/plugins/lisa-copilot/skills/lisa-setup-linear/SKILL.md +14 -7
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/commands/lisa/setup/linear.md +1 -1
- package/plugins/lisa-cursor/skills/lisa-setup-linear/SKILL.md +14 -7
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/commands/setup/linear.md +1 -1
- package/plugins/src/base/skills/lisa-setup-linear/SKILL.md +14 -7
|
@@ -206,14 +206,21 @@ function values(value) {
|
|
|
206
206
|
}
|
|
207
207
|
|
|
208
208
|
function lifecycleContract(config, provider) {
|
|
209
|
+
// Linear's lifecycle is a workflow STATE, exactly like Jira's status, so it
|
|
210
|
+
// is configured under `linear.workflow` — NOT `linear.labels.build`. The
|
|
211
|
+
// label path is still honoured as a fallback for any config written against
|
|
212
|
+
// the old shape. Reading only the label path meant nothing resolved, the
|
|
213
|
+
// GitHub-shaped `status:*` defaults below took over, and no Linear state name
|
|
214
|
+
// could ever match them, so every correctly claimed Linear issue was
|
|
215
|
+
// rejected as "not claimed".
|
|
209
216
|
const configured =
|
|
210
217
|
provider === "jira"
|
|
211
218
|
? config.jira?.workflow
|
|
212
219
|
: provider === "github"
|
|
213
220
|
? config.github?.labels?.build
|
|
214
|
-
: config.linear?.labels?.build;
|
|
221
|
+
: (config.linear?.workflow ?? config.linear?.labels?.build);
|
|
215
222
|
const defaults =
|
|
216
|
-
provider === "jira"
|
|
223
|
+
provider === "jira" || provider === "linear"
|
|
217
224
|
? {
|
|
218
225
|
ready: "Ready",
|
|
219
226
|
claimed: "In Progress",
|
|
@@ -228,7 +235,6 @@ function lifecycleContract(config, provider) {
|
|
|
228
235
|
: {
|
|
229
236
|
ready: "status:ready",
|
|
230
237
|
claimed: "status:in-progress",
|
|
231
|
-
...(provider === "linear" ? { review: "status:code-review" } : {}),
|
|
232
238
|
blocked: "status:blocked",
|
|
233
239
|
done: {
|
|
234
240
|
dev: "status:on-dev",
|
|
@@ -786,7 +792,7 @@ function linearIssue(ref, contract) {
|
|
|
786
792
|
"Linear validation requires LINEAR_API_KEY or a lisa-linear keychain entry"
|
|
787
793
|
);
|
|
788
794
|
const query =
|
|
789
|
-
"query($id:String!){issue(id:$id){id identifier team{key} state{type} labels{nodes{name}} children{nodes{state{type}}} attachments{nodes{url}} comments{nodes{body}}}}";
|
|
795
|
+
"query($id:String!){issue(id:$id){id identifier team{key} state{name type} labels{nodes{name}} children{nodes{state{type}}} attachments{nodes{url}} comments{nodes{body}}}}";
|
|
790
796
|
const payload = JSON.stringify({ query, variables: { id: ref } });
|
|
791
797
|
const result = secureCurl(
|
|
792
798
|
["https://api.linear.app/graphql"],
|
|
@@ -827,7 +833,10 @@ function linearIssue(ref, contract) {
|
|
|
827
833
|
);
|
|
828
834
|
}
|
|
829
835
|
assertRepoScope(ref, contract, issue.labels?.nodes);
|
|
830
|
-
|
|
836
|
+
// Lifecycle comes from the workflow STATE, the same shape the Jira path uses
|
|
837
|
+
// (`[issue.fields?.status?.name]`). Repo scope stays on labels above, because
|
|
838
|
+
// repo scoping genuinely IS a label.
|
|
839
|
+
assertClaimedLifecycle(ref, contract, [issue.state?.name]);
|
|
831
840
|
assertLeaf(
|
|
832
841
|
ref,
|
|
833
842
|
typeFromLabels(issue.labels?.nodes),
|
|
@@ -10,7 +10,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
|
|
|
10
10
|
"all/copy-overwrite/scripts/lisa-hooks/block-shell-json-parsing.sh": "1934a15e154fda3c2a40979a5cd6225661b14fe7bc77328a69ce499bea85dba7",
|
|
11
11
|
"all/copy-overwrite/scripts/lisa-hooks/parity-safety-net.sh": "062c69eea85157f1e941ec3626d8912aa9f182af6ccdbe19687588a6074db5ce",
|
|
12
12
|
"all/copy-overwrite/scripts/lisa-hooks/sonar-secrets.sh": "bf4132e49ba18e2f7e941520c299c15aeeacfd220e489f3d2eb8397f2048157b",
|
|
13
|
-
"all/copy-overwrite/scripts/lisa-work-item.mjs": "
|
|
13
|
+
"all/copy-overwrite/scripts/lisa-work-item.mjs": "2d9ca0841db9e75ddfd95e3a4d485fd01aa639a512ef648996f565b7991d8e2b",
|
|
14
14
|
"all/create-only/.claude/rules/PROJECT_RULES.md": "6e1c7923ad2a15356babc60c97e7f97be728d790af285b6a7cd7d1b4d39cd97f",
|
|
15
15
|
"all/create-only/.lisaignore": "3c9827e7e98daa46510b5357cd6dd9406da1821e64cc46d2eea9f311cd6d06b9",
|
|
16
16
|
"all/create-only/scripts/remote-agent-aws-setup.sh": "7677908a345891810d2104ba8b2fd1a8318bb29c408fb5ce0110d57beef9b556",
|
|
@@ -281,7 +281,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
|
|
|
281
281
|
"plugins/src/base/commands/setup/github-repo.md": "bbc7b243a8a1053f67b96108765507ae36e309db54ea3405fb4c99e7526a1d01",
|
|
282
282
|
"plugins/src/base/commands/setup/github.md": "0bc2649b3f75e06a9a4e565a568dffc6e9b25fffbf158537db9a9abdc0cddfa0",
|
|
283
283
|
"plugins/src/base/commands/setup/jira.md": "6eb95e989b25fe2ed72ec7d361a66b1c7eece6b9950ac0e841d00f6fd8f16d8a",
|
|
284
|
-
"plugins/src/base/commands/setup/linear.md": "
|
|
284
|
+
"plugins/src/base/commands/setup/linear.md": "c19f376ce1f4d52011c59ffe2bf68875323e4d74a19461798e37116e0faf9839",
|
|
285
285
|
"plugins/src/base/commands/setup/local-env.md": "e828a241d9f3ff6fbe9332a9a2ac18c594a5e0828426f8f1f0b8a2e1a3fcfbbe",
|
|
286
286
|
"plugins/src/base/commands/setup/notion.md": "2d705679db0dbb6c77728592a020430a529af9d0ef24ac7c434969d590d9f5a6",
|
|
287
287
|
"plugins/src/base/commands/setup/remote-env.md": "b1e8ec93bc660cc5ccf9e4c74a3a7bb6c94d5ff06c75f150479991fa1d564f2d",
|
|
@@ -576,7 +576,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
|
|
|
576
576
|
"plugins/src/base/skills/lisa-setup-github/SKILL.md": "75435e81130abd21c678d302b7a220da95a19868d122ca93168278628b200666",
|
|
577
577
|
"plugins/src/base/skills/lisa-setup-jira/SKILL.md": "261acaeb2923cc9238f468dcf986a0e1323a67e1e51d175b2c1b700dacab2fb8",
|
|
578
578
|
"plugins/src/base/skills/lisa-setup-kane/SKILL.md": "fe50024a4f896af01716f2435f57227b1f8de61803e80bf3e3c3247ec179b103",
|
|
579
|
-
"plugins/src/base/skills/lisa-setup-linear/SKILL.md": "
|
|
579
|
+
"plugins/src/base/skills/lisa-setup-linear/SKILL.md": "45567e53808836e418653e79066fb0f940543daae6baf158ffe07474a62560c5",
|
|
580
580
|
"plugins/src/base/skills/lisa-setup-local-env/SKILL.md": "4d4b8c92e3616256f5f689fbe433f09c31d39c623508bc4ec0d8c1770caddf22",
|
|
581
581
|
"plugins/src/base/skills/lisa-setup-local-env/scripts/local-env.mjs": "bff68aa66d6d4cd7cb9d0e39be691c6daa232edb097f8a601815432a32cca6a6",
|
|
582
582
|
"plugins/src/base/skills/lisa-setup-notion/SKILL.md": "f5a1e9290789fd1c33675168d30461fb24a11c98a433ef777c1f536bc2f905ef",
|
package/package.json
CHANGED
|
@@ -120,7 +120,7 @@
|
|
|
120
120
|
}
|
|
121
121
|
},
|
|
122
122
|
"name": "@codyswann/lisa",
|
|
123
|
-
"version": "2.341.
|
|
123
|
+
"version": "2.341.6",
|
|
124
124
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
125
125
|
"main": "dist/index.js",
|
|
126
126
|
"exports": {
|
|
@@ -6,9 +6,16 @@ allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mc
|
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the
|
|
2
|
+
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
|
|
3
3
|
allowed-tools: ["Skill"]
|
|
4
4
|
argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
|
|
5
5
|
---
|
|
@@ -1,14 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lisa-setup-linear
|
|
3
|
-
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue
|
|
3
|
+
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
|
|
4
4
|
allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the
|
|
2
|
+
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
|
|
3
3
|
allowed-tools: ["Skill"]
|
|
4
4
|
argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
|
|
5
5
|
---
|
|
@@ -1,14 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lisa-setup-linear
|
|
3
|
-
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue
|
|
3
|
+
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
|
|
4
4
|
allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the
|
|
2
|
+
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
|
|
3
3
|
allowed-tools: ["Skill"]
|
|
4
4
|
argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
|
|
5
5
|
---
|
|
@@ -1,14 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lisa-setup-linear
|
|
3
|
-
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue
|
|
3
|
+
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
|
|
4
4
|
allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the
|
|
2
|
+
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
|
|
3
3
|
allowed-tools: ["Skill"]
|
|
4
4
|
argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
|
|
5
5
|
---
|
|
@@ -1,14 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lisa-setup-linear
|
|
3
|
-
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue
|
|
3
|
+
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
|
|
4
4
|
allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.341.
|
|
3
|
+
"version": "2.341.6",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.341.
|
|
3
|
+
"version": "2.341.6",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.341.
|
|
3
|
+
"version": "2.341.6",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.341.
|
|
3
|
+
"version": "2.341.6",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.341.
|
|
3
|
+
"version": "2.341.6",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the
|
|
2
|
+
description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
|
|
3
3
|
allowed-tools: ["Skill"]
|
|
4
4
|
argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
|
|
5
5
|
---
|
|
@@ -1,14 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lisa-setup-linear
|
|
3
|
-
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue
|
|
3
|
+
description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
|
|
4
4
|
allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Setup Linear: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
9
|
+
Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The two lifecycles run on different primitives, and conflating them is the most common setup error:
|
|
12
|
+
|
|
13
|
+
- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
|
|
14
|
+
- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
|
|
15
|
+
|
|
16
|
+
Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
|
|
17
|
+
|
|
18
|
+
**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
|
|
12
19
|
|
|
13
20
|
## Workflow
|
|
14
21
|
|
|
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
|
|
|
28
35
|
|
|
29
36
|
> What should lisa use Linear for?
|
|
30
37
|
>
|
|
31
|
-
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off
|
|
38
|
+
> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
|
|
32
39
|
> 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
|
|
33
40
|
|
|
34
|
-
The role answer drives Step 3 (
|
|
41
|
+
The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
|
|
35
42
|
|
|
36
43
|
### Step 1 — Establish Linear access
|
|
37
44
|
|
|
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
|
|
|
139
146
|
- **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
|
|
140
147
|
- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
|
|
141
148
|
|
|
142
|
-
### Step 3 — Scaffold the lifecycle
|
|
149
|
+
### Step 3 — Scaffold the lifecycle namespaces
|
|
143
150
|
|
|
144
151
|
Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
|
|
145
152
|
|
|
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
|
|
|
280
287
|
[ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
|
|
281
288
|
```
|
|
282
289
|
|
|
283
|
-
Confirm
|
|
290
|
+
Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
|
|
284
291
|
|
|
285
292
|
## Idempotency
|
|
286
293
|
|