GitHub Agentic Workflows

Blog

Meet the Workflows: Continuous Simplicity

Peli de Halleux

Ah, what marvelous timing! Come, come, let me show you the next wonders in Peli’s Agent Factory!

In our previous post, we explored how a simple triage workflow helps us stay on top of incoming activity - automatically labeling issues and reducing cognitive load.

Now let’s meet the agents that work quietly in the background to keep code simple and clean. These workflows embody a powerful principle: code quality is not a destination, it’s a continuous practice. While developers race ahead implementing features and fixing bugs, autonomous cleanup agents trail behind, constantly sweeping, polishing, and simplifying. Let’s meet the agents that hunt for complexity.

The next two agents represent different aspects of code simplicity: detecting overcomplicated code and duplicated logic:

The Automatic Code Simplifier runs daily, analyzing recently modified code for opportunities to simplify without changing functionality. It looks at what changed in the last few commits and asks: “Could this be clearer? Could it be shorter? Could it be more idiomatic?”

This workflow is particularly valuable after rapid development sessions. When you’re racing to implement a feature or fix a bug, code often becomes more complex than necessary. Variables get temporary names, logic becomes nested, error handling gets verbose. The workflow tirelessly cleans up after these development sessions, creating PRs that preserve functionality while improving clarity, consistency, and maintainability.

The kinds of simplifications it proposes range from extracting repeated logic into helper functions to converting nested if-statements to early returns. It spots opportunities to simplify boolean expressions, use standard library functions instead of custom implementations, and consolidate similar error handling patterns.

Code Simplifier is a recent addition - so far it has created 6 PRs (5 merged, 83% merge rate), such as extracting an action mode helper to reduce code duplication and simplifying validation config code for clarity.

The Duplicate Code Detector uses traditional, road-tested semantic code analysis in conjunction with agentic reasoning to find duplicate patterns. It understands code meaning rather than just textual similarity, catching patterns where:

  • The same logic appears with different variable names
  • Similar functions exist across different files
  • Repeated patterns could be extracted into utilities
  • Structure is duplicated even if implementation differs

What makes this workflow special is its use of semantic analysis through Serena - a powerful coding agent toolkit capable of turning an LLM into a fully-featured agent that works directly on your codebase. When we use Serena, we understand code at the compiler-resolved level, not just syntax.

The workflow focuses on recent changes in the latest commits, intelligently filtering out test files, workflows, and non-code files. It creates issues only for significant duplication: patterns spanning more than 10 lines or appearing in 3 or more locations. It performs a multi-phase analysis. It starts by setting up Serena’s semantic environment for the repository, then finds changed .go and .cjs files while excluding tests and workflows. Using get_symbols_overview and find_symbol, it understands structure, identifies similar function signatures and logic blocks, and compares symbol overviews across files for deeper similarities. It creates issues with the [duplicate-code] prefix and limits itself to 3 issues per run, preventing overwhelm. Issues include specific file references, code snippets, and refactoring suggestions.

In our extended use of Duplicate Code Detector, the agent has raised 76 merged PRs out of 96 proposed (79% merge rate), demonstrating sustained practical value of semantic code analysis. Recent examples include refactoring expired-entity cleanup scripts to share expiration processing and refactoring safe-output update handlers to eliminate duplicate control flow.

Continuous AI for Simplicity - A New Paradigm

Section titled “Continuous AI for Simplicity - A New Paradigm”

Together, these workflows point towards an emerging shift in how we maintain code quality. Instead of periodic “cleanup sprints” or waiting for code reviews to catch complexity, we have agents that clean up after us and continuously monitor and propose improvements. This is especially valuable in AI-assisted development. When developers use AI to write code faster, these cleanup agents ensure speed doesn’t sacrifice simplicity. They understand the same patterns that humans recognize but apply them consistently across the entire codebase, every day.

The workflows never take a day off, never get tired, and never let technical debt accumulate. They embody the principle that good enough can always become better, and that incremental improvements compound over time.

You can add these workflows to your own repository and remix them. Get going with our Quick Start, then run one of the following:

