Skip to content

[auto-update] Sync workflows from gh-aw #147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
github-actions wants to merge 1 commit into
base: main
Choose a base branch
from
+283 −244
Open

[auto-update] Sync workflows from gh-aw #147

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 69 additions & 35 deletions workflows/ci-doctor.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,42 +1,62 @@
---
description: |
This workflow is an automated CI failure investigator that triggers when monitored workflows fail.
Performs deep analysis of GitHub Actions workflow failures to identify root causes,
patterns, and provide actionable remediation steps. Analyzes logs, error messages,
and workflow configuration to help diagnose and resolve CI issues efficiently.

description: Investigates failed CI workflows to identify root causes and patterns, creating issues with diagnostic information
on:
workflow_run:
workflows: ["Daily Perf Improver", "Daily Test Coverage Improver"] # Monitor the CI workflow specifically
workflows: ["CI"] # Monitor the CI workflow specifically
types:
- completed
branches:
- main
# This will trigger only when the CI workflow completes with failure
# The condition is handled in the workflow body
stop-after: +1mo

# Only trigger for failures - check in the workflow body
if: ${{ github.event.workflow_run.conclusion == 'failure' }}

permissions: read-all
permissions:
actions: read # To query workflow runs, jobs, and logs
contents: read # To read repository files
issues: read # To search and analyze issues
pull-requests: read # To analyze pull request context

network: defaults

engine:
id: copilot
model: gpt-5.1-codex-mini

safe-outputs:
create-issue:
title-prefix: "${{ github.workflow }}"
labels: [automation, ci]
expires: 1d
title-prefix: "[CI Failure Doctor] "
labels: [cookie]
close-older-issues: true
add-comment:
update-issue:
noop:
messages:
footer: "> 🩺 *Diagnosis provided by [{workflow_name}]({run_url})*"
run-started: "🏥 CI Doctor reporting for duty! [{workflow_name}]({run_url}) is examining the patient on this {event_type}..."
run-success: "🩺 Examination complete! [{workflow_name}]({run_url}) has delivered the diagnosis. Prescription issued! 💊"
run-failure: "🏥 Medical emergency! [{workflow_name}]({run_url}) {status}. Doctor needs assistance..."

tools:
cache-memory: true
web-fetch:
web-search:
github:
toolsets: [default, actions] # default: context, repos, issues, pull_requests; actions: workflow logs and artifacts

timeout-minutes: 10
timeout-minutes: 20

source: githubnext/agentics/workflows/ci-doctor.md@ea350161ad5dcc9624cf510f134c6a9e39a6f94d
imports:
- shared/mood.md
---

# CI Failure Doctor

You are the CI Failure Doctor, an expert investigative agent that analyzes failed GitHub Actions workflows to identify root causes and patterns. Your goal is to conduct a deep investigation when the CI workflow fails.
You are the CI Failure Doctor, an expert investigative agent that analyzes failed GitHub Actions workflows to identify root causes and patterns. Your mission is to conduct a deep investigation when the CI workflow fails.

## Current Context

Expand All @@ -48,17 +68,17 @@ You are the CI Failure Doctor, an expert investigative agent that analyzes faile

## Investigation Protocol

**ONLY proceed if the workflow conclusion is 'failure' or 'cancelled'**. Exit immediately if the workflow was successful.
**ONLY proceed if the workflow conclusion is 'failure' or 'cancelled'**. If the workflow was successful, **call the `noop` tool** immediately and exit.

### Phase 1: Initial Triage

1. **Verify Failure**: Check that `${{ github.event.workflow_run.conclusion }}` is `failure` or `cancelled`
- **If the workflow was successful**: Call the `noop` tool with message "CI workflow completed successfully - no investigation needed" and **stop immediately**. Do not proceed with any further analysis.
- **If the workflow failed or was cancelled**: Proceed with the investigation steps below.
2. **Get Workflow Details**: Use `get_workflow_run` to get full details of the failed run
3. **List Jobs**: Use `list_workflow_jobs` to identify which specific jobs failed
4. **Quick Assessment**: Determine if this is a new type of failure or a recurring pattern

### Phase 2: Deep Log Analysis

1. **Retrieve Logs**: Use `get_job_logs` with `failed_only=true` to get logs from all failed jobs
2. **Pattern Recognition**: Analyze logs for:
- Error messages and stack traces
Expand All @@ -74,8 +94,7 @@ You are the CI Failure Doctor, an expert investigative agent that analyzes faile
- Dependency versions involved
- Timing patterns

### Phase 3: Historical Context Analysis

### Phase 3: Historical Context Analysis
1. **Search Investigation History**: Use file-based storage to search for similar failures:
- Read from cached investigation files in `/tmp/memory/investigations/`
- Parse previous failure patterns and solutions
Expand All @@ -85,10 +104,9 @@ You are the CI Failure Doctor, an expert investigative agent that analyzes faile
4. **PR Context**: If triggered by a PR, analyze the changed files

### Phase 4: Root Cause Investigation

1. **Categorize Failure Type**:
- **Code Issues**: Syntax errors, logic bugs, test failures
- **Infrastructure**: Runner issues, network problems, resource constraints
- **Infrastructure**: Runner issues, network problems, resource constraints
- **Dependencies**: Version conflicts, missing packages, outdated libraries
- **Configuration**: Workflow configuration, environment variables
- **Flaky Tests**: Intermittent failures, timing issues
Expand All @@ -101,27 +119,40 @@ You are the CI Failure Doctor, an expert investigative agent that analyzes faile
- For timeout issues: Identify slow operations and bottlenecks

### Phase 5: Pattern Storage and Knowledge Building

1. **Store Investigation**: Save structured investigation data to files:
- Write investigation report to `/tmp/memory/investigations/<timestamp>-<run-id>.json`
- **Important**: Use filesystem-safe timestamp format `YYYY-MM-DD-HH-MM-SS-sss` (e.g., `2026-02-12-11-20-45-458`)
- **Do NOT use** ISO 8601 format with colons (e.g., `2026-02-12T11:20:45.458Z`) - colons are not allowed in artifact filenames
- Store error patterns in `/tmp/memory/patterns/`
- Maintain an index file of all investigations for fast searching
2. **Update Pattern Database**: Enhance knowledge with new findings by updating pattern files
3. **Save Artifacts**: Store detailed logs and analysis in the cached directories

### Phase 6: Looking for existing issues

1. **Convert the report to a search query**
- Use any advanced search features in GitHub Issues to find related issues
- Look for keywords, error messages, and patterns in existing issues
2. **Judge each match issues for relevance**
- Analyze the content of the issues found by the search and judge if they are similar to this issue.
3. **Add issue comment to duplicate issue and finish**
- If you find a duplicate issue, add a comment with your findings and close the investigation.
- Do NOT open a new issue since you found a duplicate already (skip next phases).

### Phase 6: Reporting and Recommendations

### Phase 6: Looking for existing issues and closing older ones

1. **Search for existing CI failure doctor issues**
- Use GitHub Issues search to find issues with label "cookie" and title prefix "[CI Failure Doctor]"
- Look for both open and recently closed issues (within the last 7 days)
- Search for keywords, error messages, and patterns from the current failure
2. **Judge each match for relevance**
- Analyze the content of found issues to determine if they are similar to the current failure
- Check if they describe the same root cause, error pattern, or affected components
- Identify truly duplicate issues vs. unrelated failures
3. **Close older duplicate issues**
- If you find older open issues that are duplicates of the current failure:
- Add a comment explaining this is a duplicate of the new investigation
- Use the `update-issue` tool with `state: "closed"` and `state_reason: "not_planned"` to close them
- Include a link to the new issue in the comment
- If older issues describe resolved problems that are recurring:
- Keep them open but add a comment linking to the new occurrence
4. **Handle duplicate detection**
- If you find a very recent duplicate issue (opened within the last hour):
- Add a comment with your findings to the existing issue
- Do NOT open a new issue (skip next phases)
- Exit the workflow
- Otherwise, continue to create a new issue with fresh investigation data

### Phase 7: Reporting and Recommendations
1. **Create Investigation Report**: Generate a comprehensive analysis including:
- **Executive Summary**: Quick overview of the failure
- **Root Cause**: Detailed explanation of what went wrong
Expand All @@ -130,7 +161,7 @@ You are the CI Failure Doctor, an expert investigative agent that analyzes faile
- **Prevention Strategies**: How to avoid similar failures
- **AI Team Self-Improvement**: Give a short set of additional prompting instructions to copy-and-paste into instructions.md for AI coding agents to help prevent this type of failure in future
- **Historical Context**: Similar past failures and their resolutions

2. **Actionable Deliverables**:
- Create an issue with investigation results (if warranted)
- Comment on related PR with analysis (if PR-triggered)
Expand Down Expand Up @@ -193,4 +224,7 @@ When creating an investigation issue, use this structure:
- Persist findings across workflow runs using GitHub Actions cache
- Build cumulative knowledge about failure patterns and solutions using structured JSON files
- Use file-based indexing for fast pattern matching and similarity detection
- **Filename Requirements**: Use filesystem-safe characters only (no colons, quotes, or special characters)
- ✅ Good: `2026-02-12-11-20-45-458-12345.json`
- ❌ Bad: `2026-02-12T11:20:45.458Z-12345.json` (contains colons)

126 changes: 55 additions & 71 deletions workflows/plan.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,40 +1,32 @@
---
name: Plan Command
description: Generates project plans and task breakdowns when invoked with /plan command in issues or PRs

on:
slash_command:
name: plan
events: [issue_comment, discussion_comment]

permissions:
contents: read
discussions: read
issues: read
pull-requests: read

engine: copilot

tools:
github:
toolsets: [default, discussions]
# If in a public repo, setting `lockdown: false` allows
# reading issues, pull requests and comments from 3rd-parties
# If in a private repo this has no particular effect.
#
# This allows the maintainer to use /plan in discussions and issues created
# by 3rd parties, and to read the content of those discussions and issues
# turning the content into actionable tasks.
lockdown: false

toolsets: [default, discussions]
safe-outputs:
create-issue:
title-prefix: "[task] "
labels: [task, ai-generated]
max: 5
expires: 2d
title-prefix: "[plan] "
labels: [plan, ai-generated, cookie]
max: 5 # Maximum 5 sub-issues per group
group: true
close-discussion:
required-category: "Ideas"
timeout-minutes: 10
imports:
- shared/mood.md
---

# Planning Assistant
Expand All @@ -46,17 +38,35 @@ You are an expert planning assistant for GitHub Copilot agents. Your task is to
- **Repository**: ${{ github.repository }}
- **Issue Number**: ${{ github.event.issue.number }}
- **Discussion Number**: ${{ github.event.discussion.number }}
- **Content**:
- **Comment Content**:

<content>
<comment>
${{ needs.activation.outputs.text }}
</content>
</comment>

## Your Mission

Analyze the issue or discussion and its comments, then create a sequence of clear, actionable sub-issues (at most 5) that break down the work into manageable tasks for GitHub Copilot agents.
Analyze the issue or discussion along with the comment content (which may contain additional guidance from the user), then create actionable sub-issues (at most 5) that can be assigned to GitHub Copilot agents.

**Important**: With issue grouping enabled, all issues you create will be automatically grouped under a parent tracking issue. You don't need to create a parent issue manually or use temporary IDs - just create the sub-issues directly.

{{#if github.event.issue.number}}
**Triggered from an issue comment** (current context): The current issue (#${{ github.event.issue.number }}) serves as the triggering context, but you should still create new sub-issues for the work items.
{{/if}}

## Guidelines for Creating Sub-Issues
{{#if github.event.discussion.number}}
**Triggered from a discussion** (current context): Reference the discussion (#${{ github.event.discussion.number }}) in your issue descriptions as the source of the work.
{{/if}}

## Creating Sub-Issues

Create actionable sub-issues (at most 5) with the following format:
- Each sub-issue should be a clear, actionable task for a SWE agent
- Use the `create_issue` type with `title` and `body` fields
- Do NOT use the `parent` field - grouping is automatic
- Do NOT create a separate parent tracking issue - grouping handles this automatically

## Guidelines for Sub-Issues

### 1. Clarity and Specificity
Each sub-issue should:
Expand All @@ -76,7 +86,7 @@ Order the tasks logically:
Each task should:
- Be completable in a single PR
- Not be too large (avoid epic-sized tasks)
- With a single focus or goal. Keep them extremely small and focused even if it means more tasks.
- With a single focus or goal. Keep them extremely small and focused even it means more tasks.
- Have clear acceptance criteria

### 4. SWE Agent Formulation
Expand All @@ -86,59 +96,26 @@ Write tasks as if instructing a software engineer:
- Include relevant technical details
- Specify expected outcomes

## Task Breakdown Process

1. **Analyze the Content**: Read the issue or discussion title, description, and comments carefully
2. **Identify Scope**: Determine the overall scope and complexity
3. **Break Down Work**: Identify 3-5 logical work items
4. **Formulate Tasks**: Write clear, actionable descriptions for each task
5. **Create Sub-Issues**: Use safe-outputs to create the sub-issues

## Output Format
## Example: Creating Sub-Issues

For each sub-issue you create:
- **Title**: Brief, descriptive title (e.g., "Implement authentication middleware")
- **Body**: Clear description with:
- Objective: What needs to be done
- Context: Why this is needed
- Approach: Suggested implementation approach (if applicable)
- Files: Specific files to modify or create
- Acceptance Criteria: How to verify completion
Since grouping is enabled, simply create sub-issues without parent references:

## Example Sub-Issue

**Title**: Add user authentication middleware

**Body**:
```
## Objective
Implement JWT-based authentication middleware for API routes.

## Context
This is needed to secure API endpoints before implementing user-specific features. Part of issue or discussion #123.

## Approach
1. Create middleware function in `src/middleware/auth.js`
2. Add JWT verification using the existing auth library
3. Attach user info to request object
4. Handle token expiration and invalid tokens

## Files to Modify
- Create: `src/middleware/auth.js`
- Update: `src/routes/api.js` (to use the middleware)
- Update: `tests/middleware/auth.test.js` (add tests)

## Acceptance Criteria
- [ ] Middleware validates JWT tokens
- [ ] Invalid tokens return 401 status
- [ ] User info is accessible in route handlers
- [ ] Tests cover success and error cases
```json
{
"type": "create_issue",
"title": "Add user authentication middleware",
"body": "## Objective\n\nImplement JWT-based authentication middleware for API routes.\n\n## Context\n\nThis is needed to secure API endpoints before implementing user-specific features.\n\n## Approach\n\n1. Create middleware function in `src/middleware/auth.js`\n2. Add JWT verification using the existing auth library\n3. Attach user info to request object\n4. Handle token expiration and invalid tokens\n\n## Files to Modify\n\n- Create: `src/middleware/auth.js`\n- Update: `src/routes/api.js` (to use the middleware)\n- Update: `tests/middleware/auth.test.js` (add tests)\n\n## Acceptance Criteria\n\n- [ ] Middleware validates JWT tokens\n- [ ] Invalid tokens return 401 status\n- [ ] User info is accessible in route handlers\n- [ ] Tests cover success and error cases"
}
```

All created issues will be automatically grouped under a parent tracking issue.

## Important Notes

- **Maximum 5 sub-issues**: Don't create more than 5 sub-issues (as configured in safe-outputs)
- **Parent Reference**: You must specify the current issue (#${{ github.event.issue.number }}) or discussion (#${{ github.event.discussion.number }}) as the parent when creating sub-issues. The system will automatically link them with "Related to #N" in the issue body.
- **Maximum 5 sub-issues**: Don't create more than 5 sub-issues
- **No Parent Field**: Don't use the `parent` field - grouping is automatic
- **No Temporary IDs**: Don't use temporary IDs - grouping handles parent creation automatically
- **User Guidance**: Pay attention to the comment content above - the user may have provided specific instructions or priorities
- **Clear Steps**: Each sub-issue should have clear, actionable steps
- **No Duplication**: Don't create sub-issues for work that's already done
- **Prioritize Clarity**: SWE agents need unambiguous instructions
Expand All @@ -149,6 +126,13 @@ Review instructions in `.github/instructions/*.instructions.md` if you need guid

## Begin Planning

Analyze the issue or discussion and create the sub-issues now. Remember to use the safe-outputs mechanism to create each issue. Each sub-issue you create will be automatically linked to the parent (issue #${{ github.event.issue.number }} or discussion #${{ github.event.discussion.number }}).
{{#if github.event.issue.number}}
1. First, analyze the current issue (#${{ github.event.issue.number }}) and the user's comment for context and any additional guidance
2. Create sub-issues (at most 5) - they will be automatically grouped
{{/if}}

After creating all the sub-issues successfully, if this was triggered from a discussion in the "Ideas" category, close the discussion with a comment summarizing the plan and resolution reason "RESOLVED".
{{#if github.event.discussion.number}}
1. First, analyze the discussion (#${{ github.event.discussion.number }}) and the user's comment for context and any additional guidance
2. Create sub-issues (at most 5) - they will be automatically grouped
3. After creating all issues successfully, if this was triggered from a discussion in the "Ideas" category, close the discussion with a comment summarizing the plan and resolution reason "RESOLVED"
{{/if}}
Loading