📊 Agentic Workflow Lock File Statistics - December 24, 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - 2025-12-24

Executive Summary

• Total Lock Files: 123 workflows (2 excluded from size analysis)
• Total Size: 36.6 MB (38,397,227 bytes)
• Average File Size: 305 KB (312,173 bytes)
• Analysis Date: December 24, 2025
• Repository: githubnext/gh-aw

Overview

This analysis examines 123 .lock.yml files representing compiled agentic workflows in the gh-aw repository. These workflows demonstrate diverse automation patterns including scheduled tasks, issue automation, pull request analysis, and continuous monitoring.

Full Report

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0%
10-50 KB	0	0%
50-100 KB	0	0%
> 100 KB	123	100%

Size Statistics:

• Smallest: example-permissions-warning.lock.yml (129 KB)
• Largest: daily-performance-summary.lock.yml (397 KB)
• Median: 307 KB
• Average: 305 KB

Key Insight: All lock files exceed 100KB, indicating substantial complexity and comprehensive agent configurations. The average workflow contains detailed instructions, multiple jobs, and extensive tool configurations.

Trigger Analysis

Trigger Distribution

Trigger Type	Count	Percentage	Description
issues	123	100%	All workflows respond to issue events
pull_request	120	98%	Nearly all handle PR events
workflow_dispatch	106	86%	Manual trigger capability
schedule	86	70%	Automated time-based execution
issue_comment	14	11%	Comment-triggered workflows
push	2	2%	Push-triggered workflows

Trigger Patterns

Most Common Pattern: Issues + Pull Requests + Workflow Dispatch + Schedule (96 workflows, 78%)

• This combination provides maximum flexibility: automated scheduling, manual triggering, and event-driven responses

Key Findings:

1. Universal Issue Support: 100% of workflows can be triggered by issue events, making issues the primary interaction point
2. High Manual Access: 86% support workflow_dispatch, enabling on-demand execution
3. Extensive Automation: 70% use scheduled triggers for proactive monitoring
4. Multi-Trigger Design: 96 workflows (78%) support multiple trigger types

Schedule Patterns

Total Scheduled Workflows: 86 workflows

Most Common Schedules:

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 only
0 0,6,12,18 * * *	3	Every 6 hours
0 6 * * 0	2	6 AM UTC, Sundays

Insights:

• Weekday Focus: Most schedules run Monday-Friday during business hours
• Distributed Execution: Times are scattered (not all at midnight) to distribute load
• 64 Unique Patterns: High variety indicates customized timing for different workflow purposes
• Hourly to Weekly Range: From every 6 hours to weekly execution

Safe Outputs Analysis

Overview

All workflows in this repository use the safe outputs pattern, which routes agent outputs through structured tools instead of direct API calls. This ensures:

• Consistent output formatting
• Centralized access control
• Audit trails for all agent actions
• Protection against unauthorized modifications

Safe Output Types

Based on the workflow structure analysis, common safe output tools include:

• create_discussion: Creates GitHub discussions (typically in "audits" or "reports" categories)
• create_issue: Creates tracked issues with sub-issue support
• add_comment: Adds comments to issues/PRs
• missing_tool: Reports when required capabilities are unavailable
• noop: Logs completion when no action is needed

Key Finding: The safe_outputs job is present in 116 workflows (94%), with an average of 15-minute timeout and write permissions for discussions, issues, and pull-requests.

Discussion Categories

While specific category usage wasn't fully extracted, workflows commonly use:

• audits: For compliance and analysis reports
• reports: For automated status summaries
• announcements: For important updates
• Q&A: For question-based workflows

Structural Characteristics

Job Complexity

• Average Jobs per Workflow: 8.07 jobs
• Maximum Jobs: 14 jobs
• Average Steps per Job: 9.75 steps
• Average Total Steps: 78.6 steps per workflow
• Maximum Steps in Single Workflow: 113 steps

Standard Workflow Structure:
Most workflows follow a 5-phase pattern:

1. pre_activation (1 job): Initial setup and validation
2. activation (1 job): Checkout and timestamp checks
3. agent (1 job): Main AI agent execution
4. detection (1 job): Success/failure detection
5. safe_outputs (1 job): Structured output handling
6. conclusion (1 job): Cleanup and status reporting
7. update_cache_memory (1-2 jobs): Persist agent memory

