📊 Agentic Workflow Lock File Statistics - February 2026

[github-actions[bot]]

Executive Summary

This comprehensive analysis examines 149 agentic workflow lock files (.lock.yml) across the repository, revealing patterns in triggers, safe outputs, structural characteristics, and resource configurations.

Key Metrics:

• Total Lock Files: 149
• Total Size: 9.22 MB
• Average File Size: 63.4 KB
• Median File Size: 60.7 KB
• Analysis Date: 2026-02-03

---

File Size Distribution

Size Range	Count	Percentage	Representative Files
< 10 KB	0	0%	None
10-50 KB	10	6.7%	Smaller workflows
50-100 KB	137	91.9%	Standard workflows (most common)
> 100 KB	2	1.3%	smoke-claude.lock.yml (107 KB)

Size Statistics:

• Smallest: codex-github-remote-mcp-test.lock.yml (23.7 KB)
• Largest: smoke-claude.lock.yml (105 KB)
• Mean: 63.4 KB
• Median: 60.7 KB

The overwhelming majority (91.9%) of lock files fall within the 50-100KB range, indicating strong consistency in workflow complexity and structure.

---

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Use Case
workflow_dispatch	123	82.6%	Manual triggering capability
schedule	103	69.1%	Automated periodic execution
issue_comment	14	9.4%	Issue interaction response
issues	13	8.7%	Issue lifecycle events
pull_request	13	8.7%	PR events
pull_request_review_comment	6	4.0%	Review comment responses
discussion_comment	5	3.4%	Discussion interactions
discussion	4	2.7%	Discussion events
workflow_run	2	1.3%	Workflow chaining
push	1	0.7%	Code push events

Common Trigger Combinations

The most prevalent pattern is combining scheduled automation with manual override capability:

1. schedule + workflow_dispatch: 85 workflows (57.0%)

   • Enables both automated runs and on-demand execution
   • Most common pattern for monitoring and analysis agents

2. Multi-event responsive workflows: 3 workflows

   • Trigger on: discussion, discussion_comment, issue_comment, issues, pull_request, pull_request_review_comment
   • Provides comprehensive coverage of repository activity

3. PR + Schedule workflows: 6 workflows

   • Combine pull request events with scheduled checks

Schedule Patterns (Cron)

Cron Pattern	Count	Description	Friendly Time
0 13 * * 1-5	4	Weekdays at 1:00 PM UTC	Business hours (distributed)
0 14 * * 1-5	4	Weekdays at 2:00 PM UTC	Business hours (distributed)
0 11 * * 1-5	4	Weekdays at 11:00 AM UTC	Business hours (distributed)
0 10 * * 1-5	2	Weekdays at 10:00 AM UTC	Morning execution
0 9 * * 1-5	2	Weekdays at 9:00 AM UTC	Morning execution
0 15 * * 1-5	2	Weekdays at 3:00 PM UTC	Afternoon execution
0 16 * * 1-5	2	Weekdays at 4:00 PM UTC	Afternoon execution
0 7 * * 1-5	2	Weekdays at 7:00 AM UTC	Early morning

Pattern: Schedules are intentionally scattered throughout business hours (weekdays only) to distribute load and avoid GitHub Actions rate limits.

---

Safe Outputs Analysis

Safe outputs enable workflows to create GitHub resources in a controlled, rate-limited manner.

Safe Output Types Distribution

Based on configuration analysis, the following safe output types are available:

Safe Output Type	Workflows Configured	Purpose
noop	141	Log completion status when no action needed
missing_tool	141	Report missing capabilities
missing_data	141	Report missing required data
create_discussion	59	Create discussions for reports/findings
create_issue	36	Create issues for actionable items
add_comment	32	Add comments to existing items
create_pull_request	27	Create PRs for code changes
upload_asset	22	Upload artifacts/assets
add_labels	15	Add labels to issues/PRs
close_discussion	6	Close discussions programmatically
update_issue	4	Update existing issues
create_pull_request_review_comment	4	Add PR review comments
update_project	4	Update GitHub Projects

