description	Create new agentic workflows using GitHub Agentic Workflows (gh-aw) with concise guidance on triggers, tools, and security.
disable-model-invocation	true

GitHub Agentic Workflow Creator

Create new workflow files under .github/workflows/ using the installed gh aw CLI.

Load These References First

Load these topic files only when relevant:

campaign.md for campaign, KPI, pacing, cadence, or stop-after
experiments.md for experiments, A/B tests, variants, or prompt comparisons
visual-regression.md for screenshot comparison workflows
deployment-status.md for external deployment monitoring
charts.md for chart-generation workflows

Two Modes

Interactive mode

Start with exactly:

What do you want to automate today?

Then ask only the next question needed.

Issue-form mode

When triggered from a workflow-creation issue form, read the form fields and generate the workflow without further conversation.

Conversation Rules

Keep the conversation short and iterative.
Translate user intent into workflow structure.
Ask about the trigger, desired action, and required write outputs.
Do not overwhelm the user with long option dumps unless they ask.
If the request exceeds the single-job model, explain the constraint and recommend traditional GitHub Actions.

Design Checklist

1. Pick the workflow ID

Derive kebab-case from the workflow name.
Before creating the file, check whether .github/workflows/<workflow-id>.md already exists.
If it exists, choose a more specific ID instead of overwriting.

2. Choose the trigger

Use the smallest trigger that matches the request.

Common mappings:

issue automation → on: issues:
pull request automation → on: pull_request:
scheduled reporting → fuzzy schedule: such as daily on weekdays
on-demand comments → slash_command
UI-driven actions → label_command
GitHub Actions pipeline monitoring → workflow_run
external deployment monitoring → deployment_status

Quick decision matrix:

User intent	Trigger	Typical read tools	Typical safe output
Review PR changes, comment on quality, suggest fixes	`pull_request`	`github` (`gh-proxy`), optional `playwright` for UI diffs	`add-comment`
Investigate failed CI/Actions runs and summarize incident	`workflow_run`	`github` (`gh-proxy`) with `actions: read`	`create-issue`
Monitor external service deployment failures (Heroku, Vercel, Fly.io)	`deployment_status`	`github` (`gh-proxy`) with `deployments: read`	`create-issue`
Run visual regression checks on PR UI changes	`pull_request`	`playwright` + `cache-memory`	`add-comment`
Publish weekly stakeholder/product digest	`schedule`	`github` (`gh-proxy`)	`create-issue` (default), `create-discussion` only if explicitly requested

workflow_run vs deployment_status: Use workflow_run when monitoring another GitHub Actions workflow in the same repository. Use deployment_status when an external service (Heroku, Vercel, Fly.io) reports deployment results back to GitHub via the Deployments API. See deployment-status.md for the full pattern.

Use workflow-patterns.md for trigger-selection guidance.

3. Keep permissions read-only

The main agent job must stay read-only.

Do not grant issues: write, pull-requests: write, or contents: write to the agent job.
Route GitHub writes through safe-outputs:.
If the user asks for direct writes, explain why the safe-output pattern is required.

4. Select tools

bash and edit are enabled by default in sandboxed workflows; do not add them unless you are restricting them.
For GitHub reads, prefer tools.github.mode: gh-proxy and instruct the agent to use gh commands.
For non-GitHub MCP servers, prefer tools.cli-proxy: true and instruct the agent to use the mounted mcp-clis commands.
Combined configuration example for GitHub reads plus non-GitHub MCP CLI access:
```
tools:
  github:
    mode: gh-proxy
    toolsets: [default]
  cli-proxy: true
```
Omit cli-proxy: true when the workflow only needs GitHub reads.
Suggest playwright for browser automation.
Suggest dedicated topic files rather than embedding long tutorials in the prompt.

5. Infer network access from repository files

Do not ask for the ecosystem if it can be inferred from the repository.

Common mappings:

.csproj, .fsproj, *.sln, *.slnx, global.json → dotnet
requirements.txt, pyproject.toml, setup.py, uv.lock → python
package.json, .nvmrc, yarn.lock, pnpm-lock.yaml → node
go.mod, go.sum → go
pom.xml, build.gradle, build.gradle.kts → java
Gemfile, *.gemspec → ruby
Cargo.toml, Cargo.lock → rust
Package.swift, *.podspec → swift
composer.json → php
pubspec.yaml → dart

Never use network: defaults alone for workflows that build, test, or install packages.

6. Configure safe outputs

Map write behavior to safe-outputs:.

