From 7eb632889d7e6d1c00e55ab3dc1ceb4585af148d Mon Sep 17 00:00:00 2001 From: GitHub Actions Date: Fri, 13 Feb 2026 15:14:34 +0000 Subject: [PATCH] docs: remove bloat from glossary Reduced verbosity while preserving all essential information: - Consolidated bullet points into concise prose - Removed repetitive "Use for:" sections in operational patterns - Eliminated redundant code examples - Streamlined definitions without losing technical accuracy - Reduced excessive explanatory text Co-Authored-By: Claude Sonnet 4.5 --- docs/src/content/docs/reference/glossary.md | 305 ++++---------------- 1 file changed, 58 insertions(+), 247 deletions(-) diff --git a/docs/src/content/docs/reference/glossary.md b/docs/src/content/docs/reference/glossary.md index e542229a222..80733e35423 100644 --- a/docs/src/content/docs/reference/glossary.md +++ b/docs/src/content/docs/reference/glossary.md @@ -15,35 +15,15 @@ This glossary provides definitions for key technical terms and concepts used in ### Agentic -The term **"agentic"** means having agency - the ability to act independently, make context-aware decisions, and adapt behavior based on circumstances. When applied to workflows: - -- **Agentic workflows** use AI to understand context and choose appropriate actions, rather than just following predefined steps -- **Agentic systems** can reason about situations and make informed decisions without explicit programming for every scenario -- Contrasts with **deterministic** workflows that execute fixed sequences of actions - -The word comes from "agent" (an entity that acts on behalf of someone) + "-ic" (having the characteristics of). +Having agency - the ability to act independently, make context-aware decisions, and adapt behavior based on circumstances. Agentic workflows use AI to understand context and choose appropriate actions, contrasting with deterministic workflows that execute fixed sequences. From "agent" + "-ic" (having the characteristics of). ### Agentic Workflow -An AI-powered workflow that can reason, make decisions, and take autonomous actions using natural language instructions. Unlike traditional workflows with fixed if/then rules, agentic workflows interpret context and adapt their behavior based on the situation they encounter. - -**Key characteristics:** - -- Written in natural language markdown instead of complex YAML -- Uses AI to understand repository context (issues, PRs, code) -- Makes context-aware decisions without explicit conditionals -- Adapts responses to different situations flexibly - -**Example:** Instead of "if issue has label X, do Y", you write "analyze this issue and provide helpful context", and the AI decides what's helpful based on the specific issue content. +An AI-powered workflow that reasons, makes decisions, and takes autonomous actions using natural language instructions. Written in markdown instead of complex YAML, agentic workflows interpret context and adapt behavior flexibly. For example, instead of "if issue has label X, do Y", you write "analyze this issue and provide helpful context", and the AI decides what's helpful based on the specific issue content. ### Orchestration -Workflows that coordinate one or more **worker workflows** toward a shared goal. A typical orchestrator/worker design: - -- An **orchestrator** decides what work to do next and dispatches workers -- **Workers** execute the concrete tasks with scoped tools and limits - -See the [Orchestration guide](/gh-aw/patterns/orchestration/) for implementation patterns. +Workflows that coordinate one or more worker workflows toward a shared goal. An orchestrator decides what work to do next and dispatches workers, while workers execute concrete tasks with scoped tools and limits. See the [Orchestration guide](/gh-aw/patterns/orchestration/). ### Orchestrator Workflow @@ -55,30 +35,19 @@ A workflow dispatched by an orchestrator that performs a focused unit of work (t ### Agentic Engine or Coding Agent -The AI system (typically GitHub Copilot CLI) that executes natural language instructions in an agentic workflow. The coding agent interprets tasks, uses available tools, and generates outputs based on context. - -Think of the coding agent as an AI assistant with access to tools (GitHub API, file system, web search) that can understand your instructions and complete tasks autonomously. The coding agent is the "intelligence" that makes workflows agentic. +The AI system (typically GitHub Copilot CLI) that executes natural language instructions in an agentic workflow. The agent interprets tasks, uses available tools (GitHub API, file system, web search), and generates outputs based on context autonomously. ### Frontmatter -The configuration section at the top of a workflow file, enclosed between `---` markers. Contains YAML settings that control when the workflow runs, what permissions it has, and what tools it can use. Separates technical configuration from natural language instructions. - -```yaml ---- -on: issues -permissions: read-all -tools: - github: ---- -``` +Configuration section at the top of a workflow file, enclosed between `---` markers. Contains YAML settings controlling when the workflow runs, permissions, and available tools, separating technical configuration from natural language instructions. ### Compilation -The process of translating Markdown workflows (`.md` files) into GitHub Actions YAML format (`.lock.yml` files). During compilation, workflows are validated, imports are resolved, tools are configured, and security hardening is applied. +Translating Markdown workflows (`.md` files) into GitHub Actions YAML format (`.lock.yml` files), including validation, import resolution, tool configuration, and security hardening. ### Workflow Lock File (.lock.yml) -The traditional GitHub Actions workflow file corresponding from a workflow markdown file (`.md`). Contains complete GitHub Actions YAML to execute the instructions as a prompt using a coding agent, with security hardening applied. Both the `.md` source file and `.lock.yml` compiled file should be committed to version control. At runtime GitHub Actions runs the lock file using a coding agent, referring to the markdown for instructions, while the `.md` file remains easy to read and edit. +The compiled GitHub Actions workflow file from a workflow markdown file (`.md`). Contains complete GitHub Actions YAML with security hardening applied. Both `.md` and `.lock.yml` files should be committed to version control. At runtime, GitHub Actions executes the lock file using a coding agent while referencing the markdown for instructions. ## Tools and Integration @@ -88,7 +57,7 @@ A standardized protocol that allows AI agents to securely connect to external to ### MCP Gateway -A transparent proxy service that enables unified HTTP access to multiple MCP servers using different transport mechanisms (stdio, HTTP). The gateway provides protocol translation, server isolation, authentication, and health monitoring capabilities. It serves as an intermediary layer between MCP clients expecting HTTP communication and MCP servers that may use various transports, allowing clients to interact with multiple backends through a single HTTP endpoint. +A transparent proxy service that enables unified HTTP access to multiple MCP servers using different transport mechanisms (stdio, HTTP). Provides protocol translation, server isolation, authentication, and health monitoring, allowing clients to interact with multiple backends through a single HTTP endpoint. ### MCP Server @@ -102,269 +71,163 @@ Capabilities that an AI agent can use during workflow execution. Tools are confi ### Safe Inputs -Custom MCP tools defined inline in the workflow frontmatter using JavaScript or shell scripts. Allows lightweight tool creation without external dependencies while maintaining controlled access to secrets. Tools are generated at runtime and mounted as an MCP server. Each tool can have typed input parameters, default values, and environment variables. Configured using the `safe-inputs:` section in frontmatter. +Custom MCP tools defined inline in workflow frontmatter using JavaScript or shell scripts. Enables lightweight tool creation without external dependencies while maintaining controlled secret access. Tools are generated at runtime and mounted as an MCP server with typed input parameters, default values, and environment variables. Configured via `safe-inputs:` section. ### SARIF -Static Analysis Results Interchange Format - a standardized JSON format for reporting results from static analysis tools. Used by GitHub Code Scanning to display security vulnerabilities and code quality issues. Workflows can generate SARIF files using the `create-code-scanning-alert` safe output to report security findings discovered during AI analysis. - -```yaml -safe-outputs: - create-code-scanning-alert: - max: 1 -``` +Static Analysis Results Interchange Format - a standardized JSON format for reporting results from static analysis tools. Used by GitHub Code Scanning to display security vulnerabilities and code quality issues. Workflows can generate SARIF files using the `create-code-scanning-alert` safe output. ### SBOM -Software Bill of Materials - a comprehensive inventory of all components, libraries, and dependencies in a software project. Used for security auditing, vulnerability tracking, and compliance requirements. Helps identify when dependencies have known security issues. Common formats include SPDX and CycloneDX. +Software Bill of Materials - a comprehensive inventory of all components, libraries, and dependencies in a software project. Used for security auditing, vulnerability tracking, and compliance. Common formats include SPDX and CycloneDX. ### Safe Outputs -Pre-approved actions the AI can take without requiring elevated permissions. The AI generates structured output describing what it wants to create (issues, comments, pull requests), which is processed by separate, permission-controlled jobs. Configured using the `safe-outputs:` section in frontmatter. This approach lets AI agents create GitHub content without direct write access, reducing security risks. +Pre-approved actions the AI can take without elevated permissions. The AI generates structured output describing what to create (issues, comments, pull requests), processed by separate permission-controlled jobs. Configured via `safe-outputs:` section, letting AI agents create GitHub content without direct write access. ### Threat Detection -Automated security analysis that scans agent output and code changes for potential security issues before they are applied. When safe outputs are configured, a threat detection job automatically runs to identify prompt injection attempts, secret leaks, and malicious code patches. Uses AI-powered analysis to detect malicious instructions, exposed credentials, and suspicious code patterns. The threat detection job runs after the main agent job completes but before safe outputs are processed, providing an additional security layer. See [Threat Detection Reference](/gh-aw/reference/threat-detection/) for configuration options. +Automated security analysis that scans agent output and code changes for potential security issues before application. When safe outputs are configured, a threat detection job automatically runs between the agent job and safe output processing to identify prompt injection attempts, secret leaks, and malicious code patches. See [Threat Detection Reference](/gh-aw/reference/threat-detection/). ### Staged Mode -A preview mode where workflows simulate their actions without making changes. The AI generates output showing what would happen, but no GitHub API write operations are performed. Use for testing and validation before running workflows in production. +A preview mode where workflows simulate actions without making changes. The AI generates output showing what would happen, but no GitHub API write operations are performed. Use for testing before production runs. ### Permissions -Access controls that define what operations a workflow can perform. Workflows follow the principle of least privilege, starting with read-only access by default. Write operations are typically handled through safe outputs rather than direct permissions. +Access controls defining workflow operations. Workflows follow least privilege, starting with read-only access by default. Write operations are typically handled through safe outputs. ### Safe Output Messages -Customizable messages that workflows can display during execution to communicate status and progress. Configured in the `safe-outputs.messages` section. Types include `run-started` (workflow begins), `run-success` (workflow completes successfully), `run-failure` (workflow fails), and `footer` (appended to all safe outputs). Supports GitHub context variables like `{workflow_name}` and `{run_url}`. - -```yaml -safe-outputs: - messages: - run-started: "🔍 Analysis starting! [{workflow_name}]({run_url})" - run-success: "✅ Analysis complete!" - footer: "> 🤖 *Generated by [{workflow_name}]({run_url})*" -``` +Customizable messages workflows can display during execution. Configured in `safe-outputs.messages` with types `run-started`, `run-success`, `run-failure`, and `footer`. Supports GitHub context variables like `{workflow_name}` and `{run_url}`. ### Upload Assets -A safe output capability that allows workflows to upload generated files (screenshots, charts, reports) to an orphaned git branch for persistent storage. Configured in the `safe-outputs.upload-assets` section. The AI calls the `upload_asset` tool to register files for upload, which are then committed to a dedicated assets branch by a separate, permission-controlled job. Assets are accessible via predictable GitHub raw URLs. Commonly used for visual testing artifacts, data visualizations, and generated documentation. - -```yaml -safe-outputs: - upload-asset: - branch: "assets/my-workflow" # branch name (default: "assets/${{ github.workflow }}") - max-size: 10240 # max file size in KB (default: 10MB) - allowed-exts: [.png, .jpg, .svg] # allowed extensions -``` +A safe output capability for uploading generated files (screenshots, charts, reports) to an orphaned git branch for persistent storage. The AI calls the `upload_asset` tool to register files, which are committed to a dedicated assets branch by a separate permission-controlled job. Assets are accessible via GitHub raw URLs. Commonly used for visual testing artifacts, data visualizations, and generated documentation. ### Base Branch -A configuration field in the `create-pull-request` safe output that specifies which branch the pull request should target. Defaults to `github.ref_name` (the triggering branch) if not specified. Particularly useful for cross-repository pull requests that need to target non-default branches like `vnext`, `release/v1.0`, or feature branches. - -```yaml -safe-outputs: - create-pull-request: - target-repo: "owner/other-repo" - base-branch: "vnext" # Target vnext branch instead of main -``` +Configuration field in the `create-pull-request` safe output specifying which branch the pull request should target. Defaults to `github.ref_name` if not specified. Useful for cross-repository pull requests targeting non-default branches. ### Minimize Comment -A safe output capability that allows workflows to hide or minimize GitHub comments without requiring write permissions. When minimized, comments are classified as SPAM. Requires GraphQL node IDs (format: `IC_kwDOABCD123456`) to identify comments. Useful for content moderation workflows. - -```yaml -safe-outputs: - minimize-comment: - max: 5 - target-repo: "owner/repo" -``` +A safe output capability for hiding or minimizing GitHub comments without requiring write permissions. When minimized, comments are classified as SPAM. Requires GraphQL node IDs to identify comments. Useful for content moderation workflows. ## Workflow Components ### Engine -The AI system that powers the [agentic workflow](#agentic-workflow). GitHub Agentic Workflows supports multiple engines: - -- **GitHub Copilot** (default): Uses GitHub's coding assistant - -An engine is essentially "which AI to use" - think of it as choosing between different AI assistants (like Copilot, Claude, or others) to execute your workflow instructions. +The AI system that powers the agentic workflow - essentially "which AI to use" to execute workflow instructions. GitHub Agentic Workflows supports multiple engines, with GitHub Copilot as the default. ### Triggers -Events that cause a workflow to run. Defined in the `on:` section of frontmatter. Includes issue events (`issues:`), pull request events (`pull_request:`), scheduled runs (`schedule:`), manual runs (`workflow_dispatch:`), and comment commands (`slash_command:`). +Events that cause a workflow to run, defined in the `on:` section of frontmatter. Includes issue events, pull requests, schedules, manual runs, and slash commands. ### Cron Schedule -A time-based trigger format. Use short syntax like `daily` or `weekly on monday` (recommended) or standard cron expressions for fixed times. - -```yaml -on: weekly on monday # Recommended: automatically scattered time -``` - -```yaml -on: - schedule: - - cron: "0 9 * * 1" # Alternative: fixed time (Monday 9 AM UTC) -``` +A time-based trigger format. Use short syntax like `daily` or `weekly on monday` (recommended with automatic time scattering) or standard cron expressions for fixed times. ### workflow_dispatch A manual trigger that runs a workflow on demand from the GitHub Actions UI or via the GitHub API. Requires explicit user initiation. -```yaml -on: workflow_dispatch -``` - ### Network Permissions -Controls over what external domains and services a workflow can access. Configured using the `network:` section in frontmatter. Options: `defaults` (common development infrastructure), custom allow-lists (specific domains), or `{}` (no network access). +Controls over external domains and services a workflow can access. Configured via `network:` section with options: `defaults` (common infrastructure), custom allow-lists, or `{}` (no access). ### Imports -Reusable workflow components that can be shared across multiple workflows. Specified in the `imports:` field. Can include tool configurations, common instructions, or security guidelines stored in separate files. +Reusable workflow components shared across multiple workflows. Specified in the `imports:` field, can include tool configurations, common instructions, or security guidelines. ### Labels -Optional workflow metadata containing an array of strings for categorization and organization. Labels help organize workflows by topic, purpose, or team, and enable filtering workflows in the CLI using the `--label` flag. - -```yaml -labels: ["automation", "ci", "diagnostics"] -``` - -View workflows with specific labels: - -```bash -gh aw status --label automation -``` +Optional workflow metadata for categorization and organization. Enables filtering workflows in the CLI using the `--label` flag. ## GitHub and Infrastructure Terms ### GitHub Actions -GitHub's built-in automation platform that runs workflows in response to repository events. Agentic workflows compile to GitHub Actions YAML format, leveraging the existing infrastructure for execution, permissions, and secrets management. +GitHub's built-in automation platform that runs workflows in response to repository events. Agentic workflows compile to GitHub Actions YAML format, leveraging existing infrastructure for execution, permissions, and secrets. ### GitHub Projects (Projects v2) -GitHub's project management and tracking system that organizes issues and pull requests using customizable boards, tables, and roadmaps. Projects v2 provides flexible custom fields (text, number, date, single-select, iteration), automation, and GraphQL API access. Agentic workflows can manage project boards using the `update-project` safe output to add items, update fields, and maintain ongoing monitoring/tracking. Requires organization-level Projects permissions for API access. - -```yaml -safe-outputs: - update-project: - github-token: ${{ secrets.GH_AW_PROJECT_GITHUB_TOKEN }} -``` +GitHub's project management and tracking system organizing issues and pull requests using customizable boards, tables, and roadmaps. Provides flexible custom fields, automation, and GraphQL API access. Agentic workflows can manage project boards using the `update-project` safe output. Requires organization-level Projects permissions. ### GitHub Actions Secret -A secure, encrypted variable stored in repository or organization settings. Holds sensitive values like API keys or tokens. Access in workflows using `${{ secrets.SECRET_NAME }}` syntax. +A secure, encrypted variable stored in repository or organization settings holding sensitive values like API keys or tokens. Access via `${{ secrets.SECRET_NAME }}` syntax. ### YAML -A human-friendly data format used for configuration files. Uses indentation and simple syntax to represent structured data. In agentic workflows, YAML appears in the frontmatter section and in compiled `.lock.yml` files. +A human-friendly data format for configuration files using indentation and simple syntax to represent structured data. In agentic workflows, YAML appears in frontmatter and compiled `.lock.yml` files. ### Personal Access Token (PAT) -A token that authenticates you to GitHub's APIs with specific permissions. Required for GitHub Copilot CLI to access Copilot services. Created at github.com/settings/personal-access-tokens. +A token authenticating you to GitHub's APIs with specific permissions. Required for GitHub Copilot CLI to access Copilot services. Created at github.com/settings/personal-access-tokens. ### Agent Files -Markdown files with YAML frontmatter stored in `.github/agents/` that define interactive Copilot Chat agents. Created by `gh aw init`, these files (like `agentic-workflows.agent.md`) can be invoked with the `/agent` command in Copilot Chat to guide workflow creation, debugging, and updates with specialized instructions. The `agentic-workflows` agent is a unified dispatcher that routes requests to specialized prompts based on your intent (create/debug/update/upgrade). +Markdown files with YAML frontmatter stored in `.github/agents/` defining interactive Copilot Chat agents. Created by `gh aw init`, these files can be invoked with the `/agent` command in Copilot Chat to guide workflow creation, debugging, and updates. The `agentic-workflows` agent is a unified dispatcher routing requests to specialized prompts. ### Fine-grained Personal Access Token -A type of GitHub Personal Access Token with granular permission control. Specify exactly which repositories the token can access and what permissions it has (`contents: read`, `issues: write`, etc.). Created at github.com/settings/personal-access-tokens. +A GitHub Personal Access Token with granular permission control, specifying exactly which repositories the token can access and what permissions it has. Created at github.com/settings/personal-access-tokens. ## Development and Compilation ### CLI (Command Line Interface) -The `gh-aw` extension for the GitHub CLI (`gh`) that provides commands for managing agentic workflows: `gh aw compile` (compile workflows), `gh aw run` (trigger runs), `gh aw status` (check status), `gh aw logs` (download and analyze logs), `gh aw add` (add workflows from repositories), and `gh aw project` (create and manage GitHub Projects V2). +The `gh-aw` extension for GitHub CLI providing commands for managing agentic workflows: compile, run, status, logs, add, and project management. ### Validation -The process of checking workflow files for errors, security issues, and best practices. Occurs during compilation and can be enhanced with strict mode and security scanners (actionlint, zizmor, poutine). +Checking workflow files for errors, security issues, and best practices. Occurs during compilation and can be enhanced with strict mode and security scanners. ## Advanced Features ### Cache Memory -Persistent storage for workflows that preserves data between runs. Configured using `cache-memory:` in the tools section, it enables workflows to remember information and build on previous interactions. Files are stored in GitHub Actions cache with 7-day retention. See [Memory Reference](/gh-aw/reference/memory/) for configuration options. +Persistent storage for workflows preserving data between runs. Configured via `cache-memory:` in tools section with 7-day retention in GitHub Actions cache. See [Memory Reference](/gh-aw/reference/memory/). ### Repo Memory -Persistent file storage via Git branches with unlimited retention. Unlike cache-memory (7-day retention via GitHub Actions cache), repo-memory stores files permanently in dedicated Git branches. The compiler automatically configures branch cloning, file access at `/tmp/gh-aw/repo-memory-{id}/`, commits, pushes, and merge conflict resolution. Useful for long-term data persistence, audit trails, and workflows requiring permanent storage. See [Memory Reference](/gh-aw/reference/memory/) for configuration details. +Persistent file storage via Git branches with unlimited retention. Unlike cache-memory (7-day retention), repo-memory stores files permanently in dedicated Git branches with automatic branch cloning, file access, commits, pushes, and merge conflict resolution. See [Memory Reference](/gh-aw/reference/memory/). ### Command Triggers -Special triggers that respond to slash commands in issue and PR comments (e.g., `/review`, `/deploy`). Configured using the `slash_command:` section with a command name. +Special triggers responding to slash commands in issue and PR comments. Configured using the `slash_command:` section with a command name. ### Concurrency Control -Settings that limit how many instances of a workflow can run simultaneously. Configured using the `concurrency:` field to prevent resource conflicts or rate limiting. +Settings limiting how many workflow instances can run simultaneously. Configured via `concurrency:` field to prevent resource conflicts or rate limiting. ### Environment Variables (env) -Configuration section in frontmatter that defines environment variables for the workflow. Variables can reference GitHub context values, workflow inputs, or static values. Accessible to all workflow steps via `${{ env.VARIABLE_NAME }}` syntax. - -```yaml -env: - ORGANIZATION: ${{ github.event.inputs.organization || 'github' }} - API_VERSION: v3 -``` +Configuration section in frontmatter defining environment variables for the workflow. Variables can reference GitHub context values, workflow inputs, or static values. Accessible via `${{ env.VARIABLE_NAME }}` syntax. ### Custom Agents -Specialized instructions or configurations that customize AI agent behavior for specific tasks or repositories. Can be stored as: - -- **Agent files** (`.github/agents/*.agent.md`) - Used with Copilot Chat `/agent` command for interactive workflow authoring and execution-time customization -- **Instruction files** (`.github/copilot/instructions/`) - Path-specific or repository-wide Copilot instructions +Specialized instructions customizing AI agent behavior for specific tasks or repositories. Stored as agent files (`.github/agents/*.agent.md`) for Copilot Chat or instruction files (`.github/copilot/instructions/`) for path-specific Copilot instructions. ### Strict Mode -An enhanced validation mode that enforces additional security checks and best practices. Enabled using `strict: true` in frontmatter or the `--strict` flag when compiling. +Enhanced validation mode enforcing additional security checks and best practices. Enabled via `strict: true` in frontmatter or `--strict` flag when compiling. ### Timeout -The maximum duration a workflow can run before being automatically cancelled. Configured using `timeout-minutes:` in frontmatter. Default GitHub Actions timeout is 360 minutes (6 hours); workflows can specify shorter timeouts to fail faster. - -```yaml -timeout-minutes: 45 -``` +Maximum duration a workflow can run before automatic cancellation. Configured via `timeout-minutes:` in frontmatter. Default is 360 minutes (6 hours); workflows can specify shorter timeouts to fail faster. ### Tracker ID -A unique identifier assigned to workflows that enables external monitoring and coordination without bidirectional coupling. Orchestrator workflows can use tracker IDs to correlate worker runs and discover outputs without workers needing to know about the orchestrator. This enables tracker-based monitoring where the orchestrator can observe its workers, but workers operate independently. - -```yaml -tracker-id: daily-file-diet-v1 -``` +A unique identifier enabling external monitoring and coordination without bidirectional coupling. Orchestrator workflows use tracker IDs to correlate worker runs and discover outputs while workers operate independently. ### Toolsets -Predefined collections of related MCP tools that can be enabled together. Used with the GitHub MCP server to group capabilities like `repos` (repository operations), `issues` (issue operations), and `pull_requests` (PR operations). Configured in the `toolsets:` field under tool configuration. - -```yaml -tools: - github: - toolsets: - - repos - - issues -``` +Predefined collections of related MCP tools enabled together. Used with the GitHub MCP server to group capabilities like `repos`, `issues`, and `pull_requests`. Configured in the `toolsets:` field. ### Workflow Inputs -Parameters that can be provided when manually triggering a workflow with `workflow_dispatch`. Defined in the `on.workflow_dispatch.inputs` section with type, description, default value, and whether the input is required. - -```yaml -on: - workflow_dispatch: - inputs: - organization: - description: "GitHub organization to scan" - required: true - type: string - default: github -``` +Parameters provided when manually triggering a workflow with `workflow_dispatch`. Defined in the `on.workflow_dispatch.inputs` section with type, description, default value, and required status. ## Operational Patterns @@ -372,107 +235,55 @@ Operational patterns (suffixed with "-Ops") are established workflow architectur ### ChatOps -Interactive automation triggered by slash commands (`/review`, `/deploy`) in issues and pull requests. Team members trigger workflows by typing commands directly in discussions, enabling human-in-the-loop automation where developers invoke AI assistance on demand. - -**Use for:** Interactive code reviews, on-demand deployments, assisted analysis, and team collaboration through shared commands. - -See [ChatOps](/gh-aw/patterns/chatops/) for implementation details. +Interactive automation triggered by slash commands (`/review`, `/deploy`) in issues and pull requests, enabling human-in-the-loop automation where developers invoke AI assistance on demand. See [ChatOps](/gh-aw/patterns/chatops/). ### DailyOps -Scheduled workflows for incremental daily improvements that automate progress toward large goals through small, manageable changes. Work happens automatically on weekday schedules with changes easy to review and integrate. - -**Use for:** Continuous code quality improvements, progressive migrations, documentation maintenance, and chipping away at technical debt one small PR at a time. - -See [DailyOps](/gh-aw/patterns/dailyops/) for implementation details. +Scheduled workflows for incremental daily improvements, automating progress toward large goals through small, manageable changes on weekday schedules. See [DailyOps](/gh-aw/patterns/dailyops/). ### DataOps -Hybrid pattern combining deterministic data extraction in `steps:` with agentic analysis in the workflow body. Shell commands reliably fetch and structure data, then the AI agent interprets results and produces insights. - -**Use for:** Data aggregation from APIs or logs, report generation, trend analysis, and auditing workflows that gather evidence and generate reports. - -See [DataOps](/gh-aw/patterns/dataops/) for implementation details. +Hybrid pattern combining deterministic data extraction in `steps:` with agentic analysis in the workflow body. Shell commands fetch and structure data, then the AI agent interprets results and produces insights. See [DataOps](/gh-aw/patterns/dataops/). ### DispatchOps -Manual workflow execution via the GitHub Actions UI or CLI using the `workflow_dispatch` trigger. Enables on-demand tasks, testing, and workflows requiring human judgment about timing. Workflows can accept custom input parameters for runtime customization. - -**Use for:** Research tasks, operational commands, development testing, debugging production issues, and ad-hoc analysis that doesn't fit scheduled or event-based triggers. - -See [DispatchOps](/gh-aw/patterns/dispatchops/) for implementation details. +Manual workflow execution via GitHub Actions UI or CLI using `workflow_dispatch` trigger. Enables on-demand tasks, testing, and workflows requiring human judgment about timing. Workflows can accept custom input parameters. See [DispatchOps](/gh-aw/patterns/dispatchops/). ### IssueOps -Automated issue management that analyzes, categorizes, and responds to issues when they are created. Uses issue event triggers with safe outputs for secure, automated triage without requiring write permissions for the AI job. - -**Use for:** Auto-triage, smart routing to teams, initial responses, quality checks, and content analysis of newly created issues. - -See the [IssueOps Examples](/gh-aw/patterns/issueops/) for implementation details. +Automated issue management that analyzes, categorizes, and responds to issues when created. Uses issue event triggers with safe outputs for secure automated triage without requiring write permissions for the AI job. See [IssueOps Examples](/gh-aw/patterns/issueops/). ### LabelOps -Workflows triggered by label changes on issues and pull requests. Uses labels as workflow triggers, metadata, and state markers with filtering to activate only for specific label additions or removals. - -**Use for:** Priority-based workflows, stage transitions, specialized processing based on label categories, and team coordination via label-based handoffs. - -See the [LabelOps Examples](/gh-aw/patterns/labelops/) for implementation details. +Workflows triggered by label changes on issues and pull requests. Uses labels as triggers, metadata, and state markers with filtering for specific label additions or removals. See [LabelOps Examples](/gh-aw/patterns/labelops/). ### MemoryOps -Stateful workflows that persist data between runs using `cache-memory` and `repo-memory`. Enables workflows to track progress, resume after interruptions, share data between runs, and avoid API throttling through incremental processing. - -**Use for:** Incremental data processing, trend analysis, multi-step tasks requiring state, workflow coordination, and long-running operations that need checkpointing. - -See the [MemoryOps](/gh-aw/guides/memoryops/) for implementation details. +Stateful workflows that persist data between runs using `cache-memory` and `repo-memory`, enabling progress tracking, resumption after interruptions, and incremental processing to avoid API throttling. See [MemoryOps](/gh-aw/guides/memoryops/). ### MultiRepoOps -Cross-repository coordination that extends automation patterns across multiple GitHub repositories. Uses secure authentication and cross-repository safe outputs to synchronize features, centralize tracking, and enforce organization-wide policies. - -**Use for:** Feature synchronization across repos, hub-and-spoke issue tracking, organization-wide policy enforcement, security patch rollouts, and coordinating services in separate repositories. - -See the [MultiRepoOps](/gh-aw/patterns/multirepoops/) for implementation details. +Cross-repository coordination extending automation patterns across multiple repositories. Uses secure authentication and cross-repository safe outputs to synchronize features, centralize tracking, and enforce organization-wide policies. See [MultiRepoOps](/gh-aw/patterns/multirepoops/). ### ProjectOps -AI-powered GitHub Projects board management that automates issue triage, routing, and field updates. Analyzes issue/PR content and makes intelligent decisions about project assignment, status, priority, and custom field values using the `update-project` safe output for secure board updates without elevated permissions. - -**Use for:** Event-driven workflows (issue opened, PR created) that need to categorize and track work on project boards, content-based routing, AI-driven priority estimation, and automated status transitions. - -See the [ProjectOps](/gh-aw/patterns/projectops/) for implementation details. +AI-powered GitHub Projects board management automating issue triage, routing, and field updates. Analyzes issue/PR content to make intelligent decisions about project assignment, status, priority, and custom fields using the `update-project` safe output. See [ProjectOps](/gh-aw/patterns/projectops/). ### SideRepoOps -Development pattern where workflows run from a separate "side" repository that targets your main codebase. Keeps AI-generated issues, comments, and workflow runs isolated from the main repository for cleaner separation between automation infrastructure and production code. - -**Use for:** Getting started with agentic workflows, experimentation without affecting main repository, keeping automation artifacts separate, and reporting workflows that generate high volumes of content. - -See the [SideRepoOps](/gh-aw/patterns/siderepoops/) for implementation details. +Development pattern where workflows run from a separate "side" repository targeting your main codebase. Keeps AI-generated issues, comments, and workflow runs isolated from the main repository for cleaner separation between automation infrastructure and production code. See [SideRepoOps](/gh-aw/patterns/siderepoops/). ### SpecOps -Maintaining and propagating W3C-style specifications using the `w3c-specification-writer` agent. Creates formal specifications with RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) and automatically synchronizes changes to consuming implementations. - -**Use for:** Maintaining formal technical specifications, keeping specifications synchronized across repositories, and ensuring implementations stay compliant with specification updates. - -See the [SpecOps](/gh-aw/patterns/specops/) for implementation details. +Maintaining and propagating W3C-style specifications using the `w3c-specification-writer` agent. Creates formal specifications with RFC 2119 keywords and automatically synchronizes changes to consuming implementations. See [SpecOps](/gh-aw/patterns/specops/). ### TaskOps -Scaffolded AI-powered code improvement strategy with three phases: research agent investigates and reports findings, developer reviews and invokes planner agent to create actionable issues, then assigns approved issues to Copilot for automated implementation. Keeps developers in control with clear decision points at each phase. - -**Use for:** Systematic code improvements requiring investigation before action, work needing breakdown for optimal AI agent execution, and situations where research findings vary in priority and require developer oversight. - -See [TaskOps](/gh-aw/patterns/taskops/) for implementation details. +Scaffolded AI-powered code improvement strategy with three phases: research agent investigates, developer reviews and invokes planner agent to create actionable issues, then assigns approved issues to Copilot for automated implementation. Keeps developers in control with clear decision points. See [TaskOps](/gh-aw/patterns/taskops/). ### TrialOps -Testing and validation pattern that executes workflows in isolated trial repositories before production deployment. Creates temporary private repositories where workflows run safely, capturing safe outputs without modifying your actual codebase. - -**Use for:** Testing workflows before production, comparing implementation approaches, validating prompt changes, debugging in isolation, and demonstrating capabilities with real results. - -See the [TrialOps](/gh-aw/patterns/trialops/) for implementation details. +Testing and validation pattern executing workflows in isolated trial repositories before production deployment. Creates temporary private repositories where workflows run safely, capturing safe outputs without modifying your actual codebase. See [TrialOps](/gh-aw/patterns/trialops/). ## Related Resources