Design Patterns — Choosing the Right Pattern

GitHub Agentic Workflows defines 15 named design patterns — proven architectures for specific types of automation. Instead of inventing your workflow structure from scratch, you pick the pattern that matches your goal and fill in the details.

Think of these patterns like design patterns in software: you wouldn't invent your own Observer pattern each time you need event handling. Similarly, you don't need to invent a new workflow architecture each time you want to automate something in your repository.

Why Patterns Matter

Every pattern answers three questions:

1. What triggers it? — The event or schedule that starts the workflow.
2. What does the agent do? — The shape of the analysis or action.
3. How does output flow? — Where results go and what permissions are needed.

By naming these shapes, patterns give you a shared vocabulary, predictable behavior, and clear safety boundaries. When someone says "that's an IssueOps workflow," you immediately know: it triggers on issue events, reads the issue context, and responds with labels or comments.

The Six Patterns Every Solo Developer Needs

Of the 15 available patterns, these six cover the vast majority of what a solo developer or small team will build:

Pattern Selection Guide

Given a goal, which pattern fits? Use this decision table:

Combining Patterns

Real workflows often combine two patterns. Here are the most common combinations:

Connection to Your Work

The workflows you've already built (or are planning) map directly to these patterns:

Recognizing the pattern means you can look at gh-aw's documentation for that pattern and immediately find configuration options, best practices, and examples that apply to your workflow.

Anatomy of a Pattern in Practice

Here's how IssueOps looks as a concrete workflow — the most common starting point for solo developers:

---
description: "Auto-triage new issues with labels and priority"
on:
  issues:
    types: [opened]

permissions:
  issues: write
  contents: read

engine:
  id: copilot
  model: gpt-4.1-mini

max-ai-credits: 300

safe-outputs:
  add-labels:
    allowed: [bug, feature, question, docs, good-first-issue, priority-high, priority-low]
  add-comment:
    max-length: 500
---

Triage this newly opened issue.

Read the issue title and body. Based on the content:

1. **Classify** — is this a bug report, feature request, question, or docs issue?
2. **Prioritize** — does it describe data loss, security, or production breakage (high)?
   Or is it cosmetic, nice-to-have, or unclear (low)?
3. **Comment** — post a brief acknowledgment explaining your classification.
   If the issue is missing reproduction steps (for bugs), ask for them.

Apply the appropriate labels from the allowed set.

If the issue is clearly spam or completely empty, apply no labels and
comment asking for clarification.

Notice how the pattern shapes every decision: the trigger (issues: opened), the permissions (write issues, read contents), and the safe-outputs (only specific labels allowed, comment length capped). The pattern constrains the agent so you don't have to think about safety boundaries from scratch.

The Other Nine Patterns (Brief)

For completeness, here are the remaining patterns you'll encounter in gh-aw documentation. You won't need most of these until your automation becomes more complex:

These follow the same principles — named trigger, scoped permissions, constrained output — just applied to more specialized use cases.

Check Your Understanding

What's Next

You now know how to identify which pattern fits your automation goal — and when to combine patterns for more complex scenarios. The next lesson covers testing and debugging workflows — how to develop workflows iteratively, test them locally, and diagnose failures when your agent doesn't behave as expected.