@codyswann/lisa 2.172.0 → 2.173.1

package/package.json

@@ -91,7 +91,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
@@ -64,7 +64,7 @@
         ]
       },
       {
-        "matcher": "TeamCreate",
+        "matcher": "TeamCreate|Agent",
         "hooks": [
           {
             "type": "command",

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

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

package/plugins/lisa/hooks/enforce-team-first.sh

@@ -9,10 +9,13 @@
 #   - UserPromptSubmit  : detects /lisa:research|plan|implement|intake|debrief in the
 #                         raw prompt and arms enforcement for the session
 #   - PreToolUse        : detects the same skills via a `Skill` tool call,
-#                         arms enforcement, and blocks bypass tool calls
-#                         until ToolSearch+TeamCreate have fired in Claude
-#   - PostToolUse       : on a successful Claude TeamCreate, marks the session as
-#                         team-created (lifts enforcement)
+#                         arms enforcement, and blocks bypass tool calls until
+#                         the team is established — i.e. until a TeamCreate
+#                         (older Claude Code) or the first Agent spawn
+#                         (implicit-team model, Claude Code >= 2.1.178) fires
+#   - PostToolUse       : on a successful Claude TeamCreate OR a successful
+#                         Agent spawn (implicit team), marks the session as
+#                         team-established (lifts enforcement)
 #   - SubagentStart     : marks the new subagent session as a teammate so
 #                         it is exempt — teammates inherit the lead's team
 #                         and must never create a second team (double-create
@@ -85,7 +88,12 @@ case "$HOOK_EVENT" in
 
   PostToolUse)
     TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null || true)
-    if [ "$TOOL_NAME" = "TeamCreate" ]; then
+    # A successful TeamCreate (older Claude Code) OR a successful Agent spawn
+    # (Claude Code >= 2.1.178, where TeamCreate/TeamDelete were removed in favor
+    # of the implicit-team model — the team forms automatically when the lead
+    # spawns its first teammate via the Agent tool) marks the session as
+    # team-established and lifts enforcement.
+    if [ "$TOOL_NAME" = "TeamCreate" ] || [ "$TOOL_NAME" = "Agent" ]; then
       ERROR=$(printf '%s' "$INPUT" | jq -r '.tool_response.error // empty' 2>/dev/null || true)
       IS_ERROR=$(printf '%s' "$INPUT" | jq -r '.tool_response.is_error // empty' 2>/dev/null || true)
       if [ -z "$ERROR" ] && [ "$IS_ERROR" != "true" ]; then
@@ -136,9 +144,12 @@ if [ -f "$TEAM_FLAG" ]; then
   exit 0
 fi
 
-# These two are the path forward; never block them.
+# These are the path forward; never block them.
+#   - ToolSearch / TeamCreate : the older explicit-team path (Claude Code < 2.1.178)
+#   - Agent                   : the implicit-team path (Claude Code >= 2.1.178) —
+#                               spawning the first teammate IS what forms the team
 case "$TOOL_NAME" in
-  ToolSearch|TeamCreate)
+  ToolSearch|TeamCreate|Agent)
     exit 0
     ;;
 esac
@@ -163,21 +174,25 @@ fi
 ACTIVE_SKILL=$(cat "$SKILL_FLAG" 2>/dev/null || echo "lisa:???")
 cat >&2 <<EOF
 Blocked: this session invoked /${ACTIVE_SKILL}, which is an agent-team flow.
-In Claude, before any other tool call, you must:
+In Claude, before any other tool call, you must establish the team by spawning
+your first teammate:
 
