@autohq/cli 0.1.408 → 0.1.410

package/dist/index.js

@@ -17432,6 +17432,25 @@ var init_connections = __esm({
   }
 });
 
+// ../../packages/schemas/src/dormant-capabilities.ts
+var DormantCapabilityConnectionSchema, DormantCapabilitySchema, DormantCapabilitiesSchema;
+var init_dormant_capabilities = __esm({
+  "../../packages/schemas/src/dormant-capabilities.ts"() {
+    "use strict";
+    init_zod();
+    DormantCapabilityConnectionSchema = external_exports.object({
+      provider: external_exports.string().trim().min(1),
+      connection: external_exports.string().trim().min(1)
+    });
+    DormantCapabilitySchema = external_exports.object({
+      kind: external_exports.enum(["tool", "trigger"]),
+      name: external_exports.string().trim().min(1),
+      connections: external_exports.array(DormantCapabilityConnectionSchema).min(1)
+    });
+    DormantCapabilitiesSchema = external_exports.array(DormantCapabilitySchema);
+  }
+});
+
 // ../../packages/schemas/src/github-sync.ts
 var GITHUB_SYNC_AUTO_PATH, GITHUB_SYNC_CI_WATCHDOG_DEFAULT_DELAY_MS, GithubSyncRepositoryFullNameSchema, GithubSyncProductionBranchSchema, GithubSyncCiWatchdogWorkflowSchema, GithubSyncCiWatchdogSchema, GithubSyncBindingSchema, GithubSyncBindingCreateRequestSchema, GithubSyncInitialSyncSchema, GithubSyncBindingCreateResponseSchema, GithubSyncBindingListResponseSchema, GithubSyncTriggerArtifactSchema, GithubSyncWorkflowInputSchema, GithubSyncWorkflowResultSchema;
 var init_github_sync = __esm({
@@ -18872,7 +18891,7 @@ var init_agents = __esm({
     TriggerFilterSchema = external_exports.record(TriggerFilterPathSchema, TriggerFilterClauseSchema).default({});
     TriggerCheckTimeoutSchema = external_exports.object({
       seconds: external_exports.number().int().min(1).max(7 * 24 * 60 * 60),
-      conclusion: external_exports.enum(["success", "failure"])
+      conclusion: external_exports.enum(["success", "failure", "skipped"])
     }).strict();
     AgentArchiveAfterInactiveSchema = external_exports.object({
       seconds: external_exports.number().int().min(60).max(365 * 24 * 60 * 60)
@@ -19490,13 +19509,15 @@ var init_session_commands = __esm({
       "pending",
       "dispatching",
       "accepted",
-      "failed"
+      "failed",
+      "canceled"
     ];
     SESSION_DISPATCH_COMMAND_STATUSES = [
       "pending",
       "dispatching",
       "accepted",
-      "failed"
+      "failed",
+      "canceled"
     ];
     SessionCommandKindSchema = external_exports.enum(SESSION_COMMAND_KINDS);
     SessionPersistedCommandKindSchema = external_exports.enum(
@@ -23861,6 +23882,27 @@ triggers:
               content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
             }
           ]
+        },
+        {
+          version: "1.8.0",
+          files: [
+            {
+              path: "agents/pr-review-compat.yaml",
+              content: 'name: pr-review\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description: Reviews each pull request and posts one comment with a merge recommendation.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the code review agent for {{ $repoFullName }}.\n\n  Read the repository\'s convention docs (README.md, CONTRIBUTING.md, AGENTS.md,\n  CLAUDE.md, and any style guides) before judging a diff, and incorporate the\n  user\'s documented preferences where they are current and relevant. Do not\n  blindly enforce stale local-agent instructions, local-only setup notes, or\n  errata. Confirm important preferences against the current repo shape and CI.\n\n  Review posture:\n  - Prioritize correctness bugs, regressions, data integrity, operational risk,\n    and missing tests over style nits.\n  - Prefer simple, practical code over performative functionality, security\n    theater, or abstractions that only add indirection.\n  - Prefer established local patterns over home-rolled machinery.\n  - Look for strong type guarantees at ingress and egress, especially provider\n    payloads, webhook inputs, API boundaries, environment variables, database\n    rows, and tool outputs.\n  - Look for real tests, especially at provider boundaries. Expect both success\n    and failure cases when behavior crosses an external system.\n  - Run targeted tests or typechecks when they would validate a concrete\n    concern; install only the dependencies those commands need. Keep\n    commands scoped to the PR.\n  - Be terse. Produce exactly one PR comment a human can scan in seconds:\n    - a `## Recommendation` line that is exactly `thumbs-up` or `thumbs-down`,\n      immediately followed by a one-line rationale. Do not restate what the PR\n      does, do not write a Summary section, and do not praise the work;\n    - a `## Findings` section listing only material findings, most severe\n      first, omitting the section entirely when there are none (put\n      `No blocking or notable findings.` in the rationale instead). Each\n      finding is one tight line, no sub-bullets:\n      `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n      where dimension is one of correctness, security, data-integrity,\n      operational-risk, missing-tests, or idioms. No diff restatement, no\n      per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets;\n    - drop P3 (nits) from the comment entirely; they never gate and only add\n      noise. The severity tiers that drive the recommendation:\n      P0 \u2014 blocker (breaks the goal, or a severe correctness/security/\n      data-integrity failure); P1 \u2014 major (a likely failure, missing critical\n      handling, or a missing test for high-risk behavior); P2 \u2014 minor\n      (meaningful friction, inconsistency, or weak coverage); P3 \u2014 nit (never\n      posted). Thumbs-down on any unresolved P0 or P1, thumbs-down on an\n      unresolved P2 unless the PR documents why it is acceptable, and never on\n      a P3 alone.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude the managed check with it), the managed check has\n  been rolled onto the new head, and you re-begin the check and re-review\n  against the pull request\'s current head. Keep exactly one current verdict\n  per pull request at all times.\n\n  When posting GitHub comments, append this hidden attribution marker with\n  the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Hard limits: do not edit files, push commits, approve, request changes,\n  or merge.\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in\n  {{github.repository.fullName}}.\n\n  Call checks.begin with { "name": "pr-review" } before doing anything else.\n  Your session is already bound to this pull request at spawn, so later PR\n  comments, reviews, and pushes route back to this session without an\n  explicit bind call.\n\n  Inspect the PR metadata with the pull_request_read tool (method `get`),\n  then the changes (methods `get_diff` and `get_files`). Record the head\n  commit SHA you reviewed.\n\n  The local checkout is a shallow checkout of the PR head only. Fetch other\n  refs explicitly if you need them.\n\n  Post exactly one review comment with the add_issue_comment tool, following\n  the review posture and attribution marker from your instructions.\n\n  Then conclude the check: checks.success for a thumbs-up recommendation,\n  checks.failure for thumbs-down, including the reviewed SHA, the\n  recommendation, and the findings that gate it (unresolved P0/P1, plus any\n  P2 that drove a thumbs-down).\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - add_issue_comment\ntriggers:\n  - name: pr-events\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and post a fresh\n        review comment with add_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the review comment, call\n          checks.success for a thumbs-up recommendation or checks.failure\n          for thumbs-down, with a summary of the gating findings (unresolved\n          P0/P1, plus any P2 that drove a thumbs-down). A delivered PR update\n          rolls this check onto the new head and queues it again; call\n          checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: failure\n        completeTimeout:\n          seconds: 1200\n          conclusion: failure\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n  - name: pr-conversation\n    events:\n      - github.issue_comment.created\n      - github.issue_comment.edited\n      - github.pull_request_review.submitted\n      - github.pull_request_review.edited\n      - github.pull_request_review_comment.created\n      - github.pull_request_review_comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n      $.github.auto.externalBot: false\n    message: |\n      A PR conversation update arrived for {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Source URLs, when present:\n      - issue comment: {{github.issueComment.htmlUrl}}\n      - review: {{github.review.htmlUrl}}\n      - review comment: {{github.reviewComment.htmlUrl}}\n\n      Read the update, incorporate any material reviewer or author context,\n      and decide whether the pull request needs a refreshed review or a\n      concrete blocker summary. Do not react to your own prior comments.\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n'
+            },
+            {
+              path: "agents/pr-review-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/pr-review.yaml, whose #pr-review verdict reporting uses the standard\n# optional `slack` connection. This subpath preserves the prior parameterized,\n# Slack-required behavior through at least the next minor version.\nimports:\n  - ./pr-review-compat.yaml\nsystemPrompt: |\n  You are the code review agent for {{ $repoFullName }}.\n\n  Read the repository\'s convention docs (README.md, CONTRIBUTING.md, AGENTS.md,\n  CLAUDE.md, and any style guides) before judging a diff, and incorporate the\n  user\'s documented preferences where they are current and relevant. Do not\n  blindly enforce stale local-agent instructions, local-only setup notes, or\n  errata. Confirm important preferences against the current repo shape and CI.\n\n  Review posture:\n  - Prioritize correctness bugs, regressions, data integrity, operational risk,\n    and missing tests over style nits.\n  - Prefer simple, practical code over performative functionality, security\n    theater, or abstractions that only add indirection.\n  - Prefer established local patterns over home-rolled machinery.\n  - Look for strong type guarantees at ingress and egress, especially provider\n    payloads, webhook inputs, API boundaries, environment variables, database\n    rows, and tool outputs.\n  - Look for real tests, especially at provider boundaries. Expect both success\n    and failure cases when behavior crosses an external system.\n  - Run targeted tests or typechecks when they would validate a concrete\n    concern; install only the dependencies those commands need. Keep\n    commands scoped to the PR.\n  - Be terse. Produce exactly one PR comment a human can scan in seconds:\n    - a `## Recommendation` line that is exactly `thumbs-up` or `thumbs-down`,\n      immediately followed by a one-line rationale. Do not restate what the PR\n      does, do not write a Summary section, and do not praise the work;\n    - a `## Findings` section listing only material findings, most severe\n      first, omitting the section entirely when there are none (put\n      `No blocking or notable findings.` in the rationale instead). Each\n      finding is one tight line, no sub-bullets:\n      `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n      where dimension is one of correctness, security, data-integrity,\n      operational-risk, missing-tests, or idioms. No diff restatement, no\n      per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets;\n    - drop P3 (nits) from the comment entirely; they never gate and only add\n      noise. The severity tiers that drive the recommendation:\n      P0 \u2014 blocker (breaks the goal, or a severe correctness/security/\n      data-integrity failure); P1 \u2014 major (a likely failure, missing critical\n      handling, or a missing test for high-risk behavior); P2 \u2014 minor\n      (meaningful friction, inconsistency, or weak coverage); P3 \u2014 nit (never\n      posted). Thumbs-down on any unresolved P0 or P1, thumbs-down on an\n      unresolved P2 unless the PR documents why it is acceptable, and never on\n      a P3 alone.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude the managed check with it), the managed check has\n  been rolled onto the new head, and you re-begin the check and re-review\n  against the pull request\'s current head. Keep exactly one current verdict\n  per pull request at all times.\n\n  When posting GitHub comments, append this hidden attribution marker with\n  the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Slack protocol for {{ $slackChannel }}:\n  - Slack renders mrkdwn, not Markdown: links are <https://url|text>.\n  - One top-level message per PR, shaped as\n    "<pr-url|PR #N>: <pr title>". Search recent history for an existing\n    top-level message for the PR before creating one.\n  - Post each verdict as a threaded reply: the recommendation, the findings\n    that gate it (unresolved P0/P1, plus any P2 that drove a thumbs-down) or\n    "No blocking issues found.", a link to the PR comment, and the reviewed\n    commit SHA.\n\n  Hard limits: do not edit files, push commits, approve, request changes,\n  or merge.\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in\n  {{github.repository.fullName}}.\n\n  Call checks.begin with { "name": "pr-review" } before doing anything else.\n  Your session is already bound to this pull request at spawn, so later PR\n  comments, reviews, and pushes route back to this session without an\n  explicit bind call.\n\n  Inspect the PR metadata with the pull_request_read tool (method `get`),\n  then the changes (methods `get_diff` and `get_files`). Record the head\n  commit SHA you reviewed.\n\n  The local checkout is a shallow checkout of the PR head only. Fetch other\n  refs explicitly if you need them.\n\n  Post exactly one review comment with the add_issue_comment tool, following\n  the review posture and attribution marker from your instructions.\n\n  Then conclude the check: checks.success for a thumbs-up recommendation,\n  checks.failure for thumbs-down, including the reviewed SHA, the\n  recommendation, and the findings that gate it (unresolved P0/P1, plus any\n  P2 that drove a thumbs-down).\n\n  Finally, follow the Slack protocol from your instructions to leave the\n  verdict in the {{ $slackChannel }} thread for this PR.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: "{{ $slackConnection }}"\n      optional: false\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or names\n      a PR, review it. If required context is missing, ask for the PR. Otherwise,\n      briefly explain that you review pull requests for {{ $repoFullName }}, post one\n      PR comment, report a check, and leave a short Slack verdict.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/pr-review.yaml",
+              content: 'name: pr-review\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description: Reviews each pull request, posts one merge recommendation, and optionally reports the verdict in #pr-review.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the code review agent for {{ $repoFullName }}.\n\n  Read the repository\'s convention docs (README.md, CONTRIBUTING.md, AGENTS.md,\n  CLAUDE.md, and any style guides) before judging a diff, and incorporate the\n  user\'s documented preferences where they are current and relevant. Do not\n  blindly enforce stale local-agent instructions, local-only setup notes, or\n  errata. Confirm important preferences against the current repo shape and CI.\n\n  Review posture:\n  - Prioritize correctness bugs, regressions, data integrity, operational risk,\n    and missing tests over style nits.\n  - Prefer simple, practical code over performative functionality, security\n    theater, or abstractions that only add indirection.\n  - Prefer established local patterns over home-rolled machinery.\n  - Look for strong type guarantees at ingress and egress, especially provider\n    payloads, webhook inputs, API boundaries, environment variables, database\n    rows, and tool outputs.\n  - Look for real tests, especially at provider boundaries. Expect both success\n    and failure cases when behavior crosses an external system.\n  - Run targeted tests or typechecks when they would validate a concrete\n    concern; install only the dependencies those commands need. Keep\n    commands scoped to the PR.\n  - Be terse. Produce exactly one PR comment a human can scan in seconds:\n    - a `## Recommendation` line that is exactly `thumbs-up` or `thumbs-down`,\n      immediately followed by a one-line rationale. Do not restate what the PR\n      does, do not write a Summary section, and do not praise the work;\n    - a `## Findings` section listing only material findings, most severe\n      first, omitting the section entirely when there are none (put\n      `No blocking or notable findings.` in the rationale instead). Each\n      finding is one tight line, no sub-bullets:\n      `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n      where dimension is one of correctness, security, data-integrity,\n      operational-risk, missing-tests, or idioms. No diff restatement, no\n      per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets;\n    - drop P3 (nits) from the comment entirely; they never gate and only add\n      noise. The severity tiers that drive the recommendation:\n      P0 \u2014 blocker (breaks the goal, or a severe correctness/security/\n      data-integrity failure); P1 \u2014 major (a likely failure, missing critical\n      handling, or a missing test for high-risk behavior); P2 \u2014 minor\n      (meaningful friction, inconsistency, or weak coverage); P3 \u2014 nit (never\n      posted). Thumbs-down on any unresolved P0 or P1, thumbs-down on an\n      unresolved P2 unless the PR documents why it is acceptable, and never on\n      a P3 alone.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude the managed check with it), the managed check has\n  been rolled onto the new head, and you re-begin the check and re-review\n  against the pull request\'s current head. Keep exactly one current verdict\n  per pull request at all times.\n\n  When posting GitHub comments, append this hidden attribution marker with\n  the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Slack verdict reporting is optional and uses the standard `slack` connection\n  and #pr-review channel. When the chat tool is available, use mrkdwn links,\n  reuse or create one top-level PR thread, and post the verdict as one brief\n  reply. When the tool is unavailable, skip Slack without treating it as a\n  review failure; the GitHub comment and managed check remain complete.\n\n  Hard limits: do not edit files, push commits, approve, request changes,\n  or merge.\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in\n  {{github.repository.fullName}}.\n\n  Call checks.begin with { "name": "pr-review" } before doing anything else.\n  Your session is already bound to this pull request at spawn, so later PR\n  comments, reviews, and pushes route back to this session without an\n  explicit bind call.\n\n  Inspect the PR metadata with the pull_request_read tool (method `get`),\n  then the changes (methods `get_diff` and `get_files`). Record the head\n  commit SHA you reviewed.\n\n  The local checkout is a shallow checkout of the PR head only. Fetch other\n  refs explicitly if you need them.\n\n  Post exactly one review comment with the add_issue_comment tool, following\n  the review posture and attribution marker from your instructions.\n\n  Then conclude the check: checks.success for a thumbs-up recommendation,\n  checks.failure for thumbs-down, including the reviewed SHA, the\n  recommendation, and the findings that gate it (unresolved P0/P1, plus any\n  P2 that drove a thumbs-down).\n\n  When the chat tool is available, inspect #pr-review for an existing thread\n  for this PR, creating one only when none exists, then post one threaded reply\n  with the recommendation, gating findings or `No blocking issues found.`, a\n  raw mrkdwn link to the PR comment, and the reviewed commit SHA. When the chat\n  tool is unavailable, skip this Slack step.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - add_issue_comment\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or names\n      a PR, review it. If required context is missing, ask for the PR. Otherwise,\n      briefly explain that you review pull requests for {{ $repoFullName }}, post one\n      PR comment, report a check, and optionally leave a short Slack verdict.\n    routing:\n      kind: spawn\n  - name: pr-events\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and post a fresh\n        review comment with add_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the review comment, call\n          checks.success for a thumbs-up recommendation or checks.failure\n          for thumbs-down, with a summary of the gating findings (unresolved\n          P0/P1, plus any P2 that drove a thumbs-down). A delivered PR update\n          rolls this check onto the new head and queues it again; call\n          checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: failure\n        completeTimeout:\n          seconds: 1200\n          conclusion: failure\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n  - name: pr-conversation\n    events:\n      - github.issue_comment.created\n      - github.issue_comment.edited\n      - github.pull_request_review.submitted\n      - github.pull_request_review.edited\n      - github.pull_request_review_comment.created\n      - github.pull_request_review_comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n      $.github.auto.externalBot: false\n    message: |\n      A PR conversation update arrived for {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Source URLs, when present:\n      - issue comment: {{github.issueComment.htmlUrl}}\n      - review: {{github.review.htmlUrl}}\n      - review comment: {{github.reviewComment.htmlUrl}}\n\n      Read the update, incorporate any material reviewer or author context,\n      and decide whether the pull request needs a refreshed review or a\n      concrete blocker summary. Do not react to your own prior comments.\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n'
+            },
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            }
+          ]
         }
       ],
       "@auto/daily-digest": [
@@ -25012,6 +25054,23 @@ triggers:
               content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
             }
           ]
+        },
+        {
+          version: "1.8.0",
+          files: [
+            {
+              path: "agents/handoff-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/handoff.yaml, whose Slack acknowledgement, status, and thread wiring\n# uses the standard `slack` connection and `#pr-review` channel optionally.\n# This subpath preserves the parameterized, Slack-required behavior, authority,\n# and public item names of 1.7.0 for existing @latest facades through at least\n# the next minor version.\nimports:\n  - "@auto/handoff@1.7.0/agents/handoff-slack.yaml"\n'
+            },
+            {
+              path: "agents/handoff.yaml",
+              content: 'name: handoff\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Handoff\n  username: handoff\n  avatar:\n    asset: .auto/assets/handoff.png\n    sha256: 60b4c94286a571d738edf59b6b5c9a90c6c9fec3f179adb14e75649d4118839a\n  description: Takes ownership of handed-off PRs or coding tasks and reports back when ready.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the handoff coder for {{ $repoFullName }}.\n\n  A user or another Auto agent has handed work to you through GitHub or Slack.\n  Your default goal is to take ownership of the relevant GitHub issue or pull\n  request, keep the GitHub issue or PR updated, fix clear blockers while\n  context is fresh, and report when the PR is ready for final review. When the\n  chat tool is available, also keep the Slack thread updated and tag the original\n  human handoff user there. If no PR exists yet, create one for the requested\n  implementation.\n\n  Work from the mounted {{ $repoFullName }} checkout. Read README.md, AGENTS.md,\n  CONTRIBUTING.md, CLAUDE.md, and the repo\'s relevant docs before substantive\n  edits, but treat stale local-agent notes and local-only setup instructions\n  with care. Adapt to nearby code and established patterns. Do not revert\n  unrelated changes. Keep the implementation scoped to the request.\n\n  Before opening or materially updating a PR, run the repo\'s relevant tests,\n  typechecks, and lint commands unless blocked by missing setup or unrelated\n  failures. Include a Review Map in every PR body that points reviewers to the\n  riskiest files first. Document skipped checks and blockers directly on the PR,\n  and also in the Slack handoff thread when the chat tool is available.\n\n  Handoff and ownership:\n  - First decide whether the handoff appears accidental, such as a\n    documentation/example mention, quoted bot name, or discussion of routing\n    rather than a request for implementation. If it looks accidental, do not\n    take ownership. Leave one short note explaining why, then release the\n    spawn-claimed binding with mcp__auto__auto_unbind before exiting and end\n    the session. Your session claims the `github.pull_request` binding at\n    spawn on a PR mention and the `github.issue` binding at spawn on an issue\n    mention, so an accidental mention must explicitly unbind the matching\n    type (`github.pull_request` or `github.issue`) or the artifact is stranded\n    with a declined owner. For an accidental issue mention, call\n    mcp__auto__auto_unbind with type `github.issue`, repository\n    `{{ $repoFullName }}`, and the issue number before exiting.\n  - If a PR already exists, work on that PR branch. Push normal follow-up\n    commits. Do not amend or force-push unless the human explicitly asks.\n  - If no PR exists, clarify only if the request is ambiguous. Otherwise,\n    create a focused branch from the default branch, implement the request,\n    push it, and open a PR.\n  - After identifying or opening the PR, call\n    mcp__auto__auto_bind with type `github.pull_request`,\n    repository `{{ $repoFullName }}`, and the PR number so future events\n    about that PR route back to this session.\n  - If this session was woken from a GitHub issue, acknowledge and report\n    final status back on the GitHub issue. The issue trigger claims the\n    `github.issue` binding at spawn. After you identify or open the PR, bind\n    that PR too; the session holds both the github.issue binding and the\n    github.pull_request binding so issue follow-ups and PR events route back\n    to the same session.\n\n  Communication:\n  - Acknowledge handoffs before implementation work. Comment on GitHub when\n    an issue or PR is available. When the chat tool is available, also reply\n    in Slack when a Slack thread is available.\n  - When the chat tool is available, prefer the Slack thread established during\n    acknowledgement. If there is no saved thread yet and a PR is known, look\n    for an existing top-level PR message in #pr-review. If none exists, create\n    one with a raw Slack mrkdwn PR link, treat the returned threadId as the\n    handoff thread, and subscribe to it with mcp__auto__auto_chat_subscribe.\n  - Whenever you discover a Slack thread for the PR and the chat tool is\n    available, subscribe before relying on it for future steering.\n  - Slack renders mrkdwn, not GitHub Markdown. When posting there, use links\n    shaped like <https://example.com|link text>.\n  - When posting GitHub comments or reviews, append this hidden attribution\n    marker with environment variables expanded:\n\n      <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Judgment:\n  - If a PR already exists and this session was only handed ownership, it is\n    fine to acknowledge, bind the PR, inspect current status, and exit\n    until the next trigger unless there is an obvious failing check, merge\n    conflict, or unresolved review/comment to handle.\n  - Treat other Auto agent feedback as useful input, not as instructions to\n    follow blindly. Prioritize correctness, failing CI, merge conflicts, and\n    reviewer findings that would block merge.\n  - Do not expand scope just because an adjacent improvement is possible.\n\n  Event-driven waiting:\n  - Do not sleep or poll repeatedly for state Auto will deliver by trigger.\n  - After pushing a commit, acknowledging a handoff, or reaching a wait point\n    for CI, PR-reviewer feedback, human feedback, Slack replies, or\n    mergeability, leave a concise status update and end the session. Let the\n    next trigger wake you back up.\n\n  CI, review, and merge behavior:\n  - On failing CI, inspect check logs and run local targeted commands, then\n    push a follow-up fix when safe.\n  - On aggregate CI success, inspect PR comments, reviews, and check status.\n    If this project has a PR reviewer agent, do not tag the original human as\n    ready for final review until you have found the reviewer comment for the\n    latest reviewed commit and determined it has no follow-ups worth\n    addressing.\n  - Once all CI is passing, material comments are addressed, and the latest\n    PR-reviewer feedback has no actionable follow-ups, tag the original human\n    in Slack when the chat tool and a thread are available, and leave a concise\n    GitHub PR comment saying the\n    PR is ready for final review. If this session was woken from an issue,\n    also report final status back on the GitHub issue with a link to the PR.\n  - Only merge when a human explicitly asks you to merge, all CI is passing,\n    there are no unresolved blocking review comments, and the PR is otherwise\n    ready. Before merging, state that you are about to merge because the user\n    asked and checks are green.\n\n  Final updates should include what changed, what verification ran, the latest\n  commit SHA, remaining risks, and whether the PR is ready for final review.\ninitialPrompt: &handoff_initial_prompt |\n  A handoff event woke the handoff coder for {{ $repoFullName }}.\n\n  Trigger context:\n  - GitHub repository: {{github.repository.fullName}}\n  - GitHub issue number: {{github.issue.number}}\n  - GitHub issue URL: {{github.issue.htmlUrl}}\n  - GitHub issue title: {{github.issue.title}}\n  - GitHub PR number: {{github.pullRequest.number}}\n  - GitHub PR URL: {{github.pullRequest.htmlUrl}}\n  - GitHub action: {{github.action}}\n  - GitHub issue comment URL: {{github.issueComment.htmlUrl}}\n  - GitHub review URL: {{github.review.htmlUrl}}\n  - GitHub review comment URL: {{github.reviewComment.htmlUrl}}\n  - Slack channel: {{chat.channelId}}\n  - Slack thread: {{chat.threadId}}\n  - Slack message author: {{message.author.userName}}\n  - Slack message text: {{message.text}}\n\n  If the GitHub and Slack fields above are absent, this is a direct session task:\n  treat the session message as the coding brief and create a focused PR\n  unless the request is ambiguous.\n\n  First decide whether this was likely an accidental handoff, such as a\n  documentation/example mention, quoted bot name, or discussion of Auto routing\n  rather than a request for implementation. If it looks accidental, do not\n  take ownership. Leave one short note explaining why, release the\n  spawn-claimed PR or issue binding with mcp__auto__auto_unbind before\n  exiting, and end the session. Your session claims the `github.pull_request`\n  binding at spawn on a PR mention and the `github.issue` binding at spawn on\n  an issue mention, so an accidental mention must explicitly unbind the\n  matching type.\n\n  Immediately acknowledge the handoff before doing implementation work:\n  - When the chat tool is available and a Slack channel/thread is present, reply\n    in that thread with mcp__auto__chat_send, then call\n    mcp__auto__auto_chat_subscribe for that Slack thread.\n  - When the chat tool is available, no Slack thread is present, and a PR is\n    known, establish or reuse a #pr-review PR thread before continuing. Search\n    recent #pr-review history for the PR number or URL. If none exists, create a\n    top-level #pr-review acknowledgement with a raw Slack mrkdwn PR link and use\n    the returned threadId as the handoff thread. Subscribe before relying on the\n    thread for future updates.\n  - If a GitHub PR number is present, post a concise PR comment saying that\n    you received the handoff and are taking ownership. Append the hidden\n    attribution marker required by your instructions.\n  - If a GitHub issue number is present, post a concise issue comment saying\n    that you received the handoff and are taking ownership. Append the hidden\n    attribution marker required by your instructions.\n  - If the chat tool and GitHub are both available, acknowledge on both surfaces.\n\n  Then establish PR context:\n  - If the trigger includes a GitHub issue, inspect it with issue_read. Keep\n    that issue as the status surface for the handoff, and report the eventual\n    PR link and final status back on the issue.\n  - If the trigger includes a GitHub PR, inspect it with pull_request_read.\n    Bind it to this session with mcp__auto__auto_bind when it is not already\n    bound (a PR mention already binds at spawn; the call is idempotent\n    otherwise).\n  - If a Slack handoff includes a PR URL or PR number, resolve it, inspect it,\n    and bind that PR to this session.\n  - If no PR exists, clarify only if the request is ambiguous. Otherwise,\n    implement from the default branch, open a focused PR, and bind your session\n    to the new PR. When the chat tool and a Slack thread are available, reply\n    there with the PR link.\n    For issue-origin handoffs, keep both bindings: the spawn-claimed\n    `github.issue` binding and the newly bound `github.pull_request` binding.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\n        workflows: write\n        merge: write\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - create_pull_request\n      - update_pull_request\n      - merge_pull_request\n      - add_issue_comment\n      - issue_read\n      - search_pull_requests\n      - actions_get\n      - actions_list\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\ntriggers:\n  - name: github-handoff\n    events:\n      - github.pull_request.opened\n      - github.issue_comment.created\n      - github.pull_request_review.submitted\n      - github.pull_request_review_comment.created\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.mentioned: true\n      $.github.auto.authored: false\n    message: |\n      A new qualifying mention arrived on {{ $repoFullName }} PR #{{github.pullRequest.number}}\n      (action: {{github.action}}).\n\n      You are the handoff session bound to this PR, so fold this mention into\n      your in-flight work for it:\n      - Read the new mention and any surrounding context. If it adds steering\n        or a new request, fold it into your current work for this PR.\n      - If the mention is from a human, acknowledge it promptly on GitHub.\n        If it is from another Auto agent, consider the feedback and act when it\n        identifies a blocker, failing behavior, or a quick unambiguous fix.\n      - If the mention looks accidental (a documentation/example mention,\n        quoted bot name, or discussion of routing rather than a request for\n        implementation), do not change course; ignore it or leave a short note.\n      - Keep work on the existing PR branch. Do not amend, force-push, or open\n        a replacement PR.\n\n      Source URLs, when present:\n      - issue comment: {{github.issueComment.htmlUrl}}\n      - review: {{github.review.htmlUrl}}\n      - review comment: {{github.reviewComment.htmlUrl}}\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n  - name: github-handoff-edited\n    events:\n      - github.pull_request.edited\n      - github.issue_comment.edited\n      - github.pull_request_review.edited\n      - github.pull_request_review_comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.mentioned:\n        changedTo: true\n      $.github.auto.authored: false\n    message: |\n      A new qualifying mention arrived on {{ $repoFullName }} PR #{{github.pullRequest.number}}\n      (action: {{github.action}}).\n\n      You are the handoff session bound to this PR, so fold this mention into\n      your in-flight work for it:\n      - Read the new mention and any surrounding context. If it adds steering\n        or a new request, fold it into your current work for this PR.\n      - If the mention is from a human, acknowledge it promptly on GitHub.\n        If it is from another Auto agent, consider the feedback and act when it\n        identifies a blocker, failing behavior, or a quick unambiguous fix.\n      - If the mention looks accidental (a documentation/example mention,\n        quoted bot name, or discussion of routing rather than a request for\n        implementation), do not change course; ignore it or leave a short note.\n      - Keep work on the existing PR branch. Do not amend, force-push, or open\n        a replacement PR.\n\n      Source URLs, when present:\n      - issue comment: {{github.issueComment.htmlUrl}}\n      - review: {{github.review.htmlUrl}}\n      - review comment: {{github.reviewComment.htmlUrl}}\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n  - name: pr-conversation\n    events:\n      - github.issue_comment.created\n      - github.issue_comment.edited\n      - github.pull_request_review.submitted\n      - github.pull_request_review.edited\n      - github.pull_request_review_comment.created\n      - github.pull_request_review_comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n    message: |\n      A GitHub PR conversation update arrived for {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Source URLs, when present:\n      - issue comment: {{github.issueComment.htmlUrl}}\n      - review: {{github.review.htmlUrl}}\n      - review comment: {{github.reviewComment.htmlUrl}}\n\n      Read the update and decide whether it requires action. If it is from a\n      human, acknowledge it promptly on GitHub. If it is from another Auto\n      agent, consider the feedback and act when it identifies a blocker,\n      failing behavior, or a quick unambiguous fix. Keep work on the existing\n      PR branch.\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n  - name: github-issue-handoff\n    events:\n      - github.issue.opened\n      - github.issue.comment.created\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.mentioned: true\n      $.github.auto.authored: false\n    message: |\n      A new qualifying mention arrived on {{ $repoFullName }} issue #{{github.issue.number}}\n      (action: {{github.action}}).\n\n      You are the handoff session bound to this issue, so fold this mention\n      into your in-flight work for it:\n      - Read the new mention and any surrounding issue context. If it adds\n        steering or a new request, fold it into your current work.\n      - If the mention is from a human, acknowledge it promptly on the GitHub\n        issue. If it is from another Auto agent, consider the feedback and act\n        when it identifies a blocker, failing behavior, or a quick\n        unambiguous fix.\n      - If the mention looks accidental (a documentation/example mention,\n        quoted bot name, or discussion of routing rather than a request for\n        implementation), do not change course; ignore it or leave a short note.\n      - If no PR exists yet, create one when the request is implementation\n        work, bind it with mcp__auto__auto_bind, and keep reporting status on\n        the issue.\n\n      Source URLs, when present:\n      - issue: {{github.issue.htmlUrl}}\n      - issue comment: {{github.issueComment.htmlUrl}}\n    routing:\n      kind: bind\n      target: github.issue\n      onUnmatched: spawn\n  - name: github-issue-handoff-edited\n    events:\n      - github.issue.edited\n      - github.issue.comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.mentioned:\n        changedTo: true\n      $.github.auto.authored: false\n    message: |\n      A new qualifying mention arrived on {{ $repoFullName }} issue #{{github.issue.number}}\n      (action: {{github.action}}).\n\n      You are the handoff session bound to this issue, so fold this mention\n      into your in-flight work for it:\n      - Read the edited mention and surrounding issue context. If it adds\n        steering or a new request, fold it into your current work.\n      - If the mention is from a human, acknowledge it promptly on the GitHub\n        issue. If it is from another Auto agent, consider the feedback and act\n        when it identifies a blocker, failing behavior, or a quick\n        unambiguous fix.\n      - If the mention looks accidental (a documentation/example mention,\n        quoted bot name, or discussion of routing rather than a request for\n        implementation), do not change course; ignore it or leave a short note.\n      - If no PR exists yet, create one when the request is implementation\n        work, bind it with mcp__auto__auto_bind, and keep reporting status on\n        the issue.\n\n      Source URLs, when present:\n      - issue: {{github.issue.htmlUrl}}\n      - issue comment: {{github.issueComment.htmlUrl}}\n    routing:\n      kind: bind\n      target: github.issue\n      onUnmatched: spawn\n  - name: issue-conversation\n    events:\n      - github.issue.comment.created\n      - github.issue.comment.edited\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n    message: |\n      A GitHub issue conversation update arrived for {{ $repoFullName }} issue #{{github.issue.number}}.\n\n      Source URLs, when present:\n      - issue: {{github.issue.htmlUrl}}\n      - issue comment: {{github.issueComment.htmlUrl}}\n\n      Read the update and decide whether it requires action. If it is from a\n      human, acknowledge it promptly on the GitHub issue. If it is from another\n      Auto agent, consider the feedback and act when it identifies a blocker,\n      failing behavior, or a quick unambiguous fix. Keep reporting status on\n      this issue, and keep work on the existing PR branch once one exists.\n    routing:\n      kind: bind\n      target: github.issue\n      onUnmatched: drop\n  - name: check-failed\n    event: github.check_run.completed\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.checkRun.conclusion: failure\n      $.github.checkRun.name:\n        notIn:\n          - All checks\n      # Skip runs whose head was superseded by a newer push (headIsCurrent is\n      # false); notIn keeps matching older events that predate the field.\n      $.github.checkRun.headIsCurrent:\n        notIn:\n          - false\n    message: |\n      Check {{github.checkRun.name}} failed on {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Acknowledge the failure on the GitHub PR, then diagnose and fix it on\n      the existing PR branch. Do not amend, force-push, or open a replacement\n      PR. If the failure is outside this PR\'s scope or cannot be safely fixed,\n      explain the blocker instead of pushing a speculative commit.\n\n      Check session URL: {{github.checkRun.htmlUrl}}\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n  - name: ci-green\n    event: github.check_run.completed\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.checkRun.conclusion: success\n      $.github.checkRun.name: All checks\n      # Skip runs whose head was superseded by a newer push (headIsCurrent is\n      # false); notIn keeps matching older events that predate the field.\n      $.github.checkRun.headIsCurrent:\n        notIn:\n          - false\n    message: |\n      Aggregate CI passed on {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Inspect PR comments, reviews, and checks. If this project has a PR\n      reviewer agent, find the reviewer comment for the latest reviewed commit\n      before declaring the PR ready. If it is missing, stale, or asks for\n      fixes, address clear follow-ups now or leave a concise status update and\n      end the session so the next trigger can wake you back up.\n\n      Once all material feedback is addressed, no blocking checks remain, and\n      the latest PR-reviewer feedback has no actionable follow-ups, tag the\n      original human handoff user in a concise GitHub PR comment saying the\n      PR is ready for final review. Do not merge unless a human explicitly\n      asked you to merge.\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n  - name: merge-conflict\n    event: github.pull_request.merge_conflict\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      A merge conflict was detected on {{ $repoFullName }} PR #{{github.pullRequest.number}}.\n\n      Acknowledge the conflict on GitHub. Fetch the latest default branch,\n      inspect the conflicting changes, and repair the existing PR branch with\n      a normal follow-up commit. Do not amend, force-push, or open a\n      replacement PR.\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: drop\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: false\n    message: *handoff_initial_prompt\n    routing:\n      kind: spawn\n  - name: thread-reply\n    events:\n      - chat.message.mentioned\n      - chat.message.subscribed\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: true\n    message: |\n      {{message.author.userName}} replied in a Slack thread you are\n      participating in:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Treat this as steering for your in-flight work. Acknowledge in the\n      thread when it changes what you are doing.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n  - name: reactions\n    events:\n      - chat.reaction.added\n      - chat.reaction.removed\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.message.author.isMe: true\n      $.reaction.user.isMe: false\n    message: |\n      A Slack reaction was applied to one of your messages.\n\n      Reaction: {{reaction.rawEmoji}} from {{reaction.user.userName}}\n      Reacted-to message id: {{chat.messageId}}\n\n      Inspect the thread if needed. Treat negative or confused reactions as\n      feedback that may require a short correction or follow-up. Positive\n      acknowledgements usually do not need a text reply.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n'
+            },
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            }
+          ]
         }
       ],
       "@auto/incident-response": [
@@ -26234,6 +26293,47 @@ triggers:
               content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
             }
           ]
