@codyswann/lisa 2.171.6 → 2.173.0

package/package.json

@@ -91,7 +91,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.171.6",
+  "version": "2.173.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.171.6",
+  "version": "2.173.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa/skills/github-build-intake/SKILL.md

@@ -245,6 +245,10 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
+# Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;
+# do not pile a second assignee onto an issue that already has an owner):
+gh issue view <number> --repo <org>/<repo> --json assignees -q '.assignees | length' # → if 0:
+gh issue edit <number> --repo <org>/<repo> --add-assignee "@me"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 

package/plugins/lisa/skills/jira-build-intake/SKILL.md

@@ -177,6 +177,7 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 #### 3b. Claim
 
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
 - This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 

package/plugins/lisa/skills/linear-build-intake/SKILL.md

@@ -186,6 +186,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 Update labels via `mcp__linear-server__save_issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
+**Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `mcp__linear-server__save_issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.
+
 Post a `[claude-build-intake]` comment via `save_comment`: `"Claimed by Claude. Starting build."`
 
 This is the idempotency lock — a re-entrant cycle's `label: $READY` filter will not see this Issue again.

package/plugins/lisa/skills/repair-intake/SKILL.md

@@ -20,10 +20,13 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   after its agent returned) — no re-dispatch. A PR that is merely **behind its base** (`BEHIND`, no
   conflict) is **re-synced in place** with `gh pr update-branch` so the already-enabled auto-merge can
   finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an
-  auto-merge PR sit unmerged forever. Only a PR that cannot merge for a non-mechanical reason (true
-  conflict / failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a failed deploy
-  gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) instead
-  of blindly re-dispatching the agent — which would just churn against an unmergeable PR.
+  auto-merge PR sit unmerged forever. A **true merge conflict** is first given **one bounded in-place
+  re-dispatch** to the build agent — whose `drive-pr-to-merge` fix-mode loop resolves conflicts — because
+  a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that
+  survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The
+  genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED`
+  review / a failed deploy — get a build-ready leaf fix ticket with the item moved to `blocked` (blocked
+  by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone. The blocker is
   one of three classes, and repair re-checks **all** of them, not just dependencies: (a) an
   `is blocked by` **dependency** has since closed; (b) a **validation / quality-gate self-block** —
@@ -316,12 +319,16 @@ a PR that cannot merge or a deploy that failed — it just churns.
      Re-sync the branch in place so the already-enabled auto-merge can land (see diagnosis step 3).
      Keep the item `claimed`; a later cycle confirms the merge and transitions. Do **not** file a fix
      ticket for a clean rebase.
-   - **A real external blocker** (PR cannot merge for a non-mechanical reason — true merge conflict /
-     failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a failed deploy) → **do not
-     dispatch the agent**. File a build-ready leaf fix ticket for the blocker, move this item
-     `claimed → blocked` with an `is blocked by` link to that ticket, and record it. The existing
-     "Build `blocked` → unblock if cleared" path resumes this item on a later cycle once the fix
-     ticket is terminal — a self-healing loop. Skip the resume steps below.
+   - **A true merge conflict** → **not** an immediate fix ticket. A conflict is fixable by re-running
+     the build, so attempt **one** in-place re-dispatch first (the resume sequence below; the vendor
+     agent re-enters `drive-pr-to-merge` fix mode, which resolves conflicts). Only a conflict that
+     survives that single attempt — the same conflicting head still `CONFLICTING` on a later cycle — or
+     that the agent reports needs design input, falls through to the fix-ticket path (diagnosis step 5).
+   - **A real external blocker re-running the build cannot fix** (failing checks / `CHANGES_REQUESTED` /
+     unaddressed CodeRabbit; or a failed deploy) → **do not dispatch the agent**. File a build-ready leaf
+     fix ticket for the blocker, move this item `claimed → blocked` with an `is blocked by` link to that
+     ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
+     a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
@@ -400,7 +407,9 @@ branch — operate on it the same way.
 
 - **True merge conflict** — `mergeable = CONFLICTING` or `mergeStateStatus = DIRTY` (overlapping
   changes a plain rebase cannot resolve), or `gh pr update-branch` (step 3) reported a conflict. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3.
+  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
+  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
+  filing — see its conflict-first rule.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -416,6 +425,19 @@ recent check/commit activity would already have been caught as `active` by the s
 
 **5. On a blocker found → file a leaf fix ticket + block the item.**
 
+**Conflict-first exception (try to resolve before filing).** A *true merge conflict* — and only a
+conflict, not failing checks, change requests, or a failed deploy — is fixable by re-running the build:
+the vendor agent's `drive-pr-to-merge` fix-mode loop resolves conflicts. So before filing a fix ticket
+for a conflict, give the item **one** in-place re-dispatch: run the resume-in-place sequence (steps 1–3
+of the parent path above), which re-enters `drive-pr-to-merge` in fix mode against the existing PR.
+Bound it to a single attempt per conflicting head — when you re-dispatch, post a `[lisa-repair-intake]
+conflict-resolve-attempt: <item-ref>@<head-sha>` marker keyed on the PR head SHA. On a later cycle, if
+that marker already exists for the **same** head SHA and the PR is still `CONFLICTING`, the attempt
+failed: stop retrying and file the fix ticket below. File immediately (skip the attempt) if the agent
+reports the conflict needs design input. Every other blocker class files the fix ticket with no
+re-dispatch. Honor the backoff window / state fingerprint (Loop prevention) so the re-dispatch is never
+re-issued against an unchanged conflicting head.
+
 1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
    vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
    `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/github-build-intake/SKILL.md

