📊 Agentic Workflow Lock File Statistics - 2026-02-10

[github-actions[bot]]

Executive Summary

This comprehensive analysis examines all 148 lock files (.lock.yml) in the .github/workflows/ directory, revealing the structural patterns, automation strategies, and safe output configurations that power this repository's agentic workflows.

Key Highlights:

• Total Lock Files: 148 workflows
• Total Size: 8.58 MB (average: 59.4 KB per workflow)
• Total Workflow Steps: ~11,015 steps across all workflows
• Automation Rate: 71.6% scheduled, 88.5% with manual triggers
• Safe Output Usage: 95.3% of workflows use safe outputs (141/148)
• MCP Integration: 23.6% of workflows use MCP servers
• Analysis Date: February 10, 2026

Quick Stats

Metric	Value
Average Jobs per Workflow	6.0
Average Steps per Workflow	74.4
Most Complex Workflow	daily-copilot-token-report (103 steps)
Smallest Workflow	codex-github-remote-mcp-test (33 steps)
Concurrency Control	98.6% use concurrency groups
Average Timeout	20 minutes

---

File Size Distribution

The majority of lock files cluster in the 50-70KB range, representing a standardized workflow structure with consistent feature sets.

Size Range	Count	Percentage	Description
< 30 KB	6	4.1%	Minimal test workflows
30-50 KB	3	2.0%	Basic workflows
50-70 KB	119	80.4%	Standard workflows (majority)
70-90 KB	17	11.5%	Feature-rich workflows
> 90 KB	3	2.0%	Comprehensive smoke tests

Size Statistics:

• Smallest: codex-github-remote-mcp-test.lock.yml (23.4 KB)
• Largest: smoke-claude.lock.yml (100.1 KB)
• Average: 59.4 KB
• Total Repository Size: 8.58 MB

View Top 10 Largest Workflows

1. smoke-claude.lock.yml - 100.1 KB (103 steps)
2. poem-bot.lock.yml - 95.4 KB (93 steps)
3. smoke-copilot.lock.yml - 95.1 KB (90 steps)
4. smoke-opencode.lock.yml - 83.2 KB (87 steps)
5. daily-performance-summary.lock.yml - 83.0 KB (93 steps)
6. mcp-inspector.lock.yml - 81.0 KB (87 steps)
7. cloclo.lock.yml - 80.9 KB (88 steps)
8. smoke-project.lock.yml - 79.0 KB (88 steps)
9. unbloat-docs.lock.yml - 78.8 KB (95 steps)
10. copilot-session-insights.lock.yml - 77.6 KB (88 steps)

---

Trigger Analysis

Most Popular Triggers

Agentic workflows in this repository favor automation and flexibility, with the vast majority supporting both scheduled execution and manual invocation.

Trigger Type	Count	Percentage	Use Case
workflow_dispatch	131	88.5%	Manual execution capability
schedule	106	71.6%	Automated periodic runs
pull_request	14	9.5%	PR-triggered analysis
issue_comment	14	9.5%	Comment-triggered actions
issues	13	8.8%	Issue-triggered workflows
pull_request_review_comment	6	4.1%	Review comment responses
discussion_comment	5	3.4%	Discussion interactions
discussion	4	2.7%	Discussion-triggered
workflow_run	2	1.4%	Chained workflow execution
push	1	0.7%	Push-triggered (rare)

Common Trigger Combinations

Most workflows combine multiple triggers for maximum flexibility:

Combination	Count	Use Pattern
schedule + workflow_dispatch	97	65.5% - Scheduled with manual override
workflow_dispatch only	19	12.8% - Manual-only execution
pull_request + schedule + workflow_dispatch	6	4.1% - PR analysis with scheduling
issues only	4	2.7% - Pure issue responders
Multi-event (all triggers)	3	2.0% - Universal responders

Insight: The dominant pattern (schedule + workflow_dispatch) enables automated daily/hourly operations while preserving the ability to trigger on-demand for testing or immediate needs.