Key Insights:

• Universal baseline: 141 workflows (94.6%) configure noop, missing_tool, and missing_data as baseline tools
• Discussion-focused: 59 workflows (39.6%) can create discussions, suggesting a preference for threaded, community-visible reporting
• Issue creation: 36 workflows (24.2%) can create issues for actionable work items
• PR automation: 27 workflows (18.1%) can create pull requests

Discussion Categories

Category	Usage Count	Purpose
reports	62	General reporting and analysis results
audits	56	Audit findings and compliance checks

The repository primarily uses two discussion categories for agent outputs, with a slight preference for reports over audits.

---

Structural Characteristics

Job & Step Complexity

Metric	Value	Context
Average Jobs per Workflow	7.9	Multi-stage pipelines with activation, agent, conclusion
Average Steps per Job	71.0	Comprehensive setup and execution sequences
Maximum Steps	92	Largest single job
Minimum Steps	31	Simplest workflow

Typical Lock File Structure

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

Size & Complexity:

• File Size: ~63 KB
• Jobs: ~8 jobs (typically: pre_activation, activation, agent, conclusion, failure_tracking, etc.)
• Steps per Job: ~71 steps total across all jobs
• Triggers: schedule + workflow_dispatch (most common)

Common Jobs:

1. pre_activation - Early workflow gating
2. activation - Timestamp checks and activation logic
3. agent - Main AI agent execution
4. conclusion - Results processing and safe outputs
5. failure_tracking - Error handling and monitoring
6. always_cleanup - Cleanup tasks

Typical Step Categories:

• Checkout and setup (actions, scripts, repository)
• MCP server configuration
• Safe outputs configuration
• Memory management (repo-memory, cache-memory)
• Agent execution with Claude/Copilot/Codex
• Output collection and processing
• GitHub API interactions

---

Permission Patterns

Workflow-Level Permissions

All 149 workflows (100%) use minimal/empty permissions at the workflow level (permissions: {}), relying on job-specific permission grants for security isolation.

Job-Level Permissions

Jobs request specific permissions as needed:

Permission	Count	Purpose
contents: read	667	Repository code access (most common)
discussions: write	273	Create/update discussions
issues: write	273	Create/update issues
pull-requests: write	245	Create/update PRs
pull-requests: read	132	Read PR data
issues: read	131	Read issue data
contents: write	78	Commit changes
actions: read	64	Read workflow run data
discussions: read	35	Read discussion data
security-events: read	16	Code scanning alerts

Security Model:

• ✅ Least privilege: Empty workflow permissions, job-specific grants
• ✅ Read-heavy: contents: read is the most common (667 instances)
• ✅ Write access is selective: Write permissions granted only when needed
• ✅ Security awareness: 18 instances of security-events access for vulnerability management

---

MCP Server & Tool Patterns

Most Used MCP Servers

MCP Server	References	Purpose
github	3,640	GitHub API operations (issues, PRs, discussions, search)
playwright	210	Web automation and testing
arxiv	6	Academic paper access
deepwiki	6	Deep web research

Dominant Pattern: The github MCP server is overwhelmingly dominant (94.5% of MCP references), providing extensive GitHub API capabilities for issue management, PR operations, and repository interactions.

Timeout Configurations

Timeout (minutes)	Occurrences	Usage Pattern
10	182	Standard short tasks
15	166	Default moderate tasks
20	162	Extended operations
30	28	Long-running analysis
45	11	Complex processing
5	10	Quick checks
60+	4	Maximum duration tasks

Timeout Strategy: Most workflows (510 instances) use timeouts between 10-20 minutes, with a normal distribution centered around 15 minutes.

---

Concurrency Control Patterns

