📊 Agentic Workflow Lock File Statistics - 2025-10-15

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - 2025-10-15

Executive Summary

• Total Lock Files: 30
• Total Repository Size: 5.68 MB
• Average File Size: 193.7 KB (Median: 187.3 KB)
• Analysis Date: October 15, 2025
• Repository: githubnext/gh-aw

This report provides comprehensive statistical analysis of all .lock.yml files in the .github/workflows/ directory, revealing usage patterns, structural characteristics, and configuration preferences across agentic workflows.

---

📏 File Size Distribution

Size Range	Count	Percentage	Notes
< 10 KB	0	0%	No minimal workflows
10-50 KB	0	0%	No small workflows
50-100 KB	0	0%	No medium workflows
100-200 KB	20	66.7%	Most common size
> 200 KB	10	33.3%	Large, complex workflows

Size Statistics:

• Smallest: smoke-opencode.lock.yml (119.3 KB)
• Largest: poem-bot.lock.yml (316.8 KB)
• Average: 193.7 KB
• Median: 187.3 KB
• Total: 5.68 MB

Key Finding: All workflows are relatively large (>100KB), indicating substantial embedded MCP server code and comprehensive safety/security checks built into each compiled lock file.

---

🚀 Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Usage
workflow_dispatch	18	60.0%	Manual execution
schedule	8	26.7%	Automated/cron
issue_comment	5	16.7%	Comment-driven
issues	2	6.7%	Issue events
discussion	2	6.7%	Discussion events
pull_request	1	3.3%	PR events
workflow_run	1	3.3%	Chained workflows
push	1	3.3%	Push events

Note: Total percentage exceeds 100% because workflows can have multiple triggers.

Trigger Combinations

The most common trigger combination is:

• schedule + workflow_dispatch: Used in 8 workflows (26.7%)

This pattern enables workflows to run automatically on a schedule while also allowing manual execution for testing or ad-hoc runs.

Example workflows: artifacts-summary, audit-workflows, cli-version-checker, daily-news, etc.

Manual Execution Capability

• 24 out of 30 workflows (80%) include workflow_dispatch, enabling manual triggering
• This high percentage suggests a strong emphasis on developer control and testing flexibility

Schedule Patterns

Schedule (Cron)	Description	Workflows
0 9 * * 0	Sundays at 9 AM UTC (2x)	artifacts-summary, github-mcp-tools-report
0 9 * * 1	Mondays at 9 AM UTC	audit-workflows
0 9 * * 1-5	Weekdays at 9 AM UTC	daily-news
0 0 * * *	Daily at midnight UTC	cli-version-checker
0 3 * * *	Daily at 3 AM UTC	go-pattern-detector
0 10 * * *	Daily at 10 AM UTC (2x)	duplicate-code-detector, tidy
0 11 * * *	Daily at 11 AM UTC	repo-tree-map

Scheduling Insights:

• Most schedules run during business hours (UTC morning)
• Mix of daily and weekly cadences
• Weekly workflows often run on Sundays/Mondays for weekly summaries

---

🛡️ Safe Outputs Analysis

Safe outputs enable agents to interact with GitHub in controlled, auditable ways.

Safe Output Types Distribution

Type	Count	Percentage	Purpose
create_issue	12	40.0%	Create GitHub issues
add_comment	7	23.3%	Comment on issues/PRs
create_pull_request	7	23.3%	Create pull requests
create_discussion	6	20.0%	Create discussions
push_to_pull_request_branch	3	10.0%	Push code changes
add_labels	2	6.7%	Add labels to issues
upload_asset	2	6.7%	Upload release assets
update_issue	1	3.3%	Update existing issues
create_pull_request_review_comment	1	3.3%	Add PR review comments
notion-add-comment	1	3.3%	Custom Notion integration

Note: The missing_tool safe output (present in all workflows) is excluded from this count as it's a utility function, not a GitHub interaction.

Safe Output Usage Examples

Issue Creation (12 workflows):

• ci-doctor, dev, duplicate-code-detector, example-workflow-analyzer, go-pattern-detector
• All 5 smoke test workflows (smoke-claude, smoke-codex, smoke-copilot, smoke-genaiscript, smoke-opencode)

Discussion Creation (6 workflows):

• artifacts-summary, audit-workflows, daily-news, github-mcp-tools-report, lockfile-stats, repo-tree-map

Pull Request Creation (7 workflows):

• cli-version-checker, q, security-fix-pr, technical-doc-writer, tidy, unbloat-docs, poem-bot

The Powerhouse: poem-bot

The poem-bot workflow is the most feature-rich, using 8 different safe output types:

• add_comment (max: 3)
• add_labels (allowed: poetry, creative, automation, ai-generated, epic, haiku, sonnet, limerick)
• create_issue (max: 2)
• create_pull_request
• create_pull_request_review_comment (max: 2)
• push_to_pull_request_branch
• update_issue (max: 2)
• upload_asset

This demonstrates the power of combining multiple safe outputs for complex agentic behaviors.

---

🏗️ Structural Characteristics