Additional jobs may include upload_assets, push_repo_memory, etc.

Typical Lock File Characteristics

Based on statistical analysis, a representative .lock.yml file:

• Size: ~305 KB
• Jobs: ~8 jobs with 5-7 core jobs + optional jobs
• Steps: ~79 total steps (~10 steps per job)
• Permissions: Read for most resources, write for discussions/issues/PRs in safe_outputs job
• Triggers: Issues + Pull Requests + Workflow Dispatch + Schedule (most common)
• Timeout: 10-20 minutes per job (default: 10-15 minutes)
• Concurrency: Enabled with workflow-specific group

Engine Distribution

Analysis of engine usage across workflows:

Engine Type	Count	Percentage
GitHub Copilot CLI	81	66%
Claude (Anthropic)	31	25%
Other/Codex	11	9%

Key Insights:

• Copilot Dominance: Two-thirds of workflows use GitHub Copilot CLI as the AI engine
• Claude Adoption: One-quarter use Claude (likely via Anthropic API)
• Engine Flexibility: The framework supports multiple engines, allowing teams to choose based on capabilities and cost

Permission Patterns

Most Common Permissions

Permission	Occurrences	Type	Typical Usage
contents: read	451	Read	Code checkout and file access
issues: write	226	Write	Issue creation/modification
discussions: write	223	Write	Discussion creation/updates
pull-requests: write	202	Write	PR comments and reviews
issues: read	112	Read	Issue querying and analysis
pull-requests: read	108	Read	PR inspection
contents: write	68	Write	Code modifications
actions: read	50	Read	Workflow run inspection
discussions: read	14	Read	Discussion querying

Permission Strategy

Principle of Least Privilege: Workflows follow a tiered permission model:

1. Workflow Level: permissions: {} (empty, deny all by default)
2. Job Level: Each job requests only needed permissions
3. Agent Job: Read-only permissions (contents, issues, PRs, discussions)
4. Safe Outputs Job: Write permissions (issues, discussions, PRs) for output creation
5. Conclusion Job: Minimal permissions for status reporting

Security Insight: This approach limits the blast radius if an agent is compromised. The agent cannot directly write to GitHub resources; all writes go through the controlled safe_outputs job.

Tool & MCP Server Analysis

MCP Server Usage

MCP Server	Workflows	Percentage	Purpose
github	122	99%	GitHub API operations
playwright	122	99%	Browser automation (likely unused/placeholder)
serena	122	99%	Safe outputs framework
arxiv	1	<1%	Academic paper search
deepwiki	1	<1%	Wikipedia deep search

Key Findings:

• Universal Base: Nearly all workflows use github, playwright, and serena MCPs
• Specialized Usage: Custom MCPs (arxiv, deepwiki) appear in specific workflows
• Extensibility: The framework supports adding custom MCP servers for specialized capabilities

Common Tool Configurations

Based on workflow structure:

• Bash tools: Available in all workflows for system commands
• GitHub API tools: Via mcp__github__* for repository operations
• Web tools: WebSearch and WebFetch in many workflows
• Safe output tools: mcp__safeoutputs__* for structured outputs

Timeout Analysis

Timeout Distribution

Timeout (minutes)	Occurrences	Workflows
10	163	Most common default
15	138	Extended timeout for complex tasks
20	131	Long-running operations
30	15	Very complex workflows
5	14	Quick validation tasks
45	7	Intensive processing
60	5	Maximum allowed for some jobs
480	1	8-hour timeout (special case)

Statistics:

• Average Timeout: 16.7 minutes
• Median Timeout: 15 minutes
• Range: 5 minutes to 8 hours

Insight: The 10-15 minute timeout is optimized for typical AI agent interactions, while longer timeouts accommodate deep analysis or large-scale operations.

Concurrency Management

• Workflows with Concurrency Control: 123 (100%)
• Most Common Pattern: group: "gh-aw-${{ github.workflow }}"

Concurrency Strategies:

1. Workflow-level: gh-aw-${{ github.workflow }} - One run per workflow type
2. Issue-specific: gh-aw-${{ github.workflow }}-${{ github.event.issue.number }} - Per-issue concurrency
3. PR-specific: gh-aw-${{ github.workflow }}-${{ github.event.pull_request.number }} - Per-PR concurrency