@@ -245,6 +245,10 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
+# Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;
+# do not pile a second assignee onto an issue that already has an owner):
+gh issue view <number> --repo <org>/<repo> --json assignees -q '.assignees | length' # → if 0:
+gh issue edit <number> --repo <org>/<repo> --add-assignee "@me"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 

package/plugins/lisa-agy/skills/jira-build-intake/SKILL.md

@@ -177,6 +177,7 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 #### 3b. Claim
 
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
 - This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 

package/plugins/lisa-agy/skills/linear-build-intake/SKILL.md

@@ -186,6 +186,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 Update labels via `mcp__linear-server__save_issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
+**Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `mcp__linear-server__save_issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.
+
 Post a `[claude-build-intake]` comment via `save_comment`: `"Claimed by Claude. Starting build."`
 
 This is the idempotency lock — a re-entrant cycle's `label: $READY` filter will not see this Issue again.

package/plugins/lisa-agy/skills/repair-intake/SKILL.md

@@ -20,10 +20,13 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   after its agent returned) — no re-dispatch. A PR that is merely **behind its base** (`BEHIND`, no
   conflict) is **re-synced in place** with `gh pr update-branch` so the already-enabled auto-merge can
   finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an
-  auto-merge PR sit unmerged forever. Only a PR that cannot merge for a non-mechanical reason (true
-  conflict / failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a failed deploy
-  gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) instead
-  of blindly re-dispatching the agent — which would just churn against an unmergeable PR.
+  auto-merge PR sit unmerged forever. A **true merge conflict** is first given **one bounded in-place
+  re-dispatch** to the build agent — whose `drive-pr-to-merge` fix-mode loop resolves conflicts — because
+  a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that
+  survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The
+  genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED`
+  review / a failed deploy — get a build-ready leaf fix ticket with the item moved to `blocked` (blocked
+  by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone. The blocker is
   one of three classes, and repair re-checks **all** of them, not just dependencies: (a) an
   `is blocked by` **dependency** has since closed; (b) a **validation / quality-gate self-block** —
@@ -316,12 +319,16 @@ a PR that cannot merge or a deploy that failed — it just churns.
      Re-sync the branch in place so the already-enabled auto-merge can land (see diagnosis step 3).
      Keep the item `claimed`; a later cycle confirms the merge and transitions. Do **not** file a fix
      ticket for a clean rebase.
-   - **A real external blocker** (PR cannot merge for a non-mechanical reason — true merge conflict /
-     failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a failed deploy) → **do not
-     dispatch the agent**. File a build-ready leaf fix ticket for the blocker, move this item
-     `claimed → blocked` with an `is blocked by` link to that ticket, and record it. The existing
-     "Build `blocked` → unblock if cleared" path resumes this item on a later cycle once the fix
-     ticket is terminal — a self-healing loop. Skip the resume steps below.
+   - **A true merge conflict** → **not** an immediate fix ticket. A conflict is fixable by re-running
+     the build, so attempt **one** in-place re-dispatch first (the resume sequence below; the vendor
+     agent re-enters `drive-pr-to-merge` fix mode, which resolves conflicts). Only a conflict that
+     survives that single attempt — the same conflicting head still `CONFLICTING` on a later cycle — or
+     that the agent reports needs design input, falls through to the fix-ticket path (diagnosis step 5).
+   - **A real external blocker re-running the build cannot fix** (failing checks / `CHANGES_REQUESTED` /
+     unaddressed CodeRabbit; or a failed deploy) → **do not dispatch the agent**. File a build-ready leaf
+     fix ticket for the blocker, move this item `claimed → blocked` with an `is blocked by` link to that
+     ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
+     a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
@@ -400,7 +407,9 @@ branch — operate on it the same way.
 
 - **True merge conflict** — `mergeable = CONFLICTING` or `mergeStateStatus = DIRTY` (overlapping
   changes a plain rebase cannot resolve), or `gh pr update-branch` (step 3) reported a conflict. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3.
+  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
+  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
+  filing — see its conflict-first rule.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -416,6 +425,19 @@ recent check/commit activity would already have been caught as `active` by the s
 
 **5. On a blocker found → file a leaf fix ticket + block the item.**
 
+**Conflict-first exception (try to resolve before filing).** A *true merge conflict* — and only a
+conflict, not failing checks, change requests, or a failed deploy — is fixable by re-running the build:
+the vendor agent's `drive-pr-to-merge` fix-mode loop resolves conflicts. So before filing a fix ticket
+for a conflict, give the item **one** in-place re-dispatch: run the resume-in-place sequence (steps 1–3
+of the parent path above), which re-enters `drive-pr-to-merge` in fix mode against the existing PR.
+Bound it to a single attempt per conflicting head — when you re-dispatch, post a `[lisa-repair-intake]
+conflict-resolve-attempt: <item-ref>@<head-sha>` marker keyed on the PR head SHA. On a later cycle, if
+that marker already exists for the **same** head SHA and the PR is still `CONFLICTING`, the attempt
+failed: stop retrying and file the fix ticket below. File immediately (skip the attempt) if the agent
+reports the conflict needs design input. Every other blocker class files the fix ticket with no
+re-dispatch. Honor the backoff window / state fingerprint (Loop prevention) so the re-dispatch is never
+re-issued against an unchanged conflicting head.
+
 1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
    vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
    `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

