📊 Agentic Workflow Lock File Statistics - 2026-01-27

[github-actions[bot]]

This comprehensive analysis examines all 139 .lock.yml files in the .github/workflows/ directory to understand usage patterns, structural characteristics, and common configurations across agentic workflows.

Executive Summary

• Total Lock Files: 139
• Total Combined Size: 10.4 MB
• Average File Size: 74 KB
• Analysis Date: 2026-01-27
• Most Complex Workflow: audit-workflows.lock.yml (92 steps)
• Smallest Workflow: codex-github-remote-mcp-test.lock.yml (23 KB, 31 steps)

Key Findings

• 89% of workflows respond to user interactions (issues, PRs, comments)
• 66% are manually triggerable via workflow_dispatch
• 73% run on a schedule for automated operations
• Most common pattern: Schedule + workflow_dispatch (92 workflows)
• Safe outputs: 21% use add-comment, 12% create pull requests

---

File Size Distribution

Size Range	Count	Percentage	Characteristics
< 10 KB	0	0.0%	None (minimum is 23 KB)
10-50 KB	7	5.0%	Simple workflows, minimal agents
50-100 KB	121	87.1%	Standard workflows - typical agent configuration
> 100 KB	11	7.9%	Complex multi-agent workflows

Size Analysis

• Smallest: codex-github-remote-mcp-test.lock.yml (23 KB)
• Largest: copilot-session-insights.lock.yml (118 KB)
• Average: 74 KB
• Total: 10,396 KB (10.4 MB)

The tight clustering around 50-100 KB suggests a consistent, well-optimized workflow structure across the repository.

---

Trigger Analysis

Workflow Trigger Distribution

Trigger Type	Workflows	Percentage	Use Case
issues	138	99.3%	Issue creation, labeling, assignment
workflow_dispatch	124	89.2%	Manual execution capability
schedule	102	73.4%	Daily reports, periodic analysis
issue_comment	14	10.1%	Comment-driven automation
pull_request	12	8.6%	PR reviews and analysis
discussion	10	7.2%	Discussion monitoring
pull_request_review_comment	6	4.3%	Code review responses
push	2	1.4%	CI/CD triggers
workflow_run	2	1.4%	Chained workflows

Most Common Trigger Combinations

1. schedule + workflow_dispatch (92 workflows) - Automated with manual override capability
2. workflow_dispatch only (18 workflows) - Purely manual workflows
3. issues only (4 workflows) - Dedicated issue handlers
4. Full interaction suite (3 workflows) - discussion + discussion_comment + issue_comment + issues + pull_request + pull_request_review_comment

View Schedule Patterns (Cron Expressions)

Most workflows are scheduled during weekday business hours (UTC):

Schedule (Cron)	Count	Description
0 14 * * 1-5	4	2:00 PM UTC, Monday-Friday
0 13 * * 1-5	4	1:00 PM UTC, Monday-Friday
0 11 * * 1-5	4	11:00 AM UTC, Monday-Friday
0 9 * * 1-5	2	9:00 AM UTC, Monday-Friday
0 7 * * 1-5	2	7:00 AM UTC, Monday-Friday
0 16 * * 1-5	2	4:00 PM UTC, Monday-Friday
0 15 * * 1-5	2	3:00 PM UTC, Monday-Friday
0 10 * * 1-5	2	10:00 AM UTC, Monday-Friday

Pattern: Workflows are staggered throughout the business day to distribute load and provide continuous monitoring.

---

Safe Outputs Analysis

Safe outputs define how workflows communicate results back to GitHub (discussions, issues, PRs, comments).

Safe Output Type Distribution

Output Type	Workflows	Percentage	Primary Use Case
add-comment	29	20.9%	Quick feedback on issues/PRs
create-pull-request	16	11.5%	Code changes, automated fixes
create-discussion	9	6.5%	Reports, analysis summaries
create-issue	7	5.0%	Problem tracking, alerts
create-pull-request-review-comment	4	2.9%	Inline code review
update-issue	2	1.4%	Status updates, progress tracking

Workflows with Multiple Safe Output Types

These versatile workflows can produce different outputs based on context:

View Workflows with Multiple Output Types

Workflow	Safe Output Types
lockfile-stats.lock.yml	add-comment, create-discussion, create-issue, create-pull-request, create-pull-request-review-comment, update-issue
security-review.lock.yml	add-comment, create-pull-request, create-pull-request-review-comment
workflow-normalizer.lock.yml	add-comment, create-discussion, create-issue
pr-nitpick-reviewer.lock.yml	add-comment, create-discussion, create-pull-request-review-comment
grumpy-reviewer.lock.yml	add-comment, create-pull-request-review-comment
craft.lock.yml	add-comment, create-issue
workflow-generator.lock.yml	add-comment, update-issue
security-alert-burndown.campaign.lock.yml	add-comment, create-pull-request
q.lock.yml	add-comment, create-pull-request
cloclo.lock.yml	add-comment, create-pull-request
discussion-task-miner.lock.yml	add-comment, create-issue

