📊 Lockfile Statistics Analysis - November 16, 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - November 16, 2025

This analysis examines all .lock.yml files in the .github/workflows/ directory to identify usage patterns, structural characteristics, and interesting trends across the repository's agentic workflows.

Executive Summary

The repository contains 82 lock files totaling 17.6 MB, with an average file size of 220.2 KB. The vast majority (74.4%) fall in the 200-300KB range, indicating consistent workflow complexity. All workflows follow a single-job architecture with an average of 58.5 steps per workflow. Scheduled triggers dominate (46%), with most workflows using read-only permissions and the GitHub MCP server (93%).

Full Report Details

File Size Distribution

Overview Statistics

Metric	Value
Total Files	82
Total Size	17.6 MB (18,490,410 bytes)
Average Size	220.2 KB (225,493 bytes)
Median Size	226.0 KB (231,424 bytes)
Smallest File	test-claude-oauth-workflow.lock.yml (76.5 KB)
Largest File	poem-bot.lock.yml (400.6 KB)

Size Distribution by Range

Size Range	Count	Percentage
50-100 KB	11	13.4%
100-200 KB	6	7.3%
200-300 KB	61	74.4%
>300 KB	4	4.9%

Key Finding: The overwhelming majority (74.4%) of lock files are remarkably consistent in size, falling in the 200-300KB range. This suggests standardized workflow complexity across the repository.

Notable Files

Smallest Lock Files (likely test/example workflows):

• test-claude-oauth-workflow.lock.yml - 76.5 KB
• arxiv.lock.yml - 80.2 KB (shared MCP workflow)
• context7.lock.yml - 80.4 KB (shared MCP workflow)

Largest Lock Files (complex/comprehensive workflows):

• poem-bot.lock.yml - 400.6 KB
• cloclo.lock.yml - 330.4 KB
• q.lock.yml - 319.3 KB

---

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Description
schedule	38	46.3%	Cron-based scheduled execution
workflow_dispatch	14	17.1%	Manual trigger capability
issue_comment	7	8.5%	Triggered by issue/PR comments
pull_request	4	4.9%	Triggered by PR events
issues	4	4.9%	Triggered by issue events
discussion	4	4.9%	Triggered by discussion events
workflow_run	2	2.4%	Triggered by other workflow completion
workflow_call	1	1.2%	Reusable workflow
push	1	1.2%	Triggered by push events
discussion_comment	1	1.2%	Triggered by discussion comments

Key Findings:

• Scheduled workflows dominate: Nearly half (46%) of all workflows run on a schedule, indicating heavy use of automated periodic tasks
• Manual control is important: 17% have manual trigger capability via workflow_dispatch
• Interactive workflows: 22% are triggered by user actions (comments, issues, PRs, discussions)

Schedule Patterns

The repository uses 30 unique cron schedules. Top patterns:

Schedule	Frequency	Description
0 0 * * *	Daily	Midnight daily runs
0 0,6,12,18 * * *	4x daily	Every 6 hours
0 9 * * 1-5	Weekdays	9 AM on weekdays
0 10 * * *	Daily	10 AM daily
0 13 * * 1-5	Weekdays	1 PM on weekdays
0 9 * * *	Daily	9 AM daily
0 6 * * 0	Weekly	6 AM on Sundays
0 9 * * 1,3,5	3x weekly	Mon/Wed/Fri at 9 AM
0/10 * * * *	Every 10 min	High-frequency monitoring

Interesting Observations:

• Most schedules align with business hours (9 AM - 6 PM)
• Some workflows run every 6 hours for continuous monitoring
• Weekly Sunday workflows likely for summarization/reporting
• Two workflows use high-frequency 10-minute intervals

---

Permissions Analysis

Most Common Permissions

Permission	Count	Workflows Using
contents	78	95.1%
pull-requests	73	89.0%
issues	69	84.1%
actions	30	36.6%
discussions	6	7.3%
security-events	3	3.7%
repository-projects	1	1.2%

Permission Modes Distribution

Mode	Total Grants	Percentage
read	256	98.5%
write	4	1.5%

Key Findings:

• Security-first approach: 98.5% of all permission grants are read-only
• Minimal write access: Only 4 write permissions across all workflows (likely for specific automation tasks)
• Standard trio: Nearly all workflows need read access to contents, PRs, and issues
• Actions permission: 37% of workflows need actions read permission, likely for workflow run analysis

Security Posture: The overwhelmingly read-only nature (98.5%) demonstrates excellent security hygiene following the principle of least privilege.

---

MCP Server Usage

Server Distribution

MCP Server	Workflows	Percentage	Purpose
github	76	92.7%	GitHub API interactions
playwright	4	4.9%	Browser automation
deepwiki	1	1.2%	Wikipedia/knowledge base
context7	1	1.2%	Context management
arxiv	1	1.2%	Academic paper research

Key Findings:

• GitHub MCP dominance: 93% of workflows use the GitHub MCP server, making it the foundational tool
• Specialized servers: Playwright, deepwiki, arxiv, and context7 are used for specific use cases
• Browser automation: 4 workflows leverage Playwright for web interaction
• Research capability: Workflows can access academic papers (arxiv) and general knowledge (deepwiki)

---

Structural Characteristics

Job Complexity

Metric	Value
Average Jobs per Workflow	1.0
Min Jobs	1
Max Jobs	1

Finding: Every single workflow uses exactly 1 job. This indicates a standardized architecture where each workflow is self-contained in a single job.

Step Complexity

Metric	Value
Average Steps per Workflow	58.5
Min Steps	27
Max Steps	101
Most Complex Workflows	poem-bot (101 steps), cloclo (91 steps)

Key Findings:

