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 comprehensive analysis examines all agentic workflow lock files (.lock.yml) in the .github/workflows/ directory, revealing patterns in triggers, safe outputs, structural complexity, and resource usage across the repository's automated agent workflows.
Total Lock Files: 124 workflows
Total Size: 10.2 MB (10,415,368 bytes)
Average File Size: 82.0 KB (83,995 bytes)
Analysis Date: December 26, 2025
Key Findings:
86% of workflows (107/124) support manual triggering via workflow_dispatch
69% of workflows (86/124) run on schedules, with weekday morning schedules being most popular
Average workflow has 6.1 jobs with 12.8 steps per job
GitHub MCP server is used in 3,224 tool configurations across all workflows
97% of workflows use safe outputs for secure GitHub API interactions
The distribution shows that agentic workflows are substantial in size, with the vast majority falling into the 50-100 KB range. This reflects the complexity of agent prompts, tool configurations, and multi-stage job orchestration.
Trigger Analysis
Most Popular Triggers
Trigger Type
Count
Percentage
Description
workflow_dispatch
107
86.3%
Manual trigger capability
schedule
86
69.4%
Automated scheduled runs
pull_request
16
12.9%
PR events
issue_comment
14
11.3%
Comment on issues
issues
13
10.5%
Issue opened/edited
discussion_comment
6
4.8%
Discussion comments
pull_request_review_comment
5
4.0%
PR review comments
discussion
5
4.0%
Discussion events
workflow_run
2
1.6%
Triggered by other workflows
push
2
1.6%
Push to branches
workflow_call
1
0.8%
Reusable workflow
Key Observations:
Manual control is paramount: 86% of workflows support workflow_dispatch, allowing on-demand execution
Scheduled automation dominates: 69% run on cron schedules for regular tasks
Event-driven workflows: 13% respond to issues/PRs, enabling reactive agent behavior
Multi-modal triggers: Many workflows combine multiple trigger types for flexibility
Common Trigger Combinations
Combination
Count
Use Case
schedule + workflow_dispatch
76
Scheduled reports with manual override
workflow_dispatch only
15
Pure on-demand workflows
pull_request + schedule + workflow_dispatch
8
PR analysis + periodic checks
issues only
4
Issue-reactive agents
Multi-event responsive
3
Omni-channel agents (issues, PRs, discussions)
issue_comment + issues + workflow_dispatch
2
Issue conversation agents
The most popular pattern (61% of workflows) is scheduled + manual, allowing regular automated runs with the flexibility to trigger on-demand.
Schedule Patterns
Schedule (Cron)
Count
Description
0 14 * * 1-5
5
2 PM UTC, weekdays
0 13 * * 1-5
4
1 PM UTC, weekdays
0 11 * * 1-5
4
11 AM UTC, weekdays
0 9 * * 1
3
9 AM UTC, Mondays
Various daily
15+
Once per day at specific times
Every 12 hours
8
Twice daily monitoring
Every 6 hours
2
Four times daily
Weekly/Monthly
5
Lower frequency checks
Schedule Analysis:
Weekday preference: Most schedules run Monday-Friday (1-5), avoiding weekends
Business hours: Peak scheduling at 9 AM - 2 PM UTC (typical business hours across timezones)
Safe Outputs Usage: 120 out of 124 workflows (96.8%) include safe outputs configuration, indicated by the presence of GH_AW_SAFE_OUTPUTS environment variable.
Safe outputs provide a security boundary that allows agents to propose GitHub API actions (create issues, discussions, comments, PRs) without direct write access. Instead, outputs are collected and processed by downstream jobs with appropriate permissions.
Safe Output Architecture
The safe outputs pattern in these workflows follows a consistent structure:
Agent Job: Runs with permissions: read-all and proposes actions via MCP tools
Output Collection: Actions are written to /tmp/gh-aw/safeoutputs/outputs.jsonl
Downstream Jobs: Process safe outputs with minimal required permissions
Available Safe Output Types
Based on the MCP server configuration visible in workflows:
Safe Output Type
Purpose
create_discussion
Create GitHub discussions
create_issue
Create GitHub issues
add_comment
Add comments to issues/PRs
missing_tool
Report missing capabilities
noop
Transparent completion without actions
Security Model: This architecture ensures agents cannot directly modify the repository or create unintended side effects, requiring explicit downstream approval for all write operations.
Structural Characteristics
Job Complexity
Average Jobs per Workflow: 6.1 jobs
Job Range: 2-9 jobs
Average Steps per Job: 12.8 steps
Steps Range: 1-56 steps
Maximum Steps in Single Job: 56 steps
Job Structure Patterns:
Most workflows follow a multi-stage pipeline:
Pre-activation checks (external user validation, permissions)
Activation (issue locking, setup)
Agent job (main AI agent execution)
Output processing (safe outputs → GitHub API actions)
Cleanup/notifications (unlocking, status updates)
Timeout Configurations
Timeout (minutes)
Count
Usage
10 minutes
140
Most common, for agent jobs
15 minutes
116
Extended timeout for complex tasks
The 10-minute timeout is standard for agent execution, with 15-minute timeouts for workflows needing additional processing time.
Concurrency Patterns
All analyzed workflows use concurrency groups to prevent parallel executions:
This ensures that only one instance of an agent workflow runs at a time per context (workflow, issue, or PR).
Permission Patterns
Workflow-Level Permissions
Analysis of permissions: blocks shows a security-conscious approach:
Empty permissions (permissions: {}): Used at workflow level in 241 instances
Read-all (permissions: read-all): Only 2 instances, primarily for agent jobs
Minimal permissions: Most jobs request only specific required permissions
Job-Level Permissions
Typical permission patterns by job type:
Job Type
Typical Permissions
pre_activation
contents: read, issues: read
activation
contents: read, issues: write
agent
read-all (for safe outputs pattern)
create_discussion_output
discussions: write
create_issue_output
issues: write
add_comment_output
issues: write, pull-requests: write
Security Principle: Workflows follow the principle of least privilege, with the agent job having read-all access but no write permissions, while output processing jobs have minimal write permissions only for their specific action.
Tool & MCP Patterns
Most Used MCP Servers
MCP Server
Count
Purpose
github
3,224
GitHub API operations (issues, PRs, repos, search)
playwright
210
Web automation and browser testing
arxiv
6
Academic paper research
deepwiki
6
Deep Wikipedia research
GitHub MCP Dominance: The GitHub MCP server is used in 93.5% of all tool configurations, reflecting these workflows' primary purpose of GitHub-centric automation and analysis.
Tool Usage Patterns
Based on analysis of workflow steps, the most common tool patterns include:
File Operations: Read, Write, Edit for code analysis and generation
Search: Glob, Grep for codebase exploration
Task Orchestration: Task tool for sub-agent delegation
Bash: For git operations, npm commands, and system tasks
Average Lock File Profile
Based on statistical analysis, a typical .lock.yml file in this repository has:
Size: ~82 KB
Jobs: ~6 jobs (pre-activation, activation, agent, 2-3 output processors)
All workflows follow a remarkably consistent security pattern with the safe outputs architecture, demonstrating a mature approach to agent security. The separation between agent execution (read-only) and action taking (write permissions) is universal.
2. Staggered Schedule Distribution
The unique minute values in cron schedules (e.g., 47 14, 19 9, 56 11) suggest intentional load distribution to avoid thundering herd problems when multiple workflows would otherwise trigger simultaneously at round-number times.
3. Weekday Business Hours Bias
The overwhelming preference for weekday scheduling (1-5 in cron expressions) and business hour timing indicates these workflows are designed to align with human work patterns, likely for timely notification delivery and responsiveness.
4. Job Complexity Distribution
The maximum of 56 steps in a single job and average of 12.8 steps indicates sophisticated multi-step orchestration within individual jobs, not just across jobs.
5. Workflow Dispatch as Standard
With 86% of workflows supporting manual triggering, the repository has embraced on-demand execution as a first-class feature, enabling easy testing, debugging, and ad-hoc runs.
6. Size Consistency
The tight clustering around 50-100 KB suggests standardized workflow templates and patterns, with outliers likely having specialized prompts, additional tool configurations, or extended documentation.
Historical Context
This is the first comprehensive statistical analysis of the repository's lock files. Future analyses will track:
Growth in workflow count
Evolution of trigger patterns
Changes in average complexity
New MCP server adoption
Safe output pattern variations
Baseline Metrics (Dec 26, 2025):
Total workflows: 124
Avg size: 82 KB
Avg jobs: 6.1
Avg steps/job: 12.8
Schedule adoption: 69%
Recommendations
1. Documentation of Standard Patterns
With such consistent patterns emerging (safe outputs, concurrency groups, permission models), creating template workflows or documentation could accelerate new workflow development and maintain consistency.
2. Schedule Optimization Review
Review the 86 scheduled workflows to ensure timing still aligns with actual usage patterns. Consider consolidating workflows with similar schedules if they perform related tasks.
3. Size Outlier Investigation
The 19 workflows >100 KB warrant review to determine if they contain duplicated logic, excessive prompts, or if they could benefit from modularization.
4. MCP Server Usage Analysis
With Playwright used in 210 instances, consider dedicated documentation or examples for browser automation patterns. The light usage of arxiv and deepwiki suggests opportunities for broader research-agent capabilities.
5. Timeout Standardization
The split between 10 and 15-minute timeouts could be standardized based on empirical runtime data to optimize cost and reliability.
6. Trigger Combination Patterns
The diversity in trigger combinations (20+ unique patterns) suggests potential for standardization. Common patterns could be documented as reference architectures.
Methodology
Analysis Tool: Python 3 script with PyYAML library
Lock Files Analyzed: 124 workflows
Data Sources: .github/workflows/*.lock.yml
Cache Memory: Scripts and data persisted to /tmp/gh-aw/cache-memory/lockfile-stats/
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.
-
Executive Summary
This comprehensive analysis examines all agentic workflow lock files (
.lock.yml) in the.github/workflows/directory, revealing patterns in triggers, safe outputs, structural complexity, and resource usage across the repository's automated agent workflows.Key Findings:
workflow_dispatchFull Report
File Size Distribution
Size Statistics:
example-permissions-warning.lock.yml(28.8 KB)copilot-session-insights.lock.yml(133.7 KB)The distribution shows that agentic workflows are substantial in size, with the vast majority falling into the 50-100 KB range. This reflects the complexity of agent prompts, tool configurations, and multi-stage job orchestration.
Trigger Analysis
Most Popular Triggers
Key Observations:
workflow_dispatch, allowing on-demand executionCommon Trigger Combinations
The most popular pattern (61% of workflows) is scheduled + manual, allowing regular automated runs with the flexibility to trigger on-demand.
Schedule Patterns
0 14 * * 1-50 13 * * 1-50 11 * * 1-50 9 * * 1Schedule Analysis:
Safe Outputs Analysis
Safe Outputs Usage: 120 out of 124 workflows (96.8%) include safe outputs configuration, indicated by the presence of
GH_AW_SAFE_OUTPUTSenvironment variable.Safe outputs provide a security boundary that allows agents to propose GitHub API actions (create issues, discussions, comments, PRs) without direct write access. Instead, outputs are collected and processed by downstream jobs with appropriate permissions.
Safe Output Architecture
The safe outputs pattern in these workflows follows a consistent structure:
permissions: read-alland proposes actions via MCP tools/tmp/gh-aw/safeoutputs/outputs.jsonlAvailable Safe Output Types
Based on the MCP server configuration visible in workflows:
create_discussioncreate_issueadd_commentmissing_toolnoopSecurity Model: This architecture ensures agents cannot directly modify the repository or create unintended side effects, requiring explicit downstream approval for all write operations.
Structural Characteristics
Job Complexity
Job Structure Patterns:
Most workflows follow a multi-stage pipeline:
Timeout Configurations
The 10-minute timeout is standard for agent execution, with 15-minute timeouts for workflows needing additional processing time.
Concurrency Patterns
All analyzed workflows use concurrency groups to prevent parallel executions:
Common Patterns:
gh-aw-${{ github.workflow }}- Workflow-level lockinggh-aw-${{ github.workflow }}-${{ github.event.issue.number }}- Issue-specific lockinggh-aw-${{ github.workflow }}-${{ github.event.pull_request.number }}- PR-specific lockingThis ensures that only one instance of an agent workflow runs at a time per context (workflow, issue, or PR).
Permission Patterns
Workflow-Level Permissions
Analysis of
permissions:blocks shows a security-conscious approach:permissions: {}): Used at workflow level in 241 instancespermissions: read-all): Only 2 instances, primarily for agent jobsJob-Level Permissions
Typical permission patterns by job type:
contents: read,issues: readcontents: read,issues: writeread-all(for safe outputs pattern)discussions: writeissues: writeissues: write,pull-requests: writeSecurity Principle: Workflows follow the principle of least privilege, with the agent job having read-all access but no write permissions, while output processing jobs have minimal write permissions only for their specific action.
Tool & MCP Patterns
Most Used MCP Servers
GitHub MCP Dominance: The GitHub MCP server is used in 93.5% of all tool configurations, reflecting these workflows' primary purpose of GitHub-centric automation and analysis.
Tool Usage Patterns
Based on analysis of workflow steps, the most common tool patterns include:
Average Lock File Profile
Based on statistical analysis, a typical .lock.yml file in this repository has:
Interesting Findings
1. Consistent Security Architecture
All workflows follow a remarkably consistent security pattern with the safe outputs architecture, demonstrating a mature approach to agent security. The separation between agent execution (read-only) and action taking (write permissions) is universal.
2. Staggered Schedule Distribution
The unique minute values in cron schedules (e.g.,
47 14,19 9,56 11) suggest intentional load distribution to avoid thundering herd problems when multiple workflows would otherwise trigger simultaneously at round-number times.3. Weekday Business Hours Bias
The overwhelming preference for weekday scheduling (
1-5in cron expressions) and business hour timing indicates these workflows are designed to align with human work patterns, likely for timely notification delivery and responsiveness.4. Job Complexity Distribution
The maximum of 56 steps in a single job and average of 12.8 steps indicates sophisticated multi-step orchestration within individual jobs, not just across jobs.
5. Workflow Dispatch as Standard
With 86% of workflows supporting manual triggering, the repository has embraced on-demand execution as a first-class feature, enabling easy testing, debugging, and ad-hoc runs.
6. Size Consistency
The tight clustering around 50-100 KB suggests standardized workflow templates and patterns, with outliers likely having specialized prompts, additional tool configurations, or extended documentation.
Historical Context
This is the first comprehensive statistical analysis of the repository's lock files. Future analyses will track:
Baseline Metrics (Dec 26, 2025):
Recommendations
1. Documentation of Standard Patterns
With such consistent patterns emerging (safe outputs, concurrency groups, permission models), creating template workflows or documentation could accelerate new workflow development and maintain consistency.
2. Schedule Optimization Review
Review the 86 scheduled workflows to ensure timing still aligns with actual usage patterns. Consider consolidating workflows with similar schedules if they perform related tasks.
3. Size Outlier Investigation
The 19 workflows >100 KB warrant review to determine if they contain duplicated logic, excessive prompts, or if they could benefit from modularization.
4. MCP Server Usage Analysis
With Playwright used in 210 instances, consider dedicated documentation or examples for browser automation patterns. The light usage of arxiv and deepwiki suggests opportunities for broader research-agent capabilities.
5. Timeout Standardization
The split between 10 and 15-minute timeouts could be standardized based on empirical runtime data to optimize cost and reliability.
6. Trigger Combination Patterns
The diversity in trigger combinations (20+ unique patterns) suggests potential for standardization. Common patterns could be documented as reference architectures.
Methodology
.github/workflows/*.lock.yml/tmp/gh-aw/cache-memory/lockfile-stats/Analysis Scripts Preserved
The following scripts have been saved to cache memory for future reuse:
collect_all_data.sh- Bash-based data extractionanalyze_lockfiles.py- Comprehensive Python analysisanalysis_results.json- Structured output dataThese scripts can be reused for future trend analysis and comparison.
References:
/tmp/gh-aw/cache-memory/lockfile-stats/data/analysis_results.json.github/workflows/Beta Was this translation helpful? Give feedback.
All reactions