### Install GitHub Copilot CLI with npm

Source: https://github.com/github/copilot-cli

Installs the GitHub Copilot CLI globally using npm. Ensure you have Node.js and npm installed and updated to the required versions.

```bash
npm install -g @github/copilot
```

--------------------------------

### Install 'gh aw' GitHub Extension

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-accessibility-review

Installs the 'gh aw' extension from the specified GitHub repository. This is the initial step to use the agentics features.

```bash
gh aw extension install githubnext/agentics
```

--------------------------------

### Install Dependencies and Build Docs with npm

Source: https://context7_llms

Provides commands for installing dependencies and building documentation using npm within the 'docs/' directory. It includes steps for a clean installation by removing `node_modules` and `package-lock.json` before running `npm install` and `npm run build`.

```bash
cd docs && npm install
```

```bash
# Clean install
cd docs
rm -rf node_modules package-lock.json
npm install
npm run build
```

--------------------------------

### Install GitHub Agentic Workflows Extension

Source: https://context7_llms

Installs the GitHub Agentic Workflows extension using the GitHub CLI. If the direct installation fails, it suggests using a personal access token or running a specific installation script.

```bash
gh extension install githubnext/gh-aw
```

--------------------------------

### Complete Workflow Example with Command Trigger and Tools

Source: https://context7_llms

An example demonstrating a complete workflow configuration using a command trigger, permissions, engine, tools, and output safety settings.

```yaml
---

on:
  command:
    name: code-review
    events: [pull_request, pull_request_comment]
permissions:
  contents: read
  pull-requests: write
engine:
  claude
tools:
  github:
    toolset: [pull_requests]
safe-outputs:
  add-comment:
    max: 5
    timeout_minutes: 10
---

# Code Review Assistant
When so
```

--------------------------------

### Install and Add Daily QA Workflow using gh aw

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-qa

This snippet shows how to install the 'gh aw' extension and add the Daily QA workflow to your repository. It involves two main commands: one for extension installation and another for adding the workflow, which initiates a pull request.

```bash
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Daily QA workflow to your repository
gh aw add githubnext/agentics/daily-qa --pr
```

--------------------------------

### Start MCP Server Locally

Source: https://context7_llms

Starts the gh-aw MCP server for local CLI usage, making GitHub CLI tools accessible to AI agents.

```bash
gh aw mcp-server
```

--------------------------------

### Install and Add Daily Plan Workflow using gh aw

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-plan

Commands to install the 'gh aw' extension and add the Daily Plan workflow to your repository. This involves creating a pull request, merging it, and then running the workflow.

```shell
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Daily Plan workflow to your repository
gh aw add githubnext/agentics/daily-plan --pr
```

```shell
gh aw run daily-plan
```

```shell
gh aw compile
```

--------------------------------

### Combined GitHub and Custom MCP Server Example

Source: https://context7_llms

A comprehensive example demonstrating the integration of GitHub tools with multiple custom MCP servers (Slack and Notion). This configuration showcases how to define allowed actions for each tool and set up their respective environment variables and secrets.

```yaml
tools:
  github:
    allowed:
      - create_issue
      - update_issue
  mcp-servers:
    slack:
      command: "npx"
      args:
        - "-y"
        - "@slack/mcp-server"
      env:
        SLACK_BOT_TOKEN: "${{ secrets.SLACK_BOT_TOKEN }}"
        SLACK_TEAM_ID: "${{ secrets.SLACK_TEAM_ID }}"
      allowed:
        - "send_message"
        - "get_channel_history"
    notion:
      container: "mcp/notion"
      env:
        NOTION_API_TOKEN: "${{ secrets.NOTION_API_TOKEN }}"
      allowed:
        - "search_pages"
        - "get_page"
```

--------------------------------

### Install and Add Update Docs Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/update-docs

Installs the 'gh aw' extension and adds the 'update-docs' workflow to a repository by creating a pull request. This requires the 'gh aw' CLI tool.

```bash
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Update Docs workflow to your repository
gh aw add githubnext/agentics/update-docs --pr

```

--------------------------------

### Install JQ on Ubuntu/Debian and macOS

Source: https://context7_llms

Provides commands to install the 'jq' command-line tool, which is required for some workflow processes and resolves the 'jq not found in PATH' error.

```bash
# Ubuntu/Debian
sudo apt-get install jq

# macOS
brew install jq
```

--------------------------------

### Example Command Workflow with Permissions and Tools

Source: https://context7_llms

An example of a complete command workflow using the 'aw' format. It defines the 'summarize-issue' command, sets necessary 'permissions' to write to issues, specifies 'tools' to interact with GitHub issues, and includes a description of the workflow's purpose.

```aw
---
on:
  command: name: summarize-issue
permissions:
  issues: write
tools:
  github:
    toolset: [issues]
---
# Issue Summarizer
When someone mentions /summarize-issue in an issue or comment, analyze and provide a helpful summary.
The current context text is: "${{ needs.activation.outputs.text }}"
```

--------------------------------

### Select Self-hosted Runner with Labels

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This example shows how to select a self-hosted runner by providing an array of labels. The job will run on a runner that possesses all specified labels, starting with `self-hosted`.

```yaml
runs-on:
  - self-hosted
  - linux
```

--------------------------------

### AW Workflow Example: Specific Issue Labeling

Source: https://context7_llms

This AW markdown example provides specific instructions for analyzing and labeling a GitHub issue. It includes project context and guidelines for the agent.

