Skip to content
GitHub Agentic Workflows

Blog

Meet the Workflows: Continuous Style

Peli de Halleux

Welcome back to Peli’s Agent Factory!

In our previous posts, we’ve explored how autonomous cleanup agents work continuously in the background, simplifying code and improving structure. Today’s post is dedicated to one agent, and the larger admirable concept it represents: continuously making things beautiful.

Today’s post is dedicated to one agent, and the larger concept it represents: the Terminal Stylist workflow. This agent’s purpose is to make things look better, by reviewing and enhancing the style of command-line interface (CLI) output.

Command-line interfaces are a primary interaction point for developer tools. When output is inconsistent or noisy, it still “works,” but it adds friction. When it’s well-styled, information becomes scannable, color highlights what matters, layouts remain readable across light and dark themes, and the overall experience feels professional.

Under the hood, the workflow looks for non-test Go files with console-related code and patterns such as fmt.Print*, console.*, and Lipgloss usage. It then checks for consistency in formatting helpers (especially for errors), sensible TTY-aware rendering, and accessible color choices. When it finds rough edges, it proposes concrete improvements, such as replacing plain output like fmt.Println("Error: compilation failed") with fmt.Fprintln(os.Stderr, console.FormatErrorMessage("Compilation failed")), or swapping ad-hoc ANSI coloring for adaptive Lipgloss styles.

Rather than opening issues or PRs, the Terminal Stylist posts GitHub Discussions in the “General” category. Styling changes are often subjective, and discussions make it easier to converge on the right balance between simplicity and polish.

The Terminal Stylist is proof that autonomous cleanup agents can have surprisingly specific taste. It focuses on terminal UI craft, using the Charmbracelet ecosystem (especially Lipgloss and Huh) to keep the CLI not just correct, but pleasant to use.

The Terminal Stylist shows that autonomous improvement isn’t limited to structure and correctness; it also covers user experience. By continuously reviewing output patterns, it helps new features match the project’s visual language, keeps styling aligned with evolving libraries, and nudges the CLI toward accessibility and clarity.

This is especially useful in AI-assisted development, where quick suggestions tend to default to fmt.Println. The Terminal Stylist cleans up after the AI, bringing that output back in line with the project’s conventions.

Continuous Style is a new frontier in code quality. It recognizes that how code looks matters just as much as how it works. By automating style reviews, we ensure that every interaction with our tools feels polished and professional.

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

Terminal Stylist:

Terminal window
gh aw add https://github.com/github/gh-aw/blob/v0.37.7/.github/workflows/terminal-stylist.md

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

Beyond simplicity, structure, and style, there’s a final dimension: holistic quality improvement. How do we analyze dependencies, type safety, and overall repository health?

Continue reading: Continuous Improvement Workflows →

Learn more about GitHub Agentic Workflows, try the Quick Start guide, and explore Charmbracelet, the terminal UI ecosystem referenced by the Terminal Stylist.


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

Meet the Workflows: Continuous Refactoring

Peli de Halleux

Welcome back to Peli’s Agent Factory!

In our previous post, we met automated agents that detect complexity and propose simpler solutions. These work tirelessly in the background, cleaning things up. Now let’s explore similar agents that take a deeper structural view, extending the automation to structural refactoring.

Our next two agents continuously analyze code structure, suggesting systematic improvements:

The Semantic Function Refactor workflow combines agentic AI with code analysis tools to analyze and address the structure of the entire codebase. It analyzes all Go source files in the pkg/ directory to identify functions that might be in the wrong place.

As codebases evolve, functions sometimes end up in files where they don’t quite belong. Humans struggle to notice these organizational issues because we work on one file at a time and focus on making code work rather than on where it lives.

The workflow performs comprehensive discovery by

  1. algorithmically collecting all function names from non-test Go files, then
  2. agentically grouping functions semantically by name and purpose.

It then identifies functions that don’t fit their current file’s theme as outliers, uses Serena-powered semantic code analysis to detect potential duplicates, and creates issues recommending consolidated refactoring. These issues can then be reviewed and addressed by coding agents.

The workflow follows a “one file per feature” principle: files should be named after their primary purpose, and functions within each file should align with that purpose. It closes existing open issues with the [refactor] prefix before creating new ones. This prevents issue accumulation and ensures recommendations stay current.

Go Pattern Detector: The Consistency Enforcer

Section titled “Go Pattern Detector: The Consistency Enforcer”

The Go Pattern Detector uses another code analysis tool, ast-grep, to scan for specific code patterns and anti-patterns. This uses abstract syntax tree (AST) pattern matching to find exact structural patterns.

Currently, the workflow detects use of json:"-" tags in Go structs - a pattern that can indicate fields that should be private but aren’t, serialization logic that could be cleaner, or potential API design issues.

The workflow runs in two phases. First, AST scanning runs on a standard GitHub Actions runner:

Terminal window
# Install ast-grep
cargo install ast-grep --locked
# Scan for patterns
sg --pattern 'json:"-"' --lang go .

If patterns are found, it triggers the second phase where the coding agent analyzes the detected patterns, reviews context around each match, determines if patterns are problematic, and creates issues with specific recommendations. This architecture is efficient: fast AST scanning uses minimal resources, expensive AI analysis only runs when needed, false positives don’t consume AI budget, and the approach scales to frequent checks without cost concerns.

The workflow is designed to be extended with additional pattern checks - common anti-patterns like ignored errors or global state, project-specific conventions, performance anti-patterns, and security-sensitive patterns.

These workflows demonstrate how AI agents can continuously maintain institutional knowledge about code organization. The benefits compound over time: better organization makes code easier to find, consistent patterns reduce cognitive load, reduced duplication improves maintainability, and clean structure attracts further cleanliness. They’re particularly valuable in AI-assisted development, where code gets written quickly and organizational concerns can take a backseat to functionality.

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

Semantic Function Refactor:

Terminal window
gh aw add https://github.com/github/gh-aw/blob/v0.37.7/.github/workflows/semantic-function-refactor.md

Go Pattern Detector:

Terminal window
gh aw add https://github.com/github/gh-aw/blob/v0.37.7/.github/workflows/go-pattern-detector.md

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

Beyond structure and organization, there’s another dimension of code quality: presentation and style. How do we maintain beautiful, consistent console output and formatting?

Continue reading: Meet the Workflows: Continuous Style →


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

Meet the Workflows: Continuous Simplicity

Peli de Halleux

Ah, what marvelous timing! Come, come, let me show you the next wonder 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 pull requests 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.

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.

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 https://github.com/github/gh-aw/blob/v0.37.7/.github/workflows/code-simplifier.md

Duplicate Code Detector:

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

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

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.

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 https://github.com/github/gh-aw/blob/v0.37.7/.github/workflows/issue-triage-agent.md

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

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 and its companion githubnext/agentics collection. 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