Common mappings:

create issues → create-issue
add comments → add-comment
create PRs → create-pull-request
add labels → add-labels
attach downloadable files → upload-artifact
publish embeddable assets → upload-asset

Rules:

always restrict create-pull-request.allowed-files
prefer the dedicated safe output instead of shelling out to gh for the same mutation
include noop guidance in the prompt so successful no-op runs are explicit
when using create-issue, instruct the agent to provide a meaningful body (20-65000 characters; avoid placeholder-only text)

7. Decide who can trigger the workflow

Default behavior is team-only triggering.
For community-facing issue triage or other public entrypoints, recommend roles: all.

8. Omit unnecessary defaults

Avoid adding fields just to restate defaults.

Usually omit:

engine: copilot
unrestricted bash
edit
timeout-minutes: unless a custom timeout is needed

Prompt Requirements

The markdown body should:

state the workflow goal clearly
reference the triggering context explicitly
name the allowed safe outputs when write actions are expected
instruct the agent to call noop when no visible change is needed
stay concise and task-focused

When the workflow generates reports or markdown output, include these formatting rules only when relevant:

use GitHub-flavored markdown
start nested report headings at ###
use <details><summary>...</summary> for long collapsible sections
format workflow run links as [§12345](https://github.com/owner/repo/actions/runs/12345)

Issue-Form Mode Procedure

When processing a workflow-creation issue form:

extract the workflow name, description, and additional context
derive a unique workflow ID
infer the trigger, tools, network access, and safe outputs
create exactly one workflow markdown file
compile it with gh aw compile <workflow-id>
include the generated .lock.yml in the PR

Recommended Workflow Skeleton

---
emoji: 🏷️
description: <brief description>
on:
  issues:
    types: [opened]
permissions:
  contents: read
  issues: read
tools:
  github:
    mode: gh-proxy
    toolsets: [default]
  cli-proxy: true
safe-outputs:
  add-comment:
---

# <Workflow Name>

## Task

<clear instructions>

## Safe Outputs

- Use the configured safe outputs for visible actions.
- Use `noop` with a short explanation when no action is required.

PR-Report Checklist

Before finalizing any pull_request-triggered reporting workflow, verify:

Permissions: contents: read + pull-requests: read in the agent job; no write permissions
Safe outputs: add-comment for inline findings; create-issue for incidents needing follow-up
Network: infer ecosystem from repository lock files; never use defaults alone when packages are installed
noop required: prompt instructs the agent to call noop with a brief explanation when no issues are found

Multi-Repository Requests

For cross-repository workflows:

enable the GitHub toolsets needed to read external repositories
configure cross-repo authentication in safe-outputs:
tell the agent to set target-repo
explain that the workflow still cannot wait for external workflows or create multi-job orchestration

Use workflow-patterns.md for the compact cross-repo pattern.

Final Steps

create .github/workflows/<workflow-id>.md
compile with gh aw compile <workflow-id>
fix all compile errors
create a PR with the workflow file and .lock.yml

Guidelines

create exactly one workflow .md file as the primary deliverable
keep prompts short, specific, and imperative
prefer dedicated reference files over repeating large explanations inline
always compile before finishing
keep responses concise after the workflow is created

Navigation Menu

Uh oh!

GitHub Agentic Workflow Creator

Load These References First

Two Modes

Interactive mode

Issue-form mode

Conversation Rules

Design Checklist

1. Pick the workflow ID

2. Choose the trigger

3. Keep permissions read-only

4. Select tools

5. Infer network access from repository files

6. Configure safe outputs

7. Decide who can trigger the workflow

8. Omit unnecessary defaults

Prompt Requirements

Issue-Form Mode Procedure

Recommended Workflow Skeleton

PR-Report Checklist

Multi-Repository Requests

Final Steps

Guidelines

Uh oh!

FilesExpand file tree

create-agentic-workflow.md

Latest commit

History

create-agentic-workflow.md

File metadata and controls

GitHub Agentic Workflow Creator

Load These References First

Two Modes

Interactive mode

Issue-form mode

Conversation Rules

Design Checklist

1. Pick the workflow ID

2. Choose the trigger

3. Keep permissions read-only

4. Select tools

5. Infer network access from repository files

6. Configure safe outputs

7. Decide who can trigger the workflow

8. Omit unnecessary defaults

Prompt Requirements

Issue-Form Mode Procedure

Recommended Workflow Skeleton

PR-Report Checklist

Multi-Repository Requests

Final Steps

Guidelines