```aw
```aw
# Good: Specific and actionable
Analyze issue #${{ github.event.issue.number }} and add appropriate labels from the repository's label list. Focus on categorizing the issue type (bug, feature, documentation) and priority level (high, medium, low).

# Project Context
This repository follows semantic versioning and GitHub Flow. When reviewing pull requests, ensure all tests pass, documentation is updated for API changes, and breaking changes are clearly marked.

# Weekly Research Report
## Research Areas
Focus on competitor analysis, emerging AI development trends, and community feedback for ${{ github.repository }}.
## Output Format
Create a structured report with executive summary, key findings by area, and recommended actions.
```
```

--------------------------------

### Example Prompt for Agentic Workflows

Source: https://context7_llms

A markdown example demonstrating a prompt for checking workflow status, logging recent runs, auditing failures, and generating a summary report using `status`, `logs`, and `audit` commands.

```markdown
Check all workflows: use `status` to list workflows, `logs` for recent runs, `audit` for failures, then generate a summary report.
```

--------------------------------

### Install and Add 'gh aw' Agentics Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-perf-improver

Commands to install the 'gh aw' extension and add the Daily Performance Improver workflow to a repository. This action automatically creates a pull request for integration.

```bash
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Daily Performance Improver workflow to your repository
gh aw add githubnext/agentics/daily-perf-improver --pr
```

--------------------------------

### MCP Server Logs Tool Continuation Example

Source: https://context7_llms

Example of a structured JSON response from the MCP server's logs tool when a timeout occurs, including continuation parameters to resume fetching.

```json
{
  "summary": {
    "total_runs": 5
  },
  "runs": [
    ...
  ],
  "continuation": {
    "message": "Timeout reached. Use these parameters to continue fetching more logs.",
    "workflow_name": "weekly-research",
    "count": 100,
    "before_run_id": 12341,
    "timeout": 50
  }
}
```

--------------------------------

### Create a New GitHub Release

Source: https://cli.github.com/

Publish a new release for a repository. This command guides the user through setting a version, title, release notes, and whether it's a prerelease, then publishes the release.

```bash
gh release create 1.0
**? Title**
GitHub CLI 1.0
**? Release notes**
Write my own
**? Is this a prerelease?**
No
**? Submit?**
Publish release
https://github.com/octocat/.github/releases/tag/1.0
```

--------------------------------

### Agentic Workflow Example (AW)

Source: https://context7_llms

An example of an agentic workflow demonstrating YAML frontmatter for configuration and Markdown for natural language instructions. It shows how to read an issue, add a comment with resources, and interact with GitHub events.

```aw
---

on: 
  issues:
    types: [opened]
permissions: 
  issues: write
tools:
  github:
    toolset: [issues]
---

# Workflow Description
Read the issue #${{ github.event.issue.number }}. Add a comment to the issue listing useful resources and links.
```

--------------------------------

### Run Daily Accessibility Review Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-accessibility-review

Immediately starts a run of the 'daily-accessibility-review' workflow after the pull request has been merged and synced to the main branch.

```bash
gh aw run daily-accessibility-review
```

--------------------------------

### Zizmor Security Scanner Output Example

Source: https://context7_llms

This example illustrates the output format of the Zizmor security scanner when run on compiled workflows. It highlights findings with severity, type, file location, and documentation URLs.

```plaintext
./.github/workflows/workflow.lock.yml:7:5: warning: [Medium] excessive-permissions: overly broad permissions (https://docs.zizmor.sh/audits/#excessive-permissions)
```

--------------------------------

### Install and Add Daily Dependency Updater Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-dependency-updates

Installs the 'gh aw' extension and adds the 'daily-dependency-updates' workflow to your repository. This process creates a pull request for review and merging.

```shell
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Daily Dependency Updater workflow to your repository
gh aw add githubnext/agentics/daily-dependency-updates --pr
```

--------------------------------

### AW Example: Code Review Process Steps

Source: https://context7_llms

This AW markdown outlines a multi-step process for code reviews, specifying checks for CI, code quality, and comment creation.

```aw
```aw
# Code Review Process
1. Check CI checks are passing and PR has appropriate title/description
2. Scan for code quality issues and verify error handling/logging
3. Create constructive comments and summarize assessment
```
```

--------------------------------

### YAML Network Configuration Examples

Source: https://context7_llms

Demonstrates various ways to configure network permissions in YAML, including default infrastructure access, selective access with ecosystems and custom domains, and denying all network access.

```yaml
# Default: basic infrastructure only
engine:
  id: claude
  network: defaults

# Ecosystems + custom domains
network:
  allowed:
    - defaults
    - python
    - node
    - "api.example.com"

# Domain patterns (exact match or wildcard)
network:
  allowed:
    - "api.example.com"
    - "*.trusted.com"

# No network access
network: {}

```

--------------------------------

### Example AW Prompt for Issue Labeling Agent

Source: https://context7_llms

Example of natural language prompt to instruct an agent to analyze issue content and add appropriate labels.

```aw
# Issue Labeling Agent
Analyze the issue content and add appropriate labels to the issue.
```

--------------------------------

### Install Agentic Workflow Firewall (CLI)

Source: https://github.com/githubnext/gh-aw-firewall

This snippet demonstrates how to download, make executable, and install the Agentic Workflow Firewall command-line interface (CLI) binary for Linux systems. It ensures the `awf` command is available system-wide. It requires `curl` and `chmod` utilities.

```shell
# Download the latest release binary
curl -L https://github.com/githubnext/gh-aw-firewall/releases/latest/download/awf-linux-x64 -o awf
chmod +x awf
sudo mv awf /usr/local/bin/

# Verify installation
sudo awf --help
```

