📊 Agentic Workflow Lock File Statistics - February 2026

[github-actions[bot]]

Executive Summary

This comprehensive statistical analysis examines 150 agentic workflow lock files (.lock.yml) in the github/gh-aw repository, providing insights into usage patterns, structural characteristics, and configuration trends across the workflow ecosystem.

Key Highlights:

• Total Lock Files: 150 workflows
• Total Size: 9.35 MB (8.91 MB)
• Average File Size: 60.84 KB
• Primary Engine: GitHub Copilot CLI (68.7% of workflows)
• Most Common Trigger: workflow_dispatch (135 workflows, 90%)
• Analysis Date: 2026-02-14

---

File Size Distribution

Size Range	Count	Percentage	Characteristics
< 10 KB	0	0.0%	None found
10-50 KB	10	6.7%	Minimal workflows
50-100 KB	138	92.0%	Standard workflows ⭐
> 100 KB	2	1.3%	Complex workflows

Size Statistics:

• Smallest: 23,738 bytes - codex-github-remote-mcp-test.lock.yml
• Largest: 108,005 bytes - smoke-copilot.lock.yml
• Average: 62,303 bytes (≈ 60.8 KB)

Insight: The overwhelming majority (92%) of workflows fall in the 50-100 KB range, indicating a consistent and well-optimized workflow structure across the repository.

---

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Use Case
workflow_dispatch	135	90.0%	Manual workflow execution
schedule	109	72.7%	Automated scheduled runs
pull_request	15	10.0%	PR-triggered workflows
issue_comment	14	9.3%	Comment-triggered workflows
issues	13	8.7%	Issue event workflows
pull_request_review_comment	6	4.0%	PR review comments
discussion_comment	5	3.3%	Discussion comment triggers
discussion	4	2.7%	Discussion events
workflow_run	2	1.3%	Workflow chain triggers
push	1	0.7%	Push event trigger

Common Trigger Combinations

1. schedule + workflow_dispatch: 100 workflows (66.7%)

   • Pattern: Scheduled workflows with manual override capability
   • Use case: Regular automated tasks that can be manually triggered

2. workflow_dispatch only: 18 workflows (12.0%)

   • Pattern: Purely manual workflows
   • Use case: On-demand operations and testing

3. pull_request + schedule + workflow_dispatch: 6 workflows (4.0%)

   • Pattern: Multi-trigger workflows for PR analysis
   • Use case: PR review automation with scheduled checks

4. issues only: 4 workflows (2.7%)

   • Pattern: Issue-specific automation
   • Use case: Issue triage and classification

5. Multi-event listeners (discussion, issue, PR, comments): 3 workflows (2.0%)

   • Pattern: Comprehensive event coverage
   • Use case: Unified response agents across all interaction types

Insight: The dominance of workflow_dispatch (90%) and schedule (72.7%) indicates a preference for controlled, predictable workflow execution rather than event-driven automation.

---

Schedule Patterns

View Detailed Cron Schedule Analysis

Most Common Schedule Frequencies

Cron Pattern	Count	Description
0 14 * * 1-5	4	Daily at 2:00 PM UTC (weekdays)
0 13 * * 1-5	4	Daily at 1:00 PM UTC (weekdays)
0 11 * * 1-5	4	Daily at 11:00 AM UTC (weekdays)
0 9 * * 1-5	3	Daily at 9:00 AM UTC (weekdays)
0 15 * * 1-5	2	Daily at 3:00 PM UTC (weekdays)
0 16 * * 1-5	2	Daily at 4:00 PM UTC (weekdays)
0 10 * * 1-5	2	Daily at 10:00 AM UTC (weekdays)
0 */6 * * *	2	Every 6 hours
*/30 * * * *	1	Every 30 minutes (most frequent)
Various hourly/daily	85+	Distributed across different times

Scheduling Insights:

• Weekday Preference: Many schedules use 1-5 (Monday-Friday) pattern, respecting business days
• Time Distribution: Schedules are well-distributed across UTC hours to avoid concentrated load
• Frequency Range: From every 30 minutes to weekly (Sunday schedules)
• Peak Hours: Most activity scheduled during 9 AM - 4 PM UTC (business hours)

---

Safe Outputs Analysis

Safe outputs are the primary mechanism for workflows to produce user-visible results (issues, discussions, comments, etc.).

Safe Output Type Distribution