package/plugins/lisa-copilot/skills/github-build-intake/SKILL.md

@@ -245,6 +245,10 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
+# Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;
+# do not pile a second assignee onto an issue that already has an owner):
+gh issue view <number> --repo <org>/<repo> --json assignees -q '.assignees | length' # → if 0:
+gh issue edit <number> --repo <org>/<repo> --add-assignee "@me"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 

package/plugins/lisa-copilot/skills/jira-build-intake/SKILL.md

@@ -177,6 +177,7 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 #### 3b. Claim
 
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
 - This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 

package/plugins/lisa-copilot/skills/linear-build-intake/SKILL.md

@@ -186,6 +186,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 Update labels via `mcp__linear-server__save_issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
+**Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `mcp__linear-server__save_issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.
+
 Post a `[claude-build-intake]` comment via `save_comment`: `"Claimed by Claude. Starting build."`
 
 This is the idempotency lock — a re-entrant cycle's `label: $READY` filter will not see this Issue again.

package/plugins/lisa-copilot/skills/repair-intake/SKILL.md

@@ -20,10 +20,13 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   after its agent returned) — no re-dispatch. A PR that is merely **behind its base** (`BEHIND`, no
   conflict) is **re-synced in place** with `gh pr update-branch` so the already-enabled auto-merge can
   finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an