--------------------------------

### Install and Add Weekly Research Workflow (CLI)

Source: https://github.com/githubnext/agentics/blob/main/docs/weekly-research

Commands to install the 'gh aw' extension and add the Weekly Research workflow to your repository. This involves using the GitHub CLI to manage agentic workflows.

```shell
gh aw extension install githubnext/agentics
gh aw add githubnext/agentics/weekly-research --pr
```

--------------------------------

### Install GitHub CLI using Homebrew

Source: https://cli.github.com/

Install the GitHub CLI on macOS using the Homebrew package manager. This is a common method for managing command-line tools on Apple systems.

```bash
` brew install gh `
```

--------------------------------

### Basic GitHub Actions Trigger Example

Source: https://context7_llms

This snippet demonstrates the basic syntax for defining a workflow trigger using standard GitHub Actions syntax.

```yaml
on:
  issues:
    types: [opened]
```

--------------------------------

### Workflow `workflow_dispatch` Permission Examples

Source: https://context7_llms

Illustrates how to configure permissions for the `workflow_dispatch` event. Examples show scenarios where permission checks are required, skipped, or where all users are allowed, demonstrating the impact of the `roles:` field.

```yaml
```yaml
# Permission check REQUIRED - write role not allowed
on:
  workflow_dispatch:
    roles: [admin, maintainer]
    # Users with write access will be denied

# Permission check SKIPPED - write role allowed (default)
on:
  workflow_dispatch:
    roles: [admin, maintainer, write]
    # Users with write access allowed

# Permission check SKIPPED - all users allowed
on:
  workflow_dispatch:
    roles: all
```
```

--------------------------------

### Example Workflow for Code Improvement Agent

Source: https://context7_llms

An example GitHub Actions workflow demonstrating how to use 'safe-outputs' for creating pull requests, including a title prefix, labels, and draft mode. It outlines the agent's instructions for making code changes and creating the PR.

```yaml
aw
---
on: push
push:
  branches: [main]
permissions:
  contents: read
  actions: read
engine: claude
safe-outputs:
  create-pull-request:
    title-prefix: "[ai] "
    labels: [automation, code-improvement]
    draft: true
---
# Code Improvement Agent
Analyze the latest commit and suggest improvements.
1. Make any file changes directly in the working directory
2. Create a pull request for your improvements, with a descriptive title and detailed description of the changes made

```

--------------------------------

### GitHub Actions Workflow Input and Job Step Example

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This example demonstrates how to define a workflow dispatch input for tags and use it within a job step. The step prints the provided tags to standard output. It requires the `tags` input to be a string.

```yaml
jobs:
  print-tag:
    runs-on: ubuntu-latest
    if: ${{ inputs.print_tags }}
    steps:
      - name: Print the input tag to STDOUT
        run: echo The tags are ${{ inputs.tags }}
```

--------------------------------

### Manually Run Daily Dependency Updater Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-dependency-updates

Starts an immediate run of the 'daily-dependency-updates' workflow after it has been added to the repository and synced to the main branch.

```shell
gh aw run daily-dependency-updates
```

--------------------------------

### Get Project

Source: https://github.com/github/github-mcp-server

Retrieves details about a specific project.

```APIDOC
## GET /projects/:owner/:project_number

### Description
Retrieves details about a specific project.

### Method
GET

### Endpoint
`/projects/:owner/:project_number`

### Parameters
#### Path Parameters
- **owner** (string) - Required - If owner_type == user it is the handle for the GitHub user account. If owner_type == org it is the name of the organization. The name is not case sensitive.
- **project_number** (number) - Required - The project's number.

#### Query Parameters
- **owner_type** (string) - Required - Owner type
```

--------------------------------

### Stdio MCP Server Configuration

Source: https://context7_llms

Configures a Stdio MCP server, which communicates via stdin/stdout. This example shows how to set up the server using a command-line executable (`uvx`) and specifies arguments for context, project, and allowed actions.

```yaml
mcp-servers:
  serena:
    command: "uvx"
    args:
      - "--from"
      - "git+https://github.com/oraios/serena"
      - "serena"
      - "start-mcp-server"
      - "--context"
      - "codex"
      - "--project"
      - "${{ github.workspace }}"
    allowed: ["*"]
```

--------------------------------

### YAML Expression Syntax for Conditions

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This code highlights the use of `${{ }}` expression syntax in YAML for conditional logic within GitHub Actions. It specifically addresses the need to escape expressions starting with '!' to avoid conflicts with YAML reserved notation, providing an example for checking if a Git ref starts with 'refs/tags/'.

```yaml
if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
```

--------------------------------

### Example: Modular Workflow with Tavily MCP Server Import (YAML)

Source: https://context7_llms

An example showcasing a modular workflow. It defines a shared MCP server configuration in a separate file (`shared/mcp/tavily.md`) and then references it in the main workflow using the `imports:` field. This allows incorporating the Tavily MCP server and other tools.

```yaml
---
mcp-servers:
  tavily:
    url: "https://mcp.tavily.com/mcp/?tavilyApiKey=${{ secrets.TAVILY_API_KEY }}"
    allowed: ["*"]
---

```

```yaml
---
on: issues
  types: [opened]
imports:
  - shared/mcp/tavily.md
tools:
  github:
    toolset: [issues]
---
# Research Agent
Perform web research using Tavily and respond to issues.

```

--------------------------------

### Run Tests with Coverage (NPM)