Benefit: Prevents concurrent runs from interfering with each other while allowing parallel execution across different issues/PRs.

Interesting Findings

1. Massive Standardization

All 123 workflows follow nearly identical structural patterns:

• Same job names (pre_activation, agent, detection, safe_outputs, conclusion)
• Consistent permission model
• Universal concurrency control
• This indicates strong framework governance and makes workflows predictable

2. The Safe Outputs Innovation

The safe_outputs job pattern is a unique architectural choice:

• Separates agent execution (read-only) from GitHub modifications (write)
• Creates an audit checkpoint for all agent actions
• Enables centralized output validation and formatting
• Reduces security risk by limiting agent permissions

3. Size Consistency Despite Variety

Despite 64 unique cron schedules and varied purposes, all files are 100KB+:

• Average deviation of only ~90KB from mean
• Suggests consistent level of agent instructions and tool configurations
• Indicates workflows are comprehensive rather than minimal

4. Multi-Modal Triggering

78% of workflows support 4+ trigger types:

• Enables workflows to be scheduled, manual, or event-driven
• Provides flexibility for different usage patterns
• Single workflow definition serves multiple use cases

5. Engine Diversity

The 66/25/9 split (Copilot/Claude/Other) shows:

• Framework is genuinely engine-agnostic
• Teams can choose engines based on task requirements
• No vendor lock-in for AI capabilities

6. Distributed Scheduling

86 scheduled workflows use 64 unique cron patterns:

• Deliberately scattered timing (not all at midnight)
• Reduces GitHub Actions load spikes
• Indicates thoughtful resource management

Historical Trends

First analysis run - no historical data available yet

Future runs will compare:

• Growth in lock file count
• Changes in average file size
• Evolution of trigger patterns
• New MCP servers or tool types

Recommendations

Based on this analysis:

1. Optimize Large Workflows

The top 10% of workflows (>350KB) may benefit from:

• Reviewing for redundant instructions
• Extracting common patterns to shared imports
• Simplifying complex conditionals

2. Standardize Timeouts

With 10-15 minutes being most common, consider:

• Documenting standard timeout guidelines
• Investigating workflows with 480-minute timeouts
• Setting reasonable defaults in the framework

3. Monitor Schedule Distribution

The 5 workflows on 0 14 * * 1-5 could be:

• Staggered by a few minutes to reduce concurrent load
• Combined if they perform related tasks
• Left as-is if simultaneous execution is desired

4. Document Safe Output Patterns

Given the universal adoption of safe outputs:

• Create best practices guide for new workflow authors
• Document common output patterns and when to use each
• Provide examples of combining multiple safe output types

5. Track Engine Performance

With 2 primary engines, consider:

• Comparative performance metrics (latency, quality, cost)
• Task-specific engine recommendations
• Migration guides between engines

6. Leverage MCP Extensibility

Only 2 custom MCPs (arxiv, deepwiki) are in use:

• Document the process for adding custom MCPs
• Identify other useful data sources (Jira, Slack, etc.)
• Create a library of community MCP servers

Methodology

Data Collection

• Analysis Tool: Bash scripts with text processing (awk, grep, sed)
• Python Analysis: Statistical aggregation using pandas-like Counter objects
• Lock Files Analyzed: 123 of 125 found (2 in shared/mcp/ excluded from some stats)

Data Sources

• Primary: .github/workflows/*.lock.yml files
• Validation: Manual inspection of sample workflows
• Caching: Scripts and data persisted to /tmp/gh-aw/cache-memory/

Limitations

• Safe output tool types not fully extracted (need deeper YAML parsing)
• Discussion categories incomplete (need structured YAML parsing)
• Engine detection based on installation steps (heuristic, not declarative)
• Some workflows in shared/mcp/ may have different patterns

Future Improvements

1. Implement full YAML parsing for accurate safe output extraction
2. Track changes over time with historical comparison
3. Add workflow execution metrics (success rate, duration, cost)
4. Correlate workflow characteristics with performance outcomes

---

References:

• §20488593493

AI generated by Lockfile Statistics Analysis Agent

[github-actions[bot]]

This discussion was automatically closed because it was created by an agentic workflow more than 3 days ago.