Ah! Let’s discuss the art of managing issues and pull requests at Peli’s Agent Factory! A most delicious topic indeed!
In our previous post, we explored documentation and content workflows - agents that maintain glossaries, technical docs, slide decks, and blog content. We learned how we took a heterogeneous approach to documentation agents - some workflows generate content, others maintain it, and still others validate it.
Now let’s talk about the daily rituals of software development: managing issues and pull requests. GitHub provides excellent primitives for collaboration, but there’s ceremony involved - linking related issues, merging main into PR branches, assigning work, closing completed sub-issues, optimizing templates. These are small papercuts individually, but they can add up to significant friction.
The Issue Arborist is an organizational workflow that has created 77 discussion reports (titled “[Issue Arborist] Issue Arborist Report”) and 18 parent issues to group related sub-issues. It keeps the issue tracker organized by automatically linking related issues, building a dependency tree we’d never maintain manually. For example, #12037 grouped engine documentation updates.
The Issue Monster is the task dispatcher - it assigns issues to the GitHub platform’s asynchronous Copilot coding agent one at a time. It doesn’t create PRs itself, but enables every other agent’s work by feeding them tasks. This prevents the chaos of parallel work on the same codebase.
Mergefest is an orchestrator workflow that automatically merges main into PR branches, keeping long-lived PRs up to date without manual intervention. It eliminates the “please merge main” dance.
Sub Issue Closer automatically closes completed sub-issues when their parent issue is resolved, keeping the issue tracker clean.
Issue and PR management workflows don’t replace GitHub’s features; they enhance them, removing ceremony and making collaboration feel smoother.
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.
Step right up, step right up, and enter the documentation chamber of Peli’s Agent Factory! Pure imagination meets technical accuracy in this most delightful corner of our establishment!
In our previous posts, we explored autonomous cleanup agents - workflows that continuously improve code quality by simplifying complexity, refactoring structure, polishing style, and maintaining overall repository health. These agents never take a day off, quietly working to make our codebase better.
Now let’s address one of software development’s eternal challenges: keeping documentation accurate and up-to-date. Code evolves rapidly; docs… not so much. Terminology drifts, API examples become outdated, slide decks grow stale, and blog posts reference deprecated features. The question isn’t “can AI agents write good documentation?” but rather “can they maintain it as code changes?” Documentation and content workflows challenge conventional wisdom about AI-generated technical content. Spoiler: the answer involves human review, but it’s way better than the alternative (no docs at all).
These agents maintain high-quality documentation and content:
Daily Documentation Updater - Reviews and updates documentation to ensure accuracy and completeness - 57 merged PRs out of 59 proposed (96% merge rate)
Glossary Maintainer - Keeps glossary synchronized with codebase - 10 merged PRs out of 10 proposed (100% merge rate)
Documentation Unbloat - Reviews and simplifies documentation by reducing verbosity - 88 merged PRs out of 103 proposed (85% merge rate)
Documentation Noob Tester - Tests documentation as a new user would, identifying confusing steps - 9 merged PRs (43% merge rate) via causal chain
Slide Deck Maintainer - Maintains presentation slide decks - 2 merged PRs out of 5 proposed (40% merge rate)
Multi-device Docs Tester - Tests documentation site across mobile, tablet, and desktop devices - 2 merged PRs out of 2 proposed (100% merge rate)
Blog Auditor - Verifies blog posts are accessible and contain expected content - 6 audits completed (5 passed, 1 flagged issues)
Documentation is where we challenged conventional wisdom. Can AI agents write good documentation?
The Technical Doc Writer generates API docs from code, but more importantly, it maintains them - updating docs when code changes. The Glossary Maintainer caught terminology drift (“we’re using three different terms for the same concept”).
The Slide Deck Maintainer keeps our presentation materials current without manual updates.
The Multi-device Docs Tester uses Playwright to verify our documentation site works across phones, tablets, and desktops - testing responsive layouts, accessibility, and interactive elements. It catches visual regressions and layout issues that only appear on specific screen sizes.
The Blog Auditor ensures our blog posts stay accurate as the codebase evolves - it flags outdated code examples and broken links. Blog Auditor is a validation-only workflow that creates audit reports rather than code changes. It has run 6 audits (5 passed, 1 flagged out-of-date content), confirming blog accuracy.
Documentation Noob Tester deserves special mention for its exploratory nature. It has produced 9 merged PRs out of 21 proposed (43% merge rate) through a causal chain: 62 discussions analyzed → 21 issues created → 21 PRs. The lower merge rate reflects this workflow’s exploratory nature - it identifies many potential improvements, some of which are too ambitious for immediate implementation. For example, Discussion #8477 led to Issue #8486 which spawned PRs #8716 and #8717, both merged.
AI-generated docs need human/agent review, but they’re dramatically better than no docs (which is often the alternative). Validation can be automated to a large extent, freeing writers to focus on content shaping, topic, clarity, tone, and accuracy.
In this collection of agents, we took a heterogeneous approach - some workflows generate content, others maintain it, and still others validate it. Other approaches are possible - all tasks can be rolled into a single agent. We found that it’s easier to explore the space by using multiple agents, to separate concerns, and that encouraged us to use agents for other communication outputs such as blogs and slides.
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.
In our previous posts, we’ve explored autonomous cleanup agents. Now we complete the picture with agents that analyze dependencies, type safety, and overall repository quality.
The Go Module Usage Expert is perhaps the most uniquely characterized workflow in the factory - an “enthusiastic Go module expert” who performs daily deep-dive reviews of the project’s Go dependencies. This isn’t just dependency scanning - it’s thoughtful analysis of how well we’re using the tools we’ve chosen.
Most dependency tools focus on vulnerabilities or outdated versions. Go Module Usage Expert asks deeper and more positive questions: Are we using this module’s best features? Have recent updates introduced better patterns we should adopt? Could we use a more appropriate module for this use case? Are we following the module’s recommended practices?
Go Module Usage Expert uses an intelligent selection algorithm. It extracts direct dependencies from go.mod, fetches GitHub metadata for each dependency including last update time, sorts by recency to prioritize recently updated modules, uses round-robin selection to cycle through modules ensuring comprehensive coverage, and maintains persistent memory through cache-memory to track which modules were recently reviewed.
This ensures recently updated modules get reviewed first since new features might be relevant, all modules eventually get reviewed so nothing is forgotten, and reviews don’t repeat unnecessarily thanks to cache tracking.
For each module, Go Module Usage Expert researches the repository (releases, docs, best practices), analyzes actual usage patterns using Serena, and generates actionable recommendations. It saves summaries under scratchpad/mods/ and opens GitHub Discussions.
The output of Go Module Usage Expert is a discussion, which is then often “task mined” for actionable tasks using the TaskOps design pattern.
Let’s take a look at an example of how this works:
Go Module Usage Expert created the Go Module Review: actionlint discussion after noticing the actionlint module was updated.
Through this multi-agent causal chain pattern, Go Module Usage Expert has generated 58 merged PRs out of 74 proposed (78% merge rate) across 67 module reviews. Notable chains include: spinner improvements (4 PRs from briandowns/spinner review), MCP SDK v1.2.0 upgrade (5 PRs from go-sdk review), and terminal styling overhaul (3 PRs from lipgloss review).
The Typist analyzes Go type usage patterns with a singular focus: improving type safety. It hunts for untyped code that should be strongly typed, and identifies duplicated type definitions that create confusion.
Typist looks for untyped usages: interface{} or any where specific types would be better, untyped constants that should have explicit types, and type assertions that could be eliminated with better design. It also hunts for duplicated type definitions - the same types defined in multiple packages, similar types with different names, and type aliases that could be unified.
Using grep patterns and Serena’s semantic analysis, it discovers type definitions, identifies semantic duplicates, analyzes untyped usage patterns, and generates refactoring recommendations.
Typist also uses the TaskOps pattern. This means the job of Typist is not to fix code, but to analyze code and recommend possible improvements.
Let’s take a look at an example of this in practice:
Through this multi-agent causal chain, Typist has produced 19 merged PRs out of 25 proposed (76% merge rate) from 57 discussions → 22 issues → 25 PRs. The blog example (Discussion #4082 → Issue #4155 → PR #4158) is a verified causal chain.
The static v. dynamic typing debate has raged for decades. Today’s hybrid languages like Go, C#, TypeScript and F# support both strong and dynamic typing. Continuous typing improvement offers a new and refreshing perspective on this old debate: rather than enforcing strict typing upfront, we can develop quickly with flexibility, then let autonomous agents like Typist trail behind, strengthening type safety over time. This allows us to get the best of both worlds: rapid development without getting bogged down in type design, while still achieving strong typing and safety as the codebase matures.
Functional Pragmatist applies moderate functional programming techniques to improve code clarity and safety, balancing pragmatism with functional principles.
The workflow focuses on seven patterns: immutability, functional initialization, transformative operations (map/filter/reduce), functional options pattern, avoiding shared mutable state, pure functions, and reusable logic wrappers.
It searches for opportunities (mutable variables, imperative loops, initialization anti-patterns, global state), scores by safety/clarity/testability improvements, uses Serena for deep analysis, and implements changes like converting to composite literals, using functional options, eliminating globals, extracting pure functions, and creating reusable wrappers (Retry, WithTiming, Memoize).
The workflow is pragmatic: Go’s simple style is respected, for-loops stay when clearer, and abstraction is added only where it genuinely improves code. It runs Tuesday and Thursday mornings, systematically improving patterns over time.
Functional Pragmatist (originally named “Functional Enhancer”) is a recent addition - so far it has created 2 PRs (both merged, 100% merge rate), demonstrating that its pragmatic approach to functional patterns is well-received.
Repository Quality Improver takes the widest view, selecting a different focus area each day to analyze the repository from that perspective.
It uses cache memory to ensure diverse coverage: 60% custom areas (repository-specific concerns), 30% standard categories (code quality, documentation, testing, security, performance), and 10% revisits for consistency.
Standard categories cover fundamentals. Custom areas are repository-specific: error message consistency, CLI flag naming conventions, workflow YAML generation patterns, console output formatting, configuration validation.
The workflow loads recent history, selects the next area, spends 20 minutes on deep analysis, generates discussions with recommendations, and saves state. It looks for cross-cutting concerns that don’t fit neatly into other categories but impact overall quality.
Example reports from our own use of this workflow are:
Through its multi-agent causal chain (59 discussions → 30 issues → 40 PRs), Repository Quality Improver has produced 25 merged PRs out of 40 proposed (62% merge rate), taking a holistic view of quality from multiple angles.
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.
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.
Terminal Stylist demonstrates multi-agent collaboration at its best. The workflow created 31 daily analysis reports as discussions, which were then mined by Discussion Task Miner and Plan Command into 25 actionable issues. Those issues spawned 16 merged PRs (80% merge rate) improving console output across the codebase - from Charmbracelet best practices adoption to progress bars to stderr routing fixes. Terminal Stylist never creates PRs directly; instead, it identifies opportunities that other agents implement, showing how workflows can collaborate through GitHub’s discussion → issue → PR pipeline.
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.
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.
Beyond simplicity, structure, and style, there’s a final dimension: holistic quality improvement. How do we analyze dependencies, type safety, and overall repository health?
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.
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
algorithmically collecting all function names from non-test Go files, then
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.
In our extended use of Semantic Function Refactoring, the workflow has driven 112 merged PRs out of 142 proposed (79% merge rate) through causal chains - creating 99 refactoring issues that downstream agents turn into code changes. For example, issue #12291 analyzing code organization opportunities led to PR #12363 splitting permissions.go into focused modules (928→133 lines).
Large files are a common code smell - they often indicate unclear boundaries, mixed responsibilities, or accumulated complexity. The Large File Simplifier workflow monitors file sizes daily and creates actionable issues when files grow too large.
The workflow runs on weekdays, analyzing all Go source files in the pkg/ directory. It identifies the largest file, checks if it exceeds healthy size thresholds, and creates a detailed issue proposing how to split it into smaller, more focused files.
What makes this workflow effective is its focus and prioritization. Instead of overwhelming developers with issues about every large file, it creates at most one issue, targeting the largest offender. The workflow also skips if an open [file-diet] issue already exists, preventing duplicate work.
In our extended use, Large File Simplifier (also known as “Daily File Diet”) has driven 26 merged PRs out of 33 proposed (79% merge rate) through causal chains - creating 37 file-diet issues targeting the largest files, which downstream agents turn into modular code changes. For example, issue #12535 targeting add_interactive.go led to PR #12545 refactoring it into 6 domain-focused modules.
The workflow uses Serena for semantic code analysis to understand function relationships and propose logical boundaries for splitting. It both counts lines and analyzes the code structure to suggest meaningful module boundaries that make sense.
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.
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.
Beyond structure and organization, there’s another dimension of code quality: presentation and style. How do we maintain beautiful, consistent console output and formatting?