-  auto-merge PR sit unmerged forever. Only a PR that cannot merge for a non-mechanical reason (true
-  conflict / failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a failed deploy
-  gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) instead
-  of blindly re-dispatching the agent — which would just churn against an unmergeable PR.
+  auto-merge PR sit unmerged forever. A **true merge conflict** is first given **one bounded in-place
+  re-dispatch** to the build agent — whose `drive-pr-to-merge` fix-mode loop resolves conflicts — because
+  a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that
+  survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The
+  genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED`
+  review / a failed deploy — get a build-ready leaf fix ticket with the item moved to `blocked` (blocked
+  by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone. The blocker is
   one of three classes, and repair re-checks **all** of them, not just dependencies: (a) an
   `is blocked by` **dependency** has since closed; (b) a **validation / quality-gate self-block** —
@@ -316,12 +319,16 @@ a PR that cannot merge or a deploy that failed — it just churns.
      Re-sync the branch in place so the already-enabled auto-merge can land (see diagnosis step 3).
      Keep the item `claimed`; a later cycle confirms the merge and transitions. Do **not** file a fix
      ticket for a clean rebase.
-   - **A real external blocker** (PR cannot merge for a non-mechanical reason — true merge conflict /
-     failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a failed deploy) → **do not
-     dispatch the agent**. File a build-ready leaf fix ticket for the blocker, move this item
-     `claimed → blocked` with an `is blocked by` link to that ticket, and record it. The existing
-     "Build `blocked` → unblock if cleared" path resumes this item on a later cycle once the fix
-     ticket is terminal — a self-healing loop. Skip the resume steps below.
+   - **A true merge conflict** → **not** an immediate fix ticket. A conflict is fixable by re-running
+     the build, so attempt **one** in-place re-dispatch first (the resume sequence below; the vendor
+     agent re-enters `drive-pr-to-merge` fix mode, which resolves conflicts). Only a conflict that
+     survives that single attempt — the same conflicting head still `CONFLICTING` on a later cycle — or
+     that the agent reports needs design input, falls through to the fix-ticket path (diagnosis step 5).
+   - **A real external blocker re-running the build cannot fix** (failing checks / `CHANGES_REQUESTED` /
+     unaddressed CodeRabbit; or a failed deploy) → **do not dispatch the agent**. File a build-ready leaf
+     fix ticket for the blocker, move this item `claimed → blocked` with an `is blocked by` link to that
+     ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
+     a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
@@ -400,7 +407,9 @@ branch — operate on it the same way.
 
 - **True merge conflict** — `mergeable = CONFLICTING` or `mergeStateStatus = DIRTY` (overlapping
   changes a plain rebase cannot resolve), or `gh pr update-branch` (step 3) reported a conflict. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3.
+  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
+  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
+  filing — see its conflict-first rule.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -416,6 +425,19 @@ recent check/commit activity would already have been caught as `active` by the s
 
 **5. On a blocker found → file a leaf fix ticket + block the item.**
 
+**Conflict-first exception (try to resolve before filing).** A *true merge conflict* — and only a
+conflict, not failing checks, change requests, or a failed deploy — is fixable by re-running the build:
+the vendor agent's `drive-pr-to-merge` fix-mode loop resolves conflicts. So before filing a fix ticket
+for a conflict, give the item **one** in-place re-dispatch: run the resume-in-place sequence (steps 1–3
+of the parent path above), which re-enters `drive-pr-to-merge` in fix mode against the existing PR.
+Bound it to a single attempt per conflicting head — when you re-dispatch, post a `[lisa-repair-intake]
+conflict-resolve-attempt: <item-ref>@<head-sha>` marker keyed on the PR head SHA. On a later cycle, if
+that marker already exists for the **same** head SHA and the PR is still `CONFLICTING`, the attempt
+failed: stop retrying and file the fix ticket below. File immediately (skip the attempt) if the agent
+reports the conflict needs design input. Every other blocker class files the fix ticket with no
+re-dispatch. Honor the backoff window / state fingerprint (Loop prevention) so the re-dispatch is never
+re-issued against an unchanged conflicting head.
+
 1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
    vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
    `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback

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

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