Schedule Patterns

View Schedule Distribution (Cron Patterns)

Most workflows run during business hours on weekdays (Monday-Friday), with peak scheduling at midday UTC:

Schedule (Cron)	Count	Time (UTC)	Description
0 13 * * 1-5	4	1:00 PM Mon-Fri	Early afternoon peak
0 14 * * 1-5	4	2:00 PM Mon-Fri	Afternoon peak
0 11 * * 1-5	4	11:00 AM Mon-Fri	Late morning peak
0 9 * * 1-5	3	9:00 AM Mon-Fri	Morning start
0 10 * * 1-5	2	10:00 AM Mon-Fri	Mid-morning
0 15 * * 1-5	2	3:00 PM Mon-Fri	Mid-afternoon
0 16 * * 1-5	2	4:00 PM Mon-Fri	Late afternoon
0 7 * * 1-5	2	7:00 AM Mon-Fri	Early morning
Others (various)	83	Various	Custom schedules

Pattern: Workflows are deliberately scheduled throughout business hours to distribute load and provide regular, continuous monitoring and maintenance.

---

Safe Outputs Analysis

Safe outputs are the primary mechanism for workflows to produce visible results. Nearly all workflows (95.3%) use at least one safe output type, with many using multiple output methods.

Safe Output Types Distribution

Safe Output Type	Count	Workflows Using	Primary Use Case
noop	141	141 (95.3%)	Transparency logging
create_discussion	58	58 (39.2%)	Audit reports & insights
create_issue	40	40 (27.0%)	Action items & bugs
add_comment	34	34 (23.0%)	Contextual feedback
create_pull_request	25	25 (16.9%)	Automated fixes
upload_asset	22	22 (14.9%)	Data artifacts
add_labels	13	13 (8.8%)	Classification
close_discussion	6	6 (4.1%)	Cleanup operations
push_to_pull_request_branch	5	5 (3.4%)	PR updates
update_issue	5	5 (3.4%)	Issue maintenance
create_project_status_update	4	4 (2.7%)	Project tracking
update_project	4	4 (2.7%)	Project management
create_pull_request_review_comment	4	4 (2.7%)	Code review feedback
create_missing_tool_issue	4	4 (2.7%)	Tool gap reporting
Others (18 types)	25	Various	Specialized operations

Total Safe Output Types: 30 distinct safe output types configured across all workflows

Safe Output Patterns

View Safe Output Combination Patterns

All 141 workflows with safe outputs use multiple output types, demonstrating sophisticated output strategies:

Common Patterns:

1. Audit Workflow Pattern: noop + create_discussion + upload_asset

   • Used by: Analysis and reporting workflows
   • Purpose: Generate comprehensive reports with data artifacts

2. Issue Management Pattern: noop + create_issue + add_comment + add_labels

   • Used by: Quality assurance and monitoring workflows
   • Purpose: Track problems and provide context

3. PR Automation Pattern: noop + create_pull_request + push_to_pull_request_branch

   • Used by: Code maintenance and refactoring workflows
   • Purpose: Automated code improvements

4. Interactive Pattern: noop + add_comment + add_labels + remove_labels

   • Used by: PR/issue triage and response workflows
   • Purpose: Real-time interaction with developers

Discussion Categories

Discussion safe outputs don't specify categories in the config (allowing dynamic category selection), showing flexibility in report organization.

---

Structural Characteristics

Job Complexity

Workflows in this repository follow a consistent multi-job architecture for modularity and parallel execution:

Metric	Value	Context
Average Jobs per Workflow	6.0	Typical 6-stage pipeline
Total Jobs Across All Workflows	885 jobs	High parallelization
Maximum Jobs	9 jobs	firewall-escape.lock.yml
Typical Job Count	5-7 jobs	Standard architecture

Step Complexity

