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

[github-actions[bot]]

Executive Summary

• Total Lock Files: 147
• Total Size: 8.8 MB (9,260,854 bytes)
• Average File Size: 61 KB (62,999 bytes)
• Analysis Date: February 7, 2026

This analysis examines all .lock.yml files in the .github/workflows/ directory to identify usage patterns, popular triggers, safe outputs, structural characteristics, and other key metrics that define how agentic workflows are configured in this repository.

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0.0%
10-50 KB	15	10.2%
50-100 KB	130	88.4%
> 100 KB	2	1.4%

Size Statistics

• Smallest: codex-github-remote-mcp-test.lock.yml (22 KB)
• Largest: smoke-claude.lock.yml (106 KB)
• Median Range: 50-100 KB (representing 88% of files)

Key Finding: The vast majority (88%) of lock files fall within a consistent 50-100 KB range, indicating standardized workflow complexity across the repository.

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Description
workflow_dispatch	130	88.4%	Manual workflow trigger
schedule	106	72.1%	Scheduled/cron-based execution
issue_comment	14	9.5%	Comments on issues
pull_request	13	8.8%	Pull request events
issues	13	8.8%	Issue events
pull_request_review_comment	6	4.1%	PR review comments
discussion_comment	5	3.4%	Discussion comments
discussion	4	2.7%	Discussion events
workflow_run	2	1.4%	Triggered by other workflows
push	1	0.7%	Push events

Key Findings:

• Manual Control Dominance: 88% of workflows support manual triggering via workflow_dispatch
• Automation Heavy: 72% use scheduled execution, indicating strong focus on automated reporting and analysis
• Interactive Workflows: Combined issue/PR/discussion triggers appear in ~25% of workflows, showing responsive agent behavior

Common Trigger Combinations

Most workflows use both workflow_dispatch AND schedule, providing flexibility for both automated execution and on-demand triggering.

View Schedule Patterns

Most Common Cron Schedules

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

Pattern: Most scheduled workflows run during business hours (9 AM - 6 PM UTC) on weekdays, with particular concentration around midday hours.

Safe Outputs Analysis

Safe outputs are the primary mechanism for workflows to create GitHub resources (issues, discussions, PRs) in a controlled manner.

Safe Output Types Distribution

Safe Output Type	Workflows Using	Percentage	Purpose
noop	140	95.2%	Status/completion messages
missing_tool	140	95.2%	Report missing capabilities
missing_data	140	95.2%	Report missing data
create_discussion	58	39.5%	Create GitHub discussions
create_issue	38	25.9%	Create GitHub issues
add_comment	33	22.4%	Add comments to issues/PRs
create_pull_request	25	17.0%	Create pull requests
upload_asset	22	15.0%	Upload release assets
add_labels	12	8.2%	Add labels to items
close_discussion	6	4.1%	Close discussions
push_to_pull_request_branch	5	3.4%	Update PR branches
update_issue	4	2.7%	Update existing issues
create_pull_request_review_comment	4	2.7%	Add PR review comments

Key Findings:

• Universal Error Handling: Nearly all workflows (95%+) include error reporting tools (noop, missing_tool, missing_data)
• Discussion-First: 40% of workflows create discussions, more than issues (26%), suggesting preference for threaded conversations
• Read-Heavy: Most workflows are analytical/reporting focused rather than making changes (only 17% create PRs)

Safe Output Combinations

Workflows commonly combine multiple safe output types:

• Most analysis workflows use: create_discussion + noop + missing_tool + missing_data
• Triage workflows use: create_issue + add_comment + add_labels
• Code change workflows use: create_pull_request + push_to_pull_request_branch

Structural Characteristics

Job Complexity

• Total Jobs Across All Workflows: 1,165
• Average Jobs per Workflow: 7.9
• Maximum Jobs in Single Workflow: 14 (in scout.lock.yml)
• Minimum Jobs: 1

Distribution: Most workflows have 4-10 jobs, following a standard pattern of:

1. Activation (setup)
2. Agent execution
3. Safe outputs processing
4. Cleanup/reporting

Step Complexity

• Total Steps Across All Workflows: 10,511
• Average Steps per Workflow: 71.5
• Maximum Steps in Single Workflow: 100 (in daily-copilot-token-report.lock.yml)

Key Finding: High step count indicates comprehensive workflow scaffolding with extensive setup, security controls, and cleanup procedures.

Average Lock File Structure

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

Metric	Typical Value
File Size	~61 KB
Jobs	~8 jobs
Steps per Workflow	~72 steps
Triggers	workflow_dispatch + schedule
Safe Outputs	3-5 types (always including noop, missing_tool, missing_data)
Primary Runner	ubuntu-slim (100% of workflows)

Permission Patterns

Most Common Permissions