Automatic Code Simplifier:

Terminal window
gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/code-simplifier.md

Duplicate Code Detector:

Terminal window
gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/duplicate-code-detector.md

Then edit and remix the workflow specifications to meet your needs, regenerate the lock file using gh aw compile, and push to your repository. See our Quick Start for further installation and setup instructions.

You can also create your own workflows.

Simplification is just the beginning. Beyond removing complexity, we can use agents to continuously improve code in many more ways. Our next posts explore this topic.

Continue reading: Continuous Refactoring →


This is part 2 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Meet the Workflows: Issue Triage

Peli de Halleux

Welcome back to Peli’s Agent Factory!

We’re the GitHub Next team. Over the past months, we’ve built and operated a collection of automated agentic workflows. These aren’t just demos - these are real agents doing actual work in our github/gh-aw repository and others.

Think of this as your guided tour through our agent factory. We’re showcasing the workflows that caught our attention. Every workflow links to its source markdown file, so you can peek under the hood and see exactly how it works.

To start the tour, let’s begin with one of the simpler workflows that handles incoming activity - issue triage.

Issue triage represents a “hello world” of automated agentic workflows: practical, immediately useful, relatively simple, and impactful. It’s used as the starter example in other agentic automation technologies like Claude Code in GitHub Actions.

When a new issue is opened, the triage agent analyzes its content, does research in the codebase and other issues, responds with a comment, and applies appropriate labels based on predefined categories. This helps maintainers quickly understand the nature of incoming issues without manual review.

Let’s take a look at the full Issue Triage Agent:

---
timeout-minutes: 5
on:
issue:
types: [opened, reopened]
permissions:
issues: read
tools:
github:
toolsets: [issues, labels]
safe-outputs:
add-labels:
allowed: [bug, feature, enhancement, documentation, question, help-wanted, good-first-issue]
add-comment: {}
---
# Issue Triage Agent
List open issues in ${{ github.repository }} that have no labels. For each
unlabeled issue, analyze the title and body, then add one of the allowed
labels: `bug`, `feature`, `enhancement`, `documentation`, `question`,
`help-wanted`, or `good-first-issue`.
Skip issues that:
- Already have any of these labels
- Have been assigned to any user (especially non-bot users)
Do research on the issue in the context of the codebase and, after
adding the label to an issue, mention the issue author in a comment, explain
why the label was added and give a brief summary of how the issue may be
addressed.

Note how concise this is - it’s like reading a to-do list for the agent. The workflow runs whenever a new issue is opened or reopened. It checks for unlabeled issues, analyzes their content, and applies appropriate labels based on content analysis. It even leaves a friendly comment explaining the label choice.

In the frontmatter, we define permissions, tools, and safe outputs. This ensures the agent only has access to what it needs and can’t perform any unsafe actions. The natural language instructions in the body guide the agent’s behavior in a clear, human-readable way.

Issue triage workflows in public repositories may need to process issues from all contributors. By default, min-integrity: approved restricts agent visibility to owners, members, and collaborators. If you are a maintainer in a public repository and need your triage agent to see and label issues from users without push access, set min-integrity: none in your GitHub tools configuration. See Integrity Filtering for security considerations and best practices.

We’ve deliberately kept this workflow ultra-simple. In practice, in your own repo, customization is key. Triage differs in every repository. Tailoring workflows to your specific context will make them more effective. Generic agents are okay, but customized ones are often a better fit.

You can add this workflow to your own repository and remix it as follows:

Issue Triage Agent:

Terminal window
gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/issue-triage-agent.md

Then edit and remix the workflow specification to meet your needs, regenerate the lock file using gh aw compile, and push to your repository. See our Quick Start for further installation and setup instructions.

You can also create your own workflows.

Next Up: Code Quality & Refactoring Workflows

Section titled “Next Up: Code Quality & Refactoring Workflows”

Now that we’ve explored how triage workflows help us stay on top of incoming activity, let’s turn to something far more radical and powerful: agents that continuously improve code.

Continue reading: Continuous Simplicity →


This is part 1 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Welcome to Peli's Agent Factory