Safe Output Type	Count	Usage	Primary Purpose
noop	1,859	95.0%	Status logging when no action needed
add-comment	98	5.0%	Adding comments to issues/PRs

Important Finding: The overwhelming use of noop (1,859 occurrences vs. 98 for add-comment) suggests that:

• Most workflow runs complete analysis without requiring GitHub API modifications
• Workflows prioritize transparency by logging completion status even when no action is taken
• The "no news is good news" pattern is common - many audits and checks produce output only when issues are found

Workflows Using Multiple Safe Output Types

26 workflows use multiple safe output types, combining noop (for status) with add-comment (for findings):

View Workflows with Multiple Safe Outputs

• smoke-codex.lock.yml
• craft.lock.yml
• tidy.lock.yml
• changeset.lock.yml
• cloclo.lock.yml
• smoke-temporary-id.lock.yml
• archie.lock.yml
• poem-bot.lock.yml
• unbloat-docs.lock.yml
• workflow-generator.lock.yml
• plan.lock.yml
• smoke-claude.lock.yml
• pdf-summary.lock.yml
• notion-issue-summary.lock.yml
• smoke-opencode.lock.yml
• q.lock.yml
• issue-classifier.lock.yml
• scout.lock.yml
• grumpy-reviewer.lock.yml
• mergefest.lock.yml
• smoke-copilot.lock.yml
• smoke-project.lock.yml
• mcp-inspector.lock.yml
• brave.lock.yml
• security-review.lock.yml
• pr-nitpick-reviewer.lock.yml

Pattern: These workflows typically:

1. Perform analysis or checks
2. Use noop to report "all clear" status
3. Use add-comment to report findings when issues are detected

---

Structural Characteristics

Job Complexity

• Average Jobs per Workflow: 1.0
• Job Count Distribution: All workflows have exactly 1 job named "agent"
• Architecture: Consistent single-job pattern across all workflows

Insight: The uniform single-job architecture indicates a standardized workflow pattern, where complexity is managed within job steps rather than through multiple parallel jobs.

Step Complexity

• Average Steps per Workflow: 73.43 steps
• Maximum Steps: 102 steps (daily-copilot-token-report.lock.yml)
• Minimum Steps: 33 steps (codex-github-remote-mcp-test.lock.yml)
• Typical Range: 60-85 steps per workflow

Step Count Distribution:

• Most workflows contain 60-80 steps for full setup and execution
• Larger workflows (80+ steps) typically include additional validation or multi-phase operations
• Smaller workflows (30-50 steps) are usually minimal smoke tests or simple checks

Average Lock File Structure

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

Characteristic	Typical Value
Size	~61 KB
Jobs	1 job (agent)
Steps per Job	~73 steps
Triggers	workflow_dispatch + schedule
Timeout	~22 minutes
Concurrency Control	Yes (100% of workflows)
Safe Outputs	noop primary, add-comment conditional
MCP Servers	GitHub MCP server (23% of workflows)

---

Permission Patterns

Finding: No explicit job-level permissions were detected in the analysis (empty permissions object).

Interpretation:

• Workflows use top-level permissions: {} (empty permissions)
• Actual permissions are granted at the job level on a per-step basis
• This follows the principle of least privilege - workflows request only necessary permissions

---

Tool & MCP Patterns

MCP Server Usage

MCP Server	Workflows	Percentage	Purpose
github	35	23.3%	GitHub API access for reading repos, issues, PRs
playwright	5	3.3%	Browser automation and web scraping
arxiv	1	0.7%	Academic paper search and retrieval
deepwiki	1	0.7%	Deep Wikipedia knowledge access

Key Insights:

• GitHub MCP: Most popular MCP server, used by nearly 1 in 4 workflows for rich GitHub integration
• Browser Automation: Playwright integration enables web-based workflows
• Specialized Knowledge: Academic (arXiv) and encyclopedic (DeepWiki) MCPs for domain-specific tasks
• Limited Adoption: Only 28% of workflows use MCP servers, suggesting most rely on built-in capabilities

---

Engine Distribution

The repository uses multiple AI engines to power agentic workflows:

Engine	Count	Percentage	Description
GitHub Copilot CLI	103	68.7%	Primary engine, GitHub's native solution ⭐
Claude	35	23.3%	Anthropic's Claude AI engine
Codex	10	6.7%	OpenAI Codex engine
Custom	2	1.3%	Custom engine implementations