Source: https://github.com/githubnext/gh-aw-firewall

Commands to manage testing and code coverage for the project using npm. It includes installing dependencies, running all tests, generating a coverage report, and running tests in watch mode. Requires Node.js and npm to be installed.

```shell
# Install dependencies
npm install

# Run all tests
npm test

# Run tests with coverage report
npm run test:coverage

# Run tests in watch mode
npm run test:watch
```

--------------------------------

### Conditional Service Container Image

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

Conditionally set the Docker image for a service container. If the image is an empty string, the service will not start, useful for conditional service setup.

```yaml
services:
  nginx:
    image: ${{ options.nginx == true && 'nginx' || '' }}
```

--------------------------------

### Complete HTTP MCP Server Configuration Example (AW)

Source: https://context7_llms

An example of a complete workflow dispatch trigger with a custom HTTP MCP server configuration. It includes the 'on' trigger, 'mcp-servers' definition with 'type', 'url', and 'headers', and specifies 'allowed' actions.

```yaml
---
on:
  workflow_dispatch:
mcp-servers:
  custom-api:
    type: http
    url: "https://api.example.com/v1/mcp"
    headers:
      X-API-Key: "${{ secrets.API_KEY }}"
    allowed:
      - search_data
      - analyze_results
---
```

--------------------------------

### Override Docker ENTRYPOINT with 'jobs..steps..with.entrypoint'

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This example illustrates how to override the Docker ENTRYPOINT for a container action using the 'entrypoint' keyword. It allows specifying a custom executable to run when the container starts.

```yaml
steps:
  - name: Run a custom command
    uses: octo-org/action-name@main
    with:
      entrypoint: /a/different/executable
```

--------------------------------

### Migrate Between Engines

Source: https://context7_llms

Examples of how to switch between AI engines by modifying the 'engine' field in the frontmatter, including simple switches and switches with specific model or version configurations.

```yaml
# Simple switch
engine: copilot

# With configuration
engine: id: copilot
model: gpt-5 # Optional; defaults to claude-sonnet-4
version: latest
```

--------------------------------

### Custom MCP Server Configuration (npx-based)

Source: https://context7_llms

Example of configuring a custom MCP server using `npx`. This involves specifying the command, arguments, and environment variables, including secrets for authentication.

```yaml
mcp-servers:
  custom-api:
    command: "npx"
    args:
      - "-y"
      - "@company/custom-mcp-server"
    env:
      API_KEY: "${{ secrets.CUSTOM_API_KEY }}"
```

--------------------------------

### Tool Allow/Disallow List Examples

Source: https://context7_llms

These YAML examples illustrate how to configure explicit allow-lists for tools within Agentic Workflows. They show how to restrict GitHub tool access to specific actions and limit bash commands for engines like Claude.

```yaml
tools:
  github:
    allowed: [get_issue, add_issue_comment]
```

```yaml
engine:
  claude:
    tools:
      edit:
        bash: ["echo", "git status"] # keep tight; avoid wildcards
```

```yaml
tools:
  github:
    allowed: ["*"] # Too broad
```

```yaml
bash:
  [:*] # Unrestricted shell access
```

--------------------------------

### Integrate LlamaGuard with Ollama (YAML)

Source: https://context7_llms

Example of integrating Ollama with LlamaGuard 3 for specialized threat detection within a GitHub Actions workflow. It installs Ollama, pulls the LlamaGuard model, and scans agent output.

```yaml
---
on: push
engine: copilot
safe-outputs:
  create-pull-request:
    threat-detection:
      steps:
        - name: Ollama LlamaGuard 3 Scan
          uses: actions/github-script@v7
          with:
            script: |
              const fs = require('fs');
              // Install Ollama
              await exec.exec('curl', ['-fsSL', 'https://ollama.com/install.sh', '-o', '/tmp/install.sh']);
              await exec.exec('sh', ['/tmp/install.sh']);
              // Start Ollama service
              exec.exec('ollama', ['serve'], { detached: true });
              // Wait for service
              let ready = false;
              for (let i = 0; i < 30; i++) {
                try {
                  await exec.exec('curl', ['-f', 'http://localhost:11434/api/version'], { silent: true });
                  ready = true;
                  break;
                } catch (e) {
                  await new Promise(r => setTimeout(r, 1000));
                }
              }
              if (!ready) {
                core.setFailed('Ollama service failed to start');
                return;
              }
              // Pull LlamaGuard model
              await exec.exec('ollama', ['pull', 'llama-guard3:1b']);
              // Scan agent output
              const outputPath = '/tmp/gh-aw/threat-detection/agent_output.json';
              if (fs.existsSync(outputPath)) {
                const content = fs.readFileSync(outputPath, 'utf8');
                const response = await exec.getExecOutput('curl', [
                  '-X', 'POST',
                  'http://localhost:11434/api/chat',
                  '-H', 'Content-Type: application/json',
                  '-d',
                  JSON.stringify({
                    model: 'llama-guard3:1b',
                    messages: [{ role: 'user', content }],
                    stream: false
                  })
                ]);
                const result = JSON.parse(response.stdout);
                const output = result.message?.content || '';
                // Check if safe
                const isSafe = output.toLowerCase().trim() === 'safe' || output.includes('s8');
                if (!isSafe) {
                  core.setFailed(`LlamaGuard detected threat: ${output}`);
                } else {
                  core.info('✅ Content appears safe');
                }
              }
timeout_minutes: 20
---
# Code Review Agent Analyze and improve code with LlamaGuard threat scanning.
```