• Workflows are step-intensive with an average of 58-59 steps
• The range (27-101) shows significant variation in complexity
• Most complex workflows (>80 steps) are creative/specialized tools

Timeout Configurations

Metric	Value
Average Timeout	12.3 minutes
Most Common	10 minutes (majority)
Min Timeout	5 minutes
Max Timeout	45 minutes

Distribution:

• 5 min: Quick checks and simple tasks
• 10 min: Standard workflow timeout (most common)
• 15-20 min: Medium complexity tasks
• 30-45 min: Complex analysis or multiple operations

---

Concurrency Patterns

Top Concurrency Groups

Pattern	Count	Purpose
gh-aw-copilot-{workflow}	~30	Copilot engine workflows
gh-aw-claude-{workflow}	~25	Claude engine workflows
gh-aw-{workflow}	~20	Generic workflows
gh-aw-{workflow}-{trigger}	~10	Trigger-specific grouping
gh-aw-codex-{workflow}	~3	Codex engine workflows

Key Finding: Concurrency groups are consistently named with gh-aw- prefix and often include the engine type (copilot, claude, codex), ensuring workflows with the same agent don't run concurrently.

---

Workflow Categories

Categorized by filename patterns and purpose:

Category	Count	Examples
Other	38	General-purpose workflows
Code Analysis	15	analyzers, detectors, metrics, checkers
Daily Reports	9	daily-, weekly- summary workflows
Testing	8	test-*, validation workflows
Documentation	6	doc-*, typist, writer workflows
Smoke Tests	4	smoke-claude, smoke-copilot, smoke-codex
Security	2	security-fix-pr, firewall workflows

Interesting Patterns:

• Code quality focus: 15 workflows dedicated to code analysis
• Automated documentation: 6 workflows maintain or generate docs
• Multi-engine testing: Separate smoke tests for Claude, Copilot, and Codex
• Daily automation: 9 workflows run daily reports and summaries

---

Engine Usage Patterns

Based on filename analysis:

Engine	Workflow Count	Detection
Copilot	5	copilot-* filenames
Claude	2	claude-* filenames
Codex	1	codex-* filenames
Ollama	1	ollama-* filenames

Note: This is based on explicit filename mentions. The actual engine usage within workflows may differ as it's configured in the workflow definition.

---

Interesting Findings

1. Remarkably Consistent Architecture

All 82 workflows follow an identical architecture: exactly 1 job per workflow. This standardization simplifies maintenance and debugging.

2. Security-First Design

With 98.5% of permissions being read-only, the workflows demonstrate exemplary security practices. Write permissions are rare and likely carefully justified.

3. Heavy Automation Through Scheduling

46% of workflows run on schedule, with many executing multiple times daily. This suggests the repository heavily leverages automated periodic tasks for maintenance, analysis, and reporting.

4. GitHub MCP is Foundational

93% of workflows use the GitHub MCP server, making it the essential building block for agentic workflows in this repository.

5. Wide Range of Complexity

From simple 27-step workflows to complex 101-step workflows, there's significant variety in workflow complexity, yet file sizes remain relatively consistent (200-300KB).

6. Business Hours Optimization

Schedule patterns show clear alignment with typical business hours (9 AM - 6 PM), with some 24/7 monitoring workflows running every 6 hours.

7. Creative and Specialized Agents

The largest workflow is poem-bot at 400KB, showing that agentic workflows extend beyond traditional CI/CD into creative and specialized domains.

8. Standardized Timeout Strategy

The dominant 10-minute timeout suggests a well-calibrated default that works for most workflows, with extensions only for complex tasks.

---

Average Lock File Profile

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

• Size: ~226 KB
• Jobs: 1 job
• Steps: ~58 steps
• Permissions: Read-only access to contents, pull-requests, and issues
• Trigger: Most likely scheduled (46% chance) or workflow_dispatch (17% chance)
• Timeout: 10 minutes
• MCP Server: GitHub MCP (93% probability)
• Concurrency: Grouped by workflow name with engine prefix

---

Recommendations

1. Maintain Security Posture

The current 98.5% read-only permission ratio is excellent. Continue this pattern for new workflows.

2. Consider Timeout Optimization

With average timeout of 12.3 minutes but most common being 10 minutes, review workflows timing out to see if optimization is possible.

3. Monitor Large Workflows

Workflows >300KB (4 files) may benefit from review for potential modularization, especially poem-bot at 400KB.

4. Standardize Scheduling

With 30 different cron patterns, consider consolidating to common time slots to reduce workflow run collisions.

5. Document MCP Server Usage

With 5 different MCP servers in use, maintain documentation on when to use specialized servers vs. the GitHub MCP default.

---

Methodology

• Analysis Tool: Python 3 scripts with regex parsing and statistical analysis
• Lock Files Analyzed: 82 unique files
• Data Sources: .github/workflows/*.lock.yml and subdirectories
• Cache Memory: Scripts and historical data stored in /tmp/gh-aw/cache-memory/
• Analysis Date: 2025-11-16 03:32 UTC

Scripts Generated

The following reusable analysis scripts were created and stored in cache memory:

1. /tmp/gh-aw/cache-memory/scripts/analyze_lockfiles.sh - Bash-based extraction
2. /tmp/gh-aw/cache-memory/scripts/extract_detailed_stats.py - Python statistical analysis
3. /tmp/gh-aw/cache-memory/data/corrected_stats.json - Complete dataset

These scripts can be reused for future analysis and trend tracking.

---

Generated by Lockfile Statistics Analysis Agent on 2025-11-16 at 03:32 UTC
Analysis covered 82 lock files totaling 17.6 MB across the githubnext/gh-aw repository

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 1 week ago.