Engine Strategy Insights:

• Copilot Dominance: GitHub Copilot CLI powers 2 out of 3 workflows, reflecting native integration advantages
• Multi-Engine Approach: Repository maintains flexibility with 4 different engines
• Specialized Use: Claude (23.3%) used for specific workflows requiring different capabilities
• Experimentation: Codex and custom engines represent exploration of alternative approaches

---

Concurrency & Timeout Patterns

Concurrency Control

• Workflows with Concurrency Groups: 150 (100%)
• Pattern: All workflows use concurrency groups to prevent duplicate runs
• Common Group: gh-aw-$\{\{ github.workflow }} or gh-aw-copilot-$\{\{ github.workflow }}

Benefit: Prevents resource waste and ensures only one instance of each workflow runs at a time.

Timeout Configuration

• Workflows with Timeout: 149 (99.3%)
• Average Timeout: 22.28 minutes
• Range: Typically 15-30 minutes per workflow

Timeout Strategy:

• Nearly universal timeout configuration prevents runaway workflows
• 22-minute average balances completion time with resource limits
• Consistent timeout values suggest standardized workflow complexity

---

Interesting Findings

1. Standardized Architecture: 100% of workflows follow a consistent pattern:

   • Single job named "agent"
   • 60-85 steps on average
   • Concurrency control enabled
   • Manual triggering capability

2. "Progressive Disclosure" Pattern: Extensive use of noop (1,859 occurrences) demonstrates a mature pattern where workflows report status even when no action is needed, improving transparency and debuggability.

3. Weekday Scheduling: Many scheduled workflows explicitly target weekdays (1-5 pattern), respecting business hours and reducing weekend noise.

4. Engine Diversity: Despite Copilot's dominance (68.7%), the repository maintains 4 different engines, enabling A/B testing and specialized capabilities.

5. Conservative MCP Adoption: Only 28% of workflows use MCP servers, suggesting most tasks can be accomplished with built-in tools and GitHub API access.

6. Size Consistency: 92% of workflows fall in the 50-100 KB range, indicating predictable resource requirements and consistent workflow patterns.

7. Minimal Permissions: Empty top-level permissions with job-level grants follow security best practices.

---

Recommendations

Based on the analysis, here are actionable recommendations:

1. Standardize Schedule Distribution: Consider load-balancing scheduled workflows more evenly across UTC hours to prevent potential bottlenecks during peak times (9 AM - 4 PM UTC).

2. MCP Server Expansion: With only 28% of workflows using MCP servers, there may be opportunities to:

   • Create more specialized MCP servers for common tasks
   • Document MCP best practices to encourage adoption
   • Identify workflows that could benefit from MCP integration

3. Engine Performance Tracking: With 4 different engines, establish metrics to compare:

   • Execution time
   • Success rate
   • Resource consumption
   • Output quality

4. Safe Output Expansion: Consider adding more safe output types beyond noop and add-comment:

   • create-issue for findings requiring tracking
   • create-discussion for analysis reports
   • update-issue for status updates on existing issues

5. Timeout Optimization: Review the ~22-minute average timeout:

   • Identify workflows that consistently complete much faster (candidates for reduced timeout)
   • Monitor workflows approaching timeout limits (candidates for optimization)

6. Size Optimization: Investigate the 2 workflows over 100 KB:

   • smoke-copilot.lock.yml (108 KB)
   • Identify if size indicates complexity that could be modularized

---

Methodology

• Analysis Tool: Python script with regex-based YAML parsing
• Lock Files Analyzed: 150
• Data Sources: .github/workflows/*.lock.yml
• Cache Memory: Scripts and data persisted to /tmp/gh-aw/cache-memory/ for reuse
• Historical Tracking: Results saved to cache-memory/history/2026-02-14.json

Technical Approach:

1. Enumerated all .lock.yml files in workflows directory
2. Parsed each file for structural elements (triggers, jobs, steps, etc.)
3. Extracted safe output patterns, MCP server usage, and scheduling
4. Aggregated statistics and generated distribution metrics
5. Identified patterns and combinations across workflows

---

References:

• §22014138867

---

Analysis generated on 2026-02-14 by Lockfile Statistics Analysis Agent

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 21, 2026, 8:26 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-21T08:26:44.089Z.

Closed by Workflow