--------------------------------

### Initialize GitHub Agentic Workflows

Source: https://context7_llms

Initializes your repository with necessary files for authoring agentic workflows, including Copilot instructions and prompt files for creating workflows and shared components.

```bash
gh aw init
```

--------------------------------

### Trigger `pull_request_target` on Branch and Path Filters (YAML)

Source: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

This YAML example demonstrates triggering a `pull_request_target` workflow based on both branch and path filters. The workflow will only run if a pull request targets a branch starting with 'releases/' AND includes changes to files with the '.js' extension.

```yaml
on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**/*.js'
```

--------------------------------

### Merging Frontmatter from Imported Files (Example)

Source: https://context7_llms

An example showcasing how frontmatter definitions (specifically 'mcp-servers') from an imported file (`shared/mcp/tavily.md`) are merged into the main workflow's configuration. This makes the imported configurations, like MCP server details, available to the AI engine.

```aw
# Base workflow
---
on: issues
engine: copilot
imports:
  - shared/mcp/tavily.md
---

```

```aw
# shared/mcp/tavily.md
---
mcp-servers:
  tavily:
    url: "https://mcp.tavily.com/mcp/?tavilyApiKey=${{ secrets.TAVILY_API_KEY }}"
    allowed: ["*"]
---

```

--------------------------------

### Default AI-Based Threat Detection Example

Source: https://context7_llms

Illustrates the default AI-powered threat detection setup where the workflow uses the configured AI engine (e.g., Claude) to analyze agent output and code changes. Threat detection is enabled by default when safe outputs are configured.

```yaml
---
on: push
engine: claude
safe-outputs:
  create-pull-request:
    threat-detection: true # Uses Claude for analysis
---
# Code Review Agent
Analyze code and create pull requests with improvements.
```

--------------------------------

### Accessing Copilot CLI Help and Configuration

Source: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-copilot-cli

Provides commands to access comprehensive help and configuration details for Copilot CLI. Users can find information on command-line options, slash commands, configuration settings, environment variables, logging, and permissions.

```bash
?

```

```bash
copilot help

```

```bash
copilot help config

```

```bash
copilot help environment

```

```bash
copilot help logging

```

```bash
copilot help permissions

```

--------------------------------

### Run Weekly Research Workflow (CLI)

Source: https://github.com/githubnext/agentics/blob/main/docs/weekly-research

Command to initiate a run of the 'weekly-research' workflow after it has been added and configured in the repository. This assumes the 'gh aw' extension is installed and the workflow is set up.

```shell
gh aw run weekly-research
```

--------------------------------

### YAML - Cache Configuration

Source: https://context7_llms

Demonstrates configuring caching for GitHub Actions using the `actions/cache` syntax. This example shows setting a key, path, and restore keys for a single cache entry.

```yaml
cache:
  key: node-modules-${{ hashFiles('package-lock.json') }}
  path: node_modules
  restore-keys:
    |
      node-modules-
```

--------------------------------

### Cache Node Modules with npm using GitHub Actions YAML

Source: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

This YAML example demonstrates how to cache npm modules in a GitHub Actions workflow. It uses the 'actions/cache@v4' action to store and restore the '~/.npm' directory based on changes in 'package-lock.json' and the runner's OS. It also includes steps to install dependencies, build, and test.

```yaml
name: Caching with npm
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Cache node modules
        id: cache-npm
        uses: actions/cache@v4
        env:
          cache-name: cache-node-modules
        with:
          # npm cache files are stored in `~/.npm` on Linux/macOS
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-
      - if: "${{ steps.cache-npm.outputs.cache-hit != 'true' }}"
        name: List the state of node modules
        continue-on-error: true
        run: npm list
      - name: Install dependencies
        run: npm install
      - name: Build
        run: npm run build
      - name: Test
        run: npm test
```

--------------------------------

### Run MCP Server in HTTP Server Mode

Source: https://context7_llms

Starts the gh-aw MCP server using HTTP/SSE transport by specifying a port.

```bash
gh aw mcp-server --port 8080
```

--------------------------------

### Tavily Search API Integration (Python)

Source: https://tavily.com/

Demonstrates how to use the Tavily Python client to perform a web search. Requires installation of the 'tavily' package and an API key.

```python
from tavily import TavilyClient

tavily_client = TavilyClient(api_key="tvly-YOUR_API_KEY")
response = tavily_client.search("Who is Leo Messi?")
print(response)
```

--------------------------------

### Format and Test Code with Make

Source: https://context7_llms

This snippet shows how to format, lint, and run unit tests for your project using Make commands. It assumes a Makefile is present in the project root.

```bash
# Format and lint
make fmt
make lint

# Run tests
make test-unit
```

--------------------------------

### Add Workflows using `gh aw add`

Source: https://context7_llms

Installs workflows from external GitHub repositories. Supports short form, versioned installations, and explicit paths. Various flags can customize the installation process.

```bash
gh aw add githubnext/agentics/ci-doctor # short form
gh aw add githubnext/agentics/ci-doctor@v1.0.0 # with version
gh aw add githubnext/agentics/workflows/ci-doctor.md # explicit path
```

--------------------------------

### MCP Server: Container vs. Command Configuration

Source: https://context7_llms

Demonstrates the correct way to configure MCP servers, highlighting that 'container' and 'command' fields are mutually exclusive. Use either one, not both, and provide appropriate arguments.