Metric	Value	Workflow
Average Steps per Workflow	74.4 steps	Comprehensive execution
Maximum Steps	103 steps	daily-copilot-token-report.lock.yml
Minimum Steps	33 steps	codex-github-remote-mcp-test.lock.yml
Total Steps Repository-Wide	~11,015 steps	Extensive automation

View Top 10 Most Complex Workflows (By Steps)

1. daily-copilot-token-report.lock.yml - 103 steps

   • Purpose: Comprehensive Copilot usage analysis

2. deep-report.lock.yml - 98 steps

   • Purpose: Deep analytical reporting

3. audit-workflows.lock.yml - 98 steps

   • Purpose: Workflow compliance auditing

4. copilot-pr-nlp-analysis.lock.yml - 95 steps

   • Purpose: Natural language processing analysis

5. unbloat-docs.lock.yml - 95 steps

   • Purpose: Documentation optimization

6. daily-performance-summary.lock.yml - 93 steps

   • Purpose: Performance metrics aggregation

7. poem-bot.lock.yml - 93 steps

   • Purpose: Creative content generation

8. prompt-clustering-analysis.lock.yml - 92 steps

   • Purpose: Prompt pattern analysis

9. smoke-copilot.lock.yml - 90 steps

   • Purpose: Copilot smoke testing

10. cloclo.lock.yml - 88 steps

    • Purpose: Code metrics and analysis

View Top 5 Simplest Workflows (By Steps)

These are minimal test workflows used for validation and debugging:

1. codex-github-remote-mcp-test.lock.yml - 33 steps
2. firewall.lock.yml - 33 steps
3. test-workflow.lock.yml - 33 steps
4. example-permissions-warning.lock.yml - 33 steps
5. chroma-issue-indexer.lock.yml - 35 steps

Average Lock File Structure

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

• Size: ~59.4 KB
• Jobs: ~6 jobs
• Steps per Workflow: ~74 steps
• Triggers: schedule (71.6%) + workflow_dispatch (88.5%)
• Timeout: 20 minutes (most common)
• Safe Outputs: 2-4 different output types including noop
• Concurrency Group: gh-aw-${{ github.workflow }} (79.1%)

---

Permission Patterns

Permission Configuration

Interestingly, zero workflows explicitly declare permissions in the top-level YAML structure. This suggests:

1. Default Permissions: Workflows inherit default repository permissions
2. Runtime Permission Management: Permissions may be managed at the organization or repository level
3. Simplified Configuration: Lock files focus on workflow logic rather than security configuration

Security Note: While no explicit permissions are declared in lock files, the workflows operate within GitHub Actions' permission model and benefit from repository-level permission controls.

---

Tool & MCP Patterns

MCP Server Usage

Only 23.6% of workflows use Model Context Protocol (MCP) servers, indicating most workflows use standard GitHub Actions capabilities:

MCP Server	Usage Count	Workflows	Primary Purpose
github	35	23.6%	GitHub API operations
playwright	5	3.4%	Browser automation
deepwiki	1	0.7%	Wiki/documentation access
arxiv	1	0.7%	Academic paper research

Insight: The GitHub MCP server dominates MCP usage, enabling advanced GitHub operations beyond standard Actions. Specialized MCPs (Playwright, DeepWiki, ArXiv) serve niche automation needs.

Tool Configuration Patterns

View Common Tool Patterns

Based on workflow analysis, common tool usage patterns include:

1. Standard GitHub Actions Tools:

   • Bash/shell commands for scripting
   • Git operations for version control
   • GitHub CLI for API interactions

2. Safe Outputs Tools (95.3% of workflows):

   • noop for transparency logging
   • create_discussion for reports
   • create_issue for tracking
   • add_comment for feedback

3. MCP Server Tools (23.6% of workflows):

   • GitHub MCP for advanced API operations
   • Specialized MCPs for domain-specific tasks

4. Custom Scripts:

   • Python for data analysis
   • Shell scripts for automation
   • Analysis tools stored in cache memory

