You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This research explores how the agentic-workflows custom agent responds to workflow creation requests from 5 distinct software worker personas. Analysis is based on deep review of the agent's instruction files (.github/aw/create-agentic-workflow.md, .github/aw/github-agentic-workflows.md) and real workflow examples in .github/workflows/*.md.
Note: The agentic-workflows agent type is not directly invocable as a task sub-agent in this environment. This analysis is based on static analysis of the agent's configuration, instruction files, and corpus of existing workflows.
Scenarios Tested: 4 representative scenarios across 5 personas
Average Quality Score: 4.1/5.0
Key Findings
🎯 Trigger selection is consistently strong — the agent correctly maps PR scenarios to pull_request, scheduled reports to schedule: weekly/daily, and command-based tasks to slash_command
🔐 Security posture is well-enforced — instructions explicitly mandate read-only agent jobs with all writes routed through safe-outputs; this is reinforced with ❌ WRONG examples showing what not to do
🌐 GitHub MCP is the correct path for API access — documentation clearly warns against network: allowed: api.github.com and always steers toward tools: github: toolsets:
⚠️Artifact/log access is an edge case — for scenarios requiring workflow run logs or coverage artifacts, the agent's tooling guidance is less prescriptive
📅 Fuzzy scheduling is the default recommendation — schedule: daily on weekdays or schedule: weekly over fixed crons
Top Patterns
Most common triggers: pull_request: [opened, synchronize], issues: [opened], schedule: daily/weekly, slash_command
Most recommended tools: github: toolsets: [default], cache-memory, mount-as-clis: true
Security practices: Read-only permissions: on agent job + safe-outputs: for all writes; lock-for-agent: true for concurrency
View Scenario Analysis (4 scenarios tested)
Scenario 1 — Backend Engineer: DB Schema Migration Review on PRs
Grouping by label + markdown formatting is clearly actionable
Completeness
5/5
workflow_dispatch auto-added with fuzzy schedule; nothing missing
Average: 5.0/5 — ✅ Excellent response expected
View Areas for Improvement
Issue 1: workflow_run Trigger Guidance Is Thin
The create-agentic-workflow.md documentation has detailed coverage of issues, pull_request, schedule, and slash_command triggers but minimal guidance on workflow_run. For DevOps incident-automation scenarios, the agent may:
Generate a trigger without the required if: conclusion == 'failure' guard
Not know to specify workflows: [...] names
Miss that github.event.workflow_run.head_sha is the correct ref for log fetching
Recommendation: Add a workflow_run trigger example to .github/aw/create-agentic-workflow.md.
Issue 2: Artifact/Coverage Data Access Is an Unsupported Pattern
QA coverage scenarios assume the agent can access CI-generated coverage artifacts. The GitHub MCP actions toolset exposes artifact metadata, but downloading artifact content requires additional steps. The agent documentation does not describe a pattern for this.
Recommendation: Document a steps: + bash pattern for downloading and parsing artifacts in .github/aw/github-agentic-workflows.md.
Issue 3: paths Filter on PR Triggers Not Always Suggested
For scenarios that should only fire when specific files change (e.g., **/migrations/*.sql, coverage/**), the agent may generate broad pull_request triggers without paths: filters, causing unnecessary runs.
Recommendation: Add a paths: filter best practice note to the trigger selection guidance section of .github/aw/create-agentic-workflow.md.
Recommendations
Add workflow_run trigger examples to .github/aw/create-agentic-workflow.md — include the if: conclusion == 'failure' guard, workflow name specification, and log-access patterns via github: toolsets: [actions]
Document artifact access pattern in .github/aw/github-agentic-workflows.md — a minimal steps: block showing how to download and expose CI artifacts (coverage reports, test results) before the agent runs
Promote paths: filters as a recommended practice for PR-triggered workflows — this reduces noisy runs and keeps workflows targeted; the create-agentic-workflow.md instruction file should prompt the agent to ask whether the workflow should be scoped to specific file patterns
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
This research explores how the
agentic-workflowscustom agent responds to workflow creation requests from 5 distinct software worker personas. Analysis is based on deep review of the agent's instruction files (.github/aw/create-agentic-workflow.md,.github/aw/github-agentic-workflows.md) and real workflow examples in.github/workflows/*.md.Persona Overview
agentic-workflowscustom agent (Copilot Chat)Key Findings
pull_request, scheduled reports toschedule: weekly/daily, and command-based tasks toslash_commandsafe-outputs; this is reinforced with❌ WRONGexamples showing what not to donetwork: allowed: api.github.comand always steers towardtools: github: toolsets:schedule: daily on weekdaysorschedule: weeklyover fixed cronsTop Patterns
pull_request: [opened, synchronize],issues: [opened],schedule: daily/weekly,slash_commandgithub: toolsets: [default],cache-memory,mount-as-clis: truepermissions:on agent job +safe-outputs:for all writes;lock-for-agent: truefor concurrencyView Scenario Analysis (4 scenarios tested)
Scenario 1 — Backend Engineer: DB Schema Migration Review on PRs
pull_request: [opened, synchronize]— exact matchgithub: toolsets: [default]for PR diff; LLM handles SQL analysis nativelyadd-commentsafe outputDROP TABLE,DROP COLUMN, missing defaultspathsfilter to scope to**/migrations/*.sqlfilesAverage: 4.4/5 — ✅ Strong response expected
Scenario 2 — DevOps Engineer: Failed Deployment Incident Creation
workflow_run: types: [completed]correct; agent may not know exact workflow namesgithub: toolsets: [actions]for log download — not always auto-inferredcreate-issue+add-commentsafe outputs; permissions OKif: github.event.workflow_run.conclusion == 'failure'guardAverage: 3.4/5 —⚠️ Adequate but needs improvement;
workflow_runtrigger is underspecifiedScenario 3 — QA Tester: Coverage Analysis on PRs
pull_request: [opened, synchronize]— exact matchgithub: toolsets: [actions]needed but may be missedadd-comment: max: 1safe output; read-only permissionsAverage: 4.0/5 —⚠️ Good trigger/security but artifact access gap
Scenario 4 — Product Manager: Weekly Feature Digest
schedule: weeklywith fuzzy scheduling — perfect fitgithub: toolsets: [issues, pull_requests]— correct and minimalcreate-discussionsafe output; read-only permissionsworkflow_dispatchauto-added with fuzzy schedule; nothing missingAverage: 5.0/5 — ✅ Excellent response expected
View Areas for Improvement
Issue 1:
workflow_runTrigger Guidance Is ThinThe
create-agentic-workflow.mddocumentation has detailed coverage ofissues,pull_request,schedule, andslash_commandtriggers but minimal guidance onworkflow_run. For DevOps incident-automation scenarios, the agent may:if: conclusion == 'failure'guardworkflows: [...]namesgithub.event.workflow_run.head_shais the correct ref for log fetchingRecommendation: Add a
workflow_runtrigger example to.github/aw/create-agentic-workflow.md.Issue 2: Artifact/Coverage Data Access Is an Unsupported Pattern
QA coverage scenarios assume the agent can access CI-generated coverage artifacts. The GitHub MCP
actionstoolset exposes artifact metadata, but downloading artifact content requires additional steps. The agent documentation does not describe a pattern for this.Recommendation: Document a
steps:+bashpattern for downloading and parsing artifacts in.github/aw/github-agentic-workflows.md.Issue 3:
pathsFilter on PR Triggers Not Always SuggestedFor scenarios that should only fire when specific files change (e.g.,
**/migrations/*.sql,coverage/**), the agent may generate broadpull_requesttriggers withoutpaths:filters, causing unnecessary runs.Recommendation: Add a
paths:filter best practice note to the trigger selection guidance section of.github/aw/create-agentic-workflow.md.Recommendations
Add
workflow_runtrigger examples to.github/aw/create-agentic-workflow.md— include theif: conclusion == 'failure'guard, workflow name specification, and log-access patterns viagithub: toolsets: [actions]Document artifact access pattern in
.github/aw/github-agentic-workflows.md— a minimalsteps:block showing how to download and expose CI artifacts (coverage reports, test results) before the agent runsPromote
paths:filters as a recommended practice for PR-triggered workflows — this reduces noisy runs and keeps workflows targeted; thecreate-agentic-workflow.mdinstruction file should prompt the agent to ask whether the workflow should be scoped to specific file patternsAppendix: Scenario Coverage Matrix
pull_requestpull_request+playwrightworkflow_runpull_requestschedule: weeklyReferences:
Beta Was this translation helpful? Give feedback.
All reactions