```yaml
# Incorrect - both container and command
mcp-servers:
  my-tool:
    container: "myorg/server:latest"
    command: "node"
    args: ["server.js"]

# Correct - use container only
mcp-servers:
  my-tool:
    container: "myorg/server:latest"
    args: ["--port", "8080"]

# Or use command only
mcp-servers:
  my-tool:
    command: "node"
    args: ["server.js"]
```

--------------------------------

### Engine Command-Line Arguments

Source: https://context7_llms

Example of providing custom command-line arguments for an engine, such as Copilot, to modify behavior like adding directories or enabling verbose logging.

```yaml
engine: id: copilot
args: ["--add-dir", "/workspace", "--verbose"]
```

--------------------------------

### AW Example: Secure Context Usage

Source: https://context7_llms

This AW code demonstrates the recommended secure method for accessing issue context using `needs.activation.outputs.text` and contrasts it with the discouraged raw context.

```aw
```aw
# RECOMMENDED: Use sanitized context text
Analyze issue #${{ github.event.issue.number }} in repository ${{ github.repository }}. The content: "${{ needs.activation.outputs.text }}"

# DISCOURAGED: Raw context (security risks)
The issue body is: "${{ github.event.issue.body }}"
```
```

--------------------------------

### Docker Container MCP Server with Arguments and Volume Mounts

Source: https://context7_llms

Configures a Docker MCP server with custom arguments and volume mounts. The `args` are passed to `docker run`, and `entrypointArgs` are passed to the container's entrypoint. This example maps a host directory to the container.

```yaml
mcp-servers:
  custom-tool:
    container: "mcp/custom-tool"
    version: "v1.0"
    args:
      - "-v"
      - "/host/data:/app/data"
    entrypointArgs:
      - "serve"
      - "--port"
      - "8080"
      - "--verbose"
    allowed: ["*"]
```

--------------------------------

### MCP Server: HTTP Configuration without Container

Source: https://context7_llms

Shows how to correctly configure an HTTP MCP server by omitting the 'container' field, as it's only applicable to stdio-based servers. Includes example of adding headers.

```yaml
# Incorrect - container with HTTP
mcp-servers:
  my-api:
    type: http
    url: "https://api.example.com/mcp"
    container: "myorg/server:latest"

# Correct - HTTP without container
mcp-servers:
  my-api:
    type: http
    url: "https://api.example.com/mcp"
    headers:
      Authorization: "Bearer ${{ secrets.API_TOKEN }}"
```

--------------------------------

### Install and Add PR Fix Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/pr-fix

Commands to install the 'gh aw' extension and add the PR Fix workflow to your repository. This involves adding a configuration file to your repository for the workflow to function.

```bash
gh aw extension install githubnext/agentics
gh aw add githubnext/agentics/pr-fix --pr
```

--------------------------------

### Configure GitHub Enterprise Cloud MCP Server

Source: https://github.com/github/github-mcp-server

This configuration example demonstrates how to set up the GitHub MCP Server for GitHub Enterprise Cloud, including the server URL and authorization headers. It is intended for use in configuration files.

```json
{
  "proxima-github": {
    "type": "http",
    "url": "https://copilot-api.octocorp.ghe.com/mcp",
    "headers": {
      "Authorization": "Bearer ${input:github_mcp_pat}"
    }
  }
}
```

--------------------------------

### Override Tool Descriptions with Environment Variables

Source: https://github.com/github/github-mcp-server

Example of overriding tool descriptions in the GitHub MCP Server using environment variables. The variable names are derived from the JSON keys, prefixed with GITHUB_MCP_ and in uppercase.

```bash
# Override the TOOL_ADD_ISSUE_COMMENT_DESCRIPTION with a custom string
export GITHUB_MCP_TOOL_ADD_ISSUE_COMMENT_DESCRIPTION="an alternative description"
```

--------------------------------

### Load Agentic Workflow Prompt with GitHub Copilot CLI

Source: https://context7_llms

Loads the `create-agentic-workflow.prompt.md` file into a GitHub Copilot CLI session using the `@` syntax, enabling workflow authoring directly from the command line.

```bash
load @.github/prompts/create-agentic-workflow.prompt.md
```

--------------------------------

### Specify Toolsets via Command Line Argument (Shell)

Source: https://github.com/github/github-mcp-server

This command demonstrates how to run the GitHub MCP server from the command line, specifying a comma-separated list of toolsets to enable. This controls which GitHub API capabilities are exposed to AI tools.

```shell
github-mcp-server --toolsets repos,issues,pull_requests,actions,code_security
```

--------------------------------

### Example AW Prompt for Issue Update Agent

Source: https://context7_llms

Example of natural language prompt to instruct an agent to analyze issue content and update its status, title, or body.

```aw
---
on: issues:
  types: [opened, edited]
permissions:
  contents: read
  actions: read
engine: claude
safe-outputs:
  update-issue:
    status: true
    title: true
    body: true
---
# Issue Update Agent
Analyze the issue and update its status, title, or body as needed. Update the issue based on your analysis. You can change the title, body content, or status (open/closed).
```

--------------------------------

### Example Runtime Errors in Bash

Source: https://context7_llms

Demonstrates common runtime errors encountered during GitHub Actions workflow execution. This includes missing tools like 'jq', permission denials due to insufficient token scopes, authentication failures, invalid time delta formats, and network connection issues.

```bash
jq not found in PATH
```

```plaintext
Error: Resource not accessible by integration
```

```plaintext
Error: authentication required
```

```plaintext
Error: invalid time delta format: +90m. Expected format like +25h, +3d
```

```plaintext
Error: failed to connect to MCP server at https://example.com
```

