@autohq/cli 0.1.378 → 0.1.379

package/dist/agent-bridge.js

@@ -23492,7 +23492,7 @@ Object.assign(lookup, {
 // package.json
 var package_default = {
   name: "@autohq/cli",
-  version: "0.1.378",
+  version: "0.1.379",
   license: "SEE LICENSE IN README.md",
   publishConfig: {
     access: "public"
@@ -31868,6 +31868,268 @@ 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.3.0",
+      files: [
+        {
+          path: "agents/incident-response-slack.yaml",
+          content: `imports:
+  - ./incident-response.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (Slack {{ $slackChannel }}):
+  - Slack renders mrkdwn links: <https://url|text>.
+  - Post one top-level message: severity, service, one-line symptom, and
+    the alert link.
+  - Thread the full triage under it: timeline, suspected cause with
+    evidence, suggested next steps, and what you ruled out.
+  - After your first reply, call auto.chat.subscribe for the thread so
+    responder questions route back to you. Answer follow-ups in the same
+    thread with the same evidence discipline.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body states the hypothesis the fix encodes with its evidence
+    and says how to verify it. Post the PR link in the incident thread.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident thread and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then post the triage
+  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.
+  If the evidence points at a clear, contained code fix, also open a draft
+  fix PR and post the link in the thread.
+# The Slack variant triages in the channel, not on a GitHub issue: narrow the
+# base's GitHub tooling to the pull-request surface and drop the issue grant.
+tools:
+  chat:
+    kind: local
+    implementation: chat
+    auth:
+      kind: connection
+      provider: slack
+      connection: "{{ $slackConnection }}"
+  github:
+    kind: github
+    tools:
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: none
+        checks: read
+        actions: read
+triggers:
+  - name: mention
+    event: chat.message.mentioned
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: false
+    message: |
+      {{message.author.userName}} mentioned you on Slack:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Reply in that thread with chat.send. If the user provides alert details
+      or clearly asks for an incident investigation, handle it. If required
+      context is missing, ask for the alert details. Otherwise, briefly explain
+      that you investigate production alerts, post triage to {{ $slackChannel }},
+      open a draft fix PR when the cause is clear, and answer follow-up
+      questions in the incident thread.
+    routing:
+      kind: spawn
+  - name: thread-reply
+    events:
+      - chat.message.mentioned
+      - chat.message.subscribed
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: true
+    message: |
+      {{message.author.userName}} replied in your incident thread:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Answer in that thread with chat.send, keeping the evidence discipline
+      from your instructions.
+    routing:
+      kind: deliver
+      routeBy:
+        kind: attributedSessions
+      onUnmatched: drop
+`
+        },
+        {
+          path: "agents/incident-response.yaml",
+          content: `name: incident-response
+model:
+  provider: anthropic
+  id: claude-opus-4-8
+identity:
+  displayName: Incident Response
+  username: incident-response
+  avatar:
+    asset: .auto/assets/sentinel.png
+    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec
+  description: First responder for production alerts - posts an evidence-based triage issue and drafts a fix PR when the cause is clear.
+imports:
+  - ../fragments/environments/agent-runtime.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (GitHub issues):
+  - Create one GitHub issue for the incident with the issue_write tool:
+    the title is "[severity] service: one-line symptom", and the body
+    opens with the alert link, then the full triage \u2014 timeline, suspected
+    cause with evidence, suggested next steps, and what you ruled out.
+  - If material findings arrive after the issue exists, add them with
+    add_issue_comment rather than rewriting the body, so the record stays
+    chronological.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body links the incident issue, states the hypothesis the fix
+    encodes with its evidence, and says how to verify it. Link the PR from
+    the incident issue with add_issue_comment.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident issue and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then create the GitHub
+  incident issue with your triage. If the evidence points at a clear,
+  contained code fix, also open a draft fix PR and link it from the issue.
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: write
+        checks: read
+        actions: read
+workingDirectory: /workspace/repo
+tools:
+  auto:
+    kind: local
+    implementation: auto
+  github:
+    kind: github
+    tools:
+      - issue_read
+      - issue_write
+      - add_issue_comment
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+triggers:
+  - name: incident-webhook
+    event: webhook.incident.opened
+    endpoint: incident-webhook
+    auth:
+      kind: bearer_token
+      secretRef: incident-webhook-secret
+    routing:
+      kind: spawn
+`
+        },
+        {
+          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/issue-triage": [
@@ -37433,7 +37695,7 @@ var TEMPLATE_DESCRIPTIONS = {
   "@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/daily-digest": "A scheduled read-only analyst that posts a daily shipped-code digest to a tracking issue; a -slack entrypoint posts to Slack instead.",
   "@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, posts a triage issue, and answers follow-ups; -slack entrypoint for channel triage.",
+  "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, 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/lead-engine": "An inbound-lead researcher that scores fit and drafts outreach for human approval; -slack entrypoint for a sales-channel flow.",
   "@auto/onboarding": "Auto's house onboarding guidance, importable as a managed template.",

package/dist/index.js

@@ -23680,6 +23680,268 @@ 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.3.0",
+          files: [
+            {
+              path: "agents/incident-response-slack.yaml",
+              content: `imports:
+  - ./incident-response.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (Slack {{ $slackChannel }}):
+  - Slack renders mrkdwn links: <https://url|text>.
+  - Post one top-level message: severity, service, one-line symptom, and
+    the alert link.
+  - Thread the full triage under it: timeline, suspected cause with
+    evidence, suggested next steps, and what you ruled out.
+  - After your first reply, call auto.chat.subscribe for the thread so
+    responder questions route back to you. Answer follow-ups in the same
+    thread with the same evidence discipline.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body states the hypothesis the fix encodes with its evidence
+    and says how to verify it. Post the PR link in the incident thread.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident thread and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then post the triage
+  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.
+  If the evidence points at a clear, contained code fix, also open a draft
+  fix PR and post the link in the thread.
+# The Slack variant triages in the channel, not on a GitHub issue: narrow the
+# base's GitHub tooling to the pull-request surface and drop the issue grant.
+tools:
+  chat:
+    kind: local
+    implementation: chat
+    auth:
+      kind: connection
+      provider: slack
+      connection: "{{ $slackConnection }}"
+  github:
+    kind: github
+    tools:
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: none
+        checks: read
+        actions: read
+triggers:
+  - name: mention
+    event: chat.message.mentioned
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: false
+    message: |
+      {{message.author.userName}} mentioned you on Slack:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Reply in that thread with chat.send. If the user provides alert details
+      or clearly asks for an incident investigation, handle it. If required
+      context is missing, ask for the alert details. Otherwise, briefly explain
+      that you investigate production alerts, post triage to {{ $slackChannel }},
+      open a draft fix PR when the cause is clear, and answer follow-up
+      questions in the incident thread.
+    routing:
+      kind: spawn
+  - name: thread-reply
+    events:
+      - chat.message.mentioned
+      - chat.message.subscribed
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: true
+    message: |
+      {{message.author.userName}} replied in your incident thread:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Answer in that thread with chat.send, keeping the evidence discipline
+      from your instructions.
+    routing:
+      kind: deliver
+      routeBy:
+        kind: attributedSessions
+      onUnmatched: drop
+`
+            },
+            {
+              path: "agents/incident-response.yaml",
+              content: `name: incident-response
+model:
+  provider: anthropic
+  id: claude-opus-4-8
+identity:
+  displayName: Incident Response
+  username: incident-response
+  avatar:
+    asset: .auto/assets/sentinel.png
+    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec
+  description: First responder for production alerts - posts an evidence-based triage issue and drafts a fix PR when the cause is clear.
+imports:
+  - ../fragments/environments/agent-runtime.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (GitHub issues):
+  - Create one GitHub issue for the incident with the issue_write tool:
+    the title is "[severity] service: one-line symptom", and the body
+    opens with the alert link, then the full triage \u2014 timeline, suspected
+    cause with evidence, suggested next steps, and what you ruled out.
+  - If material findings arrive after the issue exists, add them with
+    add_issue_comment rather than rewriting the body, so the record stays
+    chronological.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body links the incident issue, states the hypothesis the fix
+    encodes with its evidence, and says how to verify it. Link the PR from
+    the incident issue with add_issue_comment.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident issue and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then create the GitHub
+  incident issue with your triage. If the evidence points at a clear,
+  contained code fix, also open a draft fix PR and link it from the issue.
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: write
+        checks: read
+        actions: read
+workingDirectory: /workspace/repo
+tools:
+  auto:
+    kind: local
+    implementation: auto
+  github:
+    kind: github
+    tools:
+      - issue_read
+      - issue_write
+      - add_issue_comment
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+triggers:
+  - name: incident-webhook
+    event: webhook.incident.opened
+    endpoint: incident-webhook
+    auth:
+      kind: bearer_token
+      secretRef: incident-webhook-secret
+    routing:
+      kind: spawn
+`
+            },
+            {
+              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/issue-triage": [
@@ -29276,7 +29538,7 @@ var init_hardcoded = __esm({
       "@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/daily-digest": "A scheduled read-only analyst that posts a daily shipped-code digest to a tracking issue; a -slack entrypoint posts to Slack instead.",
       "@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, posts a triage issue, and answers follow-ups; -slack entrypoint for channel triage.",
+      "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, 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/lead-engine": "An inbound-lead researcher that scores fit and drafts outreach for human approval; -slack entrypoint for a sales-channel flow.",
       "@auto/onboarding": "Auto's house onboarding guidance, importable as a managed template.",
@@ -32356,7 +32618,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.378",
+      version: "0.1.379",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autohq/cli",
-  "version": "0.1.378",
+  "version": "0.1.379",
   "license": "SEE LICENSE IN README.md",
   "publishConfig": {
     "access": "public"