-  1. ToolSearch with query: "select:TeamCreate"  (load the deferred schema)
-  2. TeamCreate                                   (actually create the team)
+  Call the \`Agent\` tool with an appropriate \`subagent_type\`.
+
+The team forms automatically the moment the lead spawns its first teammate —
+this is the implicit-team model on Claude Code >= 2.1.178, where the explicit
+\`TeamCreate\`/\`TeamDelete\` tools were removed. (On older Claude Code the
+\`TeamCreate\` tool path still works and is also accepted.)
 
 The current attempt to call \`${TOOL_NAME}\` is a team-bypass path. Reading
 the ticket, exploring the code, fetching context — those are tasks for the
-team you are about to create, not for the lead session before the team
-exists.
+team you are about to spawn, not for the lead session before the team exists.
 
 If you are running Lisa in a non-Claude harness, this Claude enforcement hook
 should not be installed; follow the runtime-aware orchestration preamble in the
 skill instead.
 
-Re-read the orchestration preamble in /${ACTIVE_SKILL} and start with
-ToolSearch.
+Re-read the orchestration preamble in /${ACTIVE_SKILL} and start by spawning a
+teammate with the \`Agent\` tool.
 EOF
 exit 2

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.172.0",
+  "version": "2.173.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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.172.0",
+  "version": "2.173.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "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.172.0",
+  "version": "2.173.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/.claude-plugin/plugin.json

@@ -47,7 +47,7 @@
         ]
       },
       {
-        "matcher": "TeamCreate",
+        "matcher": "TeamCreate|Agent",
         "hooks": [
           { "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-team-first.sh" }
         ]

package/plugins/src/base/hooks/enforce-team-first.sh

@@ -9,10 +9,13 @@
 #   - UserPromptSubmit  : detects /lisa:research|plan|implement|intake|debrief in the
 #                         raw prompt and arms enforcement for the session
 #   - PreToolUse        : detects the same skills via a `Skill` tool call,
-#                         arms enforcement, and blocks bypass tool calls
-#                         until ToolSearch+TeamCreate have fired in Claude
-#   - PostToolUse       : on a successful Claude TeamCreate, marks the session as
-#                         team-created (lifts enforcement)
+#                         arms enforcement, and blocks bypass tool calls until
+#                         the team is established — i.e. until a TeamCreate
+#                         (older Claude Code) or the first Agent spawn
+#                         (implicit-team model, Claude Code >= 2.1.178) fires
+#   - PostToolUse       : on a successful Claude TeamCreate OR a successful
+#                         Agent spawn (implicit team), marks the session as
+#                         team-established (lifts enforcement)
 #   - SubagentStart     : marks the new subagent session as a teammate so
 #                         it is exempt — teammates inherit the lead's team
 #                         and must never create a second team (double-create
@@ -85,7 +88,12 @@ case "$HOOK_EVENT" in
 
   PostToolUse)
     TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null || true)
-    if [ "$TOOL_NAME" = "TeamCreate" ]; then
+    # A successful TeamCreate (older Claude Code) OR a successful Agent spawn
+    # (Claude Code >= 2.1.178, where TeamCreate/TeamDelete were removed in favor
+    # of the implicit-team model — the team forms automatically when the lead
+    # spawns its first teammate via the Agent tool) marks the session as
+    # team-established and lifts enforcement.
+    if [ "$TOOL_NAME" = "TeamCreate" ] || [ "$TOOL_NAME" = "Agent" ]; then
       ERROR=$(printf '%s' "$INPUT" | jq -r '.tool_response.error // empty' 2>/dev/null || true)
       IS_ERROR=$(printf '%s' "$INPUT" | jq -r '.tool_response.is_error // empty' 2>/dev/null || true)
       if [ -z "$ERROR" ] && [ "$IS_ERROR" != "true" ]; then
@@ -136,9 +144,12 @@ if [ -f "$TEAM_FLAG" ]; then
   exit 0
 fi
 
-# These two are the path forward; never block them.
+# These are the path forward; never block them.
+#   - ToolSearch / TeamCreate : the older explicit-team path (Claude Code < 2.1.178)
+#   - Agent                   : the implicit-team path (Claude Code >= 2.1.178) —
+#                               spawning the first teammate IS what forms the team
 case "$TOOL_NAME" in
-  ToolSearch|TeamCreate)
+  ToolSearch|TeamCreate|Agent)
     exit 0
     ;;
 esac
@@ -163,21 +174,25 @@ fi
 ACTIVE_SKILL=$(cat "$SKILL_FLAG" 2>/dev/null || echo "lisa:???")
 cat >&2 <<EOF
 Blocked: this session invoked /${ACTIVE_SKILL}, which is an agent-team flow.
-In Claude, before any other tool call, you must:
+In Claude, before any other tool call, you must establish the team by spawning
+your first teammate:
 
-  1. ToolSearch with query: "select:TeamCreate"  (load the deferred schema)
-  2. TeamCreate                                   (actually create the team)
+  Call the \`Agent\` tool with an appropriate \`subagent_type\`.
+
+The team forms automatically the moment the lead spawns its first teammate —
+this is the implicit-team model on Claude Code >= 2.1.178, where the explicit
+\`TeamCreate\`/\`TeamDelete\` tools were removed. (On older Claude Code the
+\`TeamCreate\` tool path still works and is also accepted.)
 
 The current attempt to call \`${TOOL_NAME}\` is a team-bypass path. Reading
 the ticket, exploring the code, fetching context — those are tasks for the
-team you are about to create, not for the lead session before the team
-exists.
+team you are about to spawn, not for the lead session before the team exists.
 
 If you are running Lisa in a non-Claude harness, this Claude enforcement hook
 should not be installed; follow the runtime-aware orchestration preamble in the
 skill instead.
 
-Re-read the orchestration preamble in /${ACTIVE_SKILL} and start with
-ToolSearch.
+Re-read the orchestration preamble in /${ACTIVE_SKILL} and start by spawning a
+teammate with the \`Agent\` tool.
 EOF
 exit 2

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