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

[github-actions[bot]]

This comprehensive analysis examines 125 lock files (.lock.yml) in the .github/workflows/ directory of the githubnext/gh-aw repository. These lock files represent agentic workflows that leverage AI agents (Claude, Copilot, Codex) to automate repository tasks.

Key Findings:

• Total Lock Files: 125 workflows
• Total Size: 47.60 MB (49,916,701 bytes)
• Average File Size: 389.97 KB
• Average Steps per Workflow: 76 steps
• Most Common Trigger: 98% of workflows support both workflow_dispatch and pull_request
• Primary MCP Servers: GitHub (124), Serena (122), Playwright (122)

Full Report

File Size Distribution

The lock files are substantial, reflecting the comprehensive agent instructions and tool configurations embedded in each workflow.

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

Statistics:

• Smallest: arxiv.lock.yml (80.2 KB) - MCP server configuration
• Largest: poem-bot.lock.yml (689.2 KB) - Contains 107 steps
• Average Size: 389.97 KB
• Total Size: 47.60 MB

Size Insights

Nearly all lock files exceed 100 KB, indicating that agentic workflows contain:

• Detailed agent instructions and system prompts
• Comprehensive tool configurations
• Extensive MCP server integrations
• Security guidelines and safety constraints

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Description
workflow_dispatch	123	98.4%	Manual trigger capability
pull_request	123	98.4%	PR events (opened, synchronize, etc.)
schedule	85	68.0%	Cron-based scheduled runs
issues	13	10.4%	Issue events
issue_comment	~10	8.0%	Comment-based triggers

Key Observations

• Near-Universal Manual Trigger: 98.4% of workflows support workflow_dispatch, enabling on-demand execution
• PR-Centric: 98.4% respond to pull request events, highlighting the repository's focus on PR automation
• Scheduled Automation: 68% run on schedules for periodic tasks like audits, reports, and maintenance

Common Trigger Combinations

The most common pattern combines:

• schedule (cron-based)
• issues
• issue_comment
• pull_request

This combination enables workflows that:

1. Run periodically on a schedule
2. React to new issues
3. Respond to issue comments
4. Process pull requests

Schedule Patterns

Schedule Type	Count	Description	Example
Weekday mornings (9-16 UTC)	15	Business hours automation	0 14 * * 1-5 (2 PM Mon-Fri)
Multiple times daily	7	Frequent monitoring	0 0,6,12,18 * * * (Every 6 hours)
Monday morning	5	Week-start tasks	0 9 * * 1
Sunday/weekend	3	Off-hours processing	0 6 * * 0
Every 10 minutes	2	High-frequency checks	0/10 * * * *
Hourly	1	Continuous monitoring	0 * * * *

Most Common Schedules:

• 0 14 * * 1-5 (2 PM weekdays) - 5 workflows
• 0 13 * * 1-5 (1 PM weekdays) - 4 workflows
• 0 11 * * 1-5 (11 AM weekdays) - 4 workflows

The repository favors weekday business hours (9 AM - 4 PM UTC) for scheduled tasks, suggesting these workflows perform maintenance, reporting, and monitoring during active development periods.

Safe Outputs Analysis

Agentic workflows use "safe outputs" - GitHub API tools that allow agents to create discussions, issues, comments, and PRs without direct repository write access.

Safe Output Pattern

All workflows in this repository follow a consistent safe output pattern:

• No direct safe output declarations found in the lock files
• Instead, workflows rely on MCP server tools (mcp__safeoutputs__*) available to agents
• Agents can call these tools at runtime based on their instructions

Available Safe Output Types

Based on the codebase structure, workflows have access to:

• create-discussion - Create GitHub discussions
• create-issue - Create GitHub issues
• add-comment - Add comments to issues/PRs
• create-pull-request - Create PRs
• create-pull-request-review-comment - Add PR review comments
• update-issue - Update existing issues
• noop - Log completion with no action
• missing_tool - Report missing capabilities