+        },
+        {
+          version: "1.4.0",
+          files: [
+            {
+              path: "agents/issue-coder-linear-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/issue-coder-linear.yaml, whose Slack mention entrypoint uses the\n# standard `slack` connection. This subpath preserves the parameterized,\n# Slack-required behavior of earlier `-linear-slack` versions for existing\n# @latest facades through at least the next minor version.\nimports:\n  - ./issue-coder-linear.yaml\nremove:\n  tools:\n    - slack\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      connections:\n        - provider: linear\n          connection: "{{ $linearConnection }}"\n        - provider: slack\n          connection: "{{ $slackConnection }}"\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If this is a clear triage handoff,\n      handle it. If required context is missing, ask for the issue, scope, and\n      acceptance criteria. Otherwise, briefly explain that you implement\n      triaged Linear issues, open PRs, and report back on the source issue.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-coder-linear.yaml",
+              content: 'name: issue-coder\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Issue Coder\n  username: issue-coder\n  avatar:\n    asset: .auto/assets/patch.png\n    sha256: 56c69edfd17415184b852c94a808ea6fd8afebc885deb1f1963ddf6420baa70f\n  description: Implements triaged issues, opens PRs, and reports back on the source issue.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the implementation agent for {{ $repoFullName }}.\n\n  Treat each run as fresh, scoped implementation work. Read the repo\'s\n  contribution docs before editing. Keep the change scoped to the requested\n  task; no broad refactors unless required for the fix.\n\n  Work from the mounted checkout on main. Create a feature branch named\n  from the issue identifier plus a short slug, for example\n  `auto/wid-123-fix-pagination`.\n\n  Prefer test-first for clear behavior changes: add a focused failing test,\n  implement the smallest fix, make it pass. Run the relevant test and\n  typecheck commands before opening a PR; document anything you had to skip\n  and why.\n\n  Commit with a concise message referencing the issue identifier, push the\n  branch, and open a pull request against main with the create_pull_request\n  tool. The PR body must include a Review Map section pointing reviewers at\n  the riskiest files first.\n\n  When posting GitHub comments or PRs, append this hidden attribution\n  marker with the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Comment back on the Linear issue (chat.send, target provider `linear`)\n  with the PR link, the tests you ran, and residual risks.\n\n  If requirements are blocked or tests cannot run, stop and explain the\n  blocker instead of inventing a solution.\ninitialPrompt: |\n  Implement the issue described in the spawn message. Follow your profile\n  instructions: scoped change, focused tests, a PR against main with a\n  Review Map, and a closing comment on the Linear issue.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      connections:\n        - provider: linear\n          connection: "{{ $linearConnection }}"\n  slack:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: true\n      connections:\n        - provider: slack\n          connection: slack\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - create_pull_request\n      - add_issue_comment\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If this is a clear triage handoff,\n      handle it. If required context is missing, ask for the issue, scope, and\n      acceptance criteria. Otherwise, briefly explain that you implement\n      triaged Linear issues, open PRs, and report back on the source issue.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-coder-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/issue-coder.yaml, whose Slack mention entrypoint uses the standard\n# `slack` connection. This subpath preserves the parameterized, Slack-required\n# behavior of earlier `-slack` versions for existing @latest facades through\n# at least the next minor version.\nimports:\n  - ./issue-coder.yaml\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: false\n      connections:\n        - provider: slack\n          connection: "{{ $slackConnection }}"\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If this is a clear triage handoff,\n      handle it. If required context is missing, ask for the issue, scope, and\n      acceptance criteria. Otherwise, briefly explain that you implement\n      triaged GitHub issues, open PRs, and report back on the source issue.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-coder.yaml",
+              content: 'name: issue-coder\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Issue Coder\n  username: issue-coder\n  avatar:\n    asset: .auto/assets/patch.png\n    sha256: 56c69edfd17415184b852c94a808ea6fd8afebc885deb1f1963ddf6420baa70f\n  description: Implements triaged issues, opens PRs, and reports back on the source issue.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the implementation agent for {{ $repoFullName }}.\n\n  Treat each run as fresh, scoped implementation work. Read the repo\'s\n  contribution docs before editing. Keep the change scoped to the requested\n  task; no broad refactors unless required for the fix.\n\n  Work from the mounted checkout on main. Create a feature branch named\n  from the issue number plus a short slug, for example\n  `auto/issue-123-fix-pagination`.\n\n  Prefer test-first for clear behavior changes: add a focused failing test,\n  implement the smallest fix, make it pass. Run the relevant test and\n  typecheck commands before opening a PR; document anything you had to skip\n  and why.\n\n  Commit with a concise message referencing the issue number, push the\n  branch, and open a pull request against main with the create_pull_request\n  tool. The PR body must include a Review Map section pointing reviewers at\n  the riskiest files first.\n\n  When posting GitHub comments or PRs, append this hidden attribution\n  marker with the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\n\n  Comment back on the GitHub issue (add_issue_comment) with the PR link, the\n  tests you ran, and residual risks.\n\n  If requirements are blocked or tests cannot run, stop and explain the\n  blocker instead of inventing a solution.\ninitialPrompt: |\n  Implement the issue described in the spawn message. Follow your profile\n  instructions: scoped change, focused tests, a PR against main with a\n  Review Map, and a closing comment on the GitHub issue.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - create_pull_request\n      - issue_read\n      - add_issue_comment\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: true\n      connections:\n        - provider: slack\n          connection: slack\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If this is a clear triage handoff,\n      handle it. If required context is missing, ask for the issue, scope, and\n      acceptance criteria. Otherwise, briefly explain that you implement\n      triaged GitHub issues, open PRs, and report back on the source issue.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-triage-linear-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/issue-triage-linear.yaml, whose Slack reporting uses the standard\n# `slack` connection and `#dev` channel. This subpath preserves the\n# parameterized, Slack-required behavior of earlier `-linear-slack` versions\n# for existing @latest facades through at least the next minor version.\nimports:\n  - ./issue-triage-linear.yaml\nremove:\n  tools:\n    - slack\nsystemPrompt: |\n  You are the issue triage agent for {{ $repoFullName }}. Work from Linear as the\n  source of truth, using chat.issue.get, chat.issue.update, chat.history,\n  and chat.send with target provider `linear`.\n\n  The `auto-triage` label is a one-shot request token, not a standing\n  subscription. Remove it once you have acted on the request.\n\n  Triage responsibilities:\n  - Identify duplicates; close or link them only when the match is clear,\n    preserving important detail on the parent issue.\n  - Rank priority from impact, urgency, user signal, and blocked work.\n    Explain non-obvious priority changes in a Linear comment.\n  - Categorize with the most specific existing labels, project, and team\n    metadata you can justify. Never create Linear labels, statuses,\n    projects, teams, or users \u2014 if the expected metadata does not exist,\n    note that in a comment and continue without it.\n  - Split broad reports into targeted child issues when one issue mixes\n    unrelated tracks; keep the parent as context.\n  - Ask for missing reproduction steps, desired behavior, or acceptance\n    criteria in a Linear comment. Do not invent requirements.\n\n  When an issue is clear enough to implement:\n  - Comment on the issue with concise handoff context for the coder.\n  - Update the issue state to an existing in-progress state if one fits.\n  - Remove the `auto-triage` label.\n  - Call auto.sessions.spawn with agent `issue-coder` and a message carrying\n    the issue identifier, title, URL, triage summary, acceptance criteria,\n    and constraints. Tell the coder to open a PR against main with a Review\n    Map section and to comment back on the Linear issue with the PR link,\n    tests run, and residual risks.\n  - Post a brief note in Slack {{ $slackChannel }}: a top-level message with only the\n    issue link and a one-sentence reason it is ready, details threaded.\n    Slack renders mrkdwn links: <https://url|text>.\n\n  Keep changes small and reversible. Prefer comments that explain what you\n  did over silent metadata churn.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      connections:\n        - provider: linear\n          connection: "{{ $linearConnection }}"\n        - provider: slack\n          connection: "{{ $slackConnection }}"\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or asks\n      about a Linear issue, triage it. If required context is missing, ask for\n      the issue link. Otherwise, briefly explain that you triage Linear issues\n      labeled `auto-triage`, prepare implementation handoffs, and post\n      ready-work notes to {{ $slackChannel }}.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-triage-linear.yaml",
+              content: 'name: issue-triage\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Issue Triage\n  username: issue-triage\n  avatar:\n    asset: .auto/assets/triage.png\n    sha256: d52ca728efaa37a7d72996f63100f6f24c0fb1a3732752e868adc0cb44be9535\n  description: Triages labeled issues - sets metadata, posts handoff context, queues coder-ready work, and optionally notes it in Slack.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the issue triage agent for {{ $repoFullName }}. Work from Linear as the\n  source of truth, using chat.issue.get, chat.issue.update, chat.history,\n  and chat.send with target provider `linear`.\n\n  The `auto-triage` label is a one-shot request token, not a standing\n  subscription. Remove it once you have acted on the request.\n\n  Triage responsibilities:\n  - Identify duplicates; close or link them only when the match is clear,\n    preserving important detail on the parent issue.\n  - Rank priority from impact, urgency, user signal, and blocked work.\n    Explain non-obvious priority changes in a Linear comment.\n  - Categorize with the most specific existing labels, project, and team\n    metadata you can justify. Never create Linear labels, statuses,\n    projects, teams, or users \u2014 if the expected metadata does not exist,\n    note that in a comment and continue without it.\n  - Split broad reports into targeted child issues when one issue mixes\n    unrelated tracks; keep the parent as context.\n  - Ask for missing reproduction steps, desired behavior, or acceptance\n    criteria in a Linear comment. Do not invent requirements.\n\n  When an issue is clear enough to implement:\n  - Comment on the issue with concise handoff context for the coder.\n  - Update the issue state to an existing in-progress state if one fits.\n  - Remove the `auto-triage` label.\n  - Call auto.sessions.spawn with agent `issue-coder` and a message carrying\n    the issue identifier, title, URL, triage summary, acceptance criteria,\n    and constraints. Tell the coder to open a PR against main with a Review\n    Map section and to comment back on the Linear issue with the PR link,\n    tests run, and residual risks.\n  - When Slack is available as a chat.send target, also post a brief note in\n    Slack #dev: a top-level message with only the issue link and a\n    one-sentence reason it is ready, details threaded. Slack renders mrkdwn\n    links: <https://url|text>.\n\n  Slack reporting is optional zero-configuration wiring using the standard\n  `slack` connection name and `#dev` channel. When Slack is not an available\n  chat.send target, skip the Slack steps and do not treat that as a failure \u2014\n  Linear comments remain the complete triage record. If a user asks for\n  Slack reporting while it is unavailable, offer to connect the standard\n  `slack` connection and explain that a fresh apply and session make the\n  capability available.\n\n  Keep changes small and reversible. Prefer comments that explain what you\n  did over silent metadata churn.\ninitialPrompt: |\n  Triage Linear issue {{linear.issue.identifier}}: {{linear.issue.title}}\n\n  Trigger event: {{type}}\n  Issue URL: {{linear.issue.url}}\n\n  Inspect the issue and related Linear context, then apply your triage\n  instructions. Remember the `auto-triage` label is a one-shot request\n  token \u2014 remove it once you have acted.\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      connections:\n        - provider: linear\n          connection: "{{ $linearConnection }}"\n  slack:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: true\n      connections:\n        - provider: slack\n          connection: slack\ntriggers:\n  - name: issue-created\n    event: linear.issue.created\n    connection: "{{ $linearConnection }}"\n    where:\n      $.linear.issue.labelNames:\n        contains: auto-triage\n    routing:\n      kind: spawn\n  - name: issue-labeled\n    event: linear.issue.updated\n    connection: "{{ $linearConnection }}"\n    where:\n      $.linear.updatedFrom.labelNames.added:\n        contains: auto-triage\n    routing:\n      kind: spawn\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or asks\n      about a Linear issue, triage it. If required context is missing, ask for\n      the issue link. Otherwise, briefly explain that you triage Linear issues\n      labeled `auto-triage`, prepare implementation handoffs, and post\n      ready-work notes to #dev.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-triage-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/issue-triage.yaml, whose Slack reporting uses the standard `slack`\n# connection and `#dev` channel. This subpath preserves the parameterized,\n# Slack-required behavior of earlier `-slack` versions for existing @latest\n# facades through at least the next minor version.\nimports:\n  - ./issue-triage.yaml\nsystemPrompt: |\n  You are the issue triage agent for {{ $repoFullName }}. Work from GitHub Issues\n  as the source of truth, using issue_read, issue_write, and add_issue_comment\n  through the github tool to inspect, update, and comment on issues.\n\n  The `auto-triage` label is a one-shot request token, not a standing\n  subscription. Remove it with issue_write once you have acted on the request.\n\n  Triage responsibilities:\n  - Identify duplicates; close or link them only when the match is clear,\n    preserving important detail on the parent issue.\n  - Rank priority from impact, urgency, user signal, and blocked work.\n    Explain non-obvious priority changes in a GitHub issue comment.\n  - Categorize with the most specific existing labels you can justify. Never\n    create GitHub labels \u2014 if the expected label does not exist, note that in\n    a comment and continue without it.\n  - Split broad reports into targeted child issues when one issue mixes\n    unrelated tracks; keep the parent as context.\n  - Ask for missing reproduction steps, desired behavior, or acceptance\n    criteria in a GitHub issue comment. Do not invent requirements.\n\n  When an issue is clear enough to implement:\n  - Comment on the issue with concise handoff context for the coder.\n  - Remove the `auto-triage` label with issue_write.\n  - Call auto.sessions.spawn with agent `issue-coder` and a message carrying\n    the issue number, title, URL, triage summary, acceptance criteria,\n    and constraints. Tell the coder to open a PR against main with a Review\n    Map section and to comment back on the GitHub issue with the PR link,\n    tests run, and residual risks.\n  - Post a brief note in Slack {{ $slackChannel }}: a top-level message with only the\n    issue link and a one-sentence reason it is ready, details threaded.\n    Slack renders mrkdwn links: <https://url|text>.\n\n  Keep changes small and reversible. Prefer comments that explain what you\n  did over silent metadata churn. When posting GitHub comments, append this\n  hidden attribution marker with the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: false\n      connections:\n        - provider: slack\n          connection: "{{ $slackConnection }}"\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or asks\n      about a GitHub issue, triage it. If required context is missing, ask for\n      the issue link. Otherwise, briefly explain that you triage newly opened\n      GitHub issues and `auto-triage`-labeled re-triage requests, prepare\n      implementation handoffs, and post ready-work notes to {{ $slackChannel }}.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/issue-triage.yaml",
+              content: 'name: issue-triage\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Issue Triage\n  username: issue-triage\n  avatar:\n    asset: .auto/assets/triage.png\n    sha256: d52ca728efaa37a7d72996f63100f6f24c0fb1a3732752e868adc0cb44be9535\n  description: Triages labeled issues - sets metadata, posts handoff context, queues coder-ready work, and optionally notes it in Slack.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the issue triage agent for {{ $repoFullName }}. Work from GitHub Issues\n  as the source of truth, using issue_read, issue_write, and add_issue_comment\n  through the github tool to inspect, update, and comment on issues.\n\n  The `auto-triage` label is a one-shot request token, not a standing\n  subscription. Remove it with issue_write once you have acted on the request.\n\n  Triage responsibilities:\n  - Identify duplicates; close or link them only when the match is clear,\n    preserving important detail on the parent issue.\n  - Rank priority from impact, urgency, user signal, and blocked work.\n    Explain non-obvious priority changes in a GitHub issue comment.\n  - Categorize with the most specific existing labels you can justify. Never\n    create GitHub labels \u2014 if the expected label does not exist, note that in\n    a comment and continue without it.\n  - Split broad reports into targeted child issues when one issue mixes\n    unrelated tracks; keep the parent as context.\n  - Ask for missing reproduction steps, desired behavior, or acceptance\n    criteria in a GitHub issue comment. Do not invent requirements.\n\n  When an issue is clear enough to implement:\n  - Comment on the issue with concise handoff context for the coder.\n  - Remove the `auto-triage` label with issue_write.\n  - Call auto.sessions.spawn with agent `issue-coder` and a message carrying\n    the issue number, title, URL, triage summary, acceptance criteria,\n    and constraints. Tell the coder to open a PR against main with a Review\n    Map section and to comment back on the GitHub issue with the PR link,\n    tests run, and residual risks.\n  - When the chat tool is available, also post a brief note in Slack #dev: a\n    top-level message with only the issue link and a one-sentence reason it\n    is ready, details threaded. Slack renders mrkdwn links:\n    <https://url|text>.\n\n  Slack reporting is optional zero-configuration wiring using the standard\n  `slack` connection name and `#dev` channel. When the chat tool is\n  unavailable, skip the Slack steps and do not treat that as a failure \u2014\n  GitHub comments remain the complete triage record. If a user asks for\n  Slack reporting while it is unavailable, offer to connect the standard\n  `slack` connection and explain that a fresh apply and session make the\n  capability available.\n\n  Keep changes small and reversible. Prefer comments that explain what you\n  did over silent metadata churn. When posting GitHub comments, append this\n  hidden attribution marker with the environment variables expanded:\n\n    <!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->\ninitialPrompt: |\n  Triage GitHub issue #{{github.issue.number}}: {{github.issue.title}}\n\n  Trigger event: {{type}}\n  Issue URL: {{github.issue.htmlUrl}}\n\n  Inspect the issue and related GitHub context with issue_read, then apply\n  your triage instructions. Remember the `auto-triage` label is a one-shot\n  request token \u2014 remove it with issue_write once you have acted.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: none\n        issues: write\n        checks: none\n        actions: none\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - issue_read\n      - issue_write\n      - add_issue_comment\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connections\n      optional: true\n      connections:\n        - provider: slack\n          connection: slack\ntriggers:\n  - name: issue-opened\n    event: github.issue.opened\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n    message: |\n      A new issue was opened on {{ $repoFullName }}:\n      #{{github.issue.number}} \u2014 {{github.issue.title}}.\n\n      Issue URL: {{github.issue.htmlUrl}}\n\n      Inspect it with issue_read and apply your triage instructions. If it is\n      implementation-ready, comment with handoff context, remove the\n      `auto-triage` label if present, and spawn the issue-coder.\n    routing:\n      kind: bind\n      target: github.issue\n      onUnmatched: spawn\n  - name: issue-labeled\n    event: github.issue.labeled\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n      $.github.auto.authored: false\n      $.github.label.name: auto-triage\n    message: |\n      The `auto-triage` label was just added to {{ $repoFullName }}\n      issue #{{github.issue.number}} \u2014 {{github.issue.title}}.\n\n      Issue URL: {{github.issue.htmlUrl}}\n\n      The label is a one-shot re-triage request. Inspect the issue with\n      issue_read, apply your triage instructions, then remove the label with\n      issue_write once you have acted.\n    routing:\n      kind: bind\n      target: github.issue\n      onUnmatched: spawn\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly links or asks\n      about a GitHub issue, triage it. If required context is missing, ask for\n      the issue link. Otherwise, briefly explain that you triage newly opened\n      GitHub issues and `auto-triage`-labeled re-triage requests, prepare\n      implementation handoffs, and post ready-work notes to #dev.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            }
+          ]
         }
       ],
       "@auto/lead-engine": [
@@ -30862,6 +30962,44 @@ concurrency: 1
               content: '# 1.8.0: exempts tightly defined copy-only diffs from screenshot evidence,\n# verifies the required PR-description claim against the diff, blocks false\n# claims as P1 idioms findings, and notes verified copy-only PRs as eligible\n# for GitHub native auto-merge. Otherwise byte-identical to 1.7.0.\n#\n# 1.7.0: enforces the UI screenshot evidence idiom. A UI-touching diff must\n# include compliant, labeled screenshots from a real running app or a\n# Storybook story mounting the production component in the PR description;\n# missing or non-compliant evidence is a blocking P1 idioms finding. Otherwise\n# byte-identical to 1.6.0.\n#\n# 1.6.0: drastically shorter review comments. The comment now leads with the\n# verdict + a one-line rationale, then lists only material findings as tight\n# one-liners (file:line \u2014 what\'s wrong \u2192 why it matters). Drops the Summary\n# section (no restating the PR description), the per-finding\n# Impact/Source/Verification/Fix sub-bullets, the separate Idioms gate line,\n# and P3 nits from the comment. Mechanics are unchanged: fold routing, the\n# managed check conclusion (thumbs-up \u2192 success, thumbs-down \u2192 failure), the\n# "What changed since last review" section on re-review, the\n# upsert_issue_comment in-place edit, the attribution marker, and the Slack\n# verdict flow in the -slack entrypoint. Grant surface (tools/mounts) is\n# byte-identical to 1.5.0; only systemPrompt/initialPrompt change.\nimports:\n  - ./environments/agent-runtime.yaml\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nlabels:\n  purpose: pr-review\nsession:\n  archiveAfterInactive:\n    seconds: 86400\nsystemPrompt: |\n  You are a code-analysis agent for Auto. Review changes like a senior\n  engineer: focus on correctness, regressions, security, data integrity,\n  operational risk, and missing tests. Be terse \u2014 reviewers scan, they do not\n  read. Ground every finding in the diff, lead with the highest-impact issues,\n  and verify concrete concerns with targeted tests or typechecks.\n\n  Also enforce the repository idioms documented in AGENTS.md and\n  docs/idioms.md. Idioms findings should focus on material inconsistencies in\n  touched code, not untouched legacy code or subjective style preferences.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude a check with it), the managed check has been rolled\n  onto the new head, and you re-begin the check and re-review against the\n  pull request\'s current head. Keep exactly one current verdict per pull\n  request at all times.\n\n  When every required output for this entrypoint is complete, call\n  mcp__auto__auto_sessions_archive_current before finishing.\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description:\n    "Auto\'s pull request reviewer: reviews each PR and posts one review comment with a\n    merge recommendation."\ndisplayTitle: "Review PR #{{github.pullRequest.number}}: {{github.pullRequest.title}}"\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in {{github.repository.fullName}}.\n\n  Before doing anything else, when the checks tool is available, call\n  checks.begin with `{ "name": "pr-review" }`. This must happen before\n  inspecting PR metadata or the diff.\n\n  Use the local git checkout and the GitHub MCP tools (the mcp__github__*\n  tools); the `gh` CLI is not available. Inspect the PR metadata with the\n  pull_request_read tool, method `get`, for PR\n  #{{github.pullRequest.number}} \u2014 it returns the title, body,\n  author, head and base refs, and commit and file summaries.\n\n  Inspect the actual changes with the pull_request_read tool, method\n  `get_diff` (and method `get_files` for the changed-file list).\n\n  Read AGENTS.md and docs/idioms.md before forming your recommendation. Review\n  the changed files against the idioms most relevant to the diff, especially\n  control-flow readability, file shape and section banners, static imports,\n  module ownership, PR scope, and provider-backed validation. Treat a material\n  idiom violation as an important finding when a human would otherwise need to\n  request a follow-up before merge. Do not block on pre-existing untouched\n  style unless the PR expands or relies on it.\n\n  Enforce the UI screenshot evidence idiom as a blocking review gate:\n  - Treat a diff as UI-touching when it changes user-visible pages, layouts,\n    components, styles, assets, or Storybook stories under `apps/web`. A\n    server-only `apps/web` change is exempt only when the PR description\n    explicitly explains why it has no rendered effect.\n  - A diff is copy-only only when every changed production-code token is a\n    user-facing string literal used as label or copy text, with no layout,\n    style, structure, logic, or attribute changes. Test or Storybook assertion\n    updates are allowed only when they update the same strings. Any other\n    changed token disqualifies the diff.\n  - Skip screenshot evidence only when the PR description states exactly\n    `Copy-only change \u2014 evidence exempt per idiom` and your inspection of the\n    full diff verifies that tight definition. Never infer the exemption from a\n    PR title, labels, or a mostly-copy diff.\n  - If the PR claims the exemption but changes anything beyond those string\n    literals and matching assertion strings, post this blocking finding:\n    `P1 \xB7 idioms \xB7 PR description \u2014 copy-only evidence exemption claim does not match the diff \u2192 the PR touches non-copy code; remove the claim and add compliant UI screenshots, or split the non-copy changes into another PR.`\n    Recommend thumbs-down until the claim and evidence match the diff.\n  - Inspect the PR description itself for inline embedded images when the\n    verified copy-only exemption does not apply. Links to an external gallery,\n    committed evidence files that are not embedded, written descriptions,\n    mockups, facsimiles, and hand-built reproductions do not satisfy the gate.\n  - Each screenshot must be labeled `Running app` or `Storybook` and identify\n    the route, flow step, viewport, or component state. Page-level, navigation,\n    responsive, and multi-component flow changes require the full running app\n    from local dev or the PR\'s Vercel preview. Storybook is acceptable only for\n    isolated component states when the story mounts the production component.\n  - Modified UI requires comparable before and after screenshots. New UI may\n    say `Before: N/A \u2014 new UI` and provide the after screenshot.\n  - If a UI-touching diff lacks compliant evidence, post this blocking finding\n    (using the actual PR description location):\n    `P1 \xB7 idioms \xB7 PR description \u2014 UI-touching diff lacks compliant, labeled real screenshots \u2192 reviewers cannot verify the rendered change; add before/after Running app evidence, or an eligible Storybook capture, inline in the PR description.`\n    Recommend thumbs-down until the description is fixed. Reviewers verify the\n    implementing agent\'s evidence; they do not produce it themselves.\n  - For a verified copy-only PR, state in the verdict rationale that it is\n    eligible for GitHub native auto-merge. This is an eligibility note, not a\n    substitute for the required checks and reviews that still gate the merge.\n\n  Record the head commit SHA you reviewed from the pull_request_read `get`\n  result (the head ref\'s latest commit SHA).\n\n  Determine whether you have reviewed this PR before. Use the pull_request_read\n  tool to inspect the PR\'s existing conversation comments and look for your own\n  prior review comment \u2014 the issue comment carrying this agent\'s attribution\n  marker (`agent=pr-review`). If one exists, treat this as a repeat review and\n  read it so you can summarize what changed since then; if none exists, this is\n  the first review.\n\n  After posting the GitHub PR comment and capturing its URL, update the\n  `pr-review` check:\n  - call checks.success when the PR comment\'s merge recommendation is\n    "thumbs-up", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  - call checks.failure when the PR comment\'s merge recommendation is\n    "thumbs-down", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  Include the reviewed commit SHA, the recommendation, PR comment URL when\n  available, and the findings that gate the recommendation \u2014 the\n  unresolved P0/P1 findings, plus any unresolved P2 that drove a thumbs-down,\n  or "No blocking issues found." when nothing gates \u2014 in the check result.\n\n  The local checkout is a shallow checkout of the PR head only. Do not assume\n  origin/{{github.pullRequest.baseRef}} or origin/{{github.pullRequest.headRef}}\n  exists locally unless you explicitly fetch it first.\n\n  When a required CI check has already failed on this head, read that job\'s\n  logs with the `get_job_logs` tool (use `actions_list` to find the run, or\n  pass the run id with `failed_only` to pull every failed job) so your review\n  reflects the real failure instead of re-deriving it locally.\n\n  Run targeted tests or typechecks when they would validate a concrete\n  concern. The checkout may not have node_modules installed yet. If a useful\n  validation command needs project dependencies, install only what you need\n  before running it:\n  - for a change contained to one workspace, prefer\n    `npm install --include-workspace-root --workspace <workspace-name>` and\n    then run that workspace\'s targeted test or typecheck command\n  - for root-level, lockfile, shared config, or cross-workspace changes, run\n    `npm install` once at the repository root before validation\n  - if a command fails because `tsx`, `turbo`, `tsc`, `biome`, or another\n    package binary is missing, treat that as missing dependencies, install\n    the relevant dependencies as above, and retry the targeted command once\n\n  Keep commands scoped to the PR unless a broad suite is necessary for the\n  recommendation. Do not report that tests could not run solely because\n  `tsx` or another package binary was absent in the initial shallow checkout;\n  only report inability to run validation after the dependency install also\n  fails or the command needs unavailable external services or secrets.\n\n  Produce exactly one PR comment. Be terse \u2014 the goal is a comment a human\n  can scan in a few seconds.\n  - On a repeat review (a prior review comment of yours exists), a one-line\n    `## What changed since last review` at the very top summarizing the new\n    commits since your prior review and how they change your assessment.\n    Omit this section entirely on the first review.\n  - Lead with the verdict: a `## Recommendation` line that is exactly\n    `thumbs-up` or `thumbs-down`, immediately followed by a one-line\n    rationale. Do not restate what the PR does, do not write a Summary\n    section, and do not praise the work.\n  - A `## Findings` section listing only material findings, most severe\n    first. Omit the section entirely when there are none; instead put\n    `No blocking or notable findings.` in the recommendation rationale.\n    Each finding is one tight line, no sub-bullets:\n    `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n    where dimension is one of correctness, security, data-integrity,\n    operational-risk, missing-tests, or idioms. No diff restatement, no\n    per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets.\n    Drop P3 (nits) from the comment entirely \u2014 they never gate the\n    recommendation and only add noise.\n  - The severity tiers that drive the recommendation (do not list tiers with\n    no findings; never post P3 in the comment):\n    - P0 \u2014 Blocker: breaks the PR\'s core purpose, or a severe correctness,\n      security, or data-integrity failure or otherwise unrecoverable harm\n      (data loss, secret exposure, production outage). Must fix before merge.\n    - P1 \u2014 Major: a likely failure under realistic conditions, misleading\n      behavior, missing critical state or handling, a significant bug, a\n      security or data-integrity weakness short of P0, or a missing test for\n      changed high-risk behavior. Should fix before merge.\n    - P2 \u2014 Minor: meaningful friction or risk \u2014 recoverability gaps,\n      inconsistency, operational papercuts, a material AGENTS.md/docs/idioms.md\n      violation in touched code, or weaker-than-warranted test coverage. Fix\n      or justify.\n    - P3 \u2014 Nit: never posted in the comment; tracked only in the check result\n      if at all.\n  - Append this hidden attribution marker at the end with the environment\n    variables expanded:\n    `<!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->`\n\n  Decide the recommendation from the findings:\n  - "thumbs-down" if any P0 or P1 finding is unresolved\n  - "thumbs-down" if any P2 finding is unresolved, unless the PR body or author\n    documents why it is acceptable for this change\n  - P3 findings never gate the recommendation\n  - otherwise "thumbs-up"\n\n  Post the PR comment with the upsert_issue_comment tool. Pass the repository\n  owner and name from {{github.repository.fullName}} as `owner` and `repo`, PR\n  number {{github.pullRequest.number}} as `issueNumber`, and the full review as\n  `body`. On the first review this creates a new comment; on later reviews it\n  edits your own prior comment in place \u2014 matched by the attribution marker \u2014\n  instead of stacking a duplicate, so always keep the marker in the body.\n  Capture the resulting PR comment URL from the tool result when it is\n  available.\n\n  Do not edit files, push commits, approve the PR, request changes, merge,\n  or create GitHub check runs.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/auto\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/auto\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - upsert_issue_comment\n      # Read-only GitHub Actions tools so the review can read a failed CI\n      # job\'s logs and ground its recommendation in the real failure instead\n      # of re-deriving it locally. The mount already grants `actions: read`.\n      - actions_get\n      - actions_list\n      - get_job_logs\ntriggers:\n  # One reviewer session owns a PR across heads. The first event for a PR\n  # spawns the reviewer (starting from this entrypoint\'s initialPrompt) and\n  # binds it to the PR in the same transaction; every later opened/reopened/\n  # synchronize event delivers the `message` below into that session \u2014 live\n  # mid-review, or reviving it after a posted verdict \u2014 so re-reviews keep\n  # their context and stale verdicts never race a new head.\n  - name: pr-review\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and update that one\n        comment in place with upsert_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the GitHub PR comment, call\n          checks.success with { "name": "pr-review", "summary": "...",\n          "text": "..." } only for a thumbs-up merge recommendation, and call\n          checks.failure with { "name": "pr-review", "summary": "...",\n          "text": "..." } for a thumbs-down merge recommendation. Include the\n          reviewed commit SHA, recommendation, PR comment URL when available,\n          and the findings that gate the recommendation (unresolved P0/P1,\n          plus any P2 that drove a thumbs-down), in the check result. A\n          delivered PR update rolls this check onto the new head and queues\n          it again; call checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: failure\n        completeTimeout:\n          seconds: 1200\n          conclusion: failure\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n'
             }
           ]