--------------------------------

### Example: Setting default run step options for a job

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This example demonstrates how to set default 'shell' and 'working-directory' for all 'run' steps within a specific job in a GitHub Actions workflow.

```yaml
jobs:
  job1:
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
        working-directory: ./scripts

```

--------------------------------

### MCP Server Configuration for Local Build (JSON)

Source: https://github.com/github/github-mcp-server

This JSON configures the MCP server to use a locally built executable instead of Docker. It specifies the command path to the binary, arguments, and environment variables, including a placeholder for the GitHub token.

```json
{
  "mcp": {
    "servers": {
      "github": {
        "command": "/path/to/github-mcp-server",
        "args": ["stdio"],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": ""
        }
      }
    }
  }
}
```

--------------------------------

### Custom MCP Server Configuration (Python)

Source: https://context7_llms

Example of setting up a Python-based MCP server. This configuration uses `python` as the command, specifies the module path for the server, and includes environment variables like database URLs and timeouts.

```yaml
mcp-servers:
  data-processor:
    command: "python"
    args:
      - "-m"
      - "data_processor.mcp_server"
    env:
      DATABASE_URL: "${{ secrets.DATABASE_URL }}"
      API_TIMEOUT: "30"
```

--------------------------------

### Launch GitHub Copilot CLI

Source: https://github.com/github/copilot-cli

Launches the GitHub Copilot CLI. On first launch, it displays an animated banner and prompts for authentication if not logged in.

```bash
copilot
```

--------------------------------

### Create and Ignore .env file for PAT

Source: https://github.com/github/github-mcp-server

This example demonstrates creating a .env file to store the GitHub PAT and adding it to the .gitignore file to prevent accidental commits. This enhances security by keeping sensitive credentials out of version control.

```bash
GITHUB_PAT=your_token_here
echo ".env" >> .gitignore
```

--------------------------------

### VS Code Configuration for GitHub MCP Server (PAT)

Source: https://github.com/github/github-mcp-server

This JSON configuration sets up the GitHub MCP Server in VS Code using a Personal Access Token (PAT) for authentication. It includes the server URL and a prompt for the user to input their GitHub PAT. This method also requires VS Code 1.101+ and MCP host support for remote servers.

```json
{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${input:github_mcp_pat}"
      }
    }
  },
  "inputs": [
    {
      "type": "promptString",
      "id": "github_mcp_pat",
      "description": "GitHub Personal Access Token",
      "password": true
    }
  ]
}
```

--------------------------------

### Workflow Initialization Commands

Source: https://context7_llms

Commands to initialize a repository for agentic workflows, including configuring .gitattributes and creating GitHub Copilot custom instructions. The `--mcp` flag enables GitHub Copilot Agent MCP integration.

```bash
gh aw init
gh aw init --mcp # Configure GitHub Copilot Agent MCP integration
```

--------------------------------

### Trigger Workflow on Watch Event (Started Activity)

Source: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

This workflow triggers when a repository is starred, specifically on the 'started' activity type for the 'watch' event. It shows how to limit workflow runs to specific activity types.

```yaml
on:
  watch:
    types: [started]
```

--------------------------------

### Example with Different Patch Size Limits (YAML)

Source: https://context7_llms

Illustrates setting different maximum patch size limits for various operations. This allows for fine-grained control over patch sizes, accommodating scenarios with small or large patches.

```yaml
# Small patches only (256 KB limit)
safe-outputs:
  max-patch-size: 256
  create-pull-request:
    title-prefix: "[SMALL] "
# Large patches allowed (5 MB limit)
safe-outputs:
  max-patch-size: 5120
  push-to-pull-request-branch:
    if-no-changes: "error"
```

--------------------------------

### View GitHub Repository Information

Source: https://cli.github.com/

Display details about a GitHub repository, including its description and a link to view it on GitHub. This command provides a quick way to get essential repository information directly from the terminal.

```bash
gh repo view
**cli/cli**
GitHub’s official command line tool
**GitHub CLI**
gh is GitHub on the command line. It brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code.
Image: screenshot of gh pr status → https://user-images.githubusercontent.com/98482/84171218-327e7a80-aa40-11ea-8cd1-5177fc2d0e72.png
View this repository on GitHub: https://github.com/cli/cli
```

--------------------------------

### Workflow Example with Push to Pull Request Branch

Source: https://context7_llms

An example of a GitHub Actions workflow that utilizes the 'push-to-pull-request-branch' feature. This workflow is triggered on pull request events and includes an agent that analyzes and updates code.

```yaml
---
    on: pull_request:
      types: [opened, synchronize]
    permissions:
      contents: read
    actions: read
    engine: claude
    safe-outputs:
      push-to-pull-request-branch:
        target: "triggering"
        if-no-changes: "warn"
    ---
    # Code Update Agent
    Analyze the pull request and make necessary code improvements.
    1. Make any file changes directly in the working directory
    2. Push changes to the feature branch with a descriptive commit message

```

--------------------------------

### Example of Search Priority for Restore Keys

Source: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

Illustrates the priority order in which GitHub Actions searches for matching cache keys. This example specifically shows the order for 'npm-feature-d5ea0750', 'npm-feature-', and 'npm-' when used with a specific hash.

```yaml
key: npm-feature-d5ea0750
restore-keys: |
  npm-feature-
  npm-
```

--------------------------------

### Install GitHub CI Doctor Extension

Source: https://github.com/githubnext/agentics/blob/main/docs/ci-doctor