---

Timeout & Concurrency Patterns

Timeout Configuration

Nearly all workflows (99.3%) specify explicit timeouts, with a clear preference for moderate execution windows:

Timeout (minutes)	Count	Percentage	Use Case
20 minutes	34	23.1%	Standard workflows
10 minutes	32	21.8%	Quick checks
30 minutes	29	19.7%	Complex analysis
15 minutes	25	17.0%	Moderate tasks
45 minutes	12	8.2%	Deep analysis
5 minutes	10	6.8%	Minimal tests
60 minutes	3	2.0%	Comprehensive tests
90+ minutes	2	1.4%	Smoke tests

Average Timeout: ~20 minutes
Median Timeout: 20 minutes

Pattern: Timeout distribution follows workflow complexity - simple test workflows use 5-10 minutes, standard workflows use 15-20 minutes, and comprehensive analysis workflows use 30-45 minutes.

Concurrency Groups

An overwhelming 98.6% of workflows use concurrency groups to prevent resource conflicts:

Concurrency Pattern	Count	Percentage	Behavior
gh-aw-${{ github.workflow }}	117	79.1%	One run per workflow type
gh-aw-${{ github.workflow }}-${{ github.event.issue.number || github.event.pull_request.number }}	13	8.8%	Per-item concurrency
gh-aw-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}	9	6.1%	Per-PR/branch concurrency
gh-aw-${{ github.workflow }}-${{ github.event.issue.number }}	7	4.7%	Per-issue concurrency

Pattern: The dominant pattern prevents multiple runs of the same workflow type from executing simultaneously, ensuring resource efficiency and preventing race conditions.

---

Interesting Findings

1. Standardized Workflow Architecture 📐

The remarkable consistency in file sizes (80.4% in 50-70KB range) and structure (avg 6 jobs, 74 steps) indicates a mature, standardized workflow template system. This consistency simplifies maintenance and onboarding.

2. Comprehensive Safe Output Strategy 🎯

With 95.3% of workflows using safe outputs and an average of 2-4 output types per workflow, this repository demonstrates a sophisticated approach to workflow observability. The universal use of noop (141/148) ensures transparency even when no other action is taken.

3. Automation-First Philosophy 🤖

71.6% scheduled execution combined with 88.5% manual trigger support shows a "automate everything, but maintain control" philosophy. Workflows run automatically but can be triggered on-demand for testing or urgent needs.

4. Conservative MCP Adoption 🔧

Only 23.6% of workflows use MCP servers, suggesting that standard GitHub Actions capabilities meet most needs. When MCP is used, it's predominantly for advanced GitHub operations (100% of MCP usage is GitHub MCP).

5. Minimal Permission Footprint 🔒

Zero explicit permission declarations in lock files suggests a centralized permission management strategy, likely at the organization or repository level. This reduces configuration complexity and security risks.

6. Resource-Efficient Concurrency Control ⚡

98.6% concurrency group usage with primarily workflow-level locking (gh-aw-${{ github.workflow }}) demonstrates mature resource management, preventing workflow stampedes while allowing parallel execution of different workflow types.

7. Balanced Timeout Strategy ⏱️

The timeout distribution (median 20 minutes) strikes a balance between allowing complex analysis and preventing runaway jobs. The 99.3% explicit timeout configuration shows deliberate resource planning.

8. Business Hours Scheduling 🕐

Schedule patterns cluster around business hours (7 AM - 4 PM UTC, Monday-Friday), optimizing for human review of automated results and minimizing weekend noise.

---

Historical Trends

Comparing today's analysis with the previous run (2026-02-09):

Metric	2026-02-09	2026-02-10	Change
Lock File Count	148	148	No change ✓
Total Size	8.49 MB	8.58 MB	+0.09 MB (+1.1%)
Average Size	58.7 KB	59.4 KB	+0.7 KB
Average Steps	72.4	74.4	+2.0 steps (+2.8%)
Maximum Steps	101	103	+2 steps