Job Complexity

• Average Jobs per Workflow: 1.0
• Total Jobs: All 30 workflows use a single job architecture
• Rationale: Simplifies execution flow and reduces concurrency complexity

Key Insight: The single-job pattern is universal across all workflows, suggesting this is a recommended or enforced architectural pattern for agentic workflows.

Step Complexity

• Average Steps per Workflow: 49.4 steps
• Median Steps: 49 steps
• Minimum Steps: 34 steps (notion-issue-summary)
• Maximum Steps: 72 steps (poem-bot)

Step Distribution:

• 34-40 steps: 5 workflows (16.7%) - Simpler workflows
• 41-50 steps: 16 workflows (53.3%) - Standard complexity
• 51-60 steps: 7 workflows (23.3%) - Above average
• 61-72 steps: 2 workflows (6.7%) - High complexity (poem-bot, q)

Finding: The high average (49.4 steps) reflects the comprehensive nature of agentic workflows, which include:

• Security checks
• MCP server setup
• Agent execution
• Output collection and processing
• Safe output handling

Average Lock File Structure

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

• Size: ~194 KB
• Jobs: 1 job
• Steps: ~49 steps
• Permissions: Read-mostly with selective write access
• Triggers: workflow_dispatch + optional schedule or event trigger
• Timeout: 10-20 minutes
• Safe Outputs: 1-3 types configured

---

🔐 Permission Patterns

Most Common Permissions

Permission	Count	Type
contents: read	81	Read
issues: write	40	Write
permissions: read	38	Read-all
pull-requests: write	27	Write
discussions: write	23	Write
actions: read	21	Read
contents: write	12	Write
pull-requests: read	5	Read
issues: read	3	Read
actions: write	1	Write
models: read	1	Read
security-events: read	1	Read

Permission Analysis:

• Read Permissions: Heavily used (especially contents: read)
• Write Permissions: Selective (issues, PRs, discussions)
• Principle of Least Privilege: Workflows request specific write permissions only where needed

Permission Strategy

The permission pattern reveals a security-conscious approach:

1. Default to read-only for content access
2. Grant write permissions selectively for:
   • Issue/PR creation and commenting
   • Discussion creation
   • Branch pushing (limited workflows)
3. Minimize broad permissions like contents: write

---

🧩 Tool & MCP Patterns

Most Used MCP Servers

MCP Server	Workflows	Purpose
tavily	3	Web search and research
serena	2	Data analysis/processing
context7	2	Context management
markitdown	2	Markdown processing
brave	1	Web search (Brave Search)
notion	1	Notion integration
arxiv	1	Academic paper search
deepwiki	1	Deep Wikipedia research

Total Unique MCP Servers: 8

MCP Usage Insights:

• Search & Research: Most popular use case (tavily, brave, arxiv, deepwiki)
• Integration: Custom integrations with external services (notion)
• Data Processing: Tools for handling specific data formats (markitdown, serena)

Workflows without MCP imports: 22 workflows (73.3%) don't explicitly import external MCP servers, relying on built-in capabilities.

Engine Distribution

Engine	Workflows	Percentage
Copilot	19	63.3%
Claude	12	40.0%
Codex	6	20.0%
GenAIScript	1	3.3%
OpenCode	1	3.3%

Note: Engines detected based on heuristic analysis of workflow content. Some workflows may reference multiple engines.

Engine Preferences:

• GitHub Copilot is the most prevalent, likely due to native GitHub integration
• Claude has strong representation, showing multi-model strategy
• Specialized engines (GenAIScript, OpenCode) are used for specific smoke tests

---

⏱️ Timeout Configuration

Timeout Distribution

Timeout (minutes)	Occurrences	Workflows Affected
10	82	Most common
5	30	Quick operations
20	29	Complex operations
15	7	Moderate operations

Average Timeout: 11.2 minutes

Timeout Strategy:

• 5 minutes: Fast, lightweight steps (checks, setup)
• 10 minutes: Standard agent execution (most common)
• 15-20 minutes: Complex analysis or multi-step operations

Finding: The distribution shows a tiered approach to timeouts based on operation complexity.

---

🔀 Concurrency Patterns

Concurrency Groups

Pattern	Count	Purpose
gh-aw-${{ github.workflow }}	19	One run per workflow
gh-aw-${{ github.workflow }}-${{ github.event.issue.number || github.event.pull_request.number }}	7	One run per issue/PR
gh-aw-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}	1	One run per PR/ref
gh-aw-${{ github.workflow }}-${{ github.ref }}	1	One run per ref
gh-aw-${{ github.workflow }}-${{ github.event.issue.number }}	1	One run per issue
gh-aw-copilot	1	Copilot-specific queue

Concurrency Strategy:

1. Global Workflow Lock (63.3%): Ensures only one instance of a workflow runs at a time

   • Used by scheduled workflows and single-purpose automation

2. Per-Issue/PR Lock (23.3%): Allows concurrent runs for different issues/PRs

   • Used by event-driven workflows (issue comments, PR reviews)
   • Prevents race conditions on the same issue/PR