Instructions to install the 'gh aw' extension, which includes the CI Doctor functionality. This extension is part of the GitHub Agentics project, facilitating the automation of CI workflow monitoring and analysis.

```bash
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

```

--------------------------------

### Run the Daily QA Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-qa

This command initiates a run of the 'daily-qa' workflow after the pull request has been merged and changes are synced to the main branch. It requires the workflow to be previously added and configured.

```bash
gh aw run daily-qa
```

--------------------------------

### Example of 'stop-after' with Multiple Time Units (AW)

Source: https://context7_llms

A complete workflow example using 'workflow_dispatch' and demonstrating the 'stop-after' field with a combination of weeks and days. This highlights how to specify longer durations for automated task termination.

```yaml
---
on:
  workflow_dispatch:
    stop-after: "+2w3d" # 2 weeks and 3 days
---
# Long Running Task
# Task will automatically stop after configured time.
```

--------------------------------

### Enable Dynamic Toolsets in GitHub MCP Server

Source: https://github.com/github/github-mcp-server

This snippet shows how to enable dynamic toolset discovery for the GitHub MCP Server, allowing the MCP host to list and enable toolsets in response to user prompts. This is useful for managing the available tools and avoiding model confusion. It can be done via a command-line flag or an environment variable when using Docker.

```bash
./github-mcp-server --dynamic-toolsets
```

```bash
docker run -i --rm \
-e GITHUB_PERSONAL_ACCESS_TOKEN= \
-e GITHUB_DYNAMIC_TOOLSETS=1 \
ghcr.io/github/github-mcp-server
```

--------------------------------

### Configure Docker container inputs with 'jobs..steps..with.args'

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This snippet shows how to pass arguments to a Docker container's ENTRYPOINT using the 'args' keyword. It's suitable for configuring inputs for Docker container actions, where 'args' replaces the Dockerfile's CMD instruction.

```yaml
steps:
  - name: Explain why this job ran
    uses: octo-org/action-name@main
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.
```

--------------------------------

### Example: Using toJSON with job outputs

Source: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

This is a shell command example within a GitHub Actions workflow. It uses the 'toJSON' function to convert the outputs of a preceding job ('needs.job1.outputs') into a JSON string, intended for use in a 'run' step.

```bash
run: echo '${{ toJSON(needs.job1.outputs) }}'

```

--------------------------------

### Enable All Toolsets using Command Line (Shell)

Source: https://github.com/github/github-mcp-server

This command enables all available toolsets for the GitHub MCP server by passing the special 'all' argument to the --toolsets flag. This provides the broadest access to GitHub API capabilities.

```shell
./github-mcp-server --toolsets all
```

--------------------------------

### Install and Add GitHub Agentics Daily Team Status Workflow

Source: https://github.com/githubnext/agentics/blob/main/docs/daily-team-status

Commands to install the 'gh aw' extension and add the Daily Team Status workflow to a repository. The 'add' command creates a pull request to integrate the workflow, which requires enabling GitHub Actions and Issues if in a fork.

```bash
# Install the 'gh aw' extension
gh aw extension install githubnext/agentics

# Add the Daily Team Status workflow to your repository
gh aw add githubnext/agentics/daily-team-status --pr
```

--------------------------------

### Example Cache Merge Scenario

Source: https://context7_llms

Demonstrates the merging of cache-memory configurations between an imported shared workflow and a local workflow file. The example shows how local configurations take precedence in case of ID conflicts. Requires 'aw' engine.

```aw
---
imports:
  - shared/memory-setup.md
tools:
  cache-memory:
    - id: local-logs
      key: workflow-logs
--- 
```

--------------------------------

### Verify GitHub Actions 'on:' Section Syntax

Source: https://context7_llms

Demonstrates valid 'on:' section configurations for GitHub Actions triggers, helping to resolve 'invalid on: section format' errors by adhering to the documented syntax.

```yaml
# Valid formats
on: push
# or
on: push:
  branches: [main]
# or
on: issues:
  types: [opened, edited]
```

--------------------------------

### List Projects

Source: https://github.com/github/github-mcp-server

Lists all projects for a given owner, with optional filtering.

```APIDOC
## GET /projects/:owner

### Description
Lists all projects for a given owner, with optional filtering.

### Method
GET

### Endpoint
`/projects/:owner`

### Parameters
#### Path Parameters
- **owner** (string) - Required - If owner_type == user it is the handle for the GitHub user account. If owner_type == org it is the name of the organization. The name is not case sensitive.

#### Query Parameters
- **owner_type** (string) - Required - Owner type
- **per_page** (number) - Optional - Number of results per page (max 100, default: 30)
- **query** (string) - Optional - Filter projects by a search query (matches title and description)
```

--------------------------------

### Docker Container MCP Server with Environment Variables

Source: https://context7_llms

Demonstrates configuring a Docker MCP server with environment variables, specifically for authentication (e.g., Azure credentials). The `entrypointArgs` are used to start the server in read-only mode.

```yaml
mcp-servers:
  azure:
    container: "mcr.microsoft.com/azure-sdk/azure-mcp"
    version: "latest"
    entrypointArgs:
      - "server"
      - "start"
      - "--read-only"
    env:
      AZURE_TENANT_ID: "${{ secrets.AZURE_TENANT_ID }}"
      AZURE_CLIENT_ID: "${{ secrets.AZURE_CLIENT_ID }}"
      AZURE_CLIENT_SECRET: "${{ secrets.AZURE_CLIENT_SECRET }}"
    allowed: ["*"]
```