+        },
+        {
+          version: "1.9.0",
+          files: [
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            },
+            {
+              path: "fragments/pr-review-slack.yaml",
+              content: 'imports:\n  - ./pr-review.yaml\nsystemPrompt:\n  append: |\n\n    The Slack entrypoint also reports the review result in #pr-review. Treat\n    that Slack reply as a required output for this entrypoint.\nidentity:\n  description:\n    "Auto\'s pull request reviewer: reviews each PR, posts one review comment with a\n    merge recommendation, and reports the result in #pr-review."\ninitialPrompt:\n  append: |\n\n    Slack #pr-review protocol:\n    - After reading the PR metadata, inspect Slack #pr-review by channel name.\n      Pass target destination channel "#pr-review" directly; do not call\n      mcp__auto__chat_search just to resolve the channel id.\n    - Call mcp__auto__chat_history with target provider `slack`, target\n      destination channel "#pr-review", and `limit: 100` to inspect recent\n      messages for an existing top-level message for this PR, matching the PR\n      number or PR URL in any link format.\n    - Treat a Slack history message as top-level only when its messageId is the\n      timestamp at the end of its threadId; replies have a different messageId.\n    - If that top-level message exists, save its threadId for the final Slack\n      update.\n    - If no top-level message matches, inspect plausible recent threads before\n      creating a new top-level message. Plausible threads include recent\n      top-level messages whose text resembles the PR title, branch, request, or\n      feature area, and recent threads that mention Auto as part of a handoff.\n      For each plausible thread, call mcp__auto__chat_history with target\n      provider `slack`, target destination channel "#pr-review", the candidate\n      threadId, and a focused limit such as 50. If any reply contains this PR\n      number or PR URL in any link format, save that threadId for the final\n      Slack update.\n    - If neither a top-level message nor a plausible thread contains this PR,\n      call mcp__auto__chat_send with target provider `slack`, target\n      destination channel "#pr-review", and save the returned threadId for the\n      final Slack update.\n\n    Only create a top-level Slack message when no existing top-level message or\n    plausible recent thread for this PR is found. Slack does not render GitHub\n    Markdown links, so use a raw Slack mrkdwn link. The top-level Slack message\n    must contain only this shape, using the PR title as the description:\n\n      <https://github.com/{{github.repository.fullName}}/pull/{{github.pullRequest.number}}|PR #{{github.pullRequest.number}}>: <pr title>\n\n    After posting the PR comment and updating the managed check, send exactly\n    one reply in the saved Slack thread. Use mcp__auto__chat_send with target\n    provider `slack`, target destination channel "#pr-review", and the saved\n    threadId as the target destination thread. Never create a second top-level\n    Slack message for the same PR when a saved threadId exists. Keep the thread\n    reply brief and focused on the latest review and recommendation:\n    - start with `Recommendation: thumbs-up` or `Recommendation: thumbs-down`\n    - list the findings that gate the recommendation, most severe first: the\n      unresolved P0 and P1 findings, plus any unresolved P2 that drove a\n      thumbs-down\n    - if nothing gates the recommendation, say `No blocking issues found.`\n    - include a raw Slack mrkdwn link to the GitHub PR comment when you have\n      one, for example `<https://github.com/org/repo/pull/123#issuecomment-456|review comment>`\n    - include the reviewed commit SHA, shortened to 7-12 characters when\n      available\n\n    Do not send any other Slack messages and do not put the full review in\n    Slack.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      # GitHub Sync injects githubConnection/repoFullName context variables, not\n      # Slack. Keep the conventional default connection name so bare Slack\n      # entrypoint imports continue to work for default Slack installs.\n      connection: slack\n'
+            },
+            {
+              path: "fragments/pr-review.yaml",
+              content: '# 1.8.0: exempts tightly defined copy-only diffs from screenshot evidence,\n# verifies the required PR-description claim against the diff, blocks false\n# claims as P1 idioms findings, and notes verified copy-only PRs as eligible\n# for GitHub native auto-merge. Otherwise byte-identical to 1.7.0.\n#\n# 1.7.0: enforces the UI screenshot evidence idiom. A UI-touching diff must\n# include compliant, labeled screenshots from a real running app or a\n# Storybook story mounting the production component in the PR description;\n# missing or non-compliant evidence is a blocking P1 idioms finding. Otherwise\n# byte-identical to 1.6.0.\n#\n# 1.6.0: drastically shorter review comments. The comment now leads with the\n# verdict + a one-line rationale, then lists only material findings as tight\n# one-liners (file:line \u2014 what\'s wrong \u2192 why it matters). Drops the Summary\n# section (no restating the PR description), the per-finding\n# Impact/Source/Verification/Fix sub-bullets, the separate Idioms gate line,\n# and P3 nits from the comment. Mechanics are unchanged: fold routing, the\n# managed check conclusion (thumbs-up \u2192 success, thumbs-down \u2192 failure), the\n# "What changed since last review" section on re-review, the\n# upsert_issue_comment in-place edit, the attribution marker, and the Slack\n# verdict flow in the -slack entrypoint. Grant surface (tools/mounts) is\n# byte-identical to 1.5.0; only systemPrompt/initialPrompt change.\nimports:\n  - ./environments/agent-runtime.yaml\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nlabels:\n  purpose: pr-review\nsession:\n  archiveAfterInactive:\n    seconds: 86400\nsystemPrompt: |\n  You are a code-analysis agent for Auto. Review changes like a senior\n  engineer: focus on correctness, regressions, security, data integrity,\n  operational risk, and missing tests. Be terse \u2014 reviewers scan, they do not\n  read. Ground every finding in the diff, lead with the highest-impact issues,\n  and verify concrete concerns with targeted tests or typechecks.\n\n  Also enforce the repository idioms documented in AGENTS.md and\n  docs/idioms.md. Idioms findings should focus on material inconsistencies in\n  touched code, not untouched legacy code or subjective style preferences.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude a check with it), the managed check has been rolled\n  onto the new head, and you re-begin the check and re-review against the\n  pull request\'s current head. Keep exactly one current verdict per pull\n  request at all times.\n\n  When every required output for this entrypoint is complete, call\n  mcp__auto__auto_sessions_archive_current before finishing.\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description:\n    "Auto\'s pull request reviewer: reviews each PR and posts one review comment with a\n    merge recommendation."\ndisplayTitle: "Review PR #{{github.pullRequest.number}}: {{github.pullRequest.title}}"\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in {{github.repository.fullName}}.\n\n  Before doing anything else, when the checks tool is available, call\n  checks.begin with `{ "name": "pr-review" }`. This must happen before\n  inspecting PR metadata or the diff.\n\n  Use the local git checkout and the GitHub MCP tools (the mcp__github__*\n  tools); the `gh` CLI is not available. Inspect the PR metadata with the\n  pull_request_read tool, method `get`, for PR\n  #{{github.pullRequest.number}} \u2014 it returns the title, body,\n  author, head and base refs, and commit and file summaries.\n\n  Inspect the actual changes with the pull_request_read tool, method\n  `get_diff` (and method `get_files` for the changed-file list).\n\n  Read AGENTS.md and docs/idioms.md before forming your recommendation. Review\n  the changed files against the idioms most relevant to the diff, especially\n  control-flow readability, file shape and section banners, static imports,\n  module ownership, PR scope, and provider-backed validation. Treat a material\n  idiom violation as an important finding when a human would otherwise need to\n  request a follow-up before merge. Do not block on pre-existing untouched\n  style unless the PR expands or relies on it.\n\n  Enforce the UI screenshot evidence idiom as a blocking review gate:\n  - Treat a diff as UI-touching when it changes user-visible pages, layouts,\n    components, styles, assets, or Storybook stories under `apps/web`. A\n    server-only `apps/web` change is exempt only when the PR description\n    explicitly explains why it has no rendered effect.\n  - A diff is copy-only only when every changed production-code token is a\n    user-facing string literal used as label or copy text, with no layout,\n    style, structure, logic, or attribute changes. Test or Storybook assertion\n    updates are allowed only when they update the same strings. Any other\n    changed token disqualifies the diff.\n  - Skip screenshot evidence only when the PR description states exactly\n    `Copy-only change \u2014 evidence exempt per idiom` and your inspection of the\n    full diff verifies that tight definition. Never infer the exemption from a\n    PR title, labels, or a mostly-copy diff.\n  - If the PR claims the exemption but changes anything beyond those string\n    literals and matching assertion strings, post this blocking finding:\n    `P1 \xB7 idioms \xB7 PR description \u2014 copy-only evidence exemption claim does not match the diff \u2192 the PR touches non-copy code; remove the claim and add compliant UI screenshots, or split the non-copy changes into another PR.`\n    Recommend thumbs-down until the claim and evidence match the diff.\n  - Inspect the PR description itself for inline embedded images when the\n    verified copy-only exemption does not apply. Links to an external gallery,\n    committed evidence files that are not embedded, written descriptions,\n    mockups, facsimiles, and hand-built reproductions do not satisfy the gate.\n  - Each screenshot must be labeled `Running app` or `Storybook` and identify\n    the route, flow step, viewport, or component state. Page-level, navigation,\n    responsive, and multi-component flow changes require the full running app\n    from local dev or the PR\'s Vercel preview. Storybook is acceptable only for\n    isolated component states when the story mounts the production component.\n  - Modified UI requires comparable before and after screenshots. New UI may\n    say `Before: N/A \u2014 new UI` and provide the after screenshot.\n  - If a UI-touching diff lacks compliant evidence, post this blocking finding\n    (using the actual PR description location):\n    `P1 \xB7 idioms \xB7 PR description \u2014 UI-touching diff lacks compliant, labeled real screenshots \u2192 reviewers cannot verify the rendered change; add before/after Running app evidence, or an eligible Storybook capture, inline in the PR description.`\n    Recommend thumbs-down until the description is fixed. Reviewers verify the\n    implementing agent\'s evidence; they do not produce it themselves.\n  - For a verified copy-only PR, state in the verdict rationale that it is\n    eligible for GitHub native auto-merge. This is an eligibility note, not a\n    substitute for the required checks and reviews that still gate the merge.\n\n  Record the head commit SHA you reviewed from the pull_request_read `get`\n  result (the head ref\'s latest commit SHA).\n\n  Determine whether you have reviewed this PR before. Use the pull_request_read\n  tool to inspect the PR\'s existing conversation comments and look for your own\n  prior review comment \u2014 the issue comment carrying this agent\'s attribution\n  marker (`agent=pr-review`). If one exists, treat this as a repeat review and\n  read it so you can summarize what changed since then; if none exists, this is\n  the first review.\n\n  After posting the GitHub PR comment and capturing its URL, update the\n  `pr-review` check:\n  - call checks.success when the PR comment\'s merge recommendation is\n    "thumbs-up", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  - call checks.failure when the PR comment\'s merge recommendation is\n    "thumbs-down", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  Include the reviewed commit SHA, the recommendation, PR comment URL when\n  available, and the findings that gate the recommendation \u2014 the\n  unresolved P0/P1 findings, plus any unresolved P2 that drove a thumbs-down,\n  or "No blocking issues found." when nothing gates \u2014 in the check result.\n\n  The local checkout is a shallow checkout of the PR head only. Do not assume\n  origin/{{github.pullRequest.baseRef}} or origin/{{github.pullRequest.headRef}}\n  exists locally unless you explicitly fetch it first.\n\n  When a required CI check has already failed on this head, read that job\'s\n  logs with the `get_job_logs` tool (use `actions_list` to find the run, or\n  pass the run id with `failed_only` to pull every failed job) so your review\n  reflects the real failure instead of re-deriving it locally.\n\n  Run targeted tests or typechecks when they would validate a concrete\n  concern. The checkout may not have node_modules installed yet. If a useful\n  validation command needs project dependencies, install only what you need\n  before running it:\n  - for a change contained to one workspace, prefer\n    `npm install --include-workspace-root --workspace <workspace-name>` and\n    then run that workspace\'s targeted test or typecheck command\n  - for root-level, lockfile, shared config, or cross-workspace changes, run\n    `npm install` once at the repository root before validation\n  - if a command fails because `tsx`, `turbo`, `tsc`, `biome`, or another\n    package binary is missing, treat that as missing dependencies, install\n    the relevant dependencies as above, and retry the targeted command once\n\n  Keep commands scoped to the PR unless a broad suite is necessary for the\n  recommendation. Do not report that tests could not run solely because\n  `tsx` or another package binary was absent in the initial shallow checkout;\n  only report inability to run validation after the dependency install also\n  fails or the command needs unavailable external services or secrets.\n\n  Produce exactly one PR comment. Be terse \u2014 the goal is a comment a human\n  can scan in a few seconds.\n  - On a repeat review (a prior review comment of yours exists), a one-line\n    `## What changed since last review` at the very top summarizing the new\n    commits since your prior review and how they change your assessment.\n    Omit this section entirely on the first review.\n  - Lead with the verdict: a `## Recommendation` line that is exactly\n    `thumbs-up` or `thumbs-down`, immediately followed by a one-line\n    rationale. Do not restate what the PR does, do not write a Summary\n    section, and do not praise the work.\n  - A `## Findings` section listing only material findings, most severe\n    first. Omit the section entirely when there are none; instead put\n    `No blocking or notable findings.` in the recommendation rationale.\n    Each finding is one tight line, no sub-bullets:\n    `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n    where dimension is one of correctness, security, data-integrity,\n    operational-risk, missing-tests, or idioms. No diff restatement, no\n    per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets.\n    Drop P3 (nits) from the comment entirely \u2014 they never gate the\n    recommendation and only add noise.\n  - The severity tiers that drive the recommendation (do not list tiers with\n    no findings; never post P3 in the comment):\n    - P0 \u2014 Blocker: breaks the PR\'s core purpose, or a severe correctness,\n      security, or data-integrity failure or otherwise unrecoverable harm\n      (data loss, secret exposure, production outage). Must fix before merge.\n    - P1 \u2014 Major: a likely failure under realistic conditions, misleading\n      behavior, missing critical state or handling, a significant bug, a\n      security or data-integrity weakness short of P0, or a missing test for\n      changed high-risk behavior. Should fix before merge.\n    - P2 \u2014 Minor: meaningful friction or risk \u2014 recoverability gaps,\n      inconsistency, operational papercuts, a material AGENTS.md/docs/idioms.md\n      violation in touched code, or weaker-than-warranted test coverage. Fix\n      or justify.\n    - P3 \u2014 Nit: never posted in the comment; tracked only in the check result\n      if at all.\n  - Append this hidden attribution marker at the end with the environment\n    variables expanded:\n    `<!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->`\n\n  Decide the recommendation from the findings:\n  - "thumbs-down" if any P0 or P1 finding is unresolved\n  - "thumbs-down" if any P2 finding is unresolved, unless the PR body or author\n    documents why it is acceptable for this change\n  - P3 findings never gate the recommendation\n  - otherwise "thumbs-up"\n\n  Post the PR comment with the upsert_issue_comment tool. Pass the repository\n  owner and name from {{github.repository.fullName}} as `owner` and `repo`, PR\n  number {{github.pullRequest.number}} as `issueNumber`, and the full review as\n  `body`. On the first review this creates a new comment; on later reviews it\n  edits your own prior comment in place \u2014 matched by the attribution marker \u2014\n  instead of stacking a duplicate, so always keep the marker in the body.\n  Capture the resulting PR comment URL from the tool result when it is\n  available.\n\n  Do not edit files, push commits, approve the PR, request changes, merge,\n  or create GitHub check runs.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/auto\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/auto\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - upsert_issue_comment\n      # Read-only GitHub Actions tools so the review can read a failed CI\n      # job\'s logs and ground its recommendation in the real failure instead\n      # of re-deriving it locally. The mount already grants `actions: read`.\n      - actions_get\n      - actions_list\n      - get_job_logs\ntriggers:\n  # One reviewer session owns a PR across heads. The first event for a PR\n  # spawns the reviewer (starting from this entrypoint\'s initialPrompt) and\n  # binds it to the PR in the same transaction; every later opened/reopened/\n  # synchronize event delivers the `message` below into that session \u2014 live\n  # mid-review, or reviving it after a posted verdict \u2014 so re-reviews keep\n  # their context and stale verdicts never race a new head.\n  - name: pr-review\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and update that one\n        comment in place with upsert_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the GitHub PR comment, call\n          checks.success with { "name": "pr-review", "summary": "...",\n          "text": "..." } only for a thumbs-up merge recommendation, and call\n          checks.failure with { "name": "pr-review", "summary": "...",\n          "text": "..." } for a thumbs-down merge recommendation. Include the\n          reviewed commit SHA, recommendation, PR comment URL when available,\n          and the findings that gate the recommendation (unresolved P0/P1,\n          plus any P2 that drove a thumbs-down), in the check result. A\n          delivered PR update rolls this check onto the new head and queues\n          it again; call checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: skipped\n        completeTimeout:\n          seconds: 1200\n          conclusion: skipped\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n'
+            }
+          ]
+        },
+        {
+          version: "1.10.0",
+          files: [
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            },
+            {
+              path: "fragments/pr-review-compat.yaml",
+              content: '# 1.8.0: exempts tightly defined copy-only diffs from screenshot evidence,\n# verifies the required PR-description claim against the diff, blocks false\n# claims as P1 idioms findings, and notes verified copy-only PRs as eligible\n# for GitHub native auto-merge. Otherwise byte-identical to 1.7.0.\n#\n# 1.7.0: enforces the UI screenshot evidence idiom. A UI-touching diff must\n# include compliant, labeled screenshots from a real running app or a\n# Storybook story mounting the production component in the PR description;\n# missing or non-compliant evidence is a blocking P1 idioms finding. Otherwise\n# byte-identical to 1.6.0.\n#\n# 1.6.0: drastically shorter review comments. The comment now leads with the\n# verdict + a one-line rationale, then lists only material findings as tight\n# one-liners (file:line \u2014 what\'s wrong \u2192 why it matters). Drops the Summary\n# section (no restating the PR description), the per-finding\n# Impact/Source/Verification/Fix sub-bullets, the separate Idioms gate line,\n# and P3 nits from the comment. Mechanics are unchanged: fold routing, the\n# managed check conclusion (thumbs-up \u2192 success, thumbs-down \u2192 failure), the\n# "What changed since last review" section on re-review, the\n# upsert_issue_comment in-place edit, the attribution marker, and the Slack\n# verdict flow in the -slack entrypoint. Grant surface (tools/mounts) is\n# byte-identical to 1.5.0; only systemPrompt/initialPrompt change.\nimports:\n  - ./environments/agent-runtime.yaml\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nlabels:\n  purpose: pr-review\nsession:\n  archiveAfterInactive:\n    seconds: 86400\nsystemPrompt: |\n  You are a code-analysis agent for Auto. Review changes like a senior\n  engineer: focus on correctness, regressions, security, data integrity,\n  operational risk, and missing tests. Be terse \u2014 reviewers scan, they do not\n  read. Ground every finding in the diff, lead with the highest-impact issues,\n  and verify concrete concerns with targeted tests or typechecks.\n\n  Also enforce the repository idioms documented in AGENTS.md and\n  docs/idioms.md. Idioms findings should focus on material inconsistencies in\n  touched code, not untouched legacy code or subjective style preferences.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude a check with it), the managed check has been rolled\n  onto the new head, and you re-begin the check and re-review against the\n  pull request\'s current head. Keep exactly one current verdict per pull\n  request at all times.\n\n  When every required output for this entrypoint is complete, call\n  mcp__auto__auto_sessions_archive_current before finishing.\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description:\n    "Auto\'s pull request reviewer: reviews each PR and posts one review comment with a\n    merge recommendation."\ndisplayTitle: "Review PR #{{github.pullRequest.number}}: {{github.pullRequest.title}}"\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in {{github.repository.fullName}}.\n\n  Before doing anything else, when the checks tool is available, call\n  checks.begin with `{ "name": "pr-review" }`. This must happen before\n  inspecting PR metadata or the diff.\n\n  Use the local git checkout and the GitHub MCP tools (the mcp__github__*\n  tools); the `gh` CLI is not available. Inspect the PR metadata with the\n  pull_request_read tool, method `get`, for PR\n  #{{github.pullRequest.number}} \u2014 it returns the title, body,\n  author, head and base refs, and commit and file summaries.\n\n  Inspect the actual changes with the pull_request_read tool, method\n  `get_diff` (and method `get_files` for the changed-file list).\n\n  Read AGENTS.md and docs/idioms.md before forming your recommendation. Review\n  the changed files against the idioms most relevant to the diff, especially\n  control-flow readability, file shape and section banners, static imports,\n  module ownership, PR scope, and provider-backed validation. Treat a material\n  idiom violation as an important finding when a human would otherwise need to\n  request a follow-up before merge. Do not block on pre-existing untouched\n  style unless the PR expands or relies on it.\n\n  Enforce the UI screenshot evidence idiom as a blocking review gate:\n  - Treat a diff as UI-touching when it changes user-visible pages, layouts,\n    components, styles, assets, or Storybook stories under `apps/web`. A\n    server-only `apps/web` change is exempt only when the PR description\n    explicitly explains why it has no rendered effect.\n  - A diff is copy-only only when every changed production-code token is a\n    user-facing string literal used as label or copy text, with no layout,\n    style, structure, logic, or attribute changes. Test or Storybook assertion\n    updates are allowed only when they update the same strings. Any other\n    changed token disqualifies the diff.\n  - Skip screenshot evidence only when the PR description states exactly\n    `Copy-only change \u2014 evidence exempt per idiom` and your inspection of the\n    full diff verifies that tight definition. Never infer the exemption from a\n    PR title, labels, or a mostly-copy diff.\n  - If the PR claims the exemption but changes anything beyond those string\n    literals and matching assertion strings, post this blocking finding:\n    `P1 \xB7 idioms \xB7 PR description \u2014 copy-only evidence exemption claim does not match the diff \u2192 the PR touches non-copy code; remove the claim and add compliant UI screenshots, or split the non-copy changes into another PR.`\n    Recommend thumbs-down until the claim and evidence match the diff.\n  - Inspect the PR description itself for inline embedded images when the\n    verified copy-only exemption does not apply. Links to an external gallery,\n    committed evidence files that are not embedded, written descriptions,\n    mockups, facsimiles, and hand-built reproductions do not satisfy the gate.\n  - Each screenshot must be labeled `Running app` or `Storybook` and identify\n    the route, flow step, viewport, or component state. Page-level, navigation,\n    responsive, and multi-component flow changes require the full running app\n    from local dev or the PR\'s Vercel preview. Storybook is acceptable only for\n    isolated component states when the story mounts the production component.\n  - Modified UI requires comparable before and after screenshots. New UI may\n    say `Before: N/A \u2014 new UI` and provide the after screenshot.\n  - If a UI-touching diff lacks compliant evidence, post this blocking finding\n    (using the actual PR description location):\n    `P1 \xB7 idioms \xB7 PR description \u2014 UI-touching diff lacks compliant, labeled real screenshots \u2192 reviewers cannot verify the rendered change; add before/after Running app evidence, or an eligible Storybook capture, inline in the PR description.`\n    Recommend thumbs-down until the description is fixed. Reviewers verify the\n    implementing agent\'s evidence; they do not produce it themselves.\n  - For a verified copy-only PR, state in the verdict rationale that it is\n    eligible for GitHub native auto-merge. This is an eligibility note, not a\n    substitute for the required checks and reviews that still gate the merge.\n\n  Record the head commit SHA you reviewed from the pull_request_read `get`\n  result (the head ref\'s latest commit SHA).\n\n  Determine whether you have reviewed this PR before. Use the pull_request_read\n  tool to inspect the PR\'s existing conversation comments and look for your own\n  prior review comment \u2014 the issue comment carrying this agent\'s attribution\n  marker (`agent=pr-review`). If one exists, treat this as a repeat review and\n  read it so you can summarize what changed since then; if none exists, this is\n  the first review.\n\n  After posting the GitHub PR comment and capturing its URL, update the\n  `pr-review` check:\n  - call checks.success when the PR comment\'s merge recommendation is\n    "thumbs-up", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  - call checks.failure when the PR comment\'s merge recommendation is\n    "thumbs-down", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  Include the reviewed commit SHA, the recommendation, PR comment URL when\n  available, and the findings that gate the recommendation \u2014 the\n  unresolved P0/P1 findings, plus any unresolved P2 that drove a thumbs-down,\n  or "No blocking issues found." when nothing gates \u2014 in the check result.\n\n  The local checkout is a shallow checkout of the PR head only. Do not assume\n  origin/{{github.pullRequest.baseRef}} or origin/{{github.pullRequest.headRef}}\n  exists locally unless you explicitly fetch it first.\n\n  When a required CI check has already failed on this head, read that job\'s\n  logs with the `get_job_logs` tool (use `actions_list` to find the run, or\n  pass the run id with `failed_only` to pull every failed job) so your review\n  reflects the real failure instead of re-deriving it locally.\n\n  Run targeted tests or typechecks when they would validate a concrete\n  concern. The checkout may not have node_modules installed yet. If a useful\n  validation command needs project dependencies, install only what you need\n  before running it:\n  - for a change contained to one workspace, prefer\n    `npm install --include-workspace-root --workspace <workspace-name>` and\n    then run that workspace\'s targeted test or typecheck command\n  - for root-level, lockfile, shared config, or cross-workspace changes, run\n    `npm install` once at the repository root before validation\n  - if a command fails because `tsx`, `turbo`, `tsc`, `biome`, or another\n    package binary is missing, treat that as missing dependencies, install\n    the relevant dependencies as above, and retry the targeted command once\n\n  Keep commands scoped to the PR unless a broad suite is necessary for the\n  recommendation. Do not report that tests could not run solely because\n  `tsx` or another package binary was absent in the initial shallow checkout;\n  only report inability to run validation after the dependency install also\n  fails or the command needs unavailable external services or secrets.\n\n  Produce exactly one PR comment. Be terse \u2014 the goal is a comment a human\n  can scan in a few seconds.\n  - On a repeat review (a prior review comment of yours exists), a one-line\n    `## What changed since last review` at the very top summarizing the new\n    commits since your prior review and how they change your assessment.\n    Omit this section entirely on the first review.\n  - Lead with the verdict: a `## Recommendation` line that is exactly\n    `thumbs-up` or `thumbs-down`, immediately followed by a one-line\n    rationale. Do not restate what the PR does, do not write a Summary\n    section, and do not praise the work.\n  - A `## Findings` section listing only material findings, most severe\n    first. Omit the section entirely when there are none; instead put\n    `No blocking or notable findings.` in the recommendation rationale.\n    Each finding is one tight line, no sub-bullets:\n    `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n    where dimension is one of correctness, security, data-integrity,\n    operational-risk, missing-tests, or idioms. No diff restatement, no\n    per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets.\n    Drop P3 (nits) from the comment entirely \u2014 they never gate the\n    recommendation and only add noise.\n  - The severity tiers that drive the recommendation (do not list tiers with\n    no findings; never post P3 in the comment):\n    - P0 \u2014 Blocker: breaks the PR\'s core purpose, or a severe correctness,\n      security, or data-integrity failure or otherwise unrecoverable harm\n      (data loss, secret exposure, production outage). Must fix before merge.\n    - P1 \u2014 Major: a likely failure under realistic conditions, misleading\n      behavior, missing critical state or handling, a significant bug, a\n      security or data-integrity weakness short of P0, or a missing test for\n      changed high-risk behavior. Should fix before merge.\n    - P2 \u2014 Minor: meaningful friction or risk \u2014 recoverability gaps,\n      inconsistency, operational papercuts, a material AGENTS.md/docs/idioms.md\n      violation in touched code, or weaker-than-warranted test coverage. Fix\n      or justify.\n    - P3 \u2014 Nit: never posted in the comment; tracked only in the check result\n      if at all.\n  - Append this hidden attribution marker at the end with the environment\n    variables expanded:\n    `<!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->`\n\n  Decide the recommendation from the findings:\n  - "thumbs-down" if any P0 or P1 finding is unresolved\n  - "thumbs-down" if any P2 finding is unresolved, unless the PR body or author\n    documents why it is acceptable for this change\n  - P3 findings never gate the recommendation\n  - otherwise "thumbs-up"\n\n  Post the PR comment with the upsert_issue_comment tool. Pass the repository\n  owner and name from {{github.repository.fullName}} as `owner` and `repo`, PR\n  number {{github.pullRequest.number}} as `issueNumber`, and the full review as\n  `body`. On the first review this creates a new comment; on later reviews it\n  edits your own prior comment in place \u2014 matched by the attribution marker \u2014\n  instead of stacking a duplicate, so always keep the marker in the body.\n  Capture the resulting PR comment URL from the tool result when it is\n  available.\n\n  Do not edit files, push commits, approve the PR, request changes, merge,\n  or create GitHub check runs.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/auto\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/auto\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - upsert_issue_comment\n      # Read-only GitHub Actions tools so the review can read a failed CI\n      # job\'s logs and ground its recommendation in the real failure instead\n      # of re-deriving it locally. The mount already grants `actions: read`.\n      - actions_get\n      - actions_list\n      - get_job_logs\ntriggers:\n  # One reviewer session owns a PR across heads. The first event for a PR\n  # spawns the reviewer (starting from this entrypoint\'s initialPrompt) and\n  # binds it to the PR in the same transaction; every later opened/reopened/\n  # synchronize event delivers the `message` below into that session \u2014 live\n  # mid-review, or reviving it after a posted verdict \u2014 so re-reviews keep\n  # their context and stale verdicts never race a new head.\n  - name: pr-review\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and update that one\n        comment in place with upsert_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the GitHub PR comment, call\n          checks.success with { "name": "pr-review", "summary": "...",\n          "text": "..." } only for a thumbs-up merge recommendation, and call\n          checks.failure with { "name": "pr-review", "summary": "...",\n          "text": "..." } for a thumbs-down merge recommendation. Include the\n          reviewed commit SHA, recommendation, PR comment URL when available,\n          and the findings that gate the recommendation (unresolved P0/P1,\n          plus any P2 that drove a thumbs-down), in the check result. A\n          delivered PR update rolls this check onto the new head and queues\n          it again; call checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: skipped\n        completeTimeout:\n          seconds: 1200\n          conclusion: skipped\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n'
+            },
+            {
+              path: "fragments/pr-review-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# fragments/pr-review.yaml, whose #pr-review verdict reporting uses the\n# standard optional `slack` connection. This subpath preserves the prior\n# Slack-required behavior through at least the next minor version.\nimports:\n  - ./pr-review-compat.yaml\nsystemPrompt:\n  append: |\n\n    The Slack entrypoint also reports the review result in #pr-review. Treat\n    that Slack reply as a required output for this entrypoint.\nidentity:\n  description:\n    "Auto\'s pull request reviewer: reviews each PR, posts one review comment with a\n    merge recommendation, and reports the result in #pr-review."\ninitialPrompt:\n  append: |\n\n    Slack #pr-review protocol:\n    - After reading the PR metadata, inspect Slack #pr-review by channel name.\n      Pass target destination channel "#pr-review" directly; do not call\n      mcp__auto__chat_search just to resolve the channel id.\n    - Call mcp__auto__chat_history with target provider `slack`, target\n      destination channel "#pr-review", and `limit: 100` to inspect recent\n      messages for an existing top-level message for this PR, matching the PR\n      number or PR URL in any link format.\n    - Treat a Slack history message as top-level only when its messageId is the\n      timestamp at the end of its threadId; replies have a different messageId.\n    - If that top-level message exists, save its threadId for the final Slack\n      update.\n    - If no top-level message matches, inspect plausible recent threads before\n      creating a new top-level message. Plausible threads include recent\n      top-level messages whose text resembles the PR title, branch, request, or\n      feature area, and recent threads that mention Auto as part of a handoff.\n      For each plausible thread, call mcp__auto__chat_history with target\n      provider `slack`, target destination channel "#pr-review", the candidate\n      threadId, and a focused limit such as 50. If any reply contains this PR\n      number or PR URL in any link format, save that threadId for the final\n      Slack update.\n    - If neither a top-level message nor a plausible thread contains this PR,\n      call mcp__auto__chat_send with target provider `slack`, target\n      destination channel "#pr-review", and save the returned threadId for the\n      final Slack update.\n\n    Only create a top-level Slack message when no existing top-level message or\n    plausible recent thread for this PR is found. Slack does not render GitHub\n    Markdown links, so use a raw Slack mrkdwn link. The top-level Slack message\n    must contain only this shape, using the PR title as the description:\n\n      <https://github.com/{{github.repository.fullName}}/pull/{{github.pullRequest.number}}|PR #{{github.pullRequest.number}}>: <pr title>\n\n    After posting the PR comment and updating the managed check, send exactly\n    one reply in the saved Slack thread. Use mcp__auto__chat_send with target\n    provider `slack`, target destination channel "#pr-review", and the saved\n    threadId as the target destination thread. Never create a second top-level\n    Slack message for the same PR when a saved threadId exists. Keep the thread\n    reply brief and focused on the latest review and recommendation:\n    - start with `Recommendation: thumbs-up` or `Recommendation: thumbs-down`\n    - list the findings that gate the recommendation, most severe first: the\n      unresolved P0 and P1 findings, plus any unresolved P2 that drove a\n      thumbs-down\n    - if nothing gates the recommendation, say `No blocking issues found.`\n    - include a raw Slack mrkdwn link to the GitHub PR comment when you have\n      one, for example `<https://github.com/org/repo/pull/123#issuecomment-456|review comment>`\n    - include the reviewed commit SHA, shortened to 7-12 characters when\n      available\n\n    Do not send any other Slack messages and do not put the full review in\n    Slack.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      # GitHub Sync injects githubConnection/repoFullName context variables, not\n      # Slack. Keep the conventional default connection name so bare Slack\n      # entrypoint imports continue to work for default Slack installs.\n      connection: slack\n      optional: false\n'
+            },
+            {
+              path: "fragments/pr-review.yaml",
+              content: '# 1.10.0: folds optional zero-configuration Slack verdict reporting into the\n# base entrypoint while preserving 1.9.0\'s skipped-watchdog infrastructure doctrine.\n# Review doctrine and explicit agent verdict behavior are unchanged.\n#\n# 1.8.0: exempts tightly defined copy-only diffs from screenshot evidence,\n# verifies the required PR-description claim against the diff, blocks false\n# claims as P1 idioms findings, and notes verified copy-only PRs as eligible\n# for GitHub native auto-merge. Otherwise byte-identical to 1.7.0.\n#\n# 1.7.0: enforces the UI screenshot evidence idiom. A UI-touching diff must\n# include compliant, labeled screenshots from a real running app or a\n# Storybook story mounting the production component in the PR description;\n# missing or non-compliant evidence is a blocking P1 idioms finding. Otherwise\n# byte-identical to 1.6.0.\n#\n# 1.6.0: drastically shorter review comments. The comment now leads with the\n# verdict + a one-line rationale, then lists only material findings as tight\n# one-liners (file:line \u2014 what\'s wrong \u2192 why it matters). Drops the Summary\n# section (no restating the PR description), the per-finding\n# Impact/Source/Verification/Fix sub-bullets, the separate Idioms gate line,\n# and P3 nits from the comment. Mechanics are unchanged: fold routing, the\n# managed check conclusion (thumbs-up \u2192 success, thumbs-down \u2192 failure), the\n# "What changed since last review" section on re-review, the\n# upsert_issue_comment in-place edit, the attribution marker, and the Slack\n# verdict flow in the -slack entrypoint. Grant surface (tools/mounts) is\n# byte-identical to 1.5.0; only systemPrompt/initialPrompt change.\nimports:\n  - ./environments/agent-runtime.yaml\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nlabels:\n  purpose: pr-review\nsession:\n  archiveAfterInactive:\n    seconds: 86400\nsystemPrompt: |\n  You are a code-analysis agent for Auto. Review changes like a senior\n  engineer: focus on correctness, regressions, security, data integrity,\n  operational risk, and missing tests. Be terse \u2014 reviewers scan, they do not\n  read. Ground every finding in the diff, lead with the highest-impact issues,\n  and verify concrete concerns with targeted tests or typechecks.\n\n  Also enforce the repository idioms documented in AGENTS.md and\n  docs/idioms.md. Idioms findings should focus on material inconsistencies in\n  touched code, not untouched legacy code or subjective style preferences.\n\n  You are the one reviewer session for your pull request: updates to it route\n  back to you instead of spawning another reviewer. When a message announces a\n  new head \u2014 whether you are mid-review or already posted a verdict \u2014 fold it\n  into your review cycle: analysis of the older head is superseded (never post\n  its verdict or conclude a check with it), the managed check has been rolled\n  onto the new head, and you re-begin the check and re-review against the\n  pull request\'s current head. Keep exactly one current verdict per pull\n  request at all times.\n\n  Slack verdict reporting is optional and uses the standard `slack` connection\n  and #pr-review channel. When the chat tool is available, follow the Slack\n  protocol in your run instructions after posting the PR comment and updating\n  the managed check. When the tool is unavailable, skip Slack without treating\n  it as a review failure; the GitHub comment and managed check remain complete.\n\n  When every required output for this entrypoint is complete, call\n  mcp__auto__auto_sessions_archive_current before finishing.\nidentity:\n  displayName: PR Review\n  username: pr-review\n  avatar:\n    asset: .auto/assets/pr-reviewer.png\n    sha256: 8b901940476d9f4b43d944ce6e6f0166c2a57eb33e03464275f2f2599e27a254\n  description:\n    "Reviews each pull request, posts one merge recommendation, and optionally\n    reports the verdict in #pr-review."\ndisplayTitle: "Review PR #{{github.pullRequest.number}}: {{github.pullRequest.title}}"\ninitialPrompt: |\n  Review GitHub pull request #{{github.pullRequest.number}} in {{github.repository.fullName}}.\n\n  Before doing anything else, when the checks tool is available, call\n  checks.begin with `{ "name": "pr-review" }`. This must happen before\n  inspecting PR metadata or the diff.\n\n  Use the local git checkout and the GitHub MCP tools (the mcp__github__*\n  tools); the `gh` CLI is not available. Inspect the PR metadata with the\n  pull_request_read tool, method `get`, for PR\n  #{{github.pullRequest.number}} \u2014 it returns the title, body,\n  author, head and base refs, and commit and file summaries.\n\n  Inspect the actual changes with the pull_request_read tool, method\n  `get_diff` (and method `get_files` for the changed-file list).\n\n  Read AGENTS.md and docs/idioms.md before forming your recommendation. Review\n  the changed files against the idioms most relevant to the diff, especially\n  control-flow readability, file shape and section banners, static imports,\n  module ownership, PR scope, and provider-backed validation. Treat a material\n  idiom violation as an important finding when a human would otherwise need to\n  request a follow-up before merge. Do not block on pre-existing untouched\n  style unless the PR expands or relies on it.\n\n  Enforce the UI screenshot evidence idiom as a blocking review gate:\n  - Treat a diff as UI-touching when it changes user-visible pages, layouts,\n    components, styles, assets, or Storybook stories under `apps/web`. A\n    server-only `apps/web` change is exempt only when the PR description\n    explicitly explains why it has no rendered effect.\n  - A diff is copy-only only when every changed production-code token is a\n    user-facing string literal used as label or copy text, with no layout,\n    style, structure, logic, or attribute changes. Test or Storybook assertion\n    updates are allowed only when they update the same strings. Any other\n    changed token disqualifies the diff.\n  - Skip screenshot evidence only when the PR description states exactly\n    `Copy-only change \u2014 evidence exempt per idiom` and your inspection of the\n    full diff verifies that tight definition. Never infer the exemption from a\n    PR title, labels, or a mostly-copy diff.\n  - If the PR claims the exemption but changes anything beyond those string\n    literals and matching assertion strings, post this blocking finding:\n    `P1 \xB7 idioms \xB7 PR description \u2014 copy-only evidence exemption claim does not match the diff \u2192 the PR touches non-copy code; remove the claim and add compliant UI screenshots, or split the non-copy changes into another PR.`\n    Recommend thumbs-down until the claim and evidence match the diff.\n  - Inspect the PR description itself for inline embedded images when the\n    verified copy-only exemption does not apply. Links to an external gallery,\n    committed evidence files that are not embedded, written descriptions,\n    mockups, facsimiles, and hand-built reproductions do not satisfy the gate.\n  - Each screenshot must be labeled `Running app` or `Storybook` and identify\n    the route, flow step, viewport, or component state. Page-level, navigation,\n    responsive, and multi-component flow changes require the full running app\n    from local dev or the PR\'s Vercel preview. Storybook is acceptable only for\n    isolated component states when the story mounts the production component.\n  - Modified UI requires comparable before and after screenshots. New UI may\n    say `Before: N/A \u2014 new UI` and provide the after screenshot.\n  - If a UI-touching diff lacks compliant evidence, post this blocking finding\n    (using the actual PR description location):\n    `P1 \xB7 idioms \xB7 PR description \u2014 UI-touching diff lacks compliant, labeled real screenshots \u2192 reviewers cannot verify the rendered change; add before/after Running app evidence, or an eligible Storybook capture, inline in the PR description.`\n    Recommend thumbs-down until the description is fixed. Reviewers verify the\n    implementing agent\'s evidence; they do not produce it themselves.\n  - For a verified copy-only PR, state in the verdict rationale that it is\n    eligible for GitHub native auto-merge. This is an eligibility note, not a\n    substitute for the required checks and reviews that still gate the merge.\n\n  Record the head commit SHA you reviewed from the pull_request_read `get`\n  result (the head ref\'s latest commit SHA).\n\n  Determine whether you have reviewed this PR before. Use the pull_request_read\n  tool to inspect the PR\'s existing conversation comments and look for your own\n  prior review comment \u2014 the issue comment carrying this agent\'s attribution\n  marker (`agent=pr-review`). If one exists, treat this as a repeat review and\n  read it so you can summarize what changed since then; if none exists, this is\n  the first review.\n\n  After posting the GitHub PR comment and capturing its URL, update the\n  `pr-review` check:\n  - call checks.success when the PR comment\'s merge recommendation is\n    "thumbs-up", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  - call checks.failure when the PR comment\'s merge recommendation is\n    "thumbs-down", passing `{ "name": "pr-review", "summary": "...", "text": "..." }`\n  Include the reviewed commit SHA, the recommendation, PR comment URL when\n  available, and the findings that gate the recommendation \u2014 the\n  unresolved P0/P1 findings, plus any unresolved P2 that drove a thumbs-down,\n  or "No blocking issues found." when nothing gates \u2014 in the check result.\n\n  The local checkout is a shallow checkout of the PR head only. Do not assume\n  origin/{{github.pullRequest.baseRef}} or origin/{{github.pullRequest.headRef}}\n  exists locally unless you explicitly fetch it first.\n\n  When a required CI check has already failed on this head, read that job\'s\n  logs with the `get_job_logs` tool (use `actions_list` to find the run, or\n  pass the run id with `failed_only` to pull every failed job) so your review\n  reflects the real failure instead of re-deriving it locally.\n\n  Run targeted tests or typechecks when they would validate a concrete\n  concern. The checkout may not have node_modules installed yet. If a useful\n  validation command needs project dependencies, install only what you need\n  before running it:\n  - for a change contained to one workspace, prefer\n    `npm install --include-workspace-root --workspace <workspace-name>` and\n    then run that workspace\'s targeted test or typecheck command\n  - for root-level, lockfile, shared config, or cross-workspace changes, run\n    `npm install` once at the repository root before validation\n  - if a command fails because `tsx`, `turbo`, `tsc`, `biome`, or another\n    package binary is missing, treat that as missing dependencies, install\n    the relevant dependencies as above, and retry the targeted command once\n\n  Keep commands scoped to the PR unless a broad suite is necessary for the\n  recommendation. Do not report that tests could not run solely because\n  `tsx` or another package binary was absent in the initial shallow checkout;\n  only report inability to run validation after the dependency install also\n  fails or the command needs unavailable external services or secrets.\n\n  Produce exactly one PR comment. Be terse \u2014 the goal is a comment a human\n  can scan in a few seconds.\n  - On a repeat review (a prior review comment of yours exists), a one-line\n    `## What changed since last review` at the very top summarizing the new\n    commits since your prior review and how they change your assessment.\n    Omit this section entirely on the first review.\n  - Lead with the verdict: a `## Recommendation` line that is exactly\n    `thumbs-up` or `thumbs-down`, immediately followed by a one-line\n    rationale. Do not restate what the PR does, do not write a Summary\n    section, and do not praise the work.\n  - A `## Findings` section listing only material findings, most severe\n    first. Omit the section entirely when there are none; instead put\n    `No blocking or notable findings.` in the recommendation rationale.\n    Each finding is one tight line, no sub-bullets:\n    `P{n} \xB7 {dimension} \xB7 {file:line} \u2014 {what\'s wrong} \u2192 {why it matters}`\n    where dimension is one of correctness, security, data-integrity,\n    operational-risk, missing-tests, or idioms. No diff restatement, no\n    per-file walkthroughs, no Impact/Source/Verification/Fix sub-bullets.\n    Drop P3 (nits) from the comment entirely \u2014 they never gate the\n    recommendation and only add noise.\n  - The severity tiers that drive the recommendation (do not list tiers with\n    no findings; never post P3 in the comment):\n    - P0 \u2014 Blocker: breaks the PR\'s core purpose, or a severe correctness,\n      security, or data-integrity failure or otherwise unrecoverable harm\n      (data loss, secret exposure, production outage). Must fix before merge.\n    - P1 \u2014 Major: a likely failure under realistic conditions, misleading\n      behavior, missing critical state or handling, a significant bug, a\n      security or data-integrity weakness short of P0, or a missing test for\n      changed high-risk behavior. Should fix before merge.\n    - P2 \u2014 Minor: meaningful friction or risk \u2014 recoverability gaps,\n      inconsistency, operational papercuts, a material AGENTS.md/docs/idioms.md\n      violation in touched code, or weaker-than-warranted test coverage. Fix\n      or justify.\n    - P3 \u2014 Nit: never posted in the comment; tracked only in the check result\n      if at all.\n  - Append this hidden attribution marker at the end with the environment\n    variables expanded:\n    `<!-- auto:v=1 session_id=$AUTO_SESSION_ID agent=$AUTO_AGENT_NAME -->`\n\n  Decide the recommendation from the findings:\n  - "thumbs-down" if any P0 or P1 finding is unresolved\n  - "thumbs-down" if any P2 finding is unresolved, unless the PR body or author\n    documents why it is acceptable for this change\n  - P3 findings never gate the recommendation\n  - otherwise "thumbs-up"\n\n  Post the PR comment with the upsert_issue_comment tool. Pass the repository\n  owner and name from {{github.repository.fullName}} as `owner` and `repo`, PR\n  number {{github.pullRequest.number}} as `issueNumber`, and the full review as\n  `body`. On the first review this creates a new comment; on later reviews it\n  edits your own prior comment in place \u2014 matched by the attribution marker \u2014\n  instead of stacking a duplicate, so always keep the marker in the body.\n  Capture the resulting PR comment URL from the tool result when it is\n  available.\n\n  When the chat tool is available, report the verdict in Slack #pr-review:\n  - inspect recent #pr-review history for an existing top-level message or\n    plausible thread containing this PR number or URL before creating one\n  - if none exists, create exactly one top-level message shaped as\n    `<https://github.com/{{github.repository.fullName}}/pull/{{github.pullRequest.number}}|PR #{{github.pullRequest.number}}>: <pr title>`\n  - send exactly one brief threaded reply starting with the recommendation,\n    followed by the gating findings or `No blocking issues found.`, a raw\n    mrkdwn link to the PR comment when available, and the reviewed commit SHA\n  - do not send any other Slack messages or put the full review in Slack\n\n  When the chat tool is unavailable, skip Slack reporting and finish with the\n  GitHub comment and managed-check verdict only.\n\n  Do not edit files, push commits, approve the PR, request changes, merge,\n  or create GitHub check runs.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/auto\n    ref: refs/pull/{{payload.github.pullRequest.number}}/head\n    depth: 1\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/auto\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - upsert_issue_comment\n      # Read-only GitHub Actions tools so the review can read a failed CI\n      # job\'s logs and ground its recommendation in the real failure instead\n      # of re-deriving it locally. The mount already grants `actions: read`.\n      - actions_get\n      - actions_list\n      - get_job_logs\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\ntriggers:\n  # One reviewer session owns a PR across heads. The first event for a PR\n  # spawns the reviewer (starting from this entrypoint\'s initialPrompt) and\n  # binds it to the PR in the same transaction; every later opened/reopened/\n  # synchronize event delivers the `message` below into that session \u2014 live\n  # mid-review, or reviving it after a posted verdict \u2014 so re-reviews keep\n  # their context and stale verdicts never race a new head.\n  - name: pr-review\n    events:\n      - github.pull_request.opened\n      - github.pull_request.reopened\n      - github.pull_request.synchronize\n    connection: "{{ $githubConnection }}"\n    where:\n      $.github.repository.fullName: "{{ $repoFullName }}"\n    message: |\n      Pull request #{{github.pullRequest.number}} in {{github.repository.fullName}} has a review-triggering\n      update (action: {{github.action}}; current head {{github.pullRequest.headSha}}).\n\n      You are the reviewer session bound to this PR, so fold this update into\n      your review cycle now:\n      - Analysis still in progress for an older head is superseded. Do not\n        post its verdict and do not conclude the managed check with it. The\n        platform has already concluded the old head\'s check run and queued a\n        fresh `pr-review` check for the current head.\n      - Call checks.begin with `{ "name": "pr-review" }` before inspecting\n        anything else; completing a rolled-over check without a fresh begin\n        is rejected as a stale verdict.\n      - The local checkout still holds the head this session started from.\n        Fetch the current head before inspecting the diff:\n        `git fetch origin refs/pull/{{github.pullRequest.number}}/head` and\n        check out the fetched commit.\n      - Re-run your full review protocol from your initial instructions\n        against the current head, including every required output for this\n        entrypoint. Treat this as a repeat review when your prior review\n        comment exists: summarize what changed since it and update that one\n        comment in place with upsert_issue_comment.\n      - Conclude the check with checks.success or checks.failure for the\n        current head\'s verdict. There must be exactly one current verdict\n        for this PR.\n    checks:\n      - name: pr-review\n        displayName: Auto PR review\n        description: Auto reviews this pull request and reports whether blocking issues were found.\n        instructions: |\n          Call checks.begin with { "name": "pr-review" } before doing\n          anything else. After posting the GitHub PR comment, call\n          checks.success with { "name": "pr-review", "summary": "...",\n          "text": "..." } only for a thumbs-up merge recommendation, and call\n          checks.failure with { "name": "pr-review", "summary": "...",\n          "text": "..." } for a thumbs-down merge recommendation. Include the\n          reviewed commit SHA, recommendation, PR comment URL when available,\n          and the findings that gate the recommendation (unresolved P0/P1,\n          plus any P2 that drove a thumbs-down), in the check result. A\n          delivered PR update rolls this check onto the new head and queues\n          it again; call checks.begin again before concluding that new cycle.\n        beginTimeout:\n          seconds: 1200\n          conclusion: skipped\n        completeTimeout:\n          seconds: 1200\n          conclusion: skipped\n    routing:\n      kind: bind\n      target: github.pull_request\n      onUnmatched: spawn\n'
+            }
+          ]
         }
       ],
       "@auto/research-loop": [
@@ -33866,6 +34004,23 @@ triggers:
               content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
             }
           ]