Notable: lockfile-stats.lock.yml uses all 6 safe output types, making it the most versatile workflow.

Safe Output Examples

create-discussion workflows: copilot-agent-analysis, copilot-pr-merged-report, copilot-pr-prompt-analysis
create-issue workflows: cli-consistency-checker, cli-version-checker, craft
add-comment workflows: archie, brave, changeset, copilot-pr-nlp-analysis, craft
create-pull-request workflows: cloclo, daily-doc-updater, daily-workflow-updater, security-fix-pr

---

Structural Complexity

Jobs per Workflow

• Average: 6.06 jobs per workflow
• Minimum: 2 jobs
• Maximum: 9 jobs
• Standard: Most workflows follow the pattern: activation → agent → safe-outputs

Steps per Workflow

• Average: 71.58 steps per workflow
• Minimum: 31 steps (codex-github-remote-mcp-test.lock.yml)
• Maximum: 92 steps (audit-workflows.lock.yml)
• Median range: 65-75 steps

Typical Workflow Structure

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

Structure Profile:
- Size: ~74 KB
- Jobs: ~6 jobs
  ├── activation (workflow validation)
  ├── agent (main AI agent execution)
  ├── safe-outputs-* (multiple output jobs)
  └── finalization jobs
- Steps per Job: ~12 steps average
- Total Steps: ~72 steps
- Timeout: 10-20 minutes per job
- Triggers: schedule + workflow_dispatch

---

Timeout Patterns

Timeout configurations show conservative, reliable settings:

Timeout	Workflows	Percentage	Use Case
10 min	175 instances	33.5%	Quick analyses, simple agents
15 min	154 instances	29.5%	Most common - balanced default
20 min	149 instances	28.5%	Complex analysis, multi-step
30 min	27 instances	5.2%	Deep analysis, large codebases
5 min	10 instances	1.9%	Validation, quick checks
45 min	10 instances	1.9%	Extended processing
60 min	2 instances	0.4%	Maximum timeout
90 min	1 instance	0.2%	Extreme cases

Average timeout: 17 minutes
Most common: 10-20 minute range (91.5% of all timeout settings)

---

Workflow Naming Patterns

Category Distribution

Category	Count	Pattern	Examples
Daily Workflows	25	daily-*	daily-news, daily-code-metrics, daily-team-status
Analysis/Reports	9	*-report, *-analysis	org-health-report, agent-performance-analyzer
Issue Management	9	*-issue-*, issue-*	issue-triage-agent, auto-triage-issues
Copilot-related	8	copilot-*	copilot-pr-nlp-analysis, copilot-session-insights
PR Management	7	pr-*, *-pr-*	pr-triage-agent, pr-nitpick-reviewer
Code Analysis	6	code-*, *-analyzer	code-scanning-fixer, code-simplifier
Workflow Tools	6	workflow-*	workflow-normalizer, workflow-health-manager
Smoke Tests	4	smoke-*	smoke-claude, smoke-copilot, smoke-codex
Agent Tools	4	*-agent	issue-triage-agent, pr-triage-agent

Most Common Words in Workflow Names

Word	Frequency	Context
daily	25	Scheduled periodic workflows
report/summary	9/5	Analysis and reporting workflows
issue	9	Issue management automation
copilot	8	Copilot-specific workflows
pr	7	Pull request automation
analysis/analyzer	7/6	Code and data analysis
workflow	6	Workflow management tools
code	6	Code quality and analysis
checker	5	Validation workflows
agent	5	AI agent workflows

Name Length Analysis

• Shortest: q.lock.yml (1 character)
• Longest: security-alert-burndown.campaign.lock.yml (32 characters)
• Average: ~20 characters
• Pattern: Most use kebab-case with descriptive, action-oriented names

---

Campaign Workflows

Campaign workflows are special long-running or iterative workflows designed to systematically address issues across the codebase.

• Total Campaigns: 1
• Identified Campaign: security-alert-burndown.campaign.lock.yml

This campaign workflow uses multiple safe output types (add-comment, create-pull-request) to systematically address security alerts.

---

Interesting Findings

1. Comprehensive Issue Coverage

Nearly every workflow (99.3%) responds to issue events, making the issue tracking system the primary interaction point for agentic workflows. This creates a unified interface where users can trigger complex automation simply by creating or commenting on issues.

2. Balanced Automation Strategy

The repository employs a "scheduled with manual override" pattern (66% of workflows):

• Automated execution via cron schedules for regular monitoring
• Manual workflow_dispatch for on-demand execution
• Issue/PR triggers for event-driven responses