Peli de Halleux

Welcome, welcome, WELCOME to Peli’s Agent Factory!

Imagine a software repository where AI agents work alongside your team - not replacing developers, but handling the repetitive, time-consuming tasks that slow down collaboration and forward progress.

Peli’s Agent Factory is our exploration of what happens when you take the design philosophy of “let’s create a new automated agentic workflow for that” as the answer to almost every opportunity that arises! What happens when you max out on automated agentic workflows - when you make and use dozens of specialized, automated AI agentic workflows and use them in practice.

Software development is changing rapidly. This is our attempt to understand how automated agentic AI can make software teams more efficient, collaborative, and more enjoyable.

It’s basically a candy shop chocolate factory of agentic workflows. And we’d like to share it with you.

Let’s explore together!

Peli’s factory is a collection of automated agentic workflows we use in practice. We have built and operated over 100 automated agentic workflows within the github/gh-aw repository. These were used mostly in the context of the github/gh-aw project itself, but some have also been applied at scale in GitHub internal repositories. These weren’t hypothetical demos - they were working agents that:

Some workflows are “read-only analysts”. Others proactively propose changes through pull requests. Some are meta-agents that monitor and improve the health of other workflows.

We know we’re taking things to an extreme here. Most repositories won’t need dozens of agentic workflows. No one can read all these outputs (except, of course, another workflow). But by pushing the boundaries, we learned valuable lessons about what works, what doesn’t, and how to design safe, effective agentic workflows that teams can trust and use.

When we started exploring agentic workflows, we faced a fundamental question: What should repository-level automated agentic workflows actually do?

Rather than trying to build one “perfect” agent, we took a broad, heterogeneous approach:

  1. Embrace diversity - Create many specialized workflows as we identified opportunities
  2. Use them continuously - Run them in real development workflows
  3. Observe what works - Find which patterns work and which fail
  4. Share the knowledge - Catalog the structures that make agents safe and effective

The factory becomes both an experiment and a reference collection - a living library of patterns that others can study, adapt, and remix. Each workflow is written in natural language using Markdown, then converted into secure GitHub Actions that run with carefully scoped permissions with guardrails. Everything is observable, auditable, and remixable.

In our first series, Meet the Workflows, we’ll take you on a tour of the most interesting agents in the factory. Each article is bite-sized. If you’d like to skip ahead, here’s the full list of articles in the series:

  1. Meet a Simple Triage Workflow
  2. Introducing Continuous Simplicity
  3. Introducing Continuous Refactoring
  4. Introducing Continuous Style
  5. Introducing Continuous Improvement
  6. Introducing Continuous Documentation

After that we have a cornucopia of specialized workflow categories for you to dip into:

Every post comes with instructions about how to add the workflow to your own repository, or cusomtize and remix it to create your own variant.

Running this many agents in production is a learning experience! We’ve watched agents succeed spectacularly and fail in instructive ways. Over the next few weeks, we’ll also be sharing what we’ve learned through a series of detailed articles. We’ll be looking at the design and operational patterns we’ve discovered, security lessons, and practical guides for building your own workflows.

To give a taste, some key lessons are emerging:

  • Repository-level automation is powerful - Agents embedded in the development workflow can have outsized impact
  • Specialization reveals possibilities - Focused agents allowed us to find more useful applications of automation than a single monolithic coding agent
  • Guardrails enable innovation - Strict constraints actually make it easier to experiment safely
  • Meta-agents are valuable - Agents that watch other agents become incredibly valuable
  • Cost-quality tradeoffs are real - Longer analyses aren’t always better

We’ll dive deeper into these lessons in upcoming articles.

Want to start with automated agentic workflows on GitHub? See our Quick Start.

Peli’s Agent Factory is by GitHub Next, Microsoft Research and collaborators, including Peli de Halleux, Don Syme, Mara Kiefer, Edward Aftandilian, Russell Horton, Jiaxiao Zhou. This is part of GitHub Next’s exploration of Continuous AI - making AI-enriched automation as routine as CI/CD.

Current Factory Status