[rollout] Set up GH-AW and install shared PR review workflows (#794)

## Summary This PR sets up GitHub Agentic Workflows (GH-AW) and installs shared PR review workflows in `pulumi/pulumi-docker-build`. ### Commands Executed - `gh-aw version` → `v0.56.2` (used as entrypoint) - `gh-aw init` → ran (`.github/aw/` was not present) - `gh-aw add pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@main --name docker-build-pr-review --force` - `gh-aw add pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-rereview.md@main --name docker-build-pr-rereview --force` - `gh-aw compile` - `gh-aw validate` ### Configuration | Property | Value | |---|---| | AW entrypoint | `gh-aw` (v0.56.2) | | Target base branch | `main` | | `prefix_stem` | `docker-build` | | `gh-aw init` | Ran (was not previously initialized) | ### Changed Files - `.gitattributes` — added `merge=ours` strategy for `.github/workflows/*.lock.yml` - `.github/agents/agentic-workflows.agent.md` — created by `gh-aw init` - `.github/workflows/copilot-setup-steps.yml` — generated dependency workflow - `.github/workflows/docker-build-pr-review.md` — shared PR review workflow source - `.github/workflows/docker-build-pr-review.lock.yml` — compiled lock file - `.github/workflows/docker-build-pr-rereview.md` — shared PR re-review workflow source - `.github/workflows/docker-build-pr-rereview.lock.yml` — compiled lock file - `.github/workflows/shared/review.md` — imported shared workflow - `.github/workflows/shared/plugins/code-review/code-review.md` — imported shared plugin ### Validation Output **compile:** ```` ⚠ Compiled 2 workflow(s): 0 error(s), 2 warning(s) ``` **validate:** ``` ⚠ Compiled 2 workflow(s): 0 error(s), 2 warning(s) ``` ### Validation Warnings Both workflows produced the same non-blocking warning: ``` warning: This workflow grants id-token: write permission OIDC tokens can authenticate to cloud providers (AWS, Azure, GCP). Ensure proper audience validation and trust policies are configured. ```` These warnings are expected for the shared review workflows which use OIDC for cloud authentication and are non-blocking. --- Rollout triggered by [provider-ops#41](https://github.com/pulumi/provider-ops/issues/41). > Generated by [Generic Rollout Worker](https://github.com/pulumi/provider-ops/actions/runs/23014445857) · [◷](https://github.com/search?q=repo%3Apulumi%2Fpulumi-docker-build+%22gh-aw-workflow-id%3A+gh-aw-workflow-rollout-worker%22&type=pullrequests)   Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-12 19:25:04 +00:00
parent a8af1bfb5d
commit f6b499a9d4
9 changed files with 2899 additions and 0 deletions
--- a/.github/agents/agentic-workflows.agent.md
+++ b/.github/agents/agentic-workflows.agent.md
@@ -0,0 +1,177 @@
+---
+description: GitHub Agentic Workflows (gh-aw) - Create, debug, and upgrade AI-powered workflows with intelligent prompt routing
+disable-model-invocation: true
+---
+
+# GitHub Agentic Workflows Agent
+
+This agent helps you work with **GitHub Agentic Workflows (gh-aw)**, a CLI extension for creating AI-powered workflows in natural language using markdown files.
+
+## What This Agent Does
+
+This is a **dispatcher agent** that routes your request to the appropriate specialized prompt based on your task:
+
+- **Creating new workflows**: Routes to `create` prompt
+- **Updating existing workflows**: Routes to `update` prompt
+- **Debugging workflows**: Routes to `debug` prompt  
+- **Upgrading workflows**: Routes to `upgrade-agentic-workflows` prompt
+- **Creating report-generating workflows**: Routes to `report` prompt — consult this whenever the workflow posts status updates, audits, analyses, or any structured output as issues, discussions, or comments
+- **Creating shared components**: Routes to `create-shared-agentic-workflow` prompt
+- **Fixing Dependabot PRs**: Routes to `dependabot` prompt — use this when Dependabot opens PRs that modify generated manifest files (`.github/workflows/package.json`, `.github/workflows/requirements.txt`, `.github/workflows/go.mod`). Never merge those PRs directly; instead update the source `.md` files and rerun `gh aw compile --dependabot` to bundle all fixes
+- **Analyzing test coverage**: Routes to `test-coverage` prompt — consult this whenever the workflow reads, analyzes, or reports on test coverage data from PRs or CI runs
+
+Workflows may optionally include:
+
+- **Project tracking / monitoring** (GitHub Projects updates, status reporting)
+- **Orchestration / coordination** (one workflow assigning agents or dispatching and coordinating other workflows)
+
+## Files This Applies To
+
+- Workflow files: `.github/workflows/*.md` and `.github/workflows/**/*.md`
+- Workflow lock files: `.github/workflows/*.lock.yml`
+- Shared components: `.github/workflows/shared/*.md`
+- Configuration: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/github-agentic-workflows.md
+
+## Problems This Solves
+
+- **Workflow Creation**: Design secure, validated agentic workflows with proper triggers, tools, and permissions
+- **Workflow Debugging**: Analyze logs, identify missing tools, investigate failures, and fix configuration issues
+- **Version Upgrades**: Migrate workflows to new gh-aw versions, apply codemods, fix breaking changes
+- **Component Design**: Create reusable shared workflow components that wrap MCP servers
+
+## How to Use
+
+When you interact with this agent, it will:
+
+1. **Understand your intent** - Determine what kind of task you're trying to accomplish
+2. **Route to the right prompt** - Load the specialized prompt file for your task
+3. **Execute the task** - Follow the detailed instructions in the loaded prompt
+
+## Available Prompts
+
+### Create New Workflow
+**Load when**: User wants to create a new workflow from scratch, add automation, or design a workflow that doesn't exist yet
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/create-agentic-workflow.md
+
+**Use cases**:
+- "Create a workflow that triages issues"
+- "I need a workflow to label pull requests"
+- "Design a weekly research automation"
+
+### Update Existing Workflow  
+**Load when**: User wants to modify, improve, or refactor an existing workflow
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/update-agentic-workflow.md
+
+**Use cases**:
+- "Add web-fetch tool to the issue-classifier workflow"
+- "Update the PR reviewer to use discussions instead of issues"
+- "Improve the prompt for the weekly-research workflow"
+
+### Debug Workflow  
+**Load when**: User needs to investigate, audit, debug, or understand a workflow, troubleshoot issues, analyze logs, or fix errors
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/debug-agentic-workflow.md
+
+**Use cases**:
+- "Why is this workflow failing?"
+- "Analyze the logs for workflow X"
+- "Investigate missing tool calls in run #12345"
+
+### Upgrade Agentic Workflows
+**Load when**: User wants to upgrade workflows to a new gh-aw version or fix deprecations
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/upgrade-agentic-workflows.md
+
+**Use cases**:
+- "Upgrade all workflows to the latest version"
+- "Fix deprecated fields in workflows"
+- "Apply breaking changes from the new release"
+
+### Create a Report-Generating Workflow
+**Load when**: The workflow being created or updated produces reports — recurring status updates, audit summaries, analyses, or any structured output posted as a GitHub issue, discussion, or comment
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/report.md
+
+**Use cases**:
+- "Create a weekly CI health report"
+- "Post a daily security audit to Discussions"
+- "Add a status update comment to open PRs"
+
+### Create Shared Agentic Workflow
+**Load when**: User wants to create a reusable workflow component or wrap an MCP server
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/create-shared-agentic-workflow.md
+
+**Use cases**:
+- "Create a shared component for Notion integration"
+- "Wrap the Slack MCP server as a reusable component"
+- "Design a shared workflow for database queries"
+
+### Fix Dependabot PRs
+**Load when**: User needs to close or fix open Dependabot PRs that update dependencies in generated manifest files (`.github/workflows/package.json`, `.github/workflows/requirements.txt`, `.github/workflows/go.mod`)
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/dependabot.md
+
+**Use cases**:
+- "Fix the open Dependabot PRs for npm dependencies"
+- "Bundle and close the Dependabot PRs for workflow dependencies"
+- "Update @playwright/test to fix the Dependabot PR"
+
+### Analyze Test Coverage
+**Load when**: The workflow reads, analyzes, or reports test coverage — whether triggered by a PR, a schedule, or a slash command. Always consult this prompt before designing the coverage data strategy.
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/test-coverage.md
+
+**Use cases**:
+- "Create a workflow that comments coverage on PRs"
+- "Analyze coverage trends over time"
+- "Add a coverage gate that blocks PRs below a threshold"
+
+## Instructions
+
+When a user interacts with you:
+
+1. **Identify the task type** from the user's request
+2. **Load the appropriate prompt** from the GitHub repository URLs listed above
+3. **Follow the loaded prompt's instructions** exactly
+4. **If uncertain**, ask clarifying questions to determine the right prompt
+
+## Quick Reference
+
+```bash
+# Initialize repository for agentic workflows
+gh aw init
+
+# Generate the lock file for a workflow
+gh aw compile [workflow-name]
+
+# Debug workflow runs
+gh aw logs [workflow-name]
+gh aw audit <run-id>
+
+# Upgrade workflows
+gh aw fix --write
+gh aw compile --validate
+```
+
+## Key Features of gh-aw
+
+- **Natural Language Workflows**: Write workflows in markdown with YAML frontmatter
+- **AI Engine Support**: Copilot, Claude, Codex, or custom engines
+- **MCP Server Integration**: Connect to Model Context Protocol servers for tools
+- **Safe Outputs**: Structured communication between AI and GitHub API
+- **Strict Mode**: Security-first validation and sandboxing
+- **Shared Components**: Reusable workflow building blocks
+- **Repo Memory**: Persistent git-backed storage for agents
+- **Sandboxed Execution**: All workflows run in the Agent Workflow Firewall (AWF) sandbox, enabling full `bash` and `edit` tools by default
+
+## Important Notes
+
+- Always reference the instructions file at https://github.com/github/gh-aw/blob/v0.56.2/.github/aw/github-agentic-workflows.md for complete documentation
+- Use the MCP tool `agentic-workflows` when running in GitHub Copilot Cloud
+- Workflows must be compiled to `.lock.yml` files before running in GitHub Actions
+- **Bash tools are enabled by default** - Don't restrict bash commands unnecessarily since workflows are sandboxed by the AWF
+- Follow security best practices: minimal permissions, explicit network access, no template injection
+- **Single-file output**: When creating a workflow, produce exactly **one** workflow `.md` file. Do not create separate documentation files (architecture docs, runbooks, usage guides, etc.). If documentation is needed, add a brief `## Usage` section inside the workflow file itself.
--- a/.github/workflows/copilot-setup-steps.yml
+++ b/.github/workflows/copilot-setup-steps.yml
@@ -0,0 +1,26 @@
+name: "Copilot Setup Steps"
+
+# This workflow configures the environment for GitHub Copilot Agent with gh-aw MCP server
+on:
+  workflow_dispatch:
+  push:
+    paths:
+      - .github/workflows/copilot-setup-steps.yml
+
+jobs:
+  # The job MUST be called 'copilot-setup-steps' to be recognized by GitHub Copilot Agent
+  copilot-setup-steps:
+    runs-on: ubuntu-latest
+
+    # Set minimal permissions for setup steps
+    # Copilot Agent receives its own token with appropriate permissions
+    permissions:
+      contents: read
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v6
+      - name: Install gh-aw extension
+        uses: github/gh-aw/actions/setup-cli@v0.56.2
+        with:
+          version: v0.56.2
--- a/.github/workflows/docker-build-pr-rereview.lock.yml
+++ b/.github/workflows/docker-build-pr-rereview.lock.yml
--- a/.github/workflows/docker-build-pr-rereview.md
+++ b/.github/workflows/docker-build-pr-rereview.md
@@ -0,0 +1,19 @@
+---
+description: Run PR re-review on explicit maintainer slash command.
+timeout-minutes: 15
+strict: true
+on:
+  slash_command:
+    name: review-again
+    events: [pull_request_comment, pull_request_review_comment]
+imports:
+  - shared/review.md
+  - shared/plugins/code-review/code-review.md
+permissions:
+  contents: read
+  pull-requests: read
+  id-token: write
+source: pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-rereview.md@734ef41746387a6818fd8ac3e619c9fd81ac6957
+---
+
+# Internal PR Re-Review (Slash Command)
--- a/.github/workflows/docker-build-pr-review.lock.yml
+++ b/.github/workflows/docker-build-pr-review.lock.yml
--- a/.github/workflows/docker-build-pr-review.md
+++ b/.github/workflows/docker-build-pr-review.md
@@ -0,0 +1,24 @@
+---
+description: Automated PR review for trusted internal contributors.
+timeout-minutes: 15
+strict: true
+permissions:
+  contents: read
+  pull-requests: read
+  id-token: write
+on:
+  pull_request:
+    types: [opened]
+  workflow_dispatch:
+    inputs:
+      pr_number:
+        description: "Pull request number to review"
+        required: true
+        type: string
+imports:
+  - shared/review.md
+  - shared/plugins/code-review/code-review.md
+source: pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@734ef41746387a6818fd8ac3e619c9fd81ac6957
+---
+
+# Internal Trusted PR Reviewer
--- a/.github/workflows/shared/plugins/code-review/code-review.md
+++ b/.github/workflows/shared/plugins/code-review/code-review.md
@@ -0,0 +1,179 @@
+---
+description: High-signal PR review for gh-aw workflows using safe outputs
+---
+
+Provide a code review for the given pull request.
+
+**Agent assumptions (applies to all agents and subagents):**
+- All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
+- Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
+- Use GitHub MCP tools for repository reads. Do not use `gh` CLI commands for repository inspection or for posting review output.
+- Use the workflow PR number as the authoritative target.
+- Use only gh-aw safe outputs for review side effects:
+  - `create-pull-request-review-comment` for actionable inline findings on changed lines
+  - `submit-pull-request-review` for the final review decision
+  - `noop` when no action should be taken
+- Use cache-memory only for short-lived continuity and deduplication hints. Treat live PR state and current review threads as the source of truth.
+- Never post free-form issue comments or use any side channel for review output.
+- Respect the workflow safe-output limits. Prioritize the highest-signal unique findings and keep the inline review set within the configured maximum.
+- Consult `.gitattributes` when relevant and treat files matched there as generated by default. Ignore findings that exist only in generated outputs such as `.lock.yml` files unless the corresponding source-of-truth files show a real behavioral problem.
+
+To do this, follow these steps precisely:
+
+1. Create a short todo list for yourself before starting.
+
+2. Launch a fast subagent to check if any of the following are true:
+   - The pull request is closed
+   - The pull request is a draft
+   - The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
+   - Required PR context cannot be read from the workflow tools
+
+   If any condition is true, call `noop` with a brief reason and stop.
+
+Note: Do not skip solely because prior automated review comments exist. Use prior comments for deduplication and stale-thread cleanup instead.
+
+3. Read any prior review memory for this PR from cache-memory before you start detailed analysis.
+
+   Use a PR-specific file such as:
+   - `/tmp/gh-aw/cache-memory/pr-${PR_NUMBER}.json`
+
+   If a prior memory file exists, use it only as a hint for:
+   - Previously reported issues
+   - Dedupe patterns
+   - Prior review timestamps
+   - Risk areas worth re-checking
+
+   Do not trust cache-memory over current GitHub state. If memory conflicts with the live PR, changed files, or review threads, trust the live PR and ignore stale memory.
+
+4. Launch a fast subagent to return a list of file paths (not their contents) for all relevant `CLAUDE.md` files including:
+   - The root CLAUDE.md file, if it exists
+   - Any CLAUDE.md files in directories containing files modified by the pull request
+
+5. Launch a subagent to summarize:
+   - The PR title and description
+   - The changed files
+   - The main behavioral changes in the diff
+   - Any obvious risk areas worth checking carefully
+
+6. Fetch existing review comments on the PR before preparing any new findings. Use them to identify:
+   - Similar issues already flagged
+   - Threads where a human already acknowledged the feedback
+   - Comments on code that has changed since the earlier review and may now be stale
+
+7. Launch 4 review subagents in parallel. Each agent should return a list of candidate issues, where each issue includes:
+   - A concise description
+   - The reason it was flagged (for example `CLAUDE.md adherence` or `bug`)
+   - The changed file path
+   - The changed line or closest changed hunk
+   - Why the issue is likely real
+
+   Agents 1 + 2: CLAUDE.md compliance sonnet agents
+   Audit changes for `CLAUDE.md` compliance in parallel. When evaluating a file, only consider `CLAUDE.md` files that share a path scope with that file or its parents.
+
+   Agent 3: bug-focused review agent
+   Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
+
+   Agent 4: behavior-focused review agent
+   Look for problems introduced by the new code, including security issues, incorrect logic, regressions, and missing error handling. Only look for issues that fall within changed code.
+
+   **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
+   - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
+   - The code will definitely produce wrong results regardless of inputs (clear logic errors)
+   - The code introduces a clear security or regression bug in changed lines
+   - Clear, unambiguous `CLAUDE.md` violations where you can quote the exact rule being broken
+
+   Do NOT flag:
+   - Code style or quality concerns
+   - Potential issues that depend on specific inputs or state
+   - Subjective suggestions or improvements
+
+   If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
+
+   Each review subagent should receive the PR title and description so it can evaluate intent.
+
+8. For each candidate issue, launch validation subagents in parallel. Each validator should receive the PR title, description, issue description, affected file, and affected hunk. The validator must confirm that the issue is real with high confidence.
+
+   For bug and logic issues, verify the changed code actually causes the stated problem.
+
+   For `CLAUDE.md` issues, verify both:
+   - The cited rule exists
+   - The rule applies to that file path and is actually violated
+
+9. Filter out any issue that fails validation.
+
+10. Deduplicate and prune the validated issue list. Remove:
+   - Issues already covered by an existing review comment
+   - Issues in threads where a human has already acknowledged the feedback
+   - Issues that were present in an earlier revision but are fixed in the latest code
+   - Duplicate findings reported by multiple subagents
+   - Findings that are not on changed lines or cannot be tied to a changed hunk
+   - Findings that only came from cache-memory and are not confirmed by the current PR state
+
+11. Classify the remaining issues:
+   - `Blocking`: correctness, security, regression, data loss, or clear required-rule violations
+   - `Non-blocking`: actionable but not merge-blocking concerns
+
+12. Produce a short internal summary of findings for yourself:
+   - If issues remain, list the highest-signal ones first
+   - If no issues remain, summarize that no actionable high-signal issues were found
+
+13. If no actionable issues remain, submit exactly one final review with `submit-pull-request-review`:
+   - Use `APPROVE`
+   - Briefly state that no issues were found after checking for bugs and `CLAUDE.md` compliance
+   - Do not create inline comments
+   - Before stopping, write a compact review memory file for this PR containing:
+     - review timestamp
+     - PR number
+     - files reviewed
+     - summary of what was checked
+     - `issues_reported: []`
+   - Stop after the final review is submitted and memory is updated
+
+14. If actionable issues remain, choose the highest-signal unique issues up to the safe-output comment limit. Create a list of planned inline comments for yourself before posting anything.
+
+15. Post one inline comment per chosen issue using `create-pull-request-review-comment`. For each comment:
+   - Provide a brief description of the issue
+   - Explain why it matters
+   - Reference the exact changed line
+   - Cite the relevant `CLAUDE.md` rule when applicable
+   - Keep the comment concise and actionable
+   - Do not post duplicate comments for the same issue
+
+16. Submit exactly one final review using `submit-pull-request-review`:
+   - Use `REQUEST_CHANGES` when at least one blocking issue remains
+   - Use `APPROVE` otherwise, including when only non-blocking inline comments were left
+   - Do not use `COMMENT` as the final review state
+   - Keep the summary short and aligned with the issues you posted
+
+17. After the final review is submitted, update the PR-specific cache-memory file with a compact record of this review. Store only short-lived operational state such as:
+   - review timestamp
+   - PR number
+   - files reviewed
+   - issue fingerprints or short summaries
+   - whether the final review was `APPROVE` or `REQUEST_CHANGES`
+
+   Do not store secrets, tokens, personal data, or large blobs. Keep the file concise so future runs can use it for continuity and dedupe.
+
+Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
+
+- Pre-existing issues
+- Something that appears to be a bug but is actually correct
+- Pedantic nitpicks that a senior engineer would not flag
+- Issues that a linter will catch (do not run the linter to verify)
+- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
+- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
+- Differences that exist only in files classified as generated by `.gitattributes`, unless they expose a real issue in the source workflow, prompt, or other source-of-truth file
+
+Notes:
+
+- Use GitHub tools for all repository reads. Do not use web fetch.
+- Always operate on the workflow PR target rather than guessing from local git state.
+- Inline comments should only be created for actionable issues on changed lines.
+- Cache-memory is best-effort and may be missing or stale. Use it to improve continuity, never to override current repository state.
+- When linking to code in an inline comment, use a full GitHub blob URL with a full SHA and a line range, for example: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
+  - Requires full git sha
+  - Do not use shell substitution in the URL
+  - Repo name must match the repo you're code reviewing
+  - Use `#L[start]-L[end]`
+  - Provide at least one line of context before and after when possible
+- If context checks fail or the PR is not reviewable, call `noop` with a brief explanation instead of exiting silently.
--- a/.github/workflows/shared/review.md
+++ b/.github/workflows/shared/review.md
@@ -0,0 +1,68 @@
+---
+permissions:
+  contents: read
+  pull-requests: read
+  id-token: write
+engine:
+  id: claude
+  env:
+    ANTHROPIC_API_KEY: ${{ steps.esc-secrets.outputs.ANTHROPIC_API_KEY || '__GH_AW_ACTIVATION_PLACEHOLDER__' }}
+steps:
+  - env:
+      ESC_ACTION_ENVIRONMENT: imports/github-secrets
+      ESC_ACTION_EXPORT_ENVIRONMENT_VARIABLES: "false"
+      ESC_ACTION_OIDC_AUTH: "true"
+      ESC_ACTION_OIDC_ORGANIZATION: pulumi
+      ESC_ACTION_OIDC_REQUESTED_TOKEN_TYPE: urn:pulumi:token-type:access_token:organization
+    id: esc-secrets
+    name: Fetch secrets from ESC
+    uses: pulumi/esc-action@9eb774255b1a4afb7855678ae8d4a77359da0d9b
+  - name: Validate ESC secret output
+    env:
+      ANTHROPIC_API_KEY_FROM_ESC: ${{ steps.esc-secrets.outputs.ANTHROPIC_API_KEY }}
+    run: |
+      test -n "$ANTHROPIC_API_KEY_FROM_ESC" || {
+        echo "ESC did not return ANTHROPIC_API_KEY";
+        exit 1;
+      }
+tools:
+  cache-memory: true
+  github:
+    lockdown: false
+    toolsets: [pull_requests, repos]
+safe-outputs:
+  create-pull-request-review-comment:
+    max: 12
+    side: "RIGHT"
+    target: "${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }}"
+    target-repo: "${{ github.repository }}"
+  submit-pull-request-review:
+    max: 1
+    target: "${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }}"
+  noop:
+    max: 1
+  messages:
+    footer: "> Reviewed by [{workflow_name}]({run_url})"
+    run-started: "Started automated PR review for #${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }}."
+    run-success: "Finished automated PR review for #${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }}."
+    run-failure: "Automated PR review failed for #${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }} ({status})."
+---
+
+
+Review pull request #${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }} in repository `${{ github.repository }}`.
+
+Workflow-specific rules:
+- Use `${{ github.event.pull_request.number || github.event.inputs.pr_number || github.event.issue.number }}` as the authoritative PR target.
+- Treat the imported review prompt as the source of the review procedure.
+- Use only gh-aw safe outputs for side effects:
+  - `create-pull-request-review-comment` for actionable inline findings on changed lines
+  - `submit-pull-request-review` for the final review
+  - `noop` when the PR is not reviewable or required context is missing
+- Submit exactly one final review:
+  - `REQUEST_CHANGES` when at least one blocking issue exists.
+  - `APPROVE` otherwise, including when only non-blocking observations exist.
+  - Do not submit `COMMENT` as the final review state.
+- Do not post free-form issue comments outside safe outputs.
+- Respect the configured inline comment limit and prioritize the highest-signal unique findings.
+- Use cache-memory only as a best-effort continuity aid; live PR state and current review threads are authoritative.
+- Ignore discovery steps intended for runs without PR context.