Discussion Categories

When creating discussions, workflows commonly target:

• audits (58 references) - Security and workflow audits
• general - General discussions
• announcements - Announcements

The "audits" category is the most popular, reflecting the repository's focus on automated security scanning, compliance checks, and workflow analysis.

Structural Characteristics

Job Complexity

• Average Steps per Workflow: 76.28 steps
• Maximum Steps: 113 steps (daily-file-diet.lock.yml)
• Top 5 Most Complex Workflows:
  1. daily-file-diet.lock.yml - 113 steps
  2. poem-bot.lock.yml - 107 steps
  3. deep-report.lock.yml - 105 steps
  4. daily-firewall-report.lock.yml - 101 steps
  5. intelligence.lock.yml - 100 steps

Job Structure

The analysis shows 0 average jobs per workflow in the parsed data, suggesting:

• Lock files may use a flat structure or single-job design
• Job counting logic may need refinement (jobs section might not follow ^ [a-z_-]*:$ pattern)

Typical Lock File Profile

Based on statistical analysis, a typical .lock.yml file has:

• Size: ~390 KB
• Steps: ~76 steps
• Triggers: workflow_dispatch + pull_request + optional schedule
• Permissions: Mix of read/write (see Permissions section)
• Timeout: 10-20 minutes
• MCP Servers: GitHub, Serena, Playwright

Permission Patterns

Workflows request specific GitHub API permissions following the principle of least privilege.

Permission Distribution

Permission Type	Count	Percentage
Read permissions	751	50.5%
Write permissions	734	49.4%
Read-all	2	0.1%

The nearly even split between read and write (50.5% vs 49.4%) indicates:

• Workflows require balanced access for both reading data and creating outputs
• Agents need write permissions for creating discussions, issues, and comments
• Security-conscious design: no workflows request blanket write access

Workflows with Most Permissions

Top 5 workflows by permission count:

1. unbloat-docs.lock.yml - 4 permissions
2. tidy.lock.yml - 4 permissions
3. smoke-detector.lock.yml - 4 permissions
4. smoke-copilot.lock.yml - 4 permissions
5. smoke-copilot-safe-inputs.lock.yml - 4 permissions

These workflows likely handle complex operations requiring multiple API interactions.

Tool & MCP Server Patterns

Most Used MCP Servers

MCP Server	Workflows	Percentage	Purpose
GitHub	124	99.2%	GitHub API operations
Serena	122	97.6%	(Internal tool)
Playwright	122	97.6%	Browser automation
deepwiki	1	0.8%	Wiki/documentation
arxiv	1	0.8%	Academic paper research

GitHub MCP Server - API Usage

The GitHub MCP server provides 53 unique API functions. Most popular:

Function	Usage Pattern	Purpose
search_* functions	Search users, repos, PRs, issues, code, orgs	Discovery and research
list_* functions	List workflows, runs, artifacts, jobs, tags, releases	Enumerate resources
pull_request_read	Read PR details, diffs, comments, reviews	PR analysis
Workflow operations	List/get workflows, runs, artifacts, jobs	CI/CD monitoring

Key Insight: Each function appears ~62 times, suggesting standardized agent configurations across workflows with a common set of available GitHub API tools.

Playwright MCP Server

Provides 10+ browser automation functions:

• browser_wait_for - Wait for elements
• browser_type - Type text
• browser_take_screenshot - Capture screenshots
• browser_tabs - Tab management
• browser_snapshot - DOM snapshots
• browser_select_option - Form interactions
• browser_resize - Viewport control
• browser_press_key - Keyboard input
• browser_network_requests - Network monitoring

97.6% of workflows have browser automation capability, enabling agents to:

• Test web interfaces
• Capture visual regression data
• Interact with documentation sites
• Verify deployed applications

Timeout & Execution Patterns

Timeout Configuration