package/plugins/lisa-cursor/skills/github-build-intake/SKILL.md

@@ -245,6 +245,10 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
+# Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;
+# do not pile a second assignee onto an issue that already has an owner):
+gh issue view <number> --repo <org>/<repo> --json assignees -q '.assignees | length' # → if 0:
+gh issue edit <number> --repo <org>/<repo> --add-assignee "@me"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 

package/plugins/lisa-cursor/skills/jira-build-intake/SKILL.md

@@ -177,6 +177,7 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 #### 3b. Claim
 
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
 - This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 

package/plugins/lisa-cursor/skills/linear-build-intake/SKILL.md

@@ -186,6 +186,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 Update labels via `mcp__linear-server__save_issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
+**Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `mcp__linear-server__save_issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.
+
 Post a `[claude-build-intake]` comment via `save_comment`: `"Claimed by Claude. Starting build."`
 
 This is the idempotency lock — a re-entrant cycle's `label: $READY` filter will not see this Issue again.

package/plugins/lisa-cursor/skills/repair-intake/SKILL.md

@@ -20,10 +20,13 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   after its agent returned) — no re-dispatch. A PR that is merely **behind its base** (`BEHIND`, no
   conflict) is **re-synced in place** with `gh pr update-branch` so the already-enabled auto-merge can
   finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an
-  auto-merge PR sit unmerged forever. Only a PR that cannot merge for a non-mechanical reason (true
-  conflict / failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a failed deploy
-  gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) instead
-  of blindly re-dispatching the agent — which would just churn against an unmergeable PR.
+  auto-merge PR sit unmerged forever. A **true merge conflict** is first given **one bounded in-place
+  re-dispatch** to the build agent — whose `drive-pr-to-merge` fix-mode loop resolves conflicts — because
+  a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that
+  survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The
+  genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED`
+  review / a failed deploy — get a build-ready leaf fix ticket with the item moved to `blocked` (blocked
+  by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone. The blocker is
   one of three classes, and repair re-checks **all** of them, not just dependencies: (a) an
   `is blocked by` **dependency** has since closed; (b) a **validation / quality-gate self-block** —
@@ -316,12 +319,16 @@ a PR that cannot merge or a deploy that failed — it just churns.
      Re-sync the branch in place so the already-enabled auto-merge can land (see diagnosis step 3).
      Keep the item `claimed`; a later cycle confirms the merge and transitions. Do **not** file a fix
      ticket for a clean rebase.
-   - **A real external blocker** (PR cannot merge for a non-mechanical reason — true merge conflict /
-     failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a failed deploy) → **do not
-     dispatch the agent**. File a build-ready leaf fix ticket for the blocker, move this item
-     `claimed → blocked` with an `is blocked by` link to that ticket, and record it. The existing
-     "Build `blocked` → unblock if cleared" path resumes this item on a later cycle once the fix
-     ticket is terminal — a self-healing loop. Skip the resume steps below.
+   - **A true merge conflict** → **not** an immediate fix ticket. A conflict is fixable by re-running
+     the build, so attempt **one** in-place re-dispatch first (the resume sequence below; the vendor
+     agent re-enters `drive-pr-to-merge` fix mode, which resolves conflicts). Only a conflict that
+     survives that single attempt — the same conflicting head still `CONFLICTING` on a later cycle — or
+     that the agent reports needs design input, falls through to the fix-ticket path (diagnosis step 5).
+   - **A real external blocker re-running the build cannot fix** (failing checks / `CHANGES_REQUESTED` /
+     unaddressed CodeRabbit; or a failed deploy) → **do not dispatch the agent**. File a build-ready leaf
+     fix ticket for the blocker, move this item `claimed → blocked` with an `is blocked by` link to that
+     ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
+     a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
@@ -400,7 +407,9 @@ branch — operate on it the same way.
 
 - **True merge conflict** — `mergeable = CONFLICTING` or `mergeStateStatus = DIRTY` (overlapping
   changes a plain rebase cannot resolve), or `gh pr update-branch` (step 3) reported a conflict. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3.
+  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
+  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
+  filing — see its conflict-first rule.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -416,6 +425,19 @@ recent check/commit activity would already have been caught as `active` by the s
 
 **5. On a blocker found → file a leaf fix ticket + block the item.**
 
+**Conflict-first exception (try to resolve before filing).** A *true merge conflict* — and only a
+conflict, not failing checks, change requests, or a failed deploy — is fixable by re-running the build:
+the vendor agent's `drive-pr-to-merge` fix-mode loop resolves conflicts. So before filing a fix ticket
+for a conflict, give the item **one** in-place re-dispatch: run the resume-in-place sequence (steps 1–3
+of the parent path above), which re-enters `drive-pr-to-merge` in fix mode against the existing PR.
+Bound it to a single attempt per conflicting head — when you re-dispatch, post a `[lisa-repair-intake]
+conflict-resolve-attempt: <item-ref>@<head-sha>` marker keyed on the PR head SHA. On a later cycle, if
+that marker already exists for the **same** head SHA and the PR is still `CONFLICTING`, the attempt
+failed: stop retrying and file the fix ticket below. File immediately (skip the attempt) if the agent
+reports the conflict needs design input. Every other blocker class files the fix ticket with no
+re-dispatch. Honor the backoff window / state fingerprint (Loop prevention) so the re-dispatch is never
+re-issued against an unchanged conflicting head.
+
 1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
    vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
    `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "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",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "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",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "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",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "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",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.171.6",