Permission	Occurrences	Type Distribution
contents	730 total	657 read (90%), 73 write (10%)
issues	450 total	132 read (29%), 318 write (71%)
discussions	308 total	35 read (11%), 273 write (89%)
pull-requests	373 total	131 read (35%), 242 write (65%)
actions	68 total	66 read (97%), 2 write (3%)
security-events	14 total	12 read (86%), 2 write (14%)

Key Findings:

• Principle of Least Privilege: contents is mostly read-only (90%), showing workflows avoid unnecessary write access
• Interactive Write Permissions: Issues, discussions, and PRs have high write ratios, enabling agent responses
• Security Conscious: Very limited security-events write access

Permission Distribution

• Read-only workflows: ~15% (minimal permissions, mostly reporting)
• Mixed read/write: ~85% (standard agent workflows with safe outputs)
• High privilege workflows: <5% (workflows that need contents:write)

Tool & MCP Patterns

MCP Server Usage

• GitHub MCP Server: 142 workflows (96.6%)
• Safe Outputs MCP Server: 140 workflows (95.2%)

Key Finding: Nearly universal adoption of the GitHub MCP server for GitHub API operations, with safe outputs server providing controlled resource creation.

Infrastructure Patterns

• Runner: 100% use ubuntu-slim for cost efficiency
• MCP Gateway: All workflows use containerized MCP gateway (ghcr.io/github/gh-aw-mcpg)
• Firewall: All agent workflows run within network firewall containers for security

Interesting Findings

1. Standardized Workflow Pattern

There's remarkable consistency in workflow structure:

• 88% of files are 50-100 KB
• Average of ~8 jobs and ~72 steps per workflow
• Universal use of ubuntu-slim runner
• Common job names: activation, agent, safe_outputs, conclusion

This indicates well-established patterns and potentially code generation from templates.

2. Manual Override Priority

88% of workflows support workflow_dispatch, even scheduled ones. This shows:

• Teams value the ability to trigger on-demand
• Testing and debugging flexibility is prioritized
• Schedules provide baseline automation, manual triggers handle edge cases

3. Discussion-First Culture

Workflows create discussions (40%) more than issues (26%), suggesting:

• Preference for threaded, conversational output
• Less formal reporting approach
• Community engagement over task tracking

4. Heavy Automation Schedule

106 scheduled workflows (72%) with concentration during business hours indicates:

• Daily health checks and reports
• Proactive monitoring and analysis
• Reduced need for manual intervention

5. Comprehensive Error Handling

95%+ of workflows include noop, missing_tool, and missing_data safe outputs, showing:

• Mature error handling patterns
• Transparency in agent limitations
• Clear communication when workflows can't complete

6. Security-First Design

• Minimal write permissions (contents mostly read-only)
• All workflows use network firewalls
• MCP gateway isolation
• Least-privilege permission model

This demonstrates security is architected into the workflow design, not added as an afterthought.

Recommendations

1. Workflow Consolidation Opportunities

With 147 workflows and high consistency, consider:

• Template-based workflow generation (if not already in use)
• Shared workflow components to reduce duplication
• Workflow classification system (monitoring, triage, reporting, code-change)

2. Schedule Optimization

• Current concentration around business hours may cause resource contention
• Consider spreading schedules more evenly across 24-hour period
• Use different cron patterns for different workflow priority levels

3. Size Monitoring

• Two workflows exceed 100 KB (smoke-claude.lock.yml, smoke-copilot.lock.yml)
• Consider monitoring workflow size growth as technical debt indicator
• Large workflows may benefit from decomposition

4. Permission Audit

• Review the 73 workflows with contents:write to ensure necessity
• Consider creating a permission tier system (read-only, standard, elevated)
• Document why specific workflows need elevated permissions

5. Documentation Patterns

• High use of discussions suggests need for searchable report archive
• Consider discussion category organization for better discoverability
• Implement tagging/labeling for discussion-based reports

Methodology

• Analysis Tool: Bash scripts with grep/awk/sed for YAML parsing
• Lock Files Analyzed: 147 in .github/workflows/
• Cache Memory: Scripts and data stored in /tmp/gh-aw/cache-memory/ for reuse
• Data Sources: Direct parsing of .lock.yml files
• Analysis Date: February 7, 2026

Analysis Files Generated

All analysis data has been preserved in /tmp/gh-aw/agent/:

• file_sizes.csv - File size data
• trigger_counts.txt - Trigger frequency
• safe_output_tools.txt - Safe output usage
• job_permissions.txt - Permission patterns
• schedules.txt - Cron schedules
• jobs_stats.txt - Job statistics
• step_stats.txt - Step statistics

Historical data stored in /tmp/gh-aw/cache-memory/history/2026-02-07.json for trend analysis.

---

References:

• §21777069072

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 14, 2026, 8:27 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-14T08:27:32.149Z.

Closed by Workflow