@codyswann/lisa 2.15.1 → 2.16.0

package/package.json

@@ -79,7 +79,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/skills/confluence-to-tracker/SKILL.md

@@ -76,7 +76,7 @@ orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -234,6 +234,8 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:

package/plugins/lisa/skills/github-to-tracker/SKILL.md

@@ -229,6 +229,8 @@ Capture each returned story ref — Phase 5 needs it.
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `lisa:jira-write-ticket` / `lisa:github-write-issue` / `gh issue create` directly.**
 
 Each sub-task MUST:

package/plugins/lisa/skills/github-validate-issue/SKILL.md

@@ -84,7 +84,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Parent sub-issue declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -157,11 +157,13 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the body and AC
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, body must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split into per-repo issues under a shared Epic.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, body must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-(GitHub Issues live in one repo by definition, so the `## Repository` section is technically redundant — keep it for parity with the JIRA path so downstream tooling sees the same shape.)
+(GitHub Issues live in one repo by definition, so the `## Repository` section is technically redundant — keep it for parity with the JIRA path so downstream tooling sees the same shape. Cross-repo references in AC are still possible and still fail this gate.)
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:github-to-tracker`, `lisa:notion-to-tracker`, etc.) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/lisa/skills/jira-validate-ticket/SKILL.md

@@ -79,7 +79,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Epic parent declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -156,9 +156,11 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:notion-to-tracker`, `lisa:confluence-to-tracker`, `lisa:linear-to-tracker`, `lisa:github-to-tracker`) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/lisa/skills/linear-to-tracker/SKILL.md

@@ -76,7 +76,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -227,6 +227,8 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:

package/plugins/lisa/skills/linear-validate-issue/SKILL.md

@@ -82,7 +82,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Project parent declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -161,9 +161,11 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:linear-to-tracker`, `lisa:notion-to-tracker`, etc.) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/lisa/skills/notion-to-tracker/SKILL.md

@@ -69,7 +69,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -229,6 +229,8 @@ When classification is ambiguous, err on the side of inclusion — a developer c
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
 
 Each sub-task MUST:

package/plugins/lisa/skills/task-decomposition/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-decomposition
-description: "Methodology for breaking work into ordered tasks. Each task gets acceptance criteria, verification type, dependencies, and skills required."
+description: "Methodology for breaking work into ordered tasks. Each task gets a single-repo scope, acceptance criteria, verification type, dependencies, and skills required."
 ---
 
 # Task Decomposition
@@ -16,6 +16,26 @@ Break work into ordered, well-scoped tasks that can be independently implemented
 - Avoid tasks that are too large to complete in a single session
 - Avoid tasks that are too small to be meaningful (e.g., "add an import statement")
 
+### 1.5. Scope Each Unit to a Single Repository
+
+Work units must be implementable inside a single repository. This is a hard invariant — downstream validators (`jira-validate-ticket`, `github-validate-issue`, `linear-validate-issue`) gate writes on it, so a cross-repo task will fail to be created.
+
+Apply this rule by issue type:
+
+| Issue type | Repo scope |
+|------------|-----------|
+| **Epic, Story, Spike** | MAY span repos — these are coordination containers |
+| **Task, Bug, Sub-task, Improvement** | MUST name exactly one repo — these are work units |
+
+If a candidate work unit naturally touches multiple repos (e.g., "add field to backend API and consume it in mobile app"), do not write it as one ticket. Instead:
+
+1. Split it into one work unit per repo (e.g., `[backend-api] Add field to /users endpoint`, `[mobile-app] Display new field on profile screen`).
+2. Group the per-repo units under a single parent Story (or Epic, if the parent Story already exists). The parent stays cross-repo; the children do not.
+3. Encode the order via `Dependencies` in step 4 — typically the producing repo (backend) blocks the consuming repo (frontend/mobile).
+4. Tag each work unit with `[repo-name]` as a summary prefix so the repo is visible in tracker lists at a glance.
+
+Reject any work unit whose acceptance criteria reference behavior in a different repo from the one it's scoped to. If you find yourself writing "and the frontend should also...", that's a signal to split.
+
 ### 2. Define Acceptance Criteria
 
 For each task, define what "done" looks like:
@@ -61,7 +81,8 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 ```
 ## Task Breakdown
 
-### Task 1: [imperative description]
+### Task 1: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
 - **Acceptance criteria:**
   - [specific, measurable criterion]
   - [specific, measurable criterion]
@@ -69,7 +90,8 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 - **Dependencies:** [none | task IDs that must complete first]
 - **Skills:** [list of skills needed]
 
-### Task 2: [imperative description]
+### Task 2: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
 - **Acceptance criteria:**
   - [specific, measurable criterion]
 - **Verification:** [type] -- [how to verify]
@@ -89,6 +111,7 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 
 - Every task must have at least one acceptance criterion that can be empirically verified
 - Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
+- Every Task / Bug / Sub-task / Improvement is scoped to exactly one repo -- if the work spans repos, split into per-repo work units under a shared parent Story (see step 1.5)
 - Keep tasks ordered so that no task references work that has not been completed by a prior task
 - Flag any task that requires access, permissions, or external input not yet available
 - Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/skills/confluence-to-tracker/SKILL.md

@@ -76,7 +76,7 @@ orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -234,6 +234,8 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:

package/plugins/src/base/skills/github-to-tracker/SKILL.md