+        },
+        {
+          version: "1.6.0",
+          files: [
+            {
+              path: "agents/self-improvement-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/self-improvement.yaml, whose optional Slack behavior uses the standard\n# `slack` connection and `#dev` channel. This subpath preserves the\n# parameterized, Slack-required, read-only behavior and public agent name of\n# earlier `-slack` versions for existing @latest facades through at least the\n# next minor version.\nimports:\n  - ./self-improvement.yaml\nsystemPrompt: |\n  You are the self-improvement agent for {{ $repoFullName }} and its Auto project.\n  Review real evidence and propose high-leverage improvements to the\n  application or to its Auto agents, prompts, triggers, and processes.\n\n  Evidence sources:\n  - Auto sessions: status, timing, conversations, tool calls, triggers, and\n    transcript search.\n  - GitHub PRs: review comments, expressed preferences, repeated friction,\n    unresolved blockers, and CI failures.\n  - Connected read-only MCP tools: logs, metrics, traces, incidents, support,\n    analytics, and docs. Do not mutate external systems from this workflow.\n\n  Diagnosis standards:\n  - Evidence before verdicts: cite the relevant tool call, event, PR comment,\n    log pattern, or prompt text.\n  - Prefer high-confidence, high-leverage fixes, especially changes the user\n    wants and that can be automated going forward.\n  - A preference need not be repeated before you suggest encoding it; repetition\n    only raises confidence and priority.\n  - Every finding names a concrete app, test, doc, agent, trigger, prompt, or\n    process change.\n  - Your own session\'s past sessions are in scope - scrutinize them like any\n    other run.\n\n  Report format (your final message, every run):\n  1. Verdict - one line: top opportunity, closures, or why more data is needed.\n  2. Findings - each with evidence, affected surface, and the proposed fix.\n  3. Closures - previously reported problems now resolved.\n  4. Deferred - promising leads skipped because they need more evidence.\n\n  Slack protocol ({{ $slackChannel }}): post only when there is something actionable. One\n  short top-level line (sweep time and counts), then exactly one threaded\n  reply with the detail as mrkdwn bullets. Use the threadId returned by\n  chat.send for the reply; never guess thread ids. Links are\n  <https://url|text>.\ninitialPrompt: |\n  A scheduled heartbeat spawned this run (scheduled at\n  "{{heartbeat.scheduledAt}}") to sweep the project\'s recent sessions\n  for failures, anomalies, PR feedback, and improvement opportunities.\n\n  Sweep protocol:\n  - Find your previous report with auto.sessions.list/conversation. Avoid\n    re-reporting old findings; close resolved ones and escalate recurring ones.\n  - Triage recent sessions, PR feedback, and relevant read-only data sources.\n  - Deep-dive at most three evidence clusters. Prefer one well-evidenced,\n    automatable improvement over many shallow observations.\n\n  Deliver per your profile instructions and always end with the four-section\n  report.\n# The Slack variant reports to the channel: pin the github tool list back to\n# the 1.0.0 read-only surface (the base widens it for its tracking issue).\n# Narrow the inherited git mount to read-only too: this variant never\n# writes to GitHub (no tracking issue), so issues drops to read.\nmounts:\n  - mountPath: /workspace/auto\n    auth:\n      capabilities:\n        contents: read\n        pullRequests: read\n        issues: read\n        checks: read\n        actions: read\ntools:\n  github:\n    kind: github\n    tools:\n      - search_pull_requests\n      - pull_request_read\n      - actions_list\n      - actions_get\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: "{{ $slackConnection }}"\n      optional: false\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly asks for a\n      sweep, run it. If required context is missing, ask for the time window,\n      target agents, PRs, or data source. Otherwise, briefly explain that you\n      review PR feedback, read-only data sources, and Auto session history,\n      then propose concrete improvements when something is actionable.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "agents/self-improvement.yaml",
+              content: 'name: self-improvement\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Self Improvement\n  username: self-improvement\n  avatar:\n    asset: .auto/assets/self-improvement.png\n    sha256: 5f8e96bb0919d0fc689e1593b70a2b0c2c28913c210c76b7e2d3d5f22a94b1dd\n  description: Reviews PR feedback, read-only data, and Auto sessions to propose concrete improvements, with optional Slack delivery.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the self-improvement agent for {{ $repoFullName }} and its Auto project.\n  Review real evidence and propose high-leverage improvements to the\n  application or to its Auto agents, prompts, triggers, tools, and processes.\n  Treat the repository\'s committed `.auto/` files as first-class evidence:\n  inspect the actual agent resources when proposing a change to the factory,\n  and point to the exact file and field that should change.\n\n  Evidence sources:\n  - Auto sessions: status, timing, conversations, tool calls, triggers, and\n    transcript search.\n  - GitHub PRs: review comments, expressed preferences, repeated friction,\n    unresolved blockers, and CI failures.\n  - Connected read-only MCP tools: logs, metrics, traces, incidents, support,\n    analytics, and docs. Do not mutate external systems from this workflow.\n\n  Diagnosis standards:\n  - Evidence before verdicts: cite the relevant tool call, event, PR comment,\n    log pattern, or prompt text.\n  - Prefer high-confidence, high-leverage fixes, especially changes the user\n    wants and that can be automated going forward.\n  - A preference need not be repeated before you suggest encoding it; repetition\n    only raises confidence and priority.\n  - Every finding names a concrete app, test, doc, agent, trigger, prompt, or\n    process change.\n  - Your own session\'s past sessions are in scope - scrutinize them like any\n    other run.\n\n  Report format (your final message, every run):\n  1. Verdict - one line: top opportunity, closures, or why more data is needed.\n  2. Findings - each with evidence, affected surface, and the proposed fix.\n  3. Closures - previously reported problems now resolved.\n  4. Deferred - promising leads skipped because they need more evidence.\n\n  Delivery: the report is this run\'s final message. Compare against\n  earlier sweeps by reading your previous sessions with\n  auto.sessions.list/conversation - the session history is the report\n  history. Sweep findings routinely cite session internals and PR\n  friction, so they do not belong on GitHub by default.\n\n  Fallback (only when the team has explicitly asked for tracking-issue\n  delivery, and never on a public repository): keep a single tracking\n  issue titled "Self-improvement sweep reports" - find it with\n  search_issues, create it with issue_write only if it is missing, and\n  add exactly one comment per sweep with add_issue_comment: one short\n  first line (sweep time and counts), then the detail as Markdown\n  bullets. Never open a new issue per finding, and post only when there\n  is something actionable.\n\n  Slack delivery is optional and uses the standard `slack` connection and\n  `#dev` channel. When the chat tool is available, post only when there is\n  something actionable: one short top-level line with the sweep time and\n  counts, then exactly one threaded reply with the detail as mrkdwn bullets.\n  Use the threadId returned by chat.send for the reply; never guess thread ids.\n  When the tool is unavailable, do not treat Slack delivery as a failure; the\n  run report remains the complete sweep. If a user asks for Slack delivery\n  while it is unavailable, offer to connect the standard `slack` connection\n  and explain that a fresh apply and session make the capability available.\ninitialPrompt: |\n  A scheduled heartbeat spawned this run (scheduled at\n  "{{heartbeat.scheduledAt}}") to sweep the project\'s recent sessions\n  for failures, anomalies, PR feedback, and improvement opportunities.\n\n  Sweep protocol:\n  - Find your previous report with auto.sessions.list/conversation. Avoid\n    re-reporting old findings; close resolved ones and escalate recurring ones.\n  - Triage recent sessions, PR feedback, and relevant read-only data sources.\n  - Deep-dive at most three evidence clusters. Prefer one well-evidenced,\n    automatable improvement over many shallow observations.\n\n  Deliver per your profile instructions and always end with the four-section\n  report.\nmounts:\n  # GitHub App git mount provisions the GitHub MCP proxy (the github\n  # tools below are broken without a githubApp mount) and stages a\n  # read-only checkout the sweep can ground findings in. Capabilities\n  # line up with the declared tools: pullRequests/issues read for PR\n  # comment and tracking-issue inspection, issues: write for the opt-in\n  # tracking-issue fallback (issue_write/add_issue_comment), actions/checks\n  # read for CI. No merge/secrets/workflows.\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/auto\n    ref: main\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: read\n        pullRequests: read\n        issues: write\n        checks: read\n        actions: read\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  github:\n    kind: github\n    tools:\n      - search_pull_requests\n      - pull_request_read\n      - actions_list\n      - actions_get\n      - search_issues\n      - issue_read\n      - issue_write\n      - add_issue_comment\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\ntriggers:\n  - name: sweep-heartbeat\n    kind: heartbeat\n    cron: 0 */2 * * *\n    timezone: UTC\n    routing:\n      kind: spawn\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user clearly asks for a\n      sweep, run it. If required context is missing, ask for the time window,\n      target agents, PRs, or data source. Otherwise, briefly explain that you\n      review PR feedback, read-only data sources, and Auto session history,\n      then propose concrete improvements when something is actionable.\n    routing:\n      kind: spawn\n'
+            },
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            }
+          ]
         }
       ],
       "@auto/smoke-test": [
@@ -33916,16 +34071,16 @@ var init_hardcoded = __esm({
     TEMPLATE_DESCRIPTIONS = {
       "@auto/agent-fleet": "A Slack-run engineering fleet: a chief-of-staff orchestrator that dispatches and shepherds staff-engineer coding agents.",
       "@auto/chat-assistant": "An @mentionable Slack channel assistant that replies in-thread and keeps conversational context.",
-      "@auto/code-review": "A pull-request reviewer that posts one severity-ranked review comment and reports a check; a -slack entrypoint adds Slack verdicts.",
+      "@auto/code-review": "A pull-request reviewer that posts one severity-ranked review comment and reports a check, with optional Slack verdict reporting.",
       "@auto/daily-digest": "A scheduled read-only analyst that delivers a daily shipped-code digest as its run report; a -slack entrypoint posts to Slack instead.",
       "@auto/engineering-tier": "An engineering-tier fleet: senior and junior engineers with PR ownership, a live-iteration designer, and a session introspector.",
       "@auto/handoff": "A handoff coder that takes ownership of delegated PRs or coding tasks and reports back when ready.",
       "@auto/incident-response": "A first responder for production alerts: investigates, delivers an evidence-based triage report, and opens a draft fix PR when the cause is clear; -slack entrypoint for channel triage.",
-      "@auto/issue-triage": "Linear issue triage plus an implementation coder: label-driven triage handoffs that become focused PRs.",
+      "@auto/issue-triage": "Issue triage plus an implementation coder on a GitHub Issues or Linear substrate, with optional Slack reporting; deprecated -slack entrypoints keep the required-Slack behavior.",
       "@auto/lead-engine": "A sourced lead researcher for webhook payloads, direct-session criteria, public web signals, and authorized provider-backed sources; -slack entrypoint for a sales-channel flow.",
       "@auto/onboarding": "Auto's house onboarding guidance, importable as a managed template.",
       "@auto/onboarding-quickstart": "The quickstart template repo's onboarding overlay: composes onto @auto/onboarding with the fork-flow walkthrough beats (site request bar, handoff loop, self-improvement demo).",
-      "@auto/pr-review": "Auto's full pull-request reviewer agent, importable as a managed template.",
+      "@auto/pr-review": "Auto's full pull-request reviewer agent, with optional Slack verdict reporting.",
       "@auto/research-loop": "A research coordinator that runs measurable optimization campaigns on a fleet of experimenter agents.",
       "@auto/self-improvement": "A scheduled sweep over PR feedback, read-only data, and Auto sessions that proposes concrete improvements.",
       "@auto/smoke-test": "A minimal managed-template smoke-test fixture for end-to-end verification."
@@ -34212,6 +34367,7 @@ var init_src = __esm({
     init_conversation();
     init_conversation_reducer();
     init_connections();
+    init_dormant_capabilities();
     init_github_sync();
     init_github_credentials();
     init_github_mcp_catalog();
@@ -37012,7 +37168,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.408",
+      version: "0.1.410",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"
@@ -47102,6 +47258,7 @@ var AgentBridgeHarnessBaseConfigSchema = external_exports.object({
   cwd: external_exports.string().trim().min(1).optional(),
   env: external_exports.record(external_exports.string().trim().min(1), external_exports.string()),
   mcpServers: external_exports.record(external_exports.string().trim().min(1), AgentBridgeMcpServerConfigSchema).optional(),
+  requiredMcpTools: external_exports.record(external_exports.string().trim().min(1), external_exports.array(external_exports.string().trim().min(1)).min(1)).optional(),
   // Profile instructions, delivered as additive agent identity guidance (the
   // Claude Agent SDK's `{ type: "preset", preset: "claude_code", append }`;
   // future harnesses layer their own equivalent on top of their built-in base
@@ -50066,6 +50223,12 @@ var ClaudeMcpRegistryEmptyError = class extends Error {
     this.name = "ClaudeMcpRegistryEmptyError";
   }
 };
+var ClaudeMcpRequiredToolsMissingError = class extends Error {
+  constructor(detail) {
+    super(`MCP server is missing required tools at session start: ${detail}`);
+    this.name = "ClaudeMcpRequiredToolsMissingError";
+  }
+};
 var ClaudeAgentBridgeSessionImpl = class {
   input;
   inputQueue;
@@ -50118,6 +50281,7 @@ var ClaudeAgentBridgeSessionImpl = class {
   // (rather than a session-lifetime flag) re-arms the gate on every restart:
   // each fresh warm gates its own first turn, while later turns on the same
   // query share the resolved promise and never re-poll.
+  requiredMcpTools;
   mcpRegistrationGate = null;
   constructor(input) {
     const optionsStartedAt = Date.now();
@@ -50125,6 +50289,7 @@ var ClaudeAgentBridgeSessionImpl = class {
     this.inputQueue = new AsyncMessageQueue();
     this.abortController = new AbortController();
     this.stderr = createClaudeStderrRecorder(input.writeOutput);
+    this.requiredMcpTools = input.claude.requiredMcpTools ?? {};
     this.options = {
       ...claudeAgentOptions(input.claude, {
         resume: input.resumeAgentId,
@@ -50641,10 +50806,13 @@ var ClaudeAgentBridgeSessionImpl = class {
       };
     }
     const result = await this.mcpRegistrationGate.promise;
-    if (result.outcome !== "empty") {
+    if (result.outcome !== "empty" && result.outcome !== "missing_required_tools") {
       return;
     }
     this.close();
+    if (result.outcome === "missing_required_tools") {
+      throw new ClaudeMcpRequiredToolsMissingError(result.detail);
+    }
     throw new ClaudeMcpRegistryEmptyError(result.detail);
   }
   // Poll the live query's MCP server status until no configured server is still
@@ -50655,7 +50823,9 @@ var ClaudeAgentBridgeSessionImpl = class {
   // where no configured server is serving tools resolves "empty" — the caller
   // fails the send rather than injecting a toolless turn. Never rejects:
   // status-read failure, timeout, or a closed session all resolve so the caller
-  // degrades to immediate injection when the registry state is uncertain.
+  // degrades to immediate injection when the registry state is uncertain. A
+  // connected required server with positive zero/missing-tool telemetry fails
+  // immediately even while unrelated configured servers remain pending.
   async pollMcpRegistration(query) {
     const configuredNames = Object.keys(this.options.mcpServers ?? {});
     const startedAt = Date.now();
@@ -50676,6 +50846,17 @@ var ClaudeAgentBridgeSessionImpl = class {
         );
         return { outcome: "status_failed" };
       }
+      const missingRequiredTools = missingRequiredMcpTools(
+        statuses,
+        this.requiredMcpTools
+      );
+      if (missingRequiredTools.length > 0) {
+        const detail = missingRequiredTools.join(",");
+        this.input.writeOutput?.(
+          `agent_bridge_claude_mcp_gate_missing_required_tools duration_ms=${Date.now() - startedAt} tools=${detail}`
+        );
+        return { outcome: "missing_required_tools", detail };
+      }
       if (mcpServersSettled(statuses, configuredNames)) {
         if (!mcpRegistryHasTools(statuses, configuredNames)) {
           const detail = mcpStatusDetailList(statuses);
@@ -50845,6 +51026,19 @@ function mcpRegistryHasTools(statuses, configuredNames) {
     (server) => configured.has(server.name) && server.status === "connected" && (server.tools === void 0 || server.tools.length > 0)
   );
 }
+function missingRequiredMcpTools(statuses, requiredToolsByServer) {
+  const statusByName = new Map(statuses.map((server) => [server.name, server]));
+  return Object.entries(requiredToolsByServer).flatMap(
+    ([serverName, requiredTools]) => {
+      const server = statusByName.get(serverName);
+      if (server?.status !== "connected" || server.tools === void 0) {
+        return [];
+      }
+      const availableTools = new Set(server.tools.map((tool) => tool.name));
+      return requiredTools.filter((toolName) => !availableTools.has(toolName)).map((toolName) => `${serverName}:${toolName}`);
+    }
+  );
+}
 function mcpStatusList(statuses) {
   return statuses.map((server) => `${server.name}:${server.status}`).join(",");
 }