diff --git a/.changeset/patch-inline-imports.md b/.changeset/patch-inline-imports.md
new file mode 100644
index 00000000000..1f6844a1b86
--- /dev/null
+++ b/.changeset/patch-inline-imports.md
@@ -0,0 +1,5 @@
+---
+"gh-aw": patch
+---
+
+Documented the new `inline-imports: true` frontmatter option that embeds imported fragments at compile time to avoid runtime-import macros.
diff --git a/.github/workflows/smoke-claude.lock.yml b/.github/workflows/smoke-claude.lock.yml
index f0e74df44dd..0ebe40d478d 100644
--- a/.github/workflows/smoke-claude.lock.yml
+++ b/.github/workflows/smoke-claude.lock.yml
@@ -33,7 +33,7 @@
# - shared/mcp/tavily.md
# - shared/reporting.md
#
-# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"22441496741c536b8d9d809d2e0e13589a1cf6874aa01ae130f90aabfaa11d11"}
+# gh-aw-metadata: {"schema_version":"v1","frontmatter_hash":"8c782964f7e844ae374ed837be15ae0efaf6562a1d9396782974ca826ab11b16"}
name: "Smoke Claude"
"on":
@@ -132,188 +132,6 @@ jobs:
setupGlobals(core, github, context, exec, io);
const { main } = require('/opt/gh-aw/actions/add_workflow_run_comment.cjs');
await main();
- - name: Create prompt with built-in context
- env:
- GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
- GH_AW_SAFE_OUTPUTS: ${{ env.GH_AW_SAFE_OUTPUTS }}
- GH_AW_GITHUB_ACTOR: ${{ github.actor }}
- GH_AW_GITHUB_EVENT_COMMENT_ID: ${{ github.event.comment.id }}
- GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: ${{ github.event.discussion.number }}
- GH_AW_GITHUB_EVENT_ISSUE_NUMBER: ${{ github.event.issue.number }}
- GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}
- GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
- GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
- GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
- GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
- run: |
- bash /opt/gh-aw/actions/create_prompt_first.sh
- cat << 'GH_AW_PROMPT_EOF' > "$GH_AW_PROMPT"
-
- GH_AW_PROMPT_EOF
- cat "/opt/gh-aw/prompts/xpia.md" >> "$GH_AW_PROMPT"
- cat "/opt/gh-aw/prompts/temp_folder_prompt.md" >> "$GH_AW_PROMPT"
- cat "/opt/gh-aw/prompts/markdown.md" >> "$GH_AW_PROMPT"
- cat "/opt/gh-aw/prompts/playwright_prompt.md" >> "$GH_AW_PROMPT"
- cat "/opt/gh-aw/prompts/cache_memory_prompt.md" >> "$GH_AW_PROMPT"
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
-
- GitHub API Access Instructions
-
- The gh CLI is NOT authenticated. Do NOT use gh commands for GitHub operations.
-
-
- To create or modify GitHub resources (issues, discussions, pull requests, etc.), you MUST call the appropriate safe output tool. Simply writing content will NOT work - the workflow requires actual tool calls.
-
- Temporary IDs: Some safe output tools support a temporary ID field (usually named temporary_id) so you can reference newly-created items elsewhere in the SAME agent output (for example, using #aw_abc1 in a later body).
-
- **IMPORTANT - temporary_id format rules:**
- - If you DON'T need to reference the item later, OMIT the temporary_id field entirely (it will be auto-generated if needed)
- - If you DO need cross-references/chaining, you MUST match this EXACT validation regex: /^aw_[A-Za-z0-9]{3,8}$/i
- - Format: aw_ prefix followed by 3 to 8 alphanumeric characters (A-Z, a-z, 0-9, case-insensitive)
- - Valid alphanumeric characters: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
- - INVALID examples: aw_ab (too short), aw_123456789 (too long), aw_test-id (contains hyphen), aw_id_123 (contains underscore)
- - VALID examples: aw_abc, aw_abc1, aw_Test123, aw_A1B2C3D4, aw_12345678
- - To generate valid IDs: use 3-8 random alphanumeric characters or omit the field to let the system auto-generate
-
- Do NOT invent other aw_* formats — downstream steps will reject them with validation errors matching against /^aw_[A-Za-z0-9]{3,8}$/i.
-
- Discover available tools from the safeoutputs MCP server.
-
- **Critical**: Tool calls write structured data that downstream jobs process. Without tool calls, follow-up actions will be skipped.
-
- **Note**: If you made no other safe output tool calls during this workflow execution, call the "noop" tool to provide a status message indicating completion or that no actions were needed.
-
-
-
- The following GitHub context information is available for this workflow:
- {{#if __GH_AW_GITHUB_ACTOR__ }}
- - **actor**: __GH_AW_GITHUB_ACTOR__
- {{/if}}
- {{#if __GH_AW_GITHUB_REPOSITORY__ }}
- - **repository**: __GH_AW_GITHUB_REPOSITORY__
- {{/if}}
- {{#if __GH_AW_GITHUB_WORKSPACE__ }}
- - **workspace**: __GH_AW_GITHUB_WORKSPACE__
- {{/if}}
- {{#if __GH_AW_GITHUB_EVENT_ISSUE_NUMBER__ }}
- - **issue-number**: #__GH_AW_GITHUB_EVENT_ISSUE_NUMBER__
- {{/if}}
- {{#if __GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER__ }}
- - **discussion-number**: #__GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER__
- {{/if}}
- {{#if __GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER__ }}
- - **pull-request-number**: #__GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER__
- {{/if}}
- {{#if __GH_AW_GITHUB_EVENT_COMMENT_ID__ }}
- - **comment-id**: __GH_AW_GITHUB_EVENT_COMMENT_ID__
- {{/if}}
- {{#if __GH_AW_GITHUB_RUN_ID__ }}
- - **workflow-run-id**: __GH_AW_GITHUB_RUN_ID__
- {{/if}}
-
-
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
-
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/mcp-pagination.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/gh.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/mcp/tavily.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/reporting.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/github-queries-safe-input.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/go-make.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/github-mcp-app.md}}
- GH_AW_PROMPT_EOF
- cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-claude.md}}
- GH_AW_PROMPT_EOF
- - name: Interpolate variables and render templates
- uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
- env:
- GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
- GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
- GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
- GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
- GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
- with:
- script: |
- const { setupGlobals } = require('/opt/gh-aw/actions/setup_globals.cjs');
- setupGlobals(core, github, context, exec, io);
- const { main } = require('/opt/gh-aw/actions/interpolate_prompt.cjs');
- await main();
- - name: Substitute placeholders
- uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
- env:
- GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
- GH_AW_ALLOWED_EXTENSIONS: ''
- GH_AW_CACHE_DESCRIPTION: ''
- GH_AW_CACHE_DIR: '/tmp/gh-aw/cache-memory/'
- GH_AW_GITHUB_ACTOR: ${{ github.actor }}
- GH_AW_GITHUB_EVENT_COMMENT_ID: ${{ github.event.comment.id }}
- GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: ${{ github.event.discussion.number }}
- GH_AW_GITHUB_EVENT_ISSUE_NUMBER: ${{ github.event.issue.number }}
- GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}
- GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
- GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
- GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
- GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
- GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED: ${{ needs.pre_activation.outputs.activated }}
- GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND: ${{ needs.pre_activation.outputs.matched_command }}
- with:
- script: |
- const { setupGlobals } = require('/opt/gh-aw/actions/setup_globals.cjs');
- setupGlobals(core, github, context, exec, io);
-
- const substitutePlaceholders = require('/opt/gh-aw/actions/substitute_placeholders.cjs');
-
- // Call the substitution function
- return await substitutePlaceholders({
- file: process.env.GH_AW_PROMPT,
- substitutions: {
- GH_AW_ALLOWED_EXTENSIONS: process.env.GH_AW_ALLOWED_EXTENSIONS,
- GH_AW_CACHE_DESCRIPTION: process.env.GH_AW_CACHE_DESCRIPTION,
- GH_AW_CACHE_DIR: process.env.GH_AW_CACHE_DIR,
- GH_AW_GITHUB_ACTOR: process.env.GH_AW_GITHUB_ACTOR,
- GH_AW_GITHUB_EVENT_COMMENT_ID: process.env.GH_AW_GITHUB_EVENT_COMMENT_ID,
- GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: process.env.GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER,
- GH_AW_GITHUB_EVENT_ISSUE_NUMBER: process.env.GH_AW_GITHUB_EVENT_ISSUE_NUMBER,
- GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: process.env.GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER,
- GH_AW_GITHUB_REPOSITORY: process.env.GH_AW_GITHUB_REPOSITORY,
- GH_AW_GITHUB_RUN_ID: process.env.GH_AW_GITHUB_RUN_ID,
- GH_AW_GITHUB_SERVER_URL: process.env.GH_AW_GITHUB_SERVER_URL,
- GH_AW_GITHUB_WORKSPACE: process.env.GH_AW_GITHUB_WORKSPACE,
- GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED: process.env.GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED,
- GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND: process.env.GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND
- }
- });
- - name: Validate prompt placeholders
- env:
- GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
- run: bash /opt/gh-aw/actions/validate_prompt_placeholders.sh
- - name: Print prompt
- env:
- GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
- run: bash /opt/gh-aw/actions/print_prompt_summary.sh
- - name: Upload prompt artifact
- if: success()
- uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
- with:
- name: prompt
- path: /tmp/gh-aw/aw-prompts/prompt.txt
- retention-days: 1
agent:
needs: activation
@@ -1821,11 +1639,487 @@ jobs:
script: |
const { generateWorkflowOverview } = require('/opt/gh-aw/actions/generate_workflow_overview.cjs');
await generateWorkflowOverview(core);
- - name: Download prompt artifact
- uses: actions/download-artifact@018cc2cf5baa6db3ef3c5f8a56943fffe632ef53 # v6
+ - name: Create prompt with built-in context
+ env:
+ GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
+ GH_AW_SAFE_OUTPUTS: ${{ env.GH_AW_SAFE_OUTPUTS }}
+ GH_AW_GITHUB_ACTOR: ${{ github.actor }}
+ GH_AW_GITHUB_EVENT_COMMENT_ID: ${{ github.event.comment.id }}
+ GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: ${{ github.event.discussion.number }}
+ GH_AW_GITHUB_EVENT_ISSUE_NUMBER: ${{ github.event.issue.number }}
+ GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}
+ GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
+ GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
+ GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
+ GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
+ run: |
+ bash /opt/gh-aw/actions/create_prompt_first.sh
+ cat << 'GH_AW_PROMPT_EOF' > "$GH_AW_PROMPT"
+
+ GH_AW_PROMPT_EOF
+ cat "/opt/gh-aw/prompts/xpia.md" >> "$GH_AW_PROMPT"
+ cat "/opt/gh-aw/prompts/temp_folder_prompt.md" >> "$GH_AW_PROMPT"
+ cat "/opt/gh-aw/prompts/markdown.md" >> "$GH_AW_PROMPT"
+ cat "/opt/gh-aw/prompts/playwright_prompt.md" >> "$GH_AW_PROMPT"
+ cat "/opt/gh-aw/prompts/cache_memory_prompt.md" >> "$GH_AW_PROMPT"
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+
+ GitHub API Access Instructions
+
+ The gh CLI is NOT authenticated. Do NOT use gh commands for GitHub operations.
+
+
+ To create or modify GitHub resources (issues, discussions, pull requests, etc.), you MUST call the appropriate safe output tool. Simply writing content will NOT work - the workflow requires actual tool calls.
+
+ Temporary IDs: Some safe output tools support a temporary ID field (usually named temporary_id) so you can reference newly-created items elsewhere in the SAME agent output (for example, using #aw_abc1 in a later body).
+
+ **IMPORTANT - temporary_id format rules:**
+ - If you DON'T need to reference the item later, OMIT the temporary_id field entirely (it will be auto-generated if needed)
+ - If you DO need cross-references/chaining, you MUST match this EXACT validation regex: /^aw_[A-Za-z0-9]{3,8}$/i
+ - Format: aw_ prefix followed by 3 to 8 alphanumeric characters (A-Z, a-z, 0-9, case-insensitive)
+ - Valid alphanumeric characters: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
+ - INVALID examples: aw_ab (too short), aw_123456789 (too long), aw_test-id (contains hyphen), aw_id_123 (contains underscore)
+ - VALID examples: aw_abc, aw_abc1, aw_Test123, aw_A1B2C3D4, aw_12345678
+ - To generate valid IDs: use 3-8 random alphanumeric characters or omit the field to let the system auto-generate
+
+ Do NOT invent other aw_* formats — downstream steps will reject them with validation errors matching against /^aw_[A-Za-z0-9]{3,8}$/i.
+
+ Discover available tools from the safeoutputs MCP server.
+
+ **Critical**: Tool calls write structured data that downstream jobs process. Without tool calls, follow-up actions will be skipped.
+
+ **Note**: If you made no other safe output tool calls during this workflow execution, call the "noop" tool to provide a status message indicating completion or that no actions were needed.
+
+
+
+ The following GitHub context information is available for this workflow:
+ {{#if __GH_AW_GITHUB_ACTOR__ }}
+ - **actor**: __GH_AW_GITHUB_ACTOR__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_REPOSITORY__ }}
+ - **repository**: __GH_AW_GITHUB_REPOSITORY__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_WORKSPACE__ }}
+ - **workspace**: __GH_AW_GITHUB_WORKSPACE__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_EVENT_ISSUE_NUMBER__ }}
+ - **issue-number**: #__GH_AW_GITHUB_EVENT_ISSUE_NUMBER__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER__ }}
+ - **discussion-number**: #__GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER__ }}
+ - **pull-request-number**: #__GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_EVENT_COMMENT_ID__ }}
+ - **comment-id**: __GH_AW_GITHUB_EVENT_COMMENT_ID__
+ {{/if}}
+ {{#if __GH_AW_GITHUB_RUN_ID__ }}
+ - **workflow-run-id**: __GH_AW_GITHUB_RUN_ID__
+ {{/if}}
+
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+ ## MCP Response Size Limits
+
+ MCP tool responses have a **25,000 token limit**. When GitHub API responses exceed this limit, workflows must retry with pagination parameters, wasting turns and tokens.
+
+ ### Common Scenarios
+
+ **Problem**: Fetching large result sets without pagination
+ - `list_pull_requests` with many PRs (75,897 tokens in one case)
+ - `pull_request_read` with large diff/comments (31,675 tokens observed)
+ - `search_issues`, `search_code` with many results
+
+ **Solution**: Use proactive pagination to stay under token limits
+
+ ### Pagination Best Practices
+
+ #### 1. Use `perPage` Parameter
+
+ Limit results per request to prevent oversized responses:
+
+ ```bash
+ # Good: Fetch PRs in small batches
+ list_pull_requests --perPage 10
+
+ # Good: Get issue with limited comments
+ issue_read --method get_comments --perPage 20
+
+ # Bad: Default pagination may return too much data
+ list_pull_requests # May exceed 25k tokens
+ ```
+
+ #### 2. Common `perPage` Values
+
+ - **10-20**: For detailed items (PRs with diffs, issues with comments)
+ - **50-100**: For simpler list operations (commits, branches, labels)
+ - **1-5**: For exploratory queries or schema discovery
+
+ #### 3. Handle Pagination Loops
+
+ When you need all results:
+
+ ```bash
+ # Step 1: Fetch first page
+ result=$(list_pull_requests --perPage 20 --page 1)
+
+ # Step 2: Check if more pages exist
+ # Most list operations return metadata about total count or next page
+
+ # Step 3: Fetch subsequent pages if needed
+ result=$(list_pull_requests --perPage 20 --page 2)
+ ```
+
+ ### Tool-Specific Guidance
+
+ #### Pull Requests
+
+ ```bash
+ # Fetch recent PRs in small batches
+ list_pull_requests --state all --perPage 10 --sort updated --direction desc
+
+ # Get PR details without full diff/comments
+ pull_request_read --method get --pullNumber 123
+
+ # Get PR files separately if needed
+ pull_request_read --method get_files --pullNumber 123 --perPage 30
+ ```
+
+ #### Issues
+
+ ```bash
+ # List issues with pagination
+ list_issues --perPage 20 --page 1
+
+ # Get issue comments in batches
+ issue_read --method get_comments --issue_number 123 --perPage 20
+ ```
+
+ #### Code Search
+
+ ```bash
+ # Search with limited results
+ search_code --query "function language:go" --perPage 10
+ ```
+
+ ### Error Messages to Watch For
+
+ If you see these errors, add pagination:
+
+ - `MCP tool "list_pull_requests" response (75897 tokens) exceeds maximum allowed tokens (25000)`
+ - `MCP tool "pull_request_read" response (31675 tokens) exceeds maximum allowed tokens (25000)`
+ - `Response too large for tool [tool_name]`
+
+ ### Performance Tips
+
+ 1. **Start small**: Use `perPage: 10` initially, increase if needed
+ 2. **Fetch incrementally**: Get overview first, then details for specific items
+ 3. **Avoid wildcards**: Don't fetch all data when you need specific items
+ 4. **Use filters**: Combine `perPage` with state/label/date filters to reduce results
+
+ ### Example Workflow Pattern
+
+ ```markdown
+ # Analyze Recent Pull Requests
+
+ 1. Fetch 10 most recent PRs (stay under token limit)
+ 2. For each PR, get summary without full diff
+ 3. If detailed analysis needed, fetch files for specific PR separately
+ 4. Process results incrementally rather than loading everything at once
+ ```
+
+ This proactive approach eliminates retry loops and reduces token consumption.
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+ **IMPORTANT**: Always use the `safeinputs-gh` tool for GitHub CLI commands instead of running `gh` directly via bash. The `safeinputs-gh` tool has proper authentication configured with `GITHUB_TOKEN`, while bash commands do not have GitHub CLI authentication by default.
+
+ **Correct**:
+ ```
+ Use the safeinputs-gh tool with args: "pr list --limit 5"
+ Use the safeinputs-gh tool with args: "issue view 123"
+ ```
+
+ **Incorrect**:
+ ```
+ Use the gh safe-input tool with args: "pr list --limit 5" ❌ (Wrong tool name - use safeinputs-gh)
+ Run: gh pr list --limit 5 ❌ (No authentication in bash)
+ Execute bash: gh issue view 123 ❌ (No authentication in bash)
+ ```
+
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+ ## Report Structure Guidelines
+
+ ### 1. Header Levels
+ **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.**
+
+ When creating GitHub issues or discussions:
+ - Use `###` (h3) for main sections (e.g., "### Test Summary")
+ - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results")
+ - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles
+
+ ### 2. Progressive Disclosure
+ **Wrap detailed test results in `Section Name
` tags to improve readability and reduce scrolling.**
+
+ Use collapsible sections for:
+ - Verbose details (full test logs, raw data)
+ - Secondary information (minor warnings, extra context)
+ - Per-item breakdowns when there are many items
+
+ Always keep critical information visible (summary, critical issues, key metrics).
+
+ ### 3. Report Structure Pattern
+
+ 1. **Overview**: 1-2 paragraphs summarizing key findings
+ 2. **Critical Information**: Show immediately (summary stats, critical issues)
+ 3. **Details**: Use `Section Name
` for expanded content
+ 4. **Context**: Add helpful metadata (workflow run, date, trigger)
+
+ ### Design Principles (Airbnb-Inspired)
+
+ Reports should:
+ - **Build trust through clarity**: Most important info immediately visible
+ - **Exceed expectations**: Add helpful context like trends, comparisons
+ - **Create delight**: Use progressive disclosure to reduce overwhelm
+ - **Maintain consistency**: Follow patterns across all reports
+
+ ### Example Report Structure
+
+ ```markdown
+ ### Summary
+ - Key metric 1: value
+ - Key metric 2: value
+ - Status: ✅/⚠️/❌
+
+ ### Critical Issues
+ [Always visible - these are important]
+
+
+ View Detailed Results
+
+ [Comprehensive details, logs, traces]
+
+
+
+
+ View All Warnings
+
+ [Minor issues and potential problems]
+
+
+
+ ### Recommendations
+ [Actionable next steps - keep visible]
+ ```
+
+ ## Workflow Run References
+
+ - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)`
+ - Include up to 3 most relevant run URLs at end under `**References:**`
+ - Do NOT add footer attribution (system adds automatically)
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+ **IMPORTANT**: Always use the `safeinputs-go` and `safeinputs-make` tools for Go and Make commands instead of running them directly via bash. These safe-input tools provide consistent execution and proper logging.
+
+ **Correct**:
+ ```
+ Use the safeinputs-go tool with args: "test ./..."
+ Use the safeinputs-make tool with args: "build"
+ Use the safeinputs-make tool with args: "lint"
+ Use the safeinputs-make tool with args: "test-unit"
+ ```
+
+ **Incorrect**:
+ ```
+ Use the go safe-input tool with args: "test ./..." ❌ (Wrong tool name - use safeinputs-go)
+ Run: go test ./... ❌ (Use safeinputs-go instead)
+ Execute bash: make build ❌ (Use safeinputs-make instead)
+ ```
+
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+
+ GH_AW_PROMPT_EOF
+ cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
+ # Smoke Test: Claude Engine Validation.
+
+ **IMPORTANT: Keep all outputs extremely short and concise. Use single-line responses where possible. No verbose explanations.**
+
+ ## Test Requirements
+
+ 1. **GitHub MCP Testing**: Review the last 2 merged pull requests in __GH_AW_GITHUB_REPOSITORY__
+ 2. **Safe Inputs GH CLI Testing**: Use the `safeinputs-gh` tool to query 2 pull requests from __GH_AW_GITHUB_REPOSITORY__ (use args: "pr list --repo __GH_AW_GITHUB_REPOSITORY__ --limit 2 --json number,title,author")
+ 3. **Serena MCP Testing**:
+ - Use the Serena MCP server tool `activate_project` to initialize the workspace at `__GH_AW_GITHUB_WORKSPACE__` and verify it succeeds (do NOT use bash to run go commands - use Serena's MCP tools or the safeinputs-go/safeinputs-make tools from the go-make shared workflow)
+ - After initialization, use the `find_symbol` tool to search for symbols (find which tool to call) and verify that at least 3 symbols are found in the results
+ 4. **Make Build Testing**: Use the `safeinputs-make` tool to build the project (use args: "build") and verify it succeeds
+ 5. **Playwright Testing**: Use the playwright tools to navigate to https://github.com and verify the page title contains "GitHub" (do NOT try to install playwright - use the provided MCP tools)
+ 6. **Tavily Web Search Testing**: Use the Tavily MCP server to perform a web search for "GitHub Agentic Workflows" and verify that results are returned with at least one item
+ 7. **File Writing Testing**: Create a test file `/tmp/gh-aw/agent/smoke-test-claude-__GH_AW_GITHUB_RUN_ID__.txt` with content "Smoke test passed for Claude at $(date)" (create the directory if it doesn't exist)
+ 8. **Bash Tool Testing**: Execute bash commands to verify file creation was successful (use `cat` to read the file back)
+ 9. **Discussion Interaction Testing**:
+ - Use the `github-discussion-query` safe-input tool with params: `limit=1, jq=".[0]"` to get the latest discussion from __GH_AW_GITHUB_REPOSITORY__
+ - Extract the discussion number from the result (e.g., if the result is `{"number": 123, "title": "...", ...}`, extract 123)
+ - Use the `add_comment` tool with `discussion_number: ` to add a fun, comic-book style comment stating that the smoke test agent was here
+ 10. **Agentic Workflows MCP Testing**:
+ - Call the `agentic-workflows` MCP tool using the `status` method with workflow name `smoke-claude` to query workflow status
+ - If the tool returns an error or no results, mark this test as ❌ and note "Tool unavailable or workflow not found" but continue to the Output section
+ - If the tool succeeds, extract key information from the response: total runs, success/failure counts, last run timestamp
+ - Write a summary of the results to `/tmp/gh-aw/agent/smoke-claude-status-__GH_AW_GITHUB_RUN_ID__.txt` (create directory if needed)
+ - Use bash to verify the file was created and display its contents
+
+ ## PR Review Safe Outputs Testing
+
+ **IMPORTANT**: The following tests require an open pull request. First, use the GitHub MCP tool to find an open PR in __GH_AW_GITHUB_REPOSITORY__ (or use the triggering PR if this is a pull_request event). Store the PR number for use in subsequent tests.
+
+ 11. **Update PR Testing**: Use the `update_pull_request` tool to update the PR's body by appending a test message: "✨ PR Review Safe Output Test - Run __GH_AW_GITHUB_RUN_ID__"
+ - Use `pr_number: ` to target the open PR
+ - Use `operation: "append"` and `body: "\n\n---\n✨ PR Review Safe Output Test - Run __GH_AW_GITHUB_RUN_ID__"`
+ - Verify the tool call succeeds
+
+ 12. **PR Review Comment Testing**: Use the `create_pull_request_review_comment` tool to add review comments on the PR
+ - Find a file in the PR's diff (use GitHub MCP to get PR files)
+ - Add at least 2 review comments on different lines with constructive feedback
+ - Use `pr_number: `, `path: ""`, `line: `, and `body: ""`
+ - Verify the tool calls succeed
+
+ 13. **Submit PR Review Testing**: Use the `submit_pull_request_review` tool to submit a consolidated review
+ - Use `pr_number: `, `event: "COMMENT"`, and `body: "💥 Automated smoke test review - all systems nominal!"`
+ - Verify the review is submitted successfully
+ - Note: This will bundle all review comments from test #12
+
+ 14. **Resolve Review Thread Testing**:
+ - Use the GitHub MCP tool to list review threads on the PR
+ - If any threads exist, use the `resolve_pull_request_review_thread` tool to resolve one thread
+ - Use `thread_id: ""` from an existing thread
+ - If no threads exist, mark this test as ⚠️ (skipped - no threads to resolve)
+
+ 15. **Add Reviewer Testing**: Use the `add_reviewer` tool to add a reviewer to the PR
+ - Use `pr_number: ` and `reviewers: ["copilot"]` (or another valid reviewer)
+ - Verify the tool call succeeds
+ - Note: May fail if reviewer is already assigned or doesn't have access
+
+ 16. **Push to PR Branch Testing**:
+ - Create a test file at `/tmp/test-pr-push-__GH_AW_GITHUB_RUN_ID__.txt` with content "Test file for PR push"
+ - Use git commands to check if we're on the PR branch
+ - Use the `push_to_pull_request_branch` tool to push this change
+ - Use `pr_number: ` and `commit_message: "test: Add smoke test file"`
+ - Verify the push succeeds
+ - Note: This test may be skipped if not on a PR branch or if the PR is from a fork
+
+ 17. **Close PR Testing** (CONDITIONAL - only if a test PR exists):
+ - If you can identify a test/bot PR that can be safely closed, use the `close_pull_request` tool
+ - Use `pr_number: ` and `comment: "Closing as part of smoke test - Run __GH_AW_GITHUB_RUN_ID__"`
+ - If no suitable test PR exists, mark this test as ⚠️ (skipped - no safe PR to close)
+ - **DO NOT close the triggering PR or any important PRs**
+
+ ## Output
+
+ **CRITICAL: You MUST create an issue regardless of test results - this is a required safe output.**
+
+ 1. **ALWAYS create an issue** with a summary of the smoke test run:
+ - Title: "Smoke Test: Claude - __GH_AW_GITHUB_RUN_ID__"
+ - Body should include:
+ - Test results (✅ for pass, ❌ for fail, ⚠️ for skipped) for each test (including PR review tests #11-17)
+ - Overall status: PASS (all passed), PARTIAL (some skipped), or FAIL (any failed)
+ - Run URL: __GH_AW_GITHUB_SERVER_URL__/__GH_AW_GITHUB_REPOSITORY__/actions/runs/__GH_AW_GITHUB_RUN_ID__
+ - Timestamp
+ - Note which PR was used for PR review testing (if applicable)
+ - If ANY test fails, include error details in the issue body
+ - This issue MUST be created before any other safe output operations
+
+ 2. **Only if this workflow was triggered by a pull_request event**: Use the `add_comment` tool to add a **very brief** comment (max 5-10 lines) to the triggering pull request (omit the `item_number` parameter to auto-target the triggering PR) with:
+ - Test results for core tests #1-10 (✅ or ❌)
+ - Test results for PR review tests #11-17 (✅, ❌, or ⚠️)
+ - Overall status: PASS, PARTIAL, or FAIL
+
+ 3. Use the `add_comment` tool with `item_number` set to the discussion number you extracted in step 9 to add a **fun comic-book style comment** to that discussion - be playful and use comic-book language like "💥 WHOOSH!"
+ - If step 9 failed to extract a discussion number, skip this step
+
+ If all non-skipped tests pass, use the `add_labels` tool to add the label `smoke-claude` to the pull request (omit the `item_number` parameter to auto-target the triggering PR if this workflow was triggered by a pull_request event).
+
+ GH_AW_PROMPT_EOF
+ - name: Interpolate variables and render templates
+ uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
+ env:
+ GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
+ GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
+ GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
+ GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
+ GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
+ with:
+ script: |
+ const { setupGlobals } = require('/opt/gh-aw/actions/setup_globals.cjs');
+ setupGlobals(core, github, context, exec, io);
+ const { main } = require('/opt/gh-aw/actions/interpolate_prompt.cjs');
+ await main();
+ - name: Substitute placeholders
+ uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
+ env:
+ GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
+ GH_AW_ALLOWED_EXTENSIONS: ''
+ GH_AW_CACHE_DESCRIPTION: ''
+ GH_AW_CACHE_DIR: '/tmp/gh-aw/cache-memory/'
+ GH_AW_GITHUB_ACTOR: ${{ github.actor }}
+ GH_AW_GITHUB_EVENT_COMMENT_ID: ${{ github.event.comment.id }}
+ GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: ${{ github.event.discussion.number }}
+ GH_AW_GITHUB_EVENT_ISSUE_NUMBER: ${{ github.event.issue.number }}
+ GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}
+ GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}
+ GH_AW_GITHUB_RUN_ID: ${{ github.run_id }}
+ GH_AW_GITHUB_SERVER_URL: ${{ github.server_url }}
+ GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }}
+ GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED: ${{ needs.pre_activation.outputs.activated }}
+ GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND: ${{ needs.pre_activation.outputs.matched_command }}
with:
- name: prompt
- path: /tmp/gh-aw/aw-prompts
+ script: |
+ const { setupGlobals } = require('/opt/gh-aw/actions/setup_globals.cjs');
+ setupGlobals(core, github, context, exec, io);
+
+ const substitutePlaceholders = require('/opt/gh-aw/actions/substitute_placeholders.cjs');
+
+ // Call the substitution function
+ return await substitutePlaceholders({
+ file: process.env.GH_AW_PROMPT,
+ substitutions: {
+ GH_AW_ALLOWED_EXTENSIONS: process.env.GH_AW_ALLOWED_EXTENSIONS,
+ GH_AW_CACHE_DESCRIPTION: process.env.GH_AW_CACHE_DESCRIPTION,
+ GH_AW_CACHE_DIR: process.env.GH_AW_CACHE_DIR,
+ GH_AW_GITHUB_ACTOR: process.env.GH_AW_GITHUB_ACTOR,
+ GH_AW_GITHUB_EVENT_COMMENT_ID: process.env.GH_AW_GITHUB_EVENT_COMMENT_ID,
+ GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER: process.env.GH_AW_GITHUB_EVENT_DISCUSSION_NUMBER,
+ GH_AW_GITHUB_EVENT_ISSUE_NUMBER: process.env.GH_AW_GITHUB_EVENT_ISSUE_NUMBER,
+ GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER: process.env.GH_AW_GITHUB_EVENT_PULL_REQUEST_NUMBER,
+ GH_AW_GITHUB_REPOSITORY: process.env.GH_AW_GITHUB_REPOSITORY,
+ GH_AW_GITHUB_RUN_ID: process.env.GH_AW_GITHUB_RUN_ID,
+ GH_AW_GITHUB_SERVER_URL: process.env.GH_AW_GITHUB_SERVER_URL,
+ GH_AW_GITHUB_WORKSPACE: process.env.GH_AW_GITHUB_WORKSPACE,
+ GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED: process.env.GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_ACTIVATED,
+ GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND: process.env.GH_AW_NEEDS_PRE_ACTIVATION_OUTPUTS_MATCHED_COMMAND
+ }
+ });
+ - name: Validate prompt placeholders
+ env:
+ GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
+ run: bash /opt/gh-aw/actions/validate_prompt_placeholders.sh
+ - name: Print prompt
+ env:
+ GH_AW_PROMPT: /tmp/gh-aw/aw-prompts/prompt.txt
+ run: bash /opt/gh-aw/actions/print_prompt_summary.sh
- name: Clean git credentials
run: bash /opt/gh-aw/actions/clean_git_credentials.sh
- name: Execute Claude Code CLI
diff --git a/.github/workflows/smoke-claude.md b/.github/workflows/smoke-claude.md
index 798617ddf20..3d48c0ee63a 100644
--- a/.github/workflows/smoke-claude.md
+++ b/.github/workflows/smoke-claude.md
@@ -20,6 +20,7 @@ engine:
id: claude
max-turns: 100
strict: true
+inline-imports: true
imports:
- shared/mcp-pagination.md
- shared/gh.md
diff --git a/.github/workflows/smoke-codex.lock.yml b/.github/workflows/smoke-codex.lock.yml
index a92620b3608..6997ff69ad3 100644
--- a/.github/workflows/smoke-codex.lock.yml
+++ b/.github/workflows/smoke-codex.lock.yml
@@ -211,13 +211,126 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/gh.md}}
+ **IMPORTANT**: Always use the `safeinputs-gh` tool for GitHub CLI commands instead of running `gh` directly via bash. The `safeinputs-gh` tool has proper authentication configured with `GITHUB_TOKEN`, while bash commands do not have GitHub CLI authentication by default.
+
+ **Correct**:
+ ```
+ Use the safeinputs-gh tool with args: "pr list --limit 5"
+ Use the safeinputs-gh tool with args: "issue view 123"
+ ```
+
+ **Incorrect**:
+ ```
+ Use the gh safe-input tool with args: "pr list --limit 5" ❌ (Wrong tool name - use safeinputs-gh)
+ Run: gh pr list --limit 5 ❌ (No authentication in bash)
+ Execute bash: gh issue view 123 ❌ (No authentication in bash)
+ ```
+
+
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/reporting.md}}
+ ## Report Structure Guidelines
+
+ ### 1. Header Levels
+ **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.**
+
+ When creating GitHub issues or discussions:
+ - Use `###` (h3) for main sections (e.g., "### Test Summary")
+ - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results")
+ - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles
+
+ ### 2. Progressive Disclosure
+ **Wrap detailed test results in `Section Name
` tags to improve readability and reduce scrolling.**
+
+ Use collapsible sections for:
+ - Verbose details (full test logs, raw data)
+ - Secondary information (minor warnings, extra context)
+ - Per-item breakdowns when there are many items
+
+ Always keep critical information visible (summary, critical issues, key metrics).
+
+ ### 3. Report Structure Pattern
+
+ 1. **Overview**: 1-2 paragraphs summarizing key findings
+ 2. **Critical Information**: Show immediately (summary stats, critical issues)
+ 3. **Details**: Use `Section Name
` for expanded content
+ 4. **Context**: Add helpful metadata (workflow run, date, trigger)
+
+ ### Design Principles (Airbnb-Inspired)
+
+ Reports should:
+ - **Build trust through clarity**: Most important info immediately visible
+ - **Exceed expectations**: Add helpful context like trends, comparisons
+ - **Create delight**: Use progressive disclosure to reduce overwhelm
+ - **Maintain consistency**: Follow patterns across all reports
+
+ ### Example Report Structure
+
+ ```markdown
+ ### Summary
+ - Key metric 1: value
+ - Key metric 2: value
+ - Status: ✅/⚠️/❌
+
+ ### Critical Issues
+ [Always visible - these are important]
+
+
+ View Detailed Results
+
+ [Comprehensive details, logs, traces]
+
+
+
+
+ View All Warnings
+
+ [Minor issues and potential problems]
+
+
+
+ ### Recommendations
+ [Actionable next steps - keep visible]
+ ```
+
+ ## Workflow Run References
+
+ - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)`
+ - Include up to 3 most relevant run URLs at end under `**References:**`
+ - Do NOT add footer attribution (system adds automatically)
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-codex.md}}
+ # Smoke Test: Codex Engine Validation
+
+ **CRITICAL EFFICIENCY REQUIREMENTS:**
+ - Keep ALL outputs extremely short and concise. Use single-line responses.
+ - NO verbose explanations or unnecessary context.
+ - Minimize file reading - only read what is absolutely necessary for the task.
+ - Use targeted, specific queries - avoid broad searches or large data retrievals.
+
+ ## Test Requirements
+
+ 1. **GitHub MCP Testing**: Use GitHub MCP tools to fetch details of exactly 2 merged pull requests from __GH_AW_GITHUB_REPOSITORY__ (title and number only, no descriptions)
+ 2. **Serena MCP Testing**:
+ - Use the Serena MCP server tool `activate_project` to initialize the workspace at `__GH_AW_GITHUB_WORKSPACE__` and verify it succeeds (do NOT use bash to run go commands)
+ - After initialization, use the `find_symbol` tool to search for symbols and verify that at least 3 symbols are found in the results
+ 3. **Playwright Testing**: Use the playwright tools to navigate to https://github.com and verify the page title contains "GitHub" (do NOT try to install playwright - use the provided MCP tools)
+ 4. **File Writing Testing**: Create a test file `/tmp/gh-aw/agent/smoke-test-codex-__GH_AW_GITHUB_RUN_ID__.txt` with content "Smoke test passed for Codex at $(date)" (create the directory if it doesn't exist)
+ 5. **Bash Tool Testing**: Execute bash commands to verify file creation was successful (use `cat` to read the file back)
+ 6. **Build gh-aw**: Run `GOCACHE=/tmp/go-cache GOMODCACHE=/tmp/go-mod make build` to verify the agent can successfully build the gh-aw project (both caches must be set to /tmp because the default cache locations are not writable). If the command fails, mark this test as ❌ and report the failure.
+
+ ## Output
+
+ Add a **very brief** comment (max 5-10 lines) to the current pull request with:
+ - PR titles only (no descriptions)
+ - ✅ or ❌ for each test result
+ - Overall status: PASS or FAIL
+
+ If all tests pass:
+ - Use the `add_labels` safe-output tool to add the label `smoke-codex` to the pull request
+ - Use the `remove_labels` safe-output tool to remove the label `smoke` from the pull request
+ - Use the `unassign_from_user` safe-output tool to unassign the user `githubactionagent` from the pull request (this is a fictitious user used for testing)
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/smoke-copilot.lock.yml b/.github/workflows/smoke-copilot.lock.yml
index f86c43fdff0..d367a2c5cec 100644
--- a/.github/workflows/smoke-copilot.lock.yml
+++ b/.github/workflows/smoke-copilot.lock.yml
@@ -213,16 +213,146 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/gh.md}}
+ **IMPORTANT**: Always use the `safeinputs-gh` tool for GitHub CLI commands instead of running `gh` directly via bash. The `safeinputs-gh` tool has proper authentication configured with `GITHUB_TOKEN`, while bash commands do not have GitHub CLI authentication by default.
+
+ **Correct**:
+ ```
+ Use the safeinputs-gh tool with args: "pr list --limit 5"
+ Use the safeinputs-gh tool with args: "issue view 123"
+ ```
+
+ **Incorrect**:
+ ```
+ Use the gh safe-input tool with args: "pr list --limit 5" ❌ (Wrong tool name - use safeinputs-gh)
+ Run: gh pr list --limit 5 ❌ (No authentication in bash)
+ Execute bash: gh issue view 123 ❌ (No authentication in bash)
+ ```
+
+
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/reporting.md}}
+ ## Report Structure Guidelines
+
+ ### 1. Header Levels
+ **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.**
+
+ When creating GitHub issues or discussions:
+ - Use `###` (h3) for main sections (e.g., "### Test Summary")
+ - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results")
+ - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles
+
+ ### 2. Progressive Disclosure
+ **Wrap detailed test results in `Section Name
` tags to improve readability and reduce scrolling.**
+
+ Use collapsible sections for:
+ - Verbose details (full test logs, raw data)
+ - Secondary information (minor warnings, extra context)
+ - Per-item breakdowns when there are many items
+
+ Always keep critical information visible (summary, critical issues, key metrics).
+
+ ### 3. Report Structure Pattern
+
+ 1. **Overview**: 1-2 paragraphs summarizing key findings
+ 2. **Critical Information**: Show immediately (summary stats, critical issues)
+ 3. **Details**: Use `Section Name
` for expanded content
+ 4. **Context**: Add helpful metadata (workflow run, date, trigger)
+
+ ### Design Principles (Airbnb-Inspired)
+
+ Reports should:
+ - **Build trust through clarity**: Most important info immediately visible
+ - **Exceed expectations**: Add helpful context like trends, comparisons
+ - **Create delight**: Use progressive disclosure to reduce overwhelm
+ - **Maintain consistency**: Follow patterns across all reports
+
+ ### Example Report Structure
+
+ ```markdown
+ ### Summary
+ - Key metric 1: value
+ - Key metric 2: value
+ - Status: ✅/⚠️/❌
+
+ ### Critical Issues
+ [Always visible - these are important]
+
+
+ View Detailed Results
+
+ [Comprehensive details, logs, traces]
+
+
+
+
+ View All Warnings
+
+ [Minor issues and potential problems]
+
+
+
+ ### Recommendations
+ [Actionable next steps - keep visible]
+ ```
+
+ ## Workflow Run References
+
+ - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)`
+ - Include up to 3 most relevant run URLs at end under `**References:**`
+ - Do NOT add footer attribution (system adds automatically)
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/github-queries-safe-input.md}}
+
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-copilot.md}}
+ # Smoke Test: Copilot Engine Validation
+
+ **IMPORTANT: Keep all outputs extremely short and concise. Use single-line responses where possible. No verbose explanations.**
+
+ ## Test Requirements
+
+ 1. **GitHub MCP Testing**: Review the last 2 merged pull requests in __GH_AW_GITHUB_REPOSITORY__
+ 2. **Safe Inputs GH CLI Testing**: Use the `safeinputs-gh` tool to query 2 pull requests from __GH_AW_GITHUB_REPOSITORY__ (use args: "pr list --repo __GH_AW_GITHUB_REPOSITORY__ --limit 2 --json number,title,author")
+ 3. **Serena MCP Testing**:
+ - Use the Serena MCP server tool `activate_project` to initialize the workspace at `__GH_AW_GITHUB_WORKSPACE__` and verify it succeeds (do NOT use bash to run go commands - use Serena's MCP tools)
+ - After initialization, use the `find_symbol` tool to search for symbols (find which tool to call) and verify that at least 3 symbols are found in the results
+ 4. **Playwright Testing**: Use the playwright tools to navigate to and verify the page title contains "GitHub" (do NOT try to install playwright - use the provided MCP tools)
+ 5. **File Writing Testing**: Create a test file `/tmp/gh-aw/agent/smoke-test-copilot-__GH_AW_GITHUB_RUN_ID__.txt` with content "Smoke test passed for Copilot at $(date)" (create the directory if it doesn't exist)
+ 6. **Bash Tool Testing**: Execute bash commands to verify file creation was successful (use `cat` to read the file back)
+ 7. **Discussion Interaction Testing**:
+ - Use the `github-discussion-query` safe-input tool with params: `limit=1, jq=".[0]"` to get the latest discussion from __GH_AW_GITHUB_REPOSITORY__
+ - Extract the discussion number from the result (e.g., if the result is `{"number": 123, "title": "...", ...}`, extract 123)
+ - Use the `add_comment` tool with `discussion_number: ` to add a fun, playful comment stating that the smoke test agent was here
+ 8. **Build gh-aw**: Run `GOCACHE=/tmp/go-cache GOMODCACHE=/tmp/go-mod make build` to verify the agent can successfully build the gh-aw project (both caches must be set to /tmp because the default cache locations are not writable). If the command fails, mark this test as ❌ and report the failure.
+ 9. **Discussion Creation Testing**: Use the `create_discussion` safe-output tool to create a discussion in the announcements category titled "copilot was here" with the label "ai-generated"
+ 10. **Workflow Dispatch Testing**: Use the `dispatch_workflow` safe output tool to trigger the `haiku-printer` workflow with a haiku as the message input. Create an original, creative haiku about software testing or automation.
+ 11. **PR Review Testing**: Review the diff of the current pull request. Leave 1-2 inline `create_pull_request_review_comment` comments on specific lines, then call `submit_pull_request_review` with a brief body summarizing your review and event `COMMENT`.
+
+ ## Output
+
+ 1. **Create an issue** with a summary of the smoke test run:
+ - Title: "Smoke Test: Copilot - __GH_AW_GITHUB_RUN_ID__"
+ - Body should include:
+ - Test results (✅ or ❌ for each test)
+ - Overall status: PASS or FAIL
+ - Run URL: __GH_AW_GITHUB_SERVER_URL__/__GH_AW_GITHUB_REPOSITORY__/actions/runs/__GH_AW_GITHUB_RUN_ID__
+ - Timestamp
+ - Pull request author and assignees
+
+ 2. Add a **very brief** comment (max 5-10 lines) to the current pull request with:
+ - PR titles only (no descriptions)
+ - ✅ or ❌ for each test result
+ - Overall status: PASS or FAIL
+ - Mention the pull request author and any assignees
+
+ 3. Use the `add_comment` tool to add a **fun and creative comment** to the latest discussion (using the `discussion_number` you extracted in step 7) - be playful and entertaining in your comment
+
+ 4. Use the `send_slack_message` tool to send a brief summary message (e.g., "Smoke test __GH_AW_GITHUB_RUN_ID__: All tests passed! ✅")
+
+ If all tests pass:
+ - Use the `add_labels` safe-output tool to add the label `smoke-copilot` to the pull request
+ - Use the `remove_labels` safe-output tool to remove the label `smoke` from the pull request
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/smoke-project.lock.yml b/.github/workflows/smoke-project.lock.yml
index eca71a14f77..9b146de23b7 100644
--- a/.github/workflows/smoke-project.lock.yml
+++ b/.github/workflows/smoke-project.lock.yml
@@ -202,7 +202,83 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-project.md}}
+ # Smoke Test: Project Operations Validation
+
+ Default status field for any created items: "Todo".
+ Do the following operations EXACTLY in this order.
+ Do not re-create draft items but use their returned temporary-ids for the update operations.
+
+ ## Test Requirements
+
+ 1. **Add items**: Create items in the project using different content types:
+
+ a. **Draft Issue Creation**:
+ Call `update_project` with:
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "draft_issue"
+ - `draft_title`: "Test *draft issue* for `smoke-project`"
+ - `draft_body`: "Test draft issue for smoke test validation"
+ - `temporary_id`: "draft-1"
+ - `fields`: `{"Status": "Todo", "Priority": "High"}`
+
+ b. **PR Creation**:
+ Call `update_project` with:
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "pull_request"
+ - `content_number`: 14477
+ - `fields`: `{"Status": "Todo", "Priority": "High"}`
+
+ c. **Issue Creation**:
+ Call `update_project` with:
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "issue"
+ - `content_number`: 14478
+ - `fields`: `{"Status": "Todo", "Priority": "High"}`
+
+ 2. **Update items**: Update the created items to validate field updates:
+
+ a. **Draft Issue Update**:
+ Call `update_project` with the draft issue you created (use the returned temporary-id) to change status to "In Progress":
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "draft_issue"
+ - `draft_issue_id`: The temporary-id returned from step 1a (e.g., "aw_abc123")
+ - `fields`: `{"Status": "In Progress"}`
+
+ b. **Pull Request Update**:
+ Call `update_project` to update the pull request item to change status to "In Progress":
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "pull_request"
+ - `content_number`: 14477
+ - `fields`: `{"Status": "In Progress"}`
+
+ c. **Issue Update**:
+ Call `update_project` to update the issue item to change status to "In Progress":
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `content_type`: "issue"
+ - `content_number`: 14478
+ - `fields`: `{"Status": "In Progress"}`
+
+ 3. **Project Status Update**:
+
+ a. Create a markdown report summarizing all the operations performed. Keep it short but make it clear what worked and what didn't:
+ Example `body`:
+ ```md
+ ## Run Summary
+ - Run: [{workflow_name}]({run_url})
+ - List of operations performed:
+ - [x] Created *draft issue* update with status "Todo"
+ - [ ] ...
+ ```
+
+ b. Call `create_project_status_update` with the report from step 3a.
+ Required fields:
+ - `project`: "https://github.com/orgs/github/projects/24068"
+ - `body`: The markdown report created in step 3a
+ Optional fields:
+ - `status`: "ON_TRACK" | "AT_RISK" | "OFF_TRACK" | "COMPLETE" | "INACTIVE"
+ - `start_date`: Optional date in "YYYY-MM-DD" format (if you want to represent the run start)
+ - `target_date`: Optional date in "YYYY-MM-DD" format (if you want to represent the run target/end)
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/smoke-temporary-id.lock.yml b/.github/workflows/smoke-temporary-id.lock.yml
index 3c8bdd109d6..96c4b7a0768 100644
--- a/.github/workflows/smoke-temporary-id.lock.yml
+++ b/.github/workflows/smoke-temporary-id.lock.yml
@@ -202,7 +202,78 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-temporary-id.md}}
+ # Smoke Test: Temporary ID Functionality
+
+ This workflow validates that temporary IDs work correctly for:
+ 1. Creating parent-child issue hierarchies
+ 2. Cross-referencing issues in bodies
+ 3. Different temporary ID formats (3-8 alphanumeric characters)
+
+ **IMPORTANT**: Use the exact temporary ID format `aw_` followed by 3-8 alphanumeric characters (A-Za-z0-9).
+
+ ## Test 1: Create Parent Issue with Temporary ID
+
+ Create a parent tracking issue with a temporary ID. Use a 6-character alphanumeric ID.
+
+ ```json
+ {
+ "type": "create_issue",
+ "temporary_id": "aw_test01",
+ "title": "Test Parent: Temporary ID Validation",
+ "body": "This is a parent issue created to test temporary ID functionality.\n\nSub-issues:\n- #aw_test02\n- #aw_test03\n\nAll references should be replaced with actual issue numbers."
+ }
+ ```
+
+ ## Test 2: Create Sub-Issues with Cross-References
+
+ Create two sub-issues that reference each other and the parent using temporary IDs.
+
+ ### Sub-Issue 1
+
+ ```json
+ {
+ "type": "create_issue",
+ "temporary_id": "aw_test02",
+ "parent": "aw_test01",
+ "title": "Sub-Issue 1: Test Temporary ID References",
+ "body": "This is sub-issue 1.\n\nParent: #aw_test01\nRelated: #aw_test03\n\nAll temporary IDs should be resolved to actual issue numbers."
+ }
+ ```
+
+ ### Sub-Issue 2
+
+ ```json
+ {
+ "type": "create_issue",
+ "temporary_id": "aw_test03",
+ "parent": "aw_test01",
+ "title": "Sub-Issue 2: Test Different ID Length",
+ "body": "This is sub-issue 2 with an 8-character temporary ID.\n\nParent: #aw_test01\nRelated: #aw_test02\n\nTesting that longer temporary IDs (8 chars) work correctly."
+ }
+ ```
+
+ ## Test 3: Verify Link Structure
+
+ After the issues are created, verify they are properly linked by adding a comment to the parent issue summarizing the test results.
+
+ ```json
+ {
+ "type": "add_comment",
+ "issue_number": "aw_test01",
+ "body": "## Test Results\n\n✅ Parent issue created with temporary ID `aw_test01`\n✅ Sub-issue 1 created with temporary ID `aw_test02` and linked to parent\n✅ Sub-issue 2 created with temporary ID `aw_test03` and linked to parent\n✅ Cross-references resolved correctly\n\n**Validation**: Check that:\n1. All temporary ID references (#aw_*) in issue bodies are replaced with actual issue numbers (#123)\n2. Sub-issues show parent relationship in GitHub UI\n3. Parent issue shows sub-issues in task list\n\nTemporary ID format validated: `aw_[A-Za-z0-9]{3,8}`"
+ }
+ ```
+
+ ## Expected Outcome
+
+ 1. Parent issue #aw_test01 created and assigned actual issue number (e.g., #1234)
+ 2. Sub-issues #aw_test02 and #aw_test03 created with actual issue numbers
+ 3. All references like `#aw_test01` replaced with actual numbers like `#1234`
+ 4. Sub-issues properly linked to parent with `parent` field
+ 5. Comment added to parent verifying the test results
+
+ **Success Criteria**: All 3 issues created, all temporary ID references resolved, parent-child relationships established.
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/smoke-test-tools.lock.yml b/.github/workflows/smoke-test-tools.lock.yml
index e3af3d10d2a..a0d63156e0e 100644
--- a/.github/workflows/smoke-test-tools.lock.yml
+++ b/.github/workflows/smoke-test-tools.lock.yml
@@ -188,7 +188,77 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/smoke-test-tools.md}}
+ # Smoke Test: Agent Container Tools
+
+ **Purpose:** Quick validation that common development tools are accessible in the agent container environment.
+
+ **IMPORTANT:** Keep all outputs concise. Report each tool test with ✅ or ❌ status.
+
+ ## Required Tool Tests
+
+ Run each command and verify it produces valid output:
+
+ 1. **Shell Tools:**
+ - `bash --version` - Verify Bash shell is available
+ - `sh --version` or `sh -c 'echo ok'` - Verify sh shell works
+
+ 2. **Version Control:**
+ - `git --version` - Verify Git is available
+
+ 3. **JSON/YAML Processing:**
+ - `jq --version` - Verify jq is available for JSON processing
+ - `yq --version` - Verify yq is available for YAML processing
+
+ 4. **HTTP Tools:**
+ - `curl --version` - Verify curl is available for HTTP requests
+
+ 5. **GitHub CLI:**
+ - `gh --version` - Verify GitHub CLI is available
+
+ 6. **Programming Runtimes:**
+ - `node --version` - Verify Node.js runtime is available
+ - `python3 --version` - Verify Python 3 runtime is available
+ - `go version` - Verify Go runtime is available
+ - `java --version` - Verify Java runtime is available
+ - `dotnet --version` - Verify .NET runtime is available (C#)
+
+ ## Output Requirements
+
+ After running all tests, add a **concise comment** to the pull request (if triggered by PR) with:
+
+ - Each tool name with ✅ (available) or ❌ (missing) status
+ - Total count: "X/12 tools available"
+ - Overall status: PASS (all tools found) or FAIL (any missing)
+
+ Example output format:
+ ```
+ ## Agent Container Tool Check
+
+ | Tool | Status | Version |
+ |------|--------|---------|
+ | bash | ✅ | 5.2.x |
+ | sh | ✅ | available |
+ | git | ✅ | 2.x.x |
+ | jq | ✅ | 1.x |
+ | yq | ✅ | 4.x |
+ | curl | ✅ | 8.x |
+ | gh | ✅ | 2.x |
+ | node | ✅ | 20.x |
+ | python3 | ✅ | 3.x |
+ | go | ✅ | 1.24.x |
+ | java | ✅ | 21.x |
+ | dotnet | ✅ | 8.x |
+
+ **Result:** 12/12 tools available ✅
+ ```
+
+ ## Error Handling
+
+ If any tool is missing:
+ 1. Report which tool(s) are unavailable
+ 2. Mark overall status as FAIL
+ 3. Include the error message from the failed version check
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/stale-repo-identifier.lock.yml b/.github/workflows/stale-repo-identifier.lock.yml
index 2c8f830f397..3d9ef6f5219 100644
--- a/.github/workflows/stale-repo-identifier.lock.yml
+++ b/.github/workflows/stale-repo-identifier.lock.yml
@@ -183,19 +183,660 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/mood.md}}
+ .
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/python-dataviz.md}}
+ # Python Data Visualization Guide
+
+ Python scientific libraries have been installed and are ready for use. A temporary folder structure has been created at `/tmp/gh-aw/python/` for organizing scripts, data, and outputs.
+
+ ## Installed Libraries
+
+ - **NumPy**: Array processing and numerical operations
+ - **Pandas**: Data manipulation and analysis
+ - **Matplotlib**: Chart generation and plotting
+ - **Seaborn**: Statistical data visualization
+ - **SciPy**: Scientific computing utilities
+
+ ## Directory Structure
+
+ ```
+ /tmp/gh-aw/python/
+ ├── data/ # Store all data files here (CSV, JSON, etc.)
+ ├── charts/ # Generated chart images (PNG)
+ ├── artifacts/ # Additional output files
+ └── *.py # Python scripts
+ ```
+
+ ## Data Separation Requirement
+
+ **CRITICAL**: Data must NEVER be inlined in Python code. Always store data in external files and load using pandas.
+
+ ### ❌ PROHIBITED - Inline Data
+ ```python
+ # DO NOT do this
+ data = [10, 20, 30, 40, 50]
+ labels = ['A', 'B', 'C', 'D', 'E']
+ ```
+
+ ### ✅ REQUIRED - External Data Files
+ ```python
+ # Always load data from external files
+ import pandas as pd
+
+ # Load data from CSV
+ data = pd.read_csv('/tmp/gh-aw/python/data/data.csv')
+
+ # Or from JSON
+ data = pd.read_json('/tmp/gh-aw/python/data/data.json')
+ ```
+
+ ## Chart Generation Best Practices
+
+ ### High-Quality Chart Settings
+
+ ```python
+ import matplotlib.pyplot as plt
+ import seaborn as sns
+
+ # Set style for better aesthetics
+ sns.set_style("whitegrid")
+ sns.set_palette("husl")
+
+ # Create figure with high DPI
+ fig, ax = plt.subplots(figsize=(10, 6), dpi=300)
+
+ # Your plotting code here
+ # ...
+
+ # Save with high quality
+ plt.savefig('/tmp/gh-aw/python/charts/chart.png',
+ dpi=300,
+ bbox_inches='tight',
+ facecolor='white',
+ edgecolor='none')
+ ```
+
+ ### Chart Quality Guidelines
+
+ - **DPI**: Use 300 or higher for publication quality
+ - **Figure Size**: Standard is 10x6 inches (adjustable based on needs)
+ - **Labels**: Always include clear axis labels and titles
+ - **Legend**: Add legends when plotting multiple series
+ - **Grid**: Enable grid lines for easier reading
+ - **Colors**: Use colorblind-friendly palettes (seaborn defaults are good)
+
+ ## Including Images in Reports
+
+ When creating reports (issues, discussions, etc.), use the `upload asset` tool to make images URL-addressable and include them in markdown:
+
+ ### Step 1: Generate and Upload Chart
+ ```python
+ # Generate your chart
+ plt.savefig('/tmp/gh-aw/python/charts/my_chart.png', dpi=300, bbox_inches='tight')
+ ```
+
+ ### Step 2: Upload as Asset
+ Use the `upload asset` tool to upload the chart file. The tool will return a GitHub raw content URL.
+
+ ### Step 3: Include in Markdown Report
+ When creating your discussion or issue, include the image using markdown:
+
+ ```markdown
+ ## Visualization Results
+
+ 
+
+ The chart above shows...
+ ```
+
+ **Important**: Assets are published to an orphaned git branch and become URL-addressable after workflow completion.
+
+ ## Cache Memory Integration
+
+ The cache memory at `/tmp/gh-aw/cache-memory/` is available for storing reusable code:
+
+ **Helper Functions to Cache:**
+ - Data loading utilities: `data_loader.py`
+ - Chart styling functions: `chart_utils.py`
+ - Common data transformations: `transforms.py`
+
+ **Check Cache Before Creating:**
+ ```bash
+ # Check if helper exists in cache
+ if [ -f /tmp/gh-aw/cache-memory/data_loader.py ]; then
+ cp /tmp/gh-aw/cache-memory/data_loader.py /tmp/gh-aw/python/
+ echo "Using cached data_loader.py"
+ fi
+ ```
+
+ **Save to Cache for Future Runs:**
+ ```bash
+ # Save useful helpers to cache
+ cp /tmp/gh-aw/python/data_loader.py /tmp/gh-aw/cache-memory/
+ echo "Saved data_loader.py to cache for future runs"
+ ```
+
+ ## Complete Example Workflow
+
+ ```python
+ #!/usr/bin/env python3
+ """
+ Example data visualization script
+ Generates a bar chart from external data
+ """
+ import pandas as pd
+ import matplotlib.pyplot as plt
+ import seaborn as sns
+
+ # Set style
+ sns.set_style("whitegrid")
+ sns.set_palette("husl")
+
+ # Load data from external file (NEVER inline)
+ data = pd.read_csv('/tmp/gh-aw/python/data/data.csv')
+
+ # Process data
+ summary = data.groupby('category')['value'].sum()
+
+ # Create chart
+ fig, ax = plt.subplots(figsize=(10, 6), dpi=300)
+ summary.plot(kind='bar', ax=ax)
+
+ # Customize
+ ax.set_title('Data Summary by Category', fontsize=16, fontweight='bold')
+ ax.set_xlabel('Category', fontsize=12)
+ ax.set_ylabel('Value', fontsize=12)
+ ax.grid(True, alpha=0.3)
+
+ # Save chart
+ plt.savefig('/tmp/gh-aw/python/charts/chart.png',
+ dpi=300,
+ bbox_inches='tight',
+ facecolor='white')
+
+ print("Chart saved to /tmp/gh-aw/python/charts/chart.png")
+ ```
+
+ ## Error Handling
+
+ **Check File Existence:**
+ ```python
+ import os
+
+ data_file = '/tmp/gh-aw/python/data/data.csv'
+ if not os.path.exists(data_file):
+ raise FileNotFoundError(f"Data file not found: {data_file}")
+ ```
+
+ **Validate Data:**
+ ```python
+ # Check for required columns
+ required_cols = ['category', 'value']
+ missing = set(required_cols) - set(data.columns)
+ if missing:
+ raise ValueError(f"Missing columns: {missing}")
+ ```
+
+ ## Artifact Upload
+
+ Charts and source files are automatically uploaded as artifacts:
+
+ **Charts Artifact:**
+ - Name: `data-charts`
+ - Contents: PNG files from `/tmp/gh-aw/python/charts/`
+ - Retention: 30 days
+
+ **Source and Data Artifact:**
+ - Name: `python-source-and-data`
+ - Contents: Python scripts and data files
+ - Retention: 30 days
+
+ Both artifacts are uploaded with `if: always()` condition, ensuring they're available even if the workflow fails.
+
+ ## Tips for Success
+
+ 1. **Always Separate Data**: Store data in files, never inline in code
+ 2. **Use Cache Memory**: Store reusable helpers for faster execution
+ 3. **High Quality Charts**: Use DPI 300+ and proper sizing
+ 4. **Clear Documentation**: Add docstrings and comments
+ 5. **Error Handling**: Validate data and check file existence
+ 6. **Type Hints**: Use type annotations for better code quality
+ 7. **Seaborn Defaults**: Leverage seaborn for better aesthetics
+ 8. **Reproducibility**: Set random seeds when needed
+
+ ## Common Data Sources
+
+ Based on common use cases:
+
+ **Repository Statistics:**
+ ```python
+ # Collect via GitHub API, save to data.csv
+ # Then load and visualize
+ data = pd.read_csv('/tmp/gh-aw/python/data/repo_stats.csv')
+ ```
+
+ **Workflow Metrics:**
+ ```python
+ # Collect via GitHub Actions API, save to data.json
+ data = pd.read_json('/tmp/gh-aw/python/data/workflow_metrics.json')
+ ```
+
+ **Sample Data Generation:**
+ ```python
+ # Generate with NumPy, save to file first
+ import numpy as np
+ data = np.random.randn(100, 2)
+ df = pd.DataFrame(data, columns=['x', 'y'])
+ df.to_csv('/tmp/gh-aw/python/data/sample_data.csv', index=False)
+
+ # Then load it back (demonstrating the pattern)
+ data = pd.read_csv('/tmp/gh-aw/python/data/sample_data.csv')
+ ```
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/jqschema.md}}
+ ## jqschema - JSON Schema Discovery
+
+ A utility script is available at `/tmp/gh-aw/jqschema.sh` to help you discover the structure of complex JSON responses.
+
+ ### Purpose
+
+ Generate a compact structural schema (keys + types) from JSON input. This is particularly useful when:
+ - Analyzing tool outputs from GitHub search (search_code, search_issues, search_repositories)
+ - Exploring API responses with large payloads
+ - Understanding the structure of unfamiliar data without verbose output
+ - Planning queries before fetching full data
+
+ ### Usage
+
+ ```bash
+ # Analyze a file
+ cat data.json | /tmp/gh-aw/jqschema.sh
+
+ # Analyze command output
+ echo '{"name": "test", "count": 42, "items": [{"id": 1}]}' | /tmp/gh-aw/jqschema.sh
+
+ # Analyze GitHub search results
+ gh api search/repositories?q=language:go | /tmp/gh-aw/jqschema.sh
+ ```
+
+ ### How It Works
+
+ The script transforms JSON data by:
+ 1. Replacing object values with their type names ("string", "number", "boolean", "null")
+ 2. Reducing arrays to their first element's structure (or empty array if empty)
+ 3. Recursively processing nested structures
+ 4. Outputting compact (minified) JSON
+
+ ### Example
+
+ **Input:**
+ ```json
+ {
+ "total_count": 1000,
+ "items": [
+ {"login": "user1", "id": 123, "verified": true},
+ {"login": "user2", "id": 456, "verified": false}
+ ]
+ }
+ ```
+
+ **Output:**
+ ```json
+ {"total_count":"number","items":[{"login":"string","id":"number","verified":"boolean"}]}
+ ```
+
+ ### Best Practices
+
+ **Use this script when:**
+ - You need to understand the structure of tool outputs before requesting full data
+ - GitHub search tools return large datasets (use `perPage: 1` and pipe through schema minifier first)
+ - Exploring unfamiliar APIs or data structures
+ - Planning data extraction strategies
+
+ **Example workflow for GitHub search tools:**
+ ```bash
+ # Step 1: Get schema with minimal data (fetch just 1 result)
+ # This helps understand the structure before requesting large datasets
+ echo '{}' | gh api search/repositories -f q="language:go" -f per_page=1 | /tmp/gh-aw/jqschema.sh
+
+ # Output shows the schema:
+ # {"incomplete_results":"boolean","items":[{...}],"total_count":"number"}
+
+ # Step 2: Review schema to understand available fields
+
+ # Step 3: Request full data with confidence about structure
+ # Now you know what fields are available and can query efficiently
+ ```
+
+ **Using with GitHub MCP tools:**
+ When using tools like `search_code`, `search_issues`, or `search_repositories`, pipe the output through jqschema to discover available fields:
+ ```bash
+ # Save a minimal search result to a file
+ gh api search/code -f q="jq in:file language:bash" -f per_page=1 > /tmp/sample.json
+
+ # Generate schema to understand structure
+ cat /tmp/sample.json | /tmp/gh-aw/jqschema.sh
+
+ # Now you know which fields exist and can use them in your analysis
+ ```
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/trending-charts-simple.md}}
+ # Python Environment Ready
+
+ Libraries: NumPy, Pandas, Matplotlib, Seaborn, SciPy
+ Directories: `/tmp/gh-aw/python/{data,charts,artifacts}`, `/tmp/gh-aw/cache-memory/`
+
+ ## Store Historical Data (JSON Lines)
+
+ ```python
+ import json
+ from datetime import datetime
+
+ # Append data point
+ with open('/tmp/gh-aw/cache-memory/trending//history.jsonl', 'a') as f:
+ f.write(json.dumps({"timestamp": datetime.now().isoformat(), "value": 42}) + '\n')
+ ```
+
+ ## Generate Charts
+
+ ```python
+ import pandas as pd
+ import matplotlib.pyplot as plt
+ import seaborn as sns
+
+ df = pd.read_json('history.jsonl', lines=True)
+ df['date'] = pd.to_datetime(df['timestamp']).dt.date
+
+ sns.set_style("whitegrid")
+ fig, ax = plt.subplots(figsize=(12, 7), dpi=300)
+ df.groupby('date')['value'].mean().plot(ax=ax, marker='o')
+ ax.set_title('Trend', fontsize=16, fontweight='bold')
+ plt.xticks(rotation=45)
+ plt.tight_layout()
+ plt.savefig('/tmp/gh-aw/python/charts/trend.png', dpi=300, bbox_inches='tight')
+ ```
+
+ ## Best Practices
+
+ - Use JSON Lines (`.jsonl`) for append-only storage
+ - Include ISO 8601 timestamps in all data points
+ - Implement 90-day retention: `df[df['timestamp'] >= cutoff_date]`
+ - Charts: 300 DPI, 12x7 inches, clear labels, seaborn style
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/stale-repo-identifier.md}}
+ # Stale Repository Identifier 🔍
+
+ You are an expert repository analyst that deeply investigates potentially stale repositories to determine if they are truly inactive and produces comprehensive activity reports.
+
+ ## Mission
+
+ Analyze repositories identified as potentially stale by the stale-repos tool and conduct deep research to:
+ 1. Verify that repositories are actually inactive
+ 2. Understand the repository's purpose and state
+ 3. Analyze recent activity patterns across commits, issues, and pull requests
+ 4. Assess whether the repository should remain active or be archived
+ 5. Create detailed reports as GitHub issues with findings
+
+ ## Context
+
+ - **Organization**: __GH_AW_ENV_ORGANIZATION__
+ - **Inactive Threshold**: 365 days
+ - **Exempt Topics**: keep, template
+ - **Repository**: __GH_AW_GITHUB_REPOSITORY__
+ - **Run ID**: __GH_AW_GITHUB_RUN_ID__
+
+ ## Data Available
+
+ The stale-repos tool has identified potentially inactive repositories. The output is saved at:
+ - **File**: `/tmp/stale-repos-data/inactive-repos.json`
+
+ This file contains an array of repository objects with information about each stale repository.
+
+ ## Investigation Process
+
+ ### Step 1: Load Stale Repositories Data
+
+ Read the stale repositories data:
+ ```bash
+ cat /tmp/stale-repos-data/inactive-repos.json | jq .
+ ```
+
+ Analyze the structure and count:
+ ```bash
+ echo "Total stale repositories: $(jq 'length' /tmp/stale-repos-data/inactive-repos.json)"
+ ```
+
+ ### Step 2: Deep Research Each Repository
+
+ For EACH **PUBLIC** repository in the list, conduct a thorough investigation:
+
+ **CRITICAL**: Before analyzing any repository, verify it is public. Skip all private repositories.
+
+ #### 2.1 Repository Overview
+ Use the GitHub MCP tools to gather:
+ - Repository name, description, and topics
+ - Primary language and size
+ - Creation date and last update date
+ - Default branch
+ - Visibility (public/private) - **ONLY ANALYZE PUBLIC REPOSITORIES**
+ - Archive status
+
+ **IMPORTANT**: Skip any private repositories. This workflow only reviews public repositories.
+
+ #### 2.2 Commit Activity Analysis
+ Analyze commit history:
+ - Last commit date and author
+ - Commit frequency over the last 2 years
+ - Number of unique contributors in the last year
+ - Trend analysis: Is activity declining or has it stopped abruptly?
+
+ Use the GitHub MCP `list_commits` tool to get commit history:
+ ```
+ List commits for the repository to analyze recent activity
+ ```
+
+ #### 2.3 Issue Activity Analysis
+ Examine issue activity:
+ - Total open and closed issues
+ - Recent issue activity (last 6 months)
+ - Average time to close issues
+ - Any open issues that need attention
+
+ Use the GitHub MCP `search_issues` or `list_issues` tool:
+ ```
+ Search for recent issues in the repository
+ ```
+
+ #### 2.4 Pull Request Activity
+ Review pull request patterns:
+ - Recent PRs (last 6 months)
+ - Merged vs. closed without merging
+ - Outstanding open PRs
+ - Review activity
+
+ Use the GitHub MCP `list_pull_requests` or `search_pull_requests` tool:
+ ```
+ List pull requests to understand merge activity
+ ```
+
+ #### 2.5 Release Activity
+ If the repository has releases:
+ - Last release date
+ - Release frequency
+ - Version progression
+
+ Use the GitHub MCP `list_releases` tool:
+ ```
+ List releases to check deployment activity
+ ```
+
+ #### 2.6 Repository Health Indicators
+ Assess repository health:
+ - **Active Development**: Recent commits, PRs, and issues
+ - **Community Engagement**: External contributions, issue discussions
+ - **Maintenance Status**: Response to issues/PRs, dependency updates
+ - **Documentation**: README quality, up-to-date docs
+ - **Dependencies**: Outdated dependencies, security alerts
+
+ ### Step 3: Determine True Status
+
+ Based on your research, classify each repository:
+
+ 1. **Truly Stale**: No meaningful activity, should be archived
+ - No commits in 365+ days
+ - No open issues or PRs requiring attention
+ - No ongoing projects or roadmap items
+ - No active community engagement
+
+ 2. **Low Activity but Active**: Slow-moving but not abandoned
+ - Occasional commits or maintenance
+ - Responsive to critical issues
+ - Stable mature project with low change rate
+
+ 3. **False Positive**: Appears stale but actually active
+ - Activity in other branches
+ - External development (forks, dependent projects)
+ - Strategic repository (documentation, templates)
+ - Recently migrated or reorganized
+
+ 4. **Requires Attention**: Active but needs maintenance
+ - Outstanding security issues
+ - Outdated dependencies
+ - Unanswered issues or PRs
+
+ ### Edge Cases to Consider
+
+ When analyzing repositories, be aware of these special cases:
+
+ - **Private Repositories**: ALWAYS skip private repositories. This workflow only analyzes public repositories.
+ - **Already Archived**: If a repository is already archived, skip it (no issue needed)
+ - **Seasonal Projects**: Some repositories have cyclical activity patterns (e.g., annual conference sites, seasonal tools). Look for historical patterns.
+ - **Dependency Repositories**: Check if other projects depend on this repository. Use GitHub's "Used by" information if available.
+ - **Template/Example Repositories**: Repositories marked with "template" topic or containing example/demo code may intentionally have low activity.
+ - **Documentation Repositories**: Documentation-only repos often have legitimate periods of low activity between major updates.
+ - **Mono-repo Subprojects**: Activity might be happening in a parent repository or related repos.
+ - **Bot-Maintained Repositories**: Some repos are primarily maintained by automated systems and may appear to have "stale" human activity.
+
+ ### Step 4: Create Detailed Issue Reports
+
+ For each repository classified as **Truly Stale** or **Requires Attention**, create an issue with:
+
+ **Issue Title Format**: `[Stale Repository] - `
+
+ **Issue Body Template**:
+ ```markdown
+ ## Repository Analysis: [Repository Name]
+
+ **Repository URL**: [repository URL]
+ **Last Activity**: [date]
+ **Classification**: [Truly Stale / Requires Attention]
+ **Workflow Run ID**: __GH_AW_GITHUB_RUN_ID__
+
+ ### 📊 Activity Summary
+
+ #### Commits
+ - **Last Commit**: [date] by [author]
+ - **Commits (Last Year)**: [count]
+ - **Contributors (Last Year)**: [count]
+ - **Activity Trend**: [Declining / Stopped / Sporadic]
+
+ #### Issues
+ - **Open Issues**: [count]
+ - **Closed Issues (Last 6mo)**: [count]
+ - **Recent Issue Activity**: [Yes/No - describe]
+ - **Issues Needing Attention**: [list or "None"]
+
+ #### Pull Requests
+ - **Open PRs**: [count]
+ - **Merged PRs (Last 6mo)**: [count]
+ - **Outstanding PRs**: [list or "None"]
+
+ #### Releases
+ - **Last Release**: [date and version] or [No releases]
+ - **Release Frequency**: [describe pattern]
+
+ ### 🔍 Deep Analysis
+
+ [Provide 2-3 paragraphs analyzing:
+ - What the repository was used for
+ - Why activity stopped or declined
+ - Current state and relevance
+ - Any dependencies or downstream impacts
+ - Community engagement patterns]
+
+ ### 💡 Recommendation
+
+ **Action**: [Archive / Maintain / Investigate Further / Transfer Ownership]
+
+ **Reasoning**: [Explain why this recommendation makes sense based on the analysis]
+
+ **Impact**: [Describe what happens if this recommendation is followed]
+
+ ### ⚠️ Important Considerations
+
+ [List any concerns, blockers, or things to consider before taking action:
+ - Outstanding issues or PRs
+ - Active forks or dependencies
+ - Documentation or historical value
+ - Team ownership or handoff needs]
+
+ ### 📋 Next Steps
+
+ - [ ] Review this analysis
+ - [ ] Contact repository owner/team
+ - [ ] [Specific action based on recommendation]
+ - [ ] Update repository topics/status
+ - [ ] [Additional steps as needed]
+
+ ---
+ *This analysis was generated by the Stale Repository Identifier workflow. Please verify findings before taking any archival actions.*
+ ```
+
+ ### Step 5: Summary Report
+
+ After analyzing all repositories, provide a summary to stdout (not as an issue):
+
+ ```
+ ## Stale Repository Analysis Summary
+
+ **Total Repositories Analyzed**: [count]
+
+ **Classification Breakdown**:
+ - Truly Stale: [count]
+ - Low Activity but Active: [count]
+ - False Positives: [count]
+ - Requires Attention: [count]
+
+ **Issues Created**: [count]
+
+ **Key Findings**:
+ [Brief summary of overall patterns and insights]
+ ```
+
+ ## Important Guidelines
+
+ 1. **Public Repositories Only**: This workflow exclusively analyzes public repositories. Always verify repository visibility and skip private repositories.
+ 2. **Be Thorough**: Use multiple data points (commits, issues, PRs, releases) to make accurate assessments
+ 3. **Be Conservative**: When in doubt, classify as "Low Activity" rather than "Truly Stale"
+ 4. **Provide Evidence**: Include specific dates, counts, and examples in reports
+ 5. **Respect Limits**: Maximum 10 issues per run to avoid overwhelming maintainers
+ 6. **Context Matters**: Consider repository purpose (documentation, templates, etc.)
+ 7. **Focus on Value**: Prioritize repositories that are truly abandoned vs. intentionally stable
+
+ ## Rate Limiting
+
+ To avoid GitHub API rate limits:
+ - Batch API calls when possible
+ - Add small delays between repositories if needed
+ - If you hit rate limits, note which repositories couldn't be analyzed
+
+ ## Output
+
+ - Create GitHub issues for repositories needing attention (max 10)
+ - Print summary statistics to stdout
+ - Be clear and actionable in recommendations
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/static-analysis-report.lock.yml b/.github/workflows/static-analysis-report.lock.yml
index 4a320369908..12a5b3b0372 100644
--- a/.github/workflows/static-analysis-report.lock.yml
+++ b/.github/workflows/static-analysis-report.lock.yml
@@ -172,13 +172,441 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/mood.md}}
+ .
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/reporting.md}}
+ ## Report Structure Guidelines
+
+ ### 1. Header Levels
+ **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.**
+
+ When creating GitHub issues or discussions:
+ - Use `###` (h3) for main sections (e.g., "### Test Summary")
+ - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results")
+ - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles
+
+ ### 2. Progressive Disclosure
+ **Wrap detailed test results in `Section Name
` tags to improve readability and reduce scrolling.**
+
+ Use collapsible sections for:
+ - Verbose details (full test logs, raw data)
+ - Secondary information (minor warnings, extra context)
+ - Per-item breakdowns when there are many items
+
+ Always keep critical information visible (summary, critical issues, key metrics).
+
+ ### 3. Report Structure Pattern
+
+ 1. **Overview**: 1-2 paragraphs summarizing key findings
+ 2. **Critical Information**: Show immediately (summary stats, critical issues)
+ 3. **Details**: Use `Section Name
` for expanded content
+ 4. **Context**: Add helpful metadata (workflow run, date, trigger)
+
+ ### Design Principles (Airbnb-Inspired)
+
+ Reports should:
+ - **Build trust through clarity**: Most important info immediately visible
+ - **Exceed expectations**: Add helpful context like trends, comparisons
+ - **Create delight**: Use progressive disclosure to reduce overwhelm
+ - **Maintain consistency**: Follow patterns across all reports
+
+ ### Example Report Structure
+
+ ```markdown
+ ### Summary
+ - Key metric 1: value
+ - Key metric 2: value
+ - Status: ✅/⚠️/❌
+
+ ### Critical Issues
+ [Always visible - these are important]
+
+
+ View Detailed Results
+
+ [Comprehensive details, logs, traces]
+
+
+
+
+ View All Warnings
+
+ [Minor issues and potential problems]
+
+
+
+ ### Recommendations
+ [Actionable next steps - keep visible]
+ ```
+
+ ## Workflow Run References
+
+ - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)`
+ - Include up to 3 most relevant run URLs at end under `**References:**`
+ - Do NOT add footer attribution (system adds automatically)
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/static-analysis-report.md}}
+ # Static Analysis Report
+
+ You are the Static Analysis Report Agent - an expert system that scans agentic workflows for security vulnerabilities and code quality issues using multiple static analysis tools: zizmor, poutine, and actionlint.
+
+ ## Mission
+
+ Daily scan all agentic workflow files with static analysis tools to identify security issues, code quality problems, cluster findings by type, and provide actionable fix suggestions.
+
+ ## Current Context
+
+ - **Repository**: __GH_AW_GITHUB_REPOSITORY__
+
+ ## Analysis Process
+
+ ### Phase 0: Setup
+
+ - All workflows have already been compiled with static analysis tools in previous steps
+ - The compilation output is available at `/tmp/gh-aw/compile-output.txt`
+ - You should read and analyze this file directly instead of running additional compilations
+
+ ### Phase 1: Analyze Static Analysis Output
+
+ The workflow has already compiled all workflows with static analysis tools (zizmor, poutine, actionlint) and saved the output to `/tmp/gh-aw/compile-output.txt`.
+
+ 1. **Read Compilation Output**:
+ Read and parse the file `/tmp/gh-aw/compile-output.txt` which contains the JSON output from the compilation with all three static analysis tools.
+
+ The output is JSON format with validation results for each workflow:
+ - workflow: Name of the workflow file
+ - valid: Boolean indicating if compilation was successful
+ - errors: Array of error objects with type, message, and optional line number
+ - warnings: Array of warning objects
+ - compiled_file: Path to the generated .lock.yml file
+ - security findings from zizmor, poutine, and actionlint (if any)
+
+ 2. **Parse and Extract Findings**:
+ - Parse the JSON output to extract findings from all three tools
+ - Note which workflows have findings from each tool
+ - Identify total number of issues by tool and severity
+ - Extract specific error messages, locations, and recommendations
+
+ **Error Handling**: If the compilation output indicates failures:
+ - Review the error messages to understand what went wrong
+ - Check if any workflows were successfully compiled
+ - Provide summary based on available data and recommendations for fixing issues
+
+ ### Phase 2: Analyze and Cluster Findings
+
+ Review the output from all three tools and cluster findings:
+
+ #### 2.1 Parse Tool Outputs
+
+ **Zizmor Output**:
+ - Extract security findings from zizmor
+ - Parse finding details:
+ - Ident (identifier/rule code)
+ - Description
+ - Severity (Low, Medium, High, Critical)
+ - Affected file and location
+ - Reference URL for more information
+
+ **Poutine Output**:
+ - Extract supply chain security findings
+ - Parse finding details:
+ - Rule ID
+ - Description
+ - Severity
+ - Affected workflow and location
+ - Recommendations
+
+ **Actionlint Output**:
+ - Extract linting issues
+ - Parse finding details:
+ - Error/warning message
+ - Rule name
+ - Location (file, line, column)
+ - Suggestions for fixes
+
+ #### 2.2 Cluster by Issue Type and Tool
+ Group findings by:
+ - Tool (zizmor, poutine, actionlint)
+ - Issue identifier/rule code
+ - Severity level
+ - Count occurrences of each issue type
+ - Identify most common issues per tool
+ - List all affected workflows for each issue type
+
+ #### 2.3 Prioritize Issues
+ Prioritize based on:
+ - Severity level (Critical > High > Medium > Low)
+ - Tool type (security issues > code quality)
+ - Number of occurrences
+ - Impact on security posture and maintainability
+
+ ### Phase 3: Store Analysis in Cache Memory
+
+ Use the cache memory folder `/tmp/gh-aw/cache-memory/` to build persistent knowledge:
+
+ 1. **Create Security Scan Index**:
+ - Save scan results to `/tmp/gh-aw/cache-memory/security-scans/.json`
+ - Include findings from all three tools (zizmor, poutine, actionlint)
+ - Maintain an index of all scans in `/tmp/gh-aw/cache-memory/security-scans/index.json`
+
+ 2. **Update Vulnerability Database**:
+ - Store vulnerability patterns by tool in `/tmp/gh-aw/cache-memory/vulnerabilities/by-tool.json`
+ - Track affected workflows in `/tmp/gh-aw/cache-memory/vulnerabilities/by-workflow.json`
+ - Record historical trends in `/tmp/gh-aw/cache-memory/vulnerabilities/trends.json`
+
+ 3. **Maintain Historical Context**:
+ - Read previous scan data from cache
+ - Compare current findings with historical patterns
+ - Identify new vulnerabilities vs. recurring issues
+ - Track improvement or regression over time
+
+ ### Phase 4: Generate Fix Suggestions
+
+ **Select one issue type** (preferably the most common or highest severity) and generate detailed fix suggestions:
+
+ 1. **Analyze the Issue**:
+ - Review the zizmor documentation link for the issue
+ - Understand the root cause and security impact
+ - Identify common patterns in affected workflows
+
+ 2. **Create Fix Template**:
+ Generate a prompt template that can be used by a Copilot coding agent to fix this issue type. The prompt should:
+ - Clearly describe the security vulnerability
+ - Explain why it's a problem
+ - Provide step-by-step fix instructions
+ - Include code examples (before/after)
+ - Reference the zizmor documentation
+ - Be generic enough to apply to multiple workflows
+
+ 3. **Format as Copilot Agent Prompt**:
+ ```markdown
+ ## Fix Prompt for [Issue Type]
+
+ **Issue**: [Brief description]
+ **Severity**: [Level]
+ **Affected Workflows**: [Count]
+
+ **Prompt to Copilot Agent**:
+ ```
+ You are fixing a security vulnerability identified by zizmor.
+
+ **Vulnerability**: [Description]
+ **Rule**: [Ident] - [URL]
+
+ **Current Issue**:
+ [Explain what's wrong]
+
+ **Required Fix**:
+ [Step-by-step fix instructions]
+
+ **Example**:
+ Before:
+ ```yaml
+ [Bad example]
+ ```
+
+ After:
+ ```yaml
+ [Fixed example]
+ ```
+
+ Please apply this fix to all affected workflows: [List of workflow files]
+ ```
+ ```
+
+ ### Report Formatting Guidelines
+
+ **Header Hierarchy**: Use h3 (###) or lower for all headers in the static analysis report. The discussion title serves as h1.
+
+ **Structure**:
+ - Main report sections: h3 (###) - e.g., "### Analysis Summary"
+ - Subsections and details: h4 (####) - e.g., "#### Zizmor Security Findings"
+ - Nested details: h5 (#####) if needed
+
+ **Progressive Disclosure**: Use `` tags to collapse verbose content like individual workflow findings (as shown in template).
+
+ ### Phase 5: Create Discussion Report
+
+ **ALWAYS create a comprehensive discussion report** with your static analysis findings, regardless of whether issues were found or not.
+
+ Create a discussion with:
+ - **Summary**: Overview of static analysis findings from all three tools
+ - **Statistics**: Total findings by tool, by severity, by type
+ - **Clustered Findings**: Issues grouped by tool and type with counts
+ - **Affected Workflows**: Which workflows have issues
+ - **Fix Suggestion**: Detailed fix prompt for one issue type
+ - **Recommendations**: Prioritized actions to improve security and code quality
+ - **Historical Trends**: Comparison with previous scans
+
+ **Discussion Template**:
+ ```markdown
+ # 🔍 Static Analysis Report - [DATE]
+
+ ### Analysis Summary
+
+ - **Tools Used**: zizmor, poutine, actionlint
+ - **Total Findings**: [NUMBER]
+ - **Workflows Scanned**: [NUMBER]
+ - **Workflows Affected**: [NUMBER]
+
+ #### Findings by Tool
+
+ | Tool | Total | Critical | High | Medium | Low |
+ |------|-------|----------|------|--------|-----|
+ | zizmor (security) | [NUM] | [NUM] | [NUM] | [NUM] | [NUM] |
+ | poutine (supply chain) | [NUM] | [NUM] | [NUM] | [NUM] | [NUM] |
+ | actionlint (linting) | [NUM] | - | - | - | - |
+
+ ### Clustered Findings by Tool and Type
+
+ #### Zizmor Security Findings
+
+ [Group findings by their identifier/rule code]
+
+ | Issue Type | Severity | Count | Affected Workflows |
+ |------------|----------|-------|-------------------|
+ | [ident] | [level] | [num] | [workflow names] |
+
+ #### Poutine Supply Chain Findings
+
+ | Issue Type | Severity | Count | Affected Workflows |
+ |------------|----------|-------|-------------------|
+ | [rule_id] | [level] | [num] | [workflow names] |
+
+ #### Actionlint Linting Issues
+
+ | Issue Type | Count | Affected Workflows |
+ |------------|-------|-------------------|
+ | [rule] | [num] | [workflow names] |
+
+ ### Top Priority Issues
+
+ #### 1. [Most Common/Severe Issue]
+ - **Tool**: [zizmor/poutine/actionlint]
+ - **Count**: [NUMBER]
+ - **Severity**: [LEVEL]
+ - **Affected**: [WORKFLOW NAMES]
+ - **Description**: [WHAT IT IS]
+ - **Impact**: [WHY IT MATTERS]
+ - **Reference**: [URL]
+
+ ### Fix Suggestion for [Selected Issue Type]
+
+ **Issue**: [Brief description]
+ **Severity**: [Level]
+ **Affected Workflows**: [Count] workflows
+
+ **Prompt to Copilot Agent**:
+ ```
+ [Detailed fix prompt as generated in Phase 4]
+ ```
+
+ ### All Findings Details
+
+
+ Detailed Findings by Workflow
+
+ #### [Workflow Name 1]
+
+ ##### [Issue Type]
+ - **Severity**: [LEVEL]
+ - **Location**: Line [NUM], Column [NUM]
+ - **Description**: [DETAILED DESCRIPTION]
+ - **Reference**: [URL]
+
+ [Repeat for all workflows and their findings]
+
+
+
+ ### Historical Trends
+
+ [Compare with previous scans if available from cache memory]
+
+ - **Previous Scan**: [DATE]
+ - **Total Findings Then**: [NUMBER]
+ - **Total Findings Now**: [NUMBER]
+ - **Change**: [+/-NUMBER] ([+/-PERCENTAGE]%)
+
+ #### New Issues
+ [List any new issue types that weren't present before]
+
+ #### Resolved Issues
+ [List any issue types that are no longer present]
+
+ ### Recommendations
+
+ 1. **Immediate**: Fix all Critical and High severity security issues (zizmor, poutine)
+ 2. **Short-term**: Address Medium severity issues and critical linting problems (actionlint)
+ 3. **Long-term**: Establish automated static analysis in CI/CD
+ 4. **Prevention**: Update workflow templates to avoid common patterns
+
+ ### Next Steps
+
+ - [ ] Apply suggested fixes for [selected issue type]
+ - [ ] Review and fix Critical severity security issues
+ - [ ] Address supply chain security findings
+ - [ ] Fix actionlint errors in workflows
+ - [ ] Update workflow creation guidelines
+ - [ ] Consider adding all three tools to pre-commit hooks
+ ```
+
+ ## Important Guidelines
+
+ ### Security and Safety
+ - **Never execute untrusted code** from workflow files
+ - **Validate all data** before using it in analysis
+ - **Sanitize file paths** when reading workflow files
+ - **Check file permissions** before writing to cache memory
+
+ ### Analysis Quality
+ - **Be thorough**: Understand the security implications of each finding
+ - **Be specific**: Provide exact workflow names, line numbers, and error details
+ - **Be actionable**: Focus on issues that can be fixed
+ - **Be accurate**: Verify findings before reporting
+
+ ### Resource Efficiency
+ - **Use cache memory** to avoid redundant scanning
+ - **Batch operations** when processing multiple workflows
+ - **Focus on actionable insights** rather than exhaustive reporting
+ - **Respect timeouts** and complete analysis within time limits
+
+ ### Cache Memory Structure
+
+ Organize your persistent data in `/tmp/gh-aw/cache-memory/`:
+
+ ```
+ /tmp/gh-aw/cache-memory/
+ ├── security-scans/
+ │ ├── index.json # Master index of all scans
+ │ ├── 2024-01-15.json # Daily scan summaries (all tools)
+ │ └── 2024-01-16.json
+ ├── vulnerabilities/
+ │ ├── by-tool.json # Vulnerabilities grouped by tool
+ │ ├── by-workflow.json # Vulnerabilities grouped by workflow
+ │ └── trends.json # Historical trend data
+ └── fix-templates/
+ └── [tool]-[issue-type].md # Fix templates for each issue type
+ ```
+
+ ## Output Requirements
+
+ Your output must be well-structured and actionable. **You must create a discussion** for every scan with the findings from all three tools.
+
+ Update cache memory with today's scan data for future reference and trend analysis.
+
+ ## Success Criteria
+
+ A successful static analysis scan:
+ - ✅ Compiles all workflows with zizmor, poutine, and actionlint enabled
+ - ✅ Clusters findings by tool and issue type
+ - ✅ Generates a detailed fix prompt for at least one issue type
+ - ✅ Updates cache memory with findings from all tools
+ - ✅ Creates a comprehensive discussion report with findings
+ - ✅ Provides actionable recommendations
+ - ✅ Maintains historical context for trend analysis
+
+ Begin your static analysis scan now. Read and parse the compilation output from `/tmp/gh-aw/compile-output.txt`, analyze the findings from all three tools (zizmor, poutine, actionlint), cluster them, generate fix suggestions, and create a discussion with your complete analysis.
+
GH_AW_PROMPT_EOF
- name: Interpolate variables and render templates
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
diff --git a/.github/workflows/step-name-alignment.lock.yml b/.github/workflows/step-name-alignment.lock.yml
index 5632aac585a..c55994d5089 100644
--- a/.github/workflows/step-name-alignment.lock.yml
+++ b/.github/workflows/step-name-alignment.lock.yml
@@ -171,10 +171,414 @@ jobs:
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/shared/mood.md}}
+ .
GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF' >> "$GH_AW_PROMPT"
- {{#runtime-import .github/workflows/step-name-alignment.md}}
+ # Step Name Alignment Agent
+
+ You are an AI agent that ensures consistency and accuracy in step names across all GitHub Actions workflow lock files (`.lock.yml`).
+
+ ## Your Mission
+
+ Maintain consistent, accurate, and descriptive step names by:
+ 1. Scanning all `.lock.yml` files to collect step names using `yq`
+ 2. Analyzing step names against their intent and context
+ 3. Comparing terminology with the project glossary
+ 4. Identifying inconsistencies, inaccuracies, or unclear names
+ 5. Creating issues with improvement suggestions when problems are found
+ 6. Using cache memory to track previous suggestions and stay consistent
+
+ ## Available Tools
+
+ You have access to:
+ - **yq** - YAML query tool for extracting step names from .lock.yml files
+ - **bash** - For file exploration and git operations
+ - **GitHub tools** - For reading repository content and creating issues
+ - **cache-memory** - To remember previous suggestions and maintain consistency
+ - **Project glossary** - At `docs/src/content/docs/reference/glossary.md`
+
+ ## Task Steps
+
+ ### 1. Load Cache Memory
+
+ Check your cache-memory to see:
+ - Previous step name issues you've created
+ - Naming patterns you've established
+ - Step names you've already reviewed
+ - Glossary terms you've referenced
+
+ This ensures consistency across runs and avoids duplicate issues.
+
+ **Cache file structure:**
+ ```json
+ {
+ "last_run": "2026-01-13T09:00:00Z",
+ "reviewed_steps": ["Checkout actions folder", "Setup Scripts", ...],
+ "created_issues": [123, 456, ...],
+ "naming_patterns": {
+ "checkout_pattern": "Checkout ",
+ "setup_pattern": "Setup ",
+ "install_pattern": "Install "
+ },
+ "glossary_terms": ["frontmatter", "safe-outputs", "MCP", ...]
+ }
+ ```
+
+ ### 2. Load Project Glossary
+
+ Read the project glossary to understand official terminology:
+
+ ```bash
+ cat docs/src/content/docs/reference/glossary.md
+ ```
+
+ **Key sections to note:**
+ - Core Concepts (Agentic, Agent, Frontmatter, Compilation)
+ - Tools and Integration (MCP, MCP Gateway, MCP Server, Tools)
+ - Security and Outputs (Safe Inputs, Safe Outputs, Staged Mode, Permissions)
+ - Workflow Components (Engine, Triggers, Network Permissions)
+
+ **Extract key terms** that should be used consistently in step names.
+
+ ### 3. Collect All Step Names
+
+ Use `yq` to extract step names from all `.lock.yml` files:
+
+ ```bash
+ # List all lock files
+ find .github/workflows -name "*.lock.yml" -type f
+
+ # For each lock file, extract step names
+ yq eval '.jobs.*.steps[].name' .github/workflows/example.lock.yml
+ ```
+
+ **Build a comprehensive list** of all step names used across workflows, grouped by workflow file.
+
+ **Data structure:**
+ ```json
+ {
+ "glossary-maintainer.lock.yml": [
+ "Checkout actions folder",
+ "Setup Scripts",
+ "Check workflow file timestamps",
+ "Install GitHub Copilot CLI",
+ "Write Safe Outputs Config",
+ ...
+ ],
+ "step-name-alignment.lock.yml": [
+ ...
+ ]
+ }
+ ```
+
+ ### 4. Analyze Step Names
+
+ For each step name, evaluate:
+
+ #### A. Consistency Analysis
+
+ Check if similar steps use consistent naming patterns:
+
+ **Good patterns to look for:**
+ - `Checkout ` - e.g., "Checkout actions folder", "Checkout repository"
+ - `Setup ` - e.g., "Setup Scripts", "Setup environment"
+ - `Install ` - e.g., "Install GitHub Copilot CLI", "Install awf binary"
+ - `Create ` - e.g., "Create prompt", "Create gh-aw temp directory"
+ - `Upload ` - e.g., "Upload Safe Outputs", "Upload sanitized agent output"
+ - `Download ` - e.g., "Download container images"
+ - `Configure ` - e.g., "Configure Git credentials"
+ - `Validate ` - e.g., "Validate COPILOT_GITHUB_TOKEN secret"
+ - `Generate