Timeout (minutes)	Workflows	Percentage	Use Case
10 minutes	164	31.4%	Quick tasks
15 minutes	139	26.6%	Standard operations
20 minutes	132	25.3%	Complex analysis
30 minutes	15	2.9%	Deep investigations
5 minutes	14	2.7%	Fast checks
45 minutes	7	1.3%	Extensive processing
60 minutes	5	1.0%	Long-running tasks
480 minutes (8 hours)	1	0.2%	Special case

Average Timeout: 16 minutes

Key Findings:

• 83% of timeouts are between 10-20 minutes, indicating most workflows complete within this window
• Only 6 workflows require 60+ minutes, suggesting efficient agent operations
• One outlier at 480 minutes (8 hours) likely handles batch processing or extensive analysis

Concurrency Management

• 123 workflows (98.4%) implement concurrency groups
• Prevents resource conflicts when workflows trigger simultaneously
• Ensures orderly execution on shared resources

Engine & Model Information

Model References

Workflows reference AI models dynamically:

• ${{ steps.generate_aw_info.outputs.model }} - 123 workflows (runtime selection)
• Environment-based selection pattern:
  • GH_AW_MODEL_AGENT_COPILOT - Copilot model selection
  • GH_AW_MODEL_AGENT_CLAUDE - Claude model selection
  • GH_AW_MODEL_AGENT_CODEX - Codex model selection

Default Models Observed:

• gpt-5 - 35 references
• gpt-4o-mini - 2 references

Multi-Engine Architecture

The repository supports multiple AI engines:

1. GitHub Copilot - Primary agent for many workflows
2. Claude (Anthropic) - Alternative agent option
3. Codex (OpenAI) - Legacy/specialized tasks

This multi-engine approach provides:

• Flexibility to choose the best model for each task
• Redundancy if one service is unavailable
• Cost optimization based on task complexity

Interesting Findings

1. Standardization at Scale

All 125 workflows follow remarkably consistent patterns:

• Nearly identical MCP server configurations
• Uniform trigger combinations (98% use workflow_dispatch + pull_request)
• Standardized timeout ranges (10-20 minutes)
• Consistent permission models

This suggests:

• Template-based workflow generation or shared base configuration
• Strong governance and best practices enforcement
• Easy maintenance and updates across the entire workflow suite

2. Comprehensive GitHub API Coverage

With 53 unique GitHub API functions available, agents can:

• Search across all GitHub resources (code, issues, PRs, repos, users, orgs)
• Read detailed information (commits, workflows, releases, tags)
• Monitor CI/CD pipelines (workflow runs, jobs, artifacts)
• Analyze security (secret scanning, code scanning)

This extensive API access enables sophisticated automation scenarios.

3. Browser Automation is Standard

97.6% of workflows include Playwright, indicating:

• Visual testing and UI validation are core requirements
• Agents verify deployed applications and documentation
• Screenshots and DOM snapshots support agent decision-making
• Web scraping and data extraction are common tasks

4. Business Hours Bias

Scheduled workflows strongly prefer weekday business hours (9 AM - 4 PM UTC):

• Reflects active development periods
• Ensures timely notifications during work hours
• Avoids off-hours noise for team members
• Aligns with European/US morning schedules

5. Size Consistency Despite Complexity Variation

Despite 76-step average with outliers at 113 steps, all files stay in 80-690 KB range:

• Efficient YAML structure
• Compressed agent instructions
• Shared configuration references
• Minimal redundancy

6. Concurrency is Critical

98.4% of workflows use concurrency groups, preventing:

• Race conditions on shared resources
• Duplicate work on rapid triggers
• Resource exhaustion
• Conflicting simultaneous updates

Example Workflows by Category

Issue-Triggered Workflows (10.4%)

• ai-moderator.lock.yml - Content moderation
• archie.lock.yml - Archive management
• campaign-generator.lock.yml - Campaign creation
• cloclo.lock.yml - Code analysis
• craft.lock.yml - Artifact generation

Scheduled Audit/Report Workflows