Concurrency Group Pattern	Count	Strategy
gh-aw-copilot-${{ github.workflow }}	150	Copilot engine isolation
gh-aw-${{ github.workflow }}	118	General workflow isolation
gh-aw-claude-${{ github.workflow }}	62	Claude engine isolation
gh-aw-codex-${{ github.workflow }}	17	Codex engine isolation
Per-issue/PR grouping	29	Resource-specific concurrency

Strategy: Concurrency groups are primarily organized by AI engine (Copilot/Claude/Codex) to prevent conflicts when multiple workflows use the same model provider, with workflow-level isolation as a fallback.

---

Interesting Findings

1. Strong Standardization (91.9% in 50-100KB range)

   • Lock files exhibit remarkable consistency in size and structure
   • Suggests effective workflow templates and compilation process
   • Median size (60.7 KB) very close to mean (63.4 KB) indicates low variance

2. Hybrid Automation Pattern (57% schedule + manual)

   • Most workflows combine scheduled automation with manual override
   • Enables both proactive monitoring and reactive investigation
   • Distributed scheduling across business hours prevents rate limit issues

3. Safety-First Design

   • 100% of workflows use minimal workflow-level permissions
   • 94.6% configure defensive safe output tools (noop, missing_tool, missing_data)
   • Rate limiting built into safe outputs (max 1-10 resources per run)

4. GitHub-Native Integration

   • GitHub MCP server dominates with 3,640 references (94.5%)
   • Focus on issues, PRs, and discussions as primary output mechanisms
   • Minimal external tool dependencies

5. Multi-Stage Pipeline Architecture

   • Average 7.9 jobs per workflow suggests consistent multi-stage pattern
   • Typical flow: activation → agent → conclusion → cleanup
   • Failure tracking and always-run cleanup jobs ensure reliability

6. Engine Diversity with Copilot Leadership

   • Copilot concurrency groups (150) lead, followed by Claude (62) and Codex (17)
   • Suggests Copilot is the primary execution engine
   • Multiple engine support provides flexibility

---

Recommendations

For Workflow Authors

1. Follow the 50-100KB Pattern: Your workflow is likely well-structured if it falls in this range
2. Use Schedule + Dispatch: The 57% majority pattern enables both automation and ad-hoc runs
3. Distribute Schedules: Scatter cron times across hours to avoid rate limits
4. Configure Defensive Tools: Always include noop, missing_tool, missing_data in safe outputs

For Repository Maintenance

1. Monitor Outliers: Investigate the 2 workflows >100KB for optimization opportunities
2. Standardize Categories: Consider consolidating around reports and audits categories
3. Review Timeout Distribution: The concentration at 10-20 minutes suggests most tasks complete quickly
4. Engine Load Balancing: With Copilot dominant (150 workflows), consider load distribution

For Platform Development

1. Template Success: The high consistency suggests workflow templates are effective
2. Safety Patterns Work: Universal adoption of minimal permissions shows good security culture
3. GitHub-Centric: Strong GitHub MCP adoption indicates platform integration is successful
4. Concurrency Isolation: Engine-specific concurrency groups prevent resource conflicts effectively

---

Methodology

Analysis Tools:

• Python scripts for YAML parsing and statistical analysis
• Bash utilities for pattern extraction and aggregation
• Regular expressions for structured data extraction

Data Sources:

• 149 .lock.yml files in .github/workflows/
• File size analysis via filesystem metadata
• Content analysis via regex and YAML parsing

Scripts Cached:

• /tmp/gh-aw/cache-memory/scripts/detailed_analysis.py
• /tmp/gh-aw/cache-memory/scripts/extract_details.py
• /tmp/gh-aw/cache-memory/scripts/extract_safeoutputs_config.py

**Historical (redacted)

• Analysis results stored in /tmp/gh-aw/cache-memory/history/2026-02-03/
• Enables trend analysis for future runs

---

References:

• §21622559975

Analysis generated by the Lockfile Statistics Analysis Agent on 2026-02-03

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 10, 2026, 8:28 AM UTC