3. Staggered Schedule Distribution

Daily workflows are distributed across business hours (7 AM - 4 PM UTC) to:

• Prevent resource contention
• Provide continuous monitoring throughout the day
• Distribute GitHub API load

4. Conservative Timeout Settings

91.5% of timeouts are in the 10-20 minute range, suggesting:

• Well-optimized agent execution
• Predictable workflow duration
• Adequate buffer for variability without excessive wait times

5. Multi-Output Versatility

11 workflows use multiple safe output types, with lockfile-stats.lock.yml supporting all 6 types. This versatility allows workflows to:

• Create comprehensive reports (discussions)
• Track issues for follow-up
• Provide immediate feedback (comments)
• Generate code fixes (pull requests)
• Update existing tracking issues

6. Consistent Structural Patterns

The tight clustering of file sizes (87% between 50-100 KB) and step counts (average 72 steps) indicates:

• Well-defined workflow patterns
• Consistent best practices
• Reusable components and structure
• Mature workflow architecture

7. Semantic Naming Convention

Workflows follow clear naming patterns:

• Action-oriented: code-scanning-fixer, issue-triage-agent
• Category prefixes: daily-, copilot-, smoke-*
• Descriptive suffixes: *-report, *-analysis, *-checker

This makes workflows discoverable and their purpose immediately clear.

---

Recommendations

1. Continue Standardization

The 50-100 KB size range represents an optimal workflow structure. New workflows should target this range to maintain consistency and reusability.

2. Expand Campaign Workflows

With only 1 campaign workflow identified, there's opportunity to create more systematic, iterative workflows for:

• Technical debt reduction
• Documentation updates
• Security improvements
• Code modernization

3. Permission Patterns Documentation

The analysis found no explicit permissions in the extracted data (likely due to YAML structure). Consider documenting common permission patterns to help workflow authors choose appropriate access levels.

4. Schedule Optimization

Continue the staggered schedule approach. Consider:

• Adding weekend monitoring for critical workflows
• Creating "off-hours" slots for resource-intensive analysis
• Documenting schedule collision avoidance

5. Safe Output Best Practices

Document when to use each safe output type:

• add-comment: Quick feedback, non-blocking information
• create-discussion: Comprehensive reports, community visibility
• create-issue: Actionable problems requiring tracking
• create-pull-request: Code fixes ready for review
• create-pull-request-review-comment: Inline code suggestions
• update-issue: Progress updates on existing work

6. Timeout Tuning

The 17-minute average timeout is reasonable, but consider:

• Creating timeout tiers: quick (5-10 min), standard (15-20 min), extended (30-45 min)
• Monitoring actual execution times to optimize timeout values
• Alert on workflows consistently approaching timeout limits

---

Methodology

Data Collection

• Files Analyzed: 139 .lock.yml files from .github/workflows/
• Analysis Scripts: Bash-based YAML parsing with awk, grep, sed
• Data Points Extracted:
  • File sizes and structure
  • Trigger configurations
  • Safe output types
  • Job and step counts
  • Timeout settings
  • Schedule patterns
  • Naming conventions

Analysis Tools

• Language: Bash shell scripts
• Storage: Persistent cache at /tmp/gh-aw/cache-memory/
• Scripts Created:
  • analyze_lockfiles.sh
  • extract_detailed_data.sh
  • final_analysis.sh
  • interesting_findings.sh
  • generate_statistics.sh

Cache Memory

Analysis scripts and patterns stored in /tmp/gh-aw/cache-memory/ for:

• Future analysis runs
• Historical trend tracking
• Script reusability
• Pattern library development

Statistical Methods

• Count frequencies for categorical data
• Calculate averages, min/max for numerical data
• Distribution analysis for sizes and timeouts
• Pattern matching for naming conventions
• Combination analysis for trigger patterns

---

Future Analysis Opportunities

1. Trend Analysis: Compare with future runs to track:

   • Workflow count growth
   • Size evolution
   • Pattern shifts
   • New trigger types

2. Performance Correlation: Correlate workflow characteristics with:

   • Execution duration
   • Success/failure rates
   • Resource consumption

3. Engine Comparison: Deep dive into engine-specific patterns:

   • Claude vs. Copilot vs. Codex workflow structures
   • Engine-specific safe output preferences
   • Performance characteristics by engine

4. Dependency Analysis: Map workflow dependencies:

   • Shared components
   • workflow_run chains
   • Common action usage

---

Analysis Generated: 2026-01-27
Repository: githubnext/gh-aw
Lock Files Analyzed: 139
Total Size: 10.4 MB
Analysis Engine: Lockfile Statistics Analysis Agent (Claude Sonnet 4.5)

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 3, 2026, 3:05 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-03T15:05:18.466Z.