• agent-performance-analyzer.lock.yml - Performance metrics
• artifacts-summary.lock.yml - Artifact reports
• audit-workflows.lock.yml - Workflow compliance
• blog-auditor.lock.yml - Blog content checking
• breaking-change-checker.lock.yml - API compatibility

High-Complexity Workflows (100+ steps)

• daily-file-diet.lock.yml - 113 steps - File cleanup automation
• poem-bot.lock.yml - 107 steps - Creative content generation
• deep-report.lock.yml - 105 steps - Comprehensive analysis
• daily-firewall-report.lock.yml - 101 steps - Security scanning
• intelligence.lock.yml - 100 steps - Data aggregation

Recommendations

1. Optimize Large Workflows

The top 5 workflows with 100+ steps may benefit from:

• Breaking into smaller, composable workflows
• Using reusable workflow calls
• Caching intermediate results
• Parallel execution where possible

Benefit: Faster execution, easier debugging, better maintainability.

2. Standardize Timeout Values

With 83% of workflows using 10-20 minute timeouts:

• Consider establishing 15 minutes as the standard
• Document when 30+ minutes is justified
• Set organization-wide policies for timeout limits

Benefit: Predictable resource usage, faster failure detection.

3. Document Schedule Rationale

85 workflows run on schedules with varying frequencies:

• Create a schedule registry documenting why each cron pattern was chosen
• Identify opportunities to consolidate similar schedules
• Balance load across the day to avoid peak congestion

Benefit: Prevent resource spikes, improve scheduling efficiency.

4. Monitor Permission Creep

With 734 write permissions granted:

• Regularly audit which workflows actually use write permissions
• Downgrade to read-only where possible
• Implement permission request justification process

Benefit: Reduced security risk, better compliance.

5. Leverage Template Patterns

The high consistency across workflows suggests:

• Document the template/generator used
• Provide examples for common workflow patterns
• Automate workflow creation from templates

Benefit: Faster workflow development, fewer errors, easier updates.

6. Establish Size Budgets

With an average of 390 KB per lock file:

• Set a target maximum size (e.g., 500 KB)
• Implement compression for large instruction sets
• Use external reference files for bulky content

Benefit: Faster loading, better version control diffs, easier reviews.

7. Create Workflow Health Dashboard

Based on the collected statistics:

• Track workflow execution times vs. timeouts
• Monitor success/failure rates by workflow category
• Alert on anomalies (unusually long runs, high failure rates)

Benefit: Proactive issue detection, data-driven optimization.

Historical Trends

This is the baseline analysis for the githubnext/gh-aw repository. Future runs will track:

• Growth in lock file count
• Average size trends
• New trigger patterns
• Permission evolution
• MCP server adoption
• Timeout adjustments

Data saved to: /tmp/gh-aw/cache-memory/history/2025-12-23.json

Methodology

Data Collection

• Tool: Bash scripts with text processing (grep, awk, sed)
• Coverage: All 125 .lock.yml files in .github/workflows/
• Extraction: YAML parsing via pattern matching
• Storage: Results cached in /tmp/gh-aw/cache-memory/data/

Analysis Scripts Created

1. analyze_lockfiles.sh - Main data extraction
2. generate_stats.sh - Statistical calculations
3. detailed_analysis.sh - Pattern analysis
4. find_examples.sh - Example discovery
5. github_api_analysis.sh - API usage tracking

Validation

• Cross-referenced multiple data sources
• Verified counts with manual spot checks
• Compared file parsing results with direct inspection

Reproducibility

All scripts saved to /tmp/gh-aw/cache-memory/scripts/ for future analysis runs.

---

Analysis performed: 2025-12-23
Repository: githubnext/gh-aw
Lock files analyzed: 125
Scripts stored: /tmp/gh-aw/cache-memory/scripts/
Data cached: /tmp/gh-aw/cache-memory/data/

References:

• Workflow run: §20463925588

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.