3. Specialized Locks (13.3%): Custom concurrency patterns for specific needs

Best Practice: The concurrency patterns prevent duplicate work and resource conflicts while allowing appropriate parallelism.

---

🔍 Interesting Findings

1. Standardized Architecture

All 30 workflows follow a remarkably consistent structure:

• Single job design
• ~49 steps per workflow
• Consistent security checks (membership verification)
• Embedded MCP server code
• Safe outputs for controlled GitHub interactions

This consistency suggests strong architectural guidelines and tooling that enforces best practices.

2. Security-First Design

Every workflow includes extensive security measures:

• Team membership verification
• Permission checks
• Input validation
• Safe output constraints (max limits)
• XPIA (Cross-Prompt Injection Attack) warnings in headers

Finding: Security is not an afterthought but a foundational design principle.

3. The Rise of Scheduled Automation

26.7% of workflows run on schedules, automating:

• Daily news summaries
• Weekly artifact analysis
• Continuous monitoring (CLI version checking)
• Repository maintenance (duplicate code detection)

This represents a shift toward proactive agentic automation rather than purely reactive workflows.

4. Manual Override is King

80% of workflows support workflow_dispatch, emphasizing:

• Developer control
• Testing and debugging
• Ad-hoc execution
• Override of automated schedules

Insight: Even in automated systems, humans remain firmly in control.

5. The Comprehensive "poem-bot"

The poem-bot workflow is an outlier in complexity:

• 72 steps (46% more than average)
• 8 safe output types (most diverse)
• 316.8 KB file size (largest)

It serves as a showcase of what's possible when combining multiple safe outputs and complex logic.

6. Smoke Tests Dominate Issue Creation

5 out of 12 "create_issue" workflows are smoke tests (smoke-claude, smoke-codex, smoke-copilot, smoke-genaiscript, smoke-opencode), indicating:

• Comprehensive testing across multiple engines
• Automated quality assurance
• Issue-based test reporting

---

📈 Historical Trends

First analysis run - no historical data available yet.

Future runs of this analysis will track:

• Growth in lock file count
• Changes in average file size
• Evolution of trigger patterns
• New safe output types
• MCP server adoption rates

Recommendation: Run this analysis monthly to track trends and identify emerging patterns.

---

💡 Recommendations

1. Optimize File Sizes

Observation: All files are >100KB, primarily due to embedded MCP server code.

Recommendation: Investigate opportunities to:

• Extract common MCP server code to shared libraries
• Use external MCP server references instead of embedding
• Reduce duplication across workflows

Potential Impact: 30-50% size reduction, faster parsing, easier maintenance.

2. Expand Safe Output Types

Current State: 10 safe output types in use.

Opportunity: Consider adding:

• update_pull_request - Modify PR descriptions
• create_milestone - Project planning
• create_project_card - Project board automation
• trigger_workflow - Workflow orchestration

Benefit: Enable more sophisticated automation patterns.

3. Standardize Timeout Patterns

Finding: Wide variation in timeout values (5-20 minutes).

Recommendation: Define timeout tiers:

• Tier 1: 5 minutes (checks, simple ops)
• Tier 2: 10 minutes (standard agents)
• Tier 3: 15 minutes (complex analysis)
• Tier 4: 20 minutes (heavyweight operations)

Document which operations belong in each tier for consistency.

4. Leverage Discussion Categories

Current State: Only 6 workflows use create_discussion.

Opportunity: Discussions are ideal for:

• Analysis reports (like this one!)
• Weekly/monthly summaries
• Audit findings
• Research results

Recommendation: Increase discussion usage for non-actionable outputs (vs. issues for actionable items).

5. Consider Multi-Job Workflows

Current State: 100% single-job workflows.

Opportunity: Multi-job patterns could enable:

• Parallel agent execution (faster results)
• Matrix builds (test across engines)
• Fan-out/fan-in patterns (aggregate results)

Trade-off: Increased complexity vs. improved performance.

6. Expand MCP Server Ecosystem

Current State: 8 MCP servers, 73% of workflows use none.

Opportunity: Develop/adopt MCP servers for:

• Code analysis (linting, complexity metrics)
• External APIs (Slack, PagerDuty, Jira)
• Data sources (databases, metrics systems)

Benefit: Richer agent capabilities without rebuilding infrastructure.

---

📊 Methodology

Analysis Tools

• Shell Scripts: File discovery, text processing, pattern extraction
• Python: JSON parsing, statistical analysis, data aggregation
• Bash: Data extraction, counting, sorting

Data Sources

All analysis based on 30 .lock.yml files in .github/workflows/:

• File sizes and structure
• YAML content parsing
• Configuration extraction
• Pattern matching

Cache Memory

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

• scripts/ - Reusable analysis tools
• history/ - Future historical data
• patterns/ - Extracted pa
  [Content truncated due to length]

AI generated by Lockfile Statistics Analysis Agent

[github-actions[bot]]

This discussion was automatically closed because it was created by an agentic workflow more than 1 month ago.