@codyswann/lisa 2.8.9 → 2.8.10
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/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/base-rules.md +2 -2
- package/plugins/lisa/rules/intent-routing.md +2 -2
- package/plugins/lisa/skills/implement/SKILL.md +17 -12
- package/plugins/lisa/skills/intake/SKILL.md +6 -1
- package/plugins/lisa/skills/monitor/SKILL.md +6 -1
- package/plugins/lisa/skills/plan/SKILL.md +6 -1
- package/plugins/lisa/skills/research/SKILL.md +6 -1
- package/plugins/lisa/skills/verify/SKILL.md +6 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/rules/base-rules.md +2 -2
- package/plugins/src/base/rules/intent-routing.md +2 -2
- package/plugins/src/base/skills/implement/SKILL.md +17 -12
- package/plugins/src/base/skills/intake/SKILL.md +6 -1
- package/plugins/src/base/skills/monitor/SKILL.md +6 -1
- package/plugins/src/base/skills/plan/SKILL.md +6 -1
- package/plugins/src/base/skills/research/SKILL.md +6 -1
- package/plugins/src/base/skills/verify/SKILL.md +6 -1
package/package.json
CHANGED
|
@@ -79,7 +79,7 @@
|
|
|
79
79
|
"lodash": ">=4.18.1"
|
|
80
80
|
},
|
|
81
81
|
"name": "@codyswann/lisa",
|
|
82
|
-
"version": "2.8.
|
|
82
|
+
"version": "2.8.10",
|
|
83
83
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
84
84
|
"main": "dist/index.js",
|
|
85
85
|
"exports": {
|
|
@@ -6,9 +6,9 @@ Orchestration Selection (SECOND — immediately after classifying the flow):
|
|
|
6
6
|
|
|
7
7
|
After echoing the chosen flow and BEFORE doing any work, state the orchestration mode explicitly — either `Orchestration: agent team` or `Orchestration: single agent` — with a one-sentence justification. This echo is mandatory and must appear in the same message as the flow classification.
|
|
8
8
|
|
|
9
|
-
Default to an agent team for Research, Plan, Implement (Build/Fix/Improve), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone)
|
|
9
|
+
Default to an agent team for Research, Plan, Implement (Build/Fix/Improve/Investigate-Only), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone) and Monitor (standalone). See the `intent-routing` rule's Orchestration section for the full decision matrix.
|
|
10
10
|
|
|
11
|
-
When the mode is `agent team
|
|
11
|
+
When the mode is `agent team` **and you are not already operating inside an agent team**, your FIRST tool calls after the classification echo MUST be `ToolSearch` with `query: "select:TeamCreate"` (to load the deferred tool's schema), then `TeamCreate`. Do not reach for `TaskCreate`, `Agent`, `Skill`, MCP tools, `Read`, `Bash`, or any other content-gathering call before the team exists — those are bypass paths that skip durable task state and parallel review. Reading the ticket, exploring the code, querying the API are all tasks for the team, not for the lead session before the team exists.
|
|
12
12
|
|
|
13
13
|
Requirement Verification:
|
|
14
14
|
|
|
@@ -34,9 +34,9 @@ What this rule still enforces:
|
|
|
34
34
|
|
|
35
35
|
2. **Cascade rule (load-bearing)**: Before calling `TeamCreate`, check whether you are already operating inside an agent team. Signs you are inside a team: a prior `TeamCreate` exists in this session; you were spawned via `Agent` with `team_name`; your context references a team lead. If any of these are true, **do NOT call `TeamCreate`** — the harness rejects double-creates and the work stalls. Continue within the existing team. Invoke flows via the Skill tool; the team lead inherits responsibility for orchestration.
|
|
36
36
|
|
|
37
|
-
3. **Default mode**:
|
|
37
|
+
3. **Default mode**: `Research`, `Plan`, `Implement`, and `Intake` run as agent teams. The `Implement` flow — including every work type (`Build`, `Fix`, `Improve`, `Investigate-Only`) — is **always** a team flow. Bug fixes that "look simple" are not an exception: the Reproduce sub-flow, debug-specialist, bug-fixer, parallel reviewers, and verification-specialist all need to compose. `Verify` (standalone) and `Monitor` (standalone) use the One-shot Sub-agents pattern (see `## Orchestration` below) — these flows are linear with no parallelism and the team overhead is not warranted. Single-agent mode is otherwise reserved for: `product-walkthrough` invoked standalone (not as part of Research/Plan), and one-off diagnostic Bash/Read sessions that don't invoke any lifecycle skill. When in doubt, use a team.
|
|
38
38
|
|
|
39
|
-
The mechanical
|
|
39
|
+
The mechanical TeamCreate bootstrap directive lives inside each lifecycle skill — see those skills' orchestration preambles for the exact wording: first `ToolSearch{select:TeamCreate}` (load deferred schema), then `TeamCreate`.
|
|
40
40
|
|
|
41
41
|
## Readiness Gate Protocol
|
|
42
42
|
|
|
@@ -7,26 +7,31 @@ description: This skill should be used for any non-trivial request — features,
|
|
|
7
7
|
|
|
8
8
|
## Orchestration: agent team
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
Implement is **always** a team flow. Bug, Build, Improve, and Investigate-Only all compose multiple specialists (Reproduce → debug → fix → review → verify). Single-agent mode is not an option here, regardless of how "simple" the ticket looks.
|
|
11
11
|
|
|
12
|
-
If you
|
|
12
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
15
|
+
2. `TeamCreate` — actually create the team. Every team must include the Explore agent.
|
|
15
16
|
|
|
16
|
-
|
|
17
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill` (including `lisa:tracker-read`, `lisa:jira-read-ticket`, `lisa:github-read-issue`), MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Reading the ticket, exploring the code, fetching context — every one of those is a task for the team you are about to create, not for the lead session before the team exists. Doing them inline is the exact bypass path that produces a 1-agent ad-hoc fix instead of a real team flow.
|
|
17
18
|
|
|
18
|
-
|
|
19
|
+
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool, or `lisa:intake` is running this skill per Ready ticket), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
19
20
|
|
|
20
|
-
|
|
21
|
-
- JIRA ticket → `lisa:tracker-read` → `lisa:jira-read-ticket`
|
|
22
|
-
- GitHub Issue → `lisa:tracker-read` → `lisa:github-read-issue`
|
|
23
|
-
- Linear ticket → the Linear CLI (no `lisa:linear-*` build-side adapter; Linear is a PRD source only)
|
|
21
|
+
## Resolve the input (first task assigned to the team)
|
|
24
22
|
|
|
25
|
-
|
|
23
|
+
$ARGUMENTS is either a url to a ticket containing the request, a pointer to a file containing the request, or the request in text format.
|
|
26
24
|
|
|
27
|
-
|
|
25
|
+
The team lead does NOT read the input directly. The first task on the team's plan is "resolve the input" — assigned to a teammate, which then:
|
|
28
26
|
|
|
29
|
-
If
|
|
27
|
+
- If it's a ticket, calls `lisa:tracker-read` (preferred — vendor-agnostic; dispatches per `.lisa.config.json` `tracker`). **Mismatch guard**: if the ticket format doesn't match the configured tracker (e.g., a GitHub URL when `tracker` is `jira`), `tracker-read` stops and reports the error — never auto-translates vendors:
|
|
28
|
+
- JIRA ticket → `lisa:tracker-read` → `lisa:jira-read-ticket`
|
|
29
|
+
- GitHub Issue → `lisa:tracker-read` → `lisa:github-read-issue`
|
|
30
|
+
- Linear ticket → the Linear CLI (no `lisa:linear-*` build-side adapter; Linear is a PRD source only)
|
|
31
|
+
- Captures comments and metadata, not just the description.
|
|
32
|
+
- If it's a file, reads the entire file without offset or limit.
|
|
33
|
+
- If it's a plain-text request, uses the provided text verbatim as the resolved input.
|
|
34
|
+
- Returns the resolved input to the team lead, who then proceeds to roster selection.
|
|
30
35
|
|
|
31
36
|
## Select the agent roster
|
|
32
37
|
|
|
@@ -27,7 +27,12 @@ The only legitimate reasons to stop early:
|
|
|
27
27
|
|
|
28
28
|
## Orchestration: agent team
|
|
29
29
|
|
|
30
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
30
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
31
|
+
|
|
32
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
33
|
+
2. `TeamCreate` — actually create the team.
|
|
34
|
+
|
|
35
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Scanning the queue, claiming items, dispatching per-item flows — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
31
36
|
|
|
32
37
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
33
38
|
|
|
@@ -10,7 +10,12 @@ Spot-check application health in the named environment (`dev` / `staging` / `pro
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion / Sentry), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Hitting health endpoints, pulling logs, querying Sentry — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Decompose the PRD/spec at `$ARGUMENTS` into ordered work items with acceptance c
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Reading the PRD, exploring the code, fetching context — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Produce a PRD for the problem in `$ARGUMENTS`.
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Gathering context inline as the lead is the exact bypass path that produces ad-hoc work instead of a real team flow.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Ship the current branch and prove it works in the target environment.
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Inspecting the branch, running quality gates, opening the PR — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -6,9 +6,9 @@ Orchestration Selection (SECOND — immediately after classifying the flow):
|
|
|
6
6
|
|
|
7
7
|
After echoing the chosen flow and BEFORE doing any work, state the orchestration mode explicitly — either `Orchestration: agent team` or `Orchestration: single agent` — with a one-sentence justification. This echo is mandatory and must appear in the same message as the flow classification.
|
|
8
8
|
|
|
9
|
-
Default to an agent team for Research, Plan, Implement (Build/Fix/Improve), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone)
|
|
9
|
+
Default to an agent team for Research, Plan, Implement (Build/Fix/Improve/Investigate-Only), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone) and Monitor (standalone). See the `intent-routing` rule's Orchestration section for the full decision matrix.
|
|
10
10
|
|
|
11
|
-
When the mode is `agent team
|
|
11
|
+
When the mode is `agent team` **and you are not already operating inside an agent team**, your FIRST tool calls after the classification echo MUST be `ToolSearch` with `query: "select:TeamCreate"` (to load the deferred tool's schema), then `TeamCreate`. Do not reach for `TaskCreate`, `Agent`, `Skill`, MCP tools, `Read`, `Bash`, or any other content-gathering call before the team exists — those are bypass paths that skip durable task state and parallel review. Reading the ticket, exploring the code, querying the API are all tasks for the team, not for the lead session before the team exists.
|
|
12
12
|
|
|
13
13
|
Requirement Verification:
|
|
14
14
|
|
|
@@ -34,9 +34,9 @@ What this rule still enforces:
|
|
|
34
34
|
|
|
35
35
|
2. **Cascade rule (load-bearing)**: Before calling `TeamCreate`, check whether you are already operating inside an agent team. Signs you are inside a team: a prior `TeamCreate` exists in this session; you were spawned via `Agent` with `team_name`; your context references a team lead. If any of these are true, **do NOT call `TeamCreate`** — the harness rejects double-creates and the work stalls. Continue within the existing team. Invoke flows via the Skill tool; the team lead inherits responsibility for orchestration.
|
|
36
36
|
|
|
37
|
-
3. **Default mode**:
|
|
37
|
+
3. **Default mode**: `Research`, `Plan`, `Implement`, and `Intake` run as agent teams. The `Implement` flow — including every work type (`Build`, `Fix`, `Improve`, `Investigate-Only`) — is **always** a team flow. Bug fixes that "look simple" are not an exception: the Reproduce sub-flow, debug-specialist, bug-fixer, parallel reviewers, and verification-specialist all need to compose. `Verify` (standalone) and `Monitor` (standalone) use the One-shot Sub-agents pattern (see `## Orchestration` below) — these flows are linear with no parallelism and the team overhead is not warranted. Single-agent mode is otherwise reserved for: `product-walkthrough` invoked standalone (not as part of Research/Plan), and one-off diagnostic Bash/Read sessions that don't invoke any lifecycle skill. When in doubt, use a team.
|
|
38
38
|
|
|
39
|
-
The mechanical
|
|
39
|
+
The mechanical TeamCreate bootstrap directive lives inside each lifecycle skill — see those skills' orchestration preambles for the exact wording: first `ToolSearch{select:TeamCreate}` (load deferred schema), then `TeamCreate`.
|
|
40
40
|
|
|
41
41
|
## Readiness Gate Protocol
|
|
42
42
|
|
|
@@ -7,26 +7,31 @@ description: This skill should be used for any non-trivial request — features,
|
|
|
7
7
|
|
|
8
8
|
## Orchestration: agent team
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
Implement is **always** a team flow. Bug, Build, Improve, and Investigate-Only all compose multiple specialists (Reproduce → debug → fix → review → verify). Single-agent mode is not an option here, regardless of how "simple" the ticket looks.
|
|
11
11
|
|
|
12
|
-
If you
|
|
12
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
15
|
+
2. `TeamCreate` — actually create the team. Every team must include the Explore agent.
|
|
15
16
|
|
|
16
|
-
|
|
17
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill` (including `lisa:tracker-read`, `lisa:jira-read-ticket`, `lisa:github-read-issue`), MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Reading the ticket, exploring the code, fetching context — every one of those is a task for the team you are about to create, not for the lead session before the team exists. Doing them inline is the exact bypass path that produces a 1-agent ad-hoc fix instead of a real team flow.
|
|
17
18
|
|
|
18
|
-
|
|
19
|
+
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool, or `lisa:intake` is running this skill per Ready ticket), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
19
20
|
|
|
20
|
-
|
|
21
|
-
- JIRA ticket → `lisa:tracker-read` → `lisa:jira-read-ticket`
|
|
22
|
-
- GitHub Issue → `lisa:tracker-read` → `lisa:github-read-issue`
|
|
23
|
-
- Linear ticket → the Linear CLI (no `lisa:linear-*` build-side adapter; Linear is a PRD source only)
|
|
21
|
+
## Resolve the input (first task assigned to the team)
|
|
24
22
|
|
|
25
|
-
|
|
23
|
+
$ARGUMENTS is either a url to a ticket containing the request, a pointer to a file containing the request, or the request in text format.
|
|
26
24
|
|
|
27
|
-
|
|
25
|
+
The team lead does NOT read the input directly. The first task on the team's plan is "resolve the input" — assigned to a teammate, which then:
|
|
28
26
|
|
|
29
|
-
If
|
|
27
|
+
- If it's a ticket, calls `lisa:tracker-read` (preferred — vendor-agnostic; dispatches per `.lisa.config.json` `tracker`). **Mismatch guard**: if the ticket format doesn't match the configured tracker (e.g., a GitHub URL when `tracker` is `jira`), `tracker-read` stops and reports the error — never auto-translates vendors:
|
|
28
|
+
- JIRA ticket → `lisa:tracker-read` → `lisa:jira-read-ticket`
|
|
29
|
+
- GitHub Issue → `lisa:tracker-read` → `lisa:github-read-issue`
|
|
30
|
+
- Linear ticket → the Linear CLI (no `lisa:linear-*` build-side adapter; Linear is a PRD source only)
|
|
31
|
+
- Captures comments and metadata, not just the description.
|
|
32
|
+
- If it's a file, reads the entire file without offset or limit.
|
|
33
|
+
- If it's a plain-text request, uses the provided text verbatim as the resolved input.
|
|
34
|
+
- Returns the resolved input to the team lead, who then proceeds to roster selection.
|
|
30
35
|
|
|
31
36
|
## Select the agent roster
|
|
32
37
|
|
|
@@ -27,7 +27,12 @@ The only legitimate reasons to stop early:
|
|
|
27
27
|
|
|
28
28
|
## Orchestration: agent team
|
|
29
29
|
|
|
30
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
30
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
31
|
+
|
|
32
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
33
|
+
2. `TeamCreate` — actually create the team.
|
|
34
|
+
|
|
35
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Scanning the queue, claiming items, dispatching per-item flows — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
31
36
|
|
|
32
37
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
33
38
|
|
|
@@ -10,7 +10,12 @@ Spot-check application health in the named environment (`dev` / `staging` / `pro
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion / Sentry), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Hitting health endpoints, pulling logs, querying Sentry — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Decompose the PRD/spec at `$ARGUMENTS` into ordered work items with acceptance c
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Reading the PRD, exploring the code, fetching context — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Produce a PRD for the problem in `$ARGUMENTS`.
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Gathering context inline as the lead is the exact bypass path that produces ad-hoc work instead of a real team flow.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|
|
@@ -10,7 +10,12 @@ Ship the current branch and prove it works in the target environment.
|
|
|
10
10
|
|
|
11
11
|
## Orchestration: agent team
|
|
12
12
|
|
|
13
|
-
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`),
|
|
13
|
+
If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), the very first thing you do is create the team. Two tool calls only, in this exact order:
|
|
14
|
+
|
|
15
|
+
1. `ToolSearch` with `query: "select:TeamCreate"` — `TeamCreate` is a deferred tool whose schema must be loaded before it can be invoked. A cold call returns `InputValidationError` and tempts a fallback to direct `Agent` calls, which bypasses the team.
|
|
16
|
+
2. `TeamCreate` — actually create the team.
|
|
17
|
+
|
|
18
|
+
Until `TeamCreate` returns successfully, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Inspecting the branch, running quality gates, opening the PR — all of those are tasks for the team you are about to create, not for the lead session before the team exists.
|
|
14
19
|
|
|
15
20
|
If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
|
|
16
21
|
|