@@ -229,6 +229,8 @@ Capture each returned story ref — Phase 5 needs it.
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `lisa:jira-write-ticket` / `lisa:github-write-issue` / `gh issue create` directly.**
 
 Each sub-task MUST:

package/plugins/src/base/skills/github-validate-issue/SKILL.md

@@ -84,7 +84,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Parent sub-issue declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -157,11 +157,13 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the body and AC
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, body must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split into per-repo issues under a shared Epic.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, body must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-(GitHub Issues live in one repo by definition, so the `## Repository` section is technically redundant — keep it for parity with the JIRA path so downstream tooling sees the same shape.)
+(GitHub Issues live in one repo by definition, so the `## Repository` section is technically redundant — keep it for parity with the JIRA path so downstream tooling sees the same shape. Cross-repo references in AC are still possible and still fail this gate.)
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:github-to-tracker`, `lisa:notion-to-tracker`, etc.) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/src/base/skills/jira-validate-ticket/SKILL.md

@@ -79,7 +79,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Epic parent declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -156,9 +156,11 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:notion-to-tracker`, `lisa:confluence-to-tracker`, `lisa:linear-to-tracker`, `lisa:github-to-tracker`) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/src/base/skills/linear-to-tracker/SKILL.md

@@ -76,7 +76,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -227,6 +227,8 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:

package/plugins/src/base/skills/linear-validate-issue/SKILL.md

@@ -82,7 +82,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S7 Project parent declared | `structural` | false |
 | S8 Target Backend Environment | `technical` | false |
 | S9 Sign-in Required | `technical` | false |
-| S10 Single-repo scope | `scope` | true |
+| S10 Single-repo scope | `scope` | false |
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
@@ -161,9 +161,11 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task}`, description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation to split.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike / Improvement: skipped (may span repos).
+Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+
+This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:linear-to-tracker`, `lisa:notion-to-tracker`, etc.) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
 #### S11 — Validation Journey present
 

package/plugins/src/base/skills/notion-to-tracker/SKILL.md

@@ -69,7 +69,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Gherkin acceptance criteria
 - Epic parent validation
 - Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task
+- Single-repo scope check on Bug / Task / Sub-task / Improvement
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
@@ -229,6 +229,8 @@ When classification is ambiguous, err on the side of inclusion — a developer c
 
 ### Phase 5: Create Sub-tasks
 
+**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
+
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
 
 Each sub-task MUST:

package/plugins/src/base/skills/task-decomposition/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-decomposition
-description: "Methodology for breaking work into ordered tasks. Each task gets acceptance criteria, verification type, dependencies, and skills required."
+description: "Methodology for breaking work into ordered tasks. Each task gets a single-repo scope, acceptance criteria, verification type, dependencies, and skills required."
 ---
 
 # Task Decomposition
@@ -16,6 +16,26 @@ Break work into ordered, well-scoped tasks that can be independently implemented
 - Avoid tasks that are too large to complete in a single session
 - Avoid tasks that are too small to be meaningful (e.g., "add an import statement")
 
+### 1.5. Scope Each Unit to a Single Repository
+
+Work units must be implementable inside a single repository. This is a hard invariant — downstream validators (`jira-validate-ticket`, `github-validate-issue`, `linear-validate-issue`) gate writes on it, so a cross-repo task will fail to be created.
+
+Apply this rule by issue type:
+
+| Issue type | Repo scope |
+|------------|-----------|
+| **Epic, Story, Spike** | MAY span repos — these are coordination containers |
+| **Task, Bug, Sub-task, Improvement** | MUST name exactly one repo — these are work units |
+
+If a candidate work unit naturally touches multiple repos (e.g., "add field to backend API and consume it in mobile app"), do not write it as one ticket. Instead:
+
+1. Split it into one work unit per repo (e.g., `[backend-api] Add field to /users endpoint`, `[mobile-app] Display new field on profile screen`).
+2. Group the per-repo units under a single parent Story (or Epic, if the parent Story already exists). The parent stays cross-repo; the children do not.
+3. Encode the order via `Dependencies` in step 4 — typically the producing repo (backend) blocks the consuming repo (frontend/mobile).
+4. Tag each work unit with `[repo-name]` as a summary prefix so the repo is visible in tracker lists at a glance.
+
+Reject any work unit whose acceptance criteria reference behavior in a different repo from the one it's scoped to. If you find yourself writing "and the frontend should also...", that's a signal to split.
+
 ### 2. Define Acceptance Criteria
 
 For each task, define what "done" looks like:
@@ -61,7 +81,8 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 ```
 ## Task Breakdown
 
-### Task 1: [imperative description]
+### Task 1: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
 - **Acceptance criteria:**
   - [specific, measurable criterion]
   - [specific, measurable criterion]
@@ -69,7 +90,8 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 - **Dependencies:** [none | task IDs that must complete first]
 - **Skills:** [list of skills needed]
 
-### Task 2: [imperative description]
+### Task 2: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
 - **Acceptance criteria:**
   - [specific, measurable criterion]
 - **Verification:** [type] -- [how to verify]
@@ -89,6 +111,7 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 
 - Every task must have at least one acceptance criterion that can be empirically verified
 - Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
+- Every Task / Bug / Sub-task / Improvement is scoped to exactly one repo -- if the work spans repos, split into per-repo work units under a shared parent Story (see step 1.5)
 - Keep tasks ordered so that no task references work that has not been completed by a prior task
 - Flag any task that requires access, permissions, or external input not yet available
 - Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail