Elastic AI Software Factory (GitHub Agent Workflows)¶

Elastic AI Software Factory is built on GitHub Agent Workflows with safe-output guardrails. Engine and model are configurable per workflow, and updates are delivered via the v0 tag.

Install (caller-based, recommended)¶

Copy a workflow's example.yml from gh-agent-workflows/ and customize inputs. No gh-aw CLI required.

# .github/workflows/trigger-pr-review.yml
name: PR Review
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
jobs:
  run:
    uses: elastic/ai-github-actions/.github/workflows/gh-aw-pr-review.lock.yml@v0
    secrets:
      COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}

Each workflow directory contains an example.yml starter and a README for trigger details, inputs, and safe outputs.

Recommended workflow sets¶

The quick setup script bundles two opinionated sets. The homepage shows how to install the core workflows with a single copy-paste command.

Core (default): pr-review, issue-triage, mention-in-issue, mention-in-pr, pr-actions-detective
Continuous improvement add-ons (--continuous-improvement): bug-hunter, code-complexity-detector, code-duplication-detector, docs-patrol, newbie-contributor-patrol, small-problem-fixer, stale-issues-investigator, stale-issues-remediator, test-coverage-detector, breaking-change-detector, update-pr-body

Available workflows¶

Base workflows¶

Two generic base workflows let you build custom detectors and fixers without writing a full workflow from scratch. Provide your domain-specific instructions via additional-instructions:

Workflow	Role	Output
Scheduled Audit	Detect issues and file reports	`create-issue`
Scheduled Fix	Fix reported issues	`create-pull-request`

These pair together: a Scheduled Audit finds problems, a Scheduled Fix resolves them. The specialized workflows below are built on top of these base fragments.

Human-coordinated workflows¶

Workflow	Trigger	Description
Plan	`/plan` in issues	Triage-style planning from comments with optional issue/sub-issue creation
Mention in Issue	`/ai` in issues	Answer questions, debug, create PRs
Mention in PR	`/ai` in PRs	Review, fix code, push changes
PR Actions Fixer	Manual (workflow_dispatch)	Opt-in fixes for failed PR checks

Event-driven workflows¶

Workflow	Trigger	Description
Dependency Review	Dependabot/Renovate/Updatecli PRs	Analyze dependency updates across ecosystems with changelog, compatibility, and risk checks
Duplicate Issue Detector	New issues	Detect duplicate issues and comment with links
Issue Triage	New issues	Investigate and provide implementation plans
Issue Fixer	New issues	Triage plus automatic draft PR for straightforward fixes
Branch Actions Detective	Failed branch CI	Diagnose post-merge CI failures and file tracking issues
PR Actions Detective	Failed PR checks	Diagnose failures and recommend fixes
PR Review	PR opened/updated	AI code review with inline comments
PR Review (Fork)	PR opened/updated (`pull_request_target`)	AI code review for fork PRs — private repos or trusted contributors only
Update PR Body	PR opened / updated / ready for review	Auto-populate PR description from diff and linked issues

Scheduled workflows¶

Detector / fixer pairs¶

Many scheduled workflows follow a detector pattern: the detector finds issues and files reports. Any detector can chain to Create PR from Issue in the same workflow run for a fully autonomous detect-and-fix loop. For comment-only responses (no PR), chain to Create Comment On Issue. Or use the detector alone for human-in-the-loop review.

Detector	Domain
Bug Hunter	Reproducible bugs
Code Complexity Detector	Overly complex code
Code Duplication Detector	Duplicate / clustered code
Docs Patrol	Stale internal documentation
Newbie Contributor Patrol	Onboarding documentation gaps
Stale Issues Investigator	Stale issue lifecycle
Test Coverage Detector	Test coverage gaps
Text Auditor	User-facing text quality

Stale Issues Investigator pairs with Stale Issues Remediator for label-based lifecycle management (not issue-driven chaining).

Standalone scheduled workflows¶

Workflow	Trigger	Description
Agent Suggestions	Weekly schedule	Suggest new agent workflows based on repo and downstream needs
Autonomy Atomicity Analyzer	Weekday schedule	Find patterns that block concurrent development by multiple agents or developers
Breaking Change Detector	Weekday schedule	Detect undocumented public breaking changes
Flaky Test Investigator	Weekday schedule + failed CI runs	Identify repeated flaky failures and file root-cause-first triage reports
Framework Best Practices	Weekday schedule	Find where library-native features could replace hand-rolled solutions
Information Architecture	Weekday schedule	Audit UI information architecture for navigation, placement, and consistency
Performance Profiler	Weekday schedule	Profile performance hotspots
Product Manager Impersonator	Weekday schedule	Propose feature ideas from a configurable persona and scope
Project Summary	Daily schedule	Summarize recent activity and priorities
Release Update Check	Weekly schedule	Open a PR updating pinned ai-github-actions workflow SHAs and suggest workflow changes
Small Problem Fixer	Weekday schedule	Fix small, related issues and open a focused PR
UX Design Patrol	Weekday schedule	Detect UI/UX design drift and file consolidation reports

Elastic-specific workflows¶

These workflows are tailored for Elastic's internal tooling and documentation platform. They reference Elastic's published documentation on elastic.co/docs, Elastic's style guide and applies_to tag conventions, or Elastic-owned infrastructure (Buildkite, downstream repositories). Use these if you are working in an Elastic repository.

Human-coordinated¶

Workflow	Trigger	Description
Docs PR Review (Elastic-specific)	`/docs-review` on PRs	Review docs for Elastic style guide, `applies_to`, and consistency with elastic.co/docs

Event-driven¶

Workflow	Trigger	Description
PR Buildkite Detective (Elastic-specific)	Failed PR checks	Diagnose Buildkite failures and recommend fixes

Scheduled¶

Detector	Fixer	Domain
Docs Patrol External (Elastic-specific)	—	Stale published Elastic docs
Newbie Contributor Patrol External (Elastic-specific)	—	Cross-referencing published Elastic docs

Workflow	Trigger	Description
Resource Not Accessible Detector (Elastic-specific)	Daily schedule	Detect `Resource not accessible by integration` CI errors and file one combined tracking issue

Secrets¶

These workflows require a Copilot PAT stored as COPILOT_GITHUB_TOKEN.

Create a Copilot PAT with the copilot-requests scope (the scope is only available for public repositories). The link pre-fills the name, description, and scope. Set the expiry to longer than the 30-day default (e.g., 90 days or 1 year) to avoid frequent rotation.
Store it as a repository secret:

printf '%s' "(pat)" | gh secret set COPILOT_GITHUB_TOKEN --repo OWNER/REPO

UI path: Settings → Secrets and variables → Actions → New repository secret.

See the upstream gh-aw auth docs for canonical steps.

Some workflows require additional provider-specific secrets (for example, PR Buildkite Detective requires BUILDKITE_API_TOKEN).

Agentic maintenance workflow required¶

Any workflow that uses safe-outputs with expires (create-issue, create-pull-request, create-discussion) requires the agentics-maintenance workflow so expired items are closed automatically. Install it once per repo:

mkdir -p .github/workflows && curl -fsSL \
  https://raw.githubusercontent.com/elastic/ai-github-actions/v0/.github/workflows/agentics-maintenance.yml \
  -o .github/workflows/agentics-maintenance.yml

Standard inputs¶

All workflows accept these optional inputs via workflow_call:

Input	Type	Description
`additional-instructions`	string	Repo-specific instructions appended to the agent prompt
`setup-commands`	string	Shell commands to run before the agent starts (dependency install, build, etc.)

`setup-commands` examples¶

# Python
setup-commands: |
  pip install -e ".[dev]"

# Node.js
setup-commands: |
  npm ci

# Go
setup-commands: |
  go mod download

# Multiple steps
setup-commands: |
  pip install -e ".[dev]"
  npm ci
  make build

How it works¶

Each workflow has two layers:

Workflow (gh-aw-*.md -> gh-aw-*.lock.yml): The agent logic, compiled by gh-aw. Triggers only on workflow_call with standard inputs (additional-instructions, setup-commands) and a COPILOT_GITHUB_TOKEN secret.
Trigger (<name>/example.yml): A plain YAML file that defines the actual event triggers (schedule, PR events, slash commands, etc.) and calls the compiled .lock.yml via uses:. These serve as both examples for consumers and dogfood for this repo (copied to .github/workflows/trigger-*.yml by scripts/dogfood.sh for workflows not listed in EXCLUDED_WORKFLOWS).

Consumer repos copy a workflow's example.yml, change the uses: path if needed, and customize the with: inputs. Updates propagate automatically when this repo updates the v0 tag on release.