Trend Analysis

Repository Growth: The 1.1% size increase without adding new workflows indicates feature enrichment - existing workflows are being enhanced with additional capabilities, steps, and safe outputs.

Increasing Complexity: The 2.8% increase in average steps per workflow suggests ongoing feature development. The daily-copilot-token-report workflow grew from 101 to 103 steps, now the most complex workflow in the repository.

Stable Architecture: File count remains constant at 148, indicating the workflow portfolio is mature. Growth is now focused on deepening existing workflows rather than adding new ones.

---

Recommendations

1. Consider MCP Expansion 🚀

With only 23.6% of workflows using MCP servers, there may be opportunities to leverage additional MCP capabilities:

• Evaluate whether Playwright (browser automation) could benefit more workflows
• Explore additional MCP servers for specialized tasks
• Document MCP best practices for workflow authors

2. Optimize Timeout Allocation ⚡

With average workflow steps at 74.4 and growing:

• Review workflows with 5-minute timeouts to ensure they have adequate buffer
• Consider implementing dynamic timeout scaling based on workflow complexity
• Monitor timeout-related failures to identify bottlenecks

3. Standardize Safe Output Patterns 📊

With 30 different safe output types in use:

• Document common safe output combinations as reusable patterns
• Create templates for audit workflows, issue management, and PR automation
• Consider consolidating rarely-used output types (18 types with <3 uses)

4. Schedule Load Balancing ⏰

Current schedule clustering at midday (11 AM - 2 PM UTC):

• Spread workflows more evenly across business hours to reduce concurrent load
• Consider using minutes offset in cron (e.g., 7 13 * * 1-5) for natural distribution
• Monitor GitHub Actions quota usage during peak hours

5. Document Permission Strategy 🔐

With zero explicit permissions in lock files:

• Document the repository-level permission strategy for workflow authors
• Consider whether critical workflows should explicitly declare minimal permissions
• Add permission audit workflows to ensure least-privilege principles

6. Cache Memory Best Practices 💾

Successfully using /tmp/gh-aw/cache-memory/ for scripts and history:

• Encourage more workflows to store reusable scripts in cache memory
• Create a cache memory index for discoverability
• Implement cache cleanup policies for stale data

---

Methodology

Analysis Tools & Approach

Data Collection:

• Bash scripts for file discovery and enumeration
• Python 3 for YAML parsing and statistical analysis
• Regex patterns for extracting configuration sections
• JSON for data serialization and storage

Lock Files Analyzed: 148 workflows in .github/workflows/*.lock.yml

Cache Memory Usage:

• Scripts persisted to /tmp/gh-aw/cache-memory/scripts/ for reuse
• Historical data tracked in /tmp/gh-aw/cache-memory/history/
• Analysis results stored in /tmp/gh-aw/cache-memory/data/

Data Sources:

• Lock file YAML structure (triggers, jobs, steps, safe outputs)
• Embedded safe outputs config JSON
• File metadata (size, modification time)
• Historical comparison data from previous runs

Statistical Methods:

• Frequency distribution for trigger and safe output analysis
• Percentile calculations for size and complexity metrics
• Pattern matching for schedule, timeout, and concurrency analysis
• Time-series comparison for trend detection

Analysis Script

The primary analysis script (lockfile_analysis_v3.py) performs:

1. YAML structure parsing without external dependencies
2. Safe outputs extraction from embedded JSON config
3. MCP server identification from function calls
4. Statistical aggregation and distribution calculation
5. Historical comparison and trend analysis

Script location: /tmp/gh-aw/cache-memory/scripts/lockfile_analysis_v3.py

---

References:

• §21857323557 - Current workflow run

Generated by Lockfile Statistics Analysis Agent on 2026-02-10

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 17, 2026, 8:33 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-17T08:33:50.208Z.

Closed by Workflow