+  "version": "2.173.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.171.6",
+  "version": "2.173.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.171.6",
+  "version": "2.173.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/skills/github-build-intake/SKILL.md

@@ -245,6 +245,10 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
+# Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;
+# do not pile a second assignee onto an issue that already has an owner):
+gh issue view <number> --repo <org>/<repo> --json assignees -q '.assignees | length' # → if 0:
+gh issue edit <number> --repo <org>/<repo> --add-assignee "@me"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 

package/plugins/src/base/skills/jira-build-intake/SKILL.md

@@ -177,6 +177,7 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 #### 3b. Claim
 
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
 - This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 

package/plugins/src/base/skills/linear-build-intake/SKILL.md

@@ -186,6 +186,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 Update labels via `mcp__linear-server__save_issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
+**Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `mcp__linear-server__save_issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.
+
 Post a `[claude-build-intake]` comment via `save_comment`: `"Claimed by Claude. Starting build."`
 
 This is the idempotency lock — a re-entrant cycle's `label: $READY` filter will not see this Issue again.

package/plugins/src/base/skills/repair-intake/SKILL.md

@@ -20,10 +20,13 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   after its agent returned) — no re-dispatch. A PR that is merely **behind its base** (`BEHIND`, no
   conflict) is **re-synced in place** with `gh pr update-branch` so the already-enabled auto-merge can
   finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an
-  auto-merge PR sit unmerged forever. Only a PR that cannot merge for a non-mechanical reason (true
-  conflict / failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED` review) or a failed deploy
-  gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) instead
-  of blindly re-dispatching the agent — which would just churn against an unmergeable PR.
+  auto-merge PR sit unmerged forever. A **true merge conflict** is first given **one bounded in-place
+  re-dispatch** to the build agent — whose `drive-pr-to-merge` fix-mode loop resolves conflicts — because
+  a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that
+  survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The
+  genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or `CHANGES_REQUESTED`
+  review / a failed deploy — get a build-ready leaf fix ticket with the item moved to `blocked` (blocked
+  by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
 - **Recoverable blocked** — an item in `blocked` whose blocker may now be gone. The blocker is
   one of three classes, and repair re-checks **all** of them, not just dependencies: (a) an
   `is blocked by` **dependency** has since closed; (b) a **validation / quality-gate self-block** —
@@ -316,12 +319,16 @@ a PR that cannot merge or a deploy that failed — it just churns.
      Re-sync the branch in place so the already-enabled auto-merge can land (see diagnosis step 3).
      Keep the item `claimed`; a later cycle confirms the merge and transitions. Do **not** file a fix
      ticket for a clean rebase.
-   - **A real external blocker** (PR cannot merge for a non-mechanical reason — true merge conflict /
-     failing checks / `CHANGES_REQUESTED` / unaddressed CodeRabbit; or a failed deploy) → **do not
-     dispatch the agent**. File a build-ready leaf fix ticket for the blocker, move this item
-     `claimed → blocked` with an `is blocked by` link to that ticket, and record it. The existing
-     "Build `blocked` → unblock if cleared" path resumes this item on a later cycle once the fix
-     ticket is terminal — a self-healing loop. Skip the resume steps below.
+   - **A true merge conflict** → **not** an immediate fix ticket. A conflict is fixable by re-running
+     the build, so attempt **one** in-place re-dispatch first (the resume sequence below; the vendor
+     agent re-enters `drive-pr-to-merge` fix mode, which resolves conflicts). Only a conflict that
+     survives that single attempt — the same conflicting head still `CONFLICTING` on a later cycle — or
+     that the agent reports needs design input, falls through to the fix-ticket path (diagnosis step 5).
+   - **A real external blocker re-running the build cannot fix** (failing checks / `CHANGES_REQUESTED` /
+     unaddressed CodeRabbit; or a failed deploy) → **do not dispatch the agent**. File a build-ready leaf
+     fix ticket for the blocker, move this item `claimed → blocked` with an `is blocked by` link to that
+     ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
+     a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
@@ -400,7 +407,9 @@ branch — operate on it the same way.
 
 - **True merge conflict** — `mergeable = CONFLICTING` or `mergeStateStatus = DIRTY` (overlapping
   changes a plain rebase cannot resolve), or `gh pr update-branch` (step 3) reported a conflict. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3.
+  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
+  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
+  filing — see its conflict-first rule.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -416,6 +425,19 @@ recent check/commit activity would already have been caught as `active` by the s
 
 **5. On a blocker found → file a leaf fix ticket + block the item.**
 
+**Conflict-first exception (try to resolve before filing).** A *true merge conflict* — and only a
+conflict, not failing checks, change requests, or a failed deploy — is fixable by re-running the build:
+the vendor agent's `drive-pr-to-merge` fix-mode loop resolves conflicts. So before filing a fix ticket
+for a conflict, give the item **one** in-place re-dispatch: run the resume-in-place sequence (steps 1–3
+of the parent path above), which re-enters `drive-pr-to-merge` in fix mode against the existing PR.
+Bound it to a single attempt per conflicting head — when you re-dispatch, post a `[lisa-repair-intake]
+conflict-resolve-attempt: <item-ref>@<head-sha>` marker keyed on the PR head SHA. On a later cycle, if
+that marker already exists for the **same** head SHA and the PR is still `CONFLICTING`, the attempt
+failed: stop retrying and file the fix ticket below. File immediately (skip the attempt) if the agent
+reports the conflict needs design input. Every other blocker class files the fix ticket with no
+re-dispatch. Honor the backoff window / state fingerprint (Loop prevention) so the re-dispatch is never
+re-issued against an unchanged conflicting head.
+
 1. **File one build-ready leaf fix ticket** per distinct blocker via `lisa:tracker-write` (the
    vendor-neutral leaf writer + validation gate; never a vendor `*-write-*` skill directly),
    `issue_type: Bug` for a failing-check/conflict/failed-deploy, `Task` for review-feedback