📊 Agentic Workflow Lock File Statistics - November 4, 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - November 4, 2025

This report provides comprehensive statistical analysis of all .lock.yml files in the githubnext/gh-aw repository, revealing patterns in workflow triggers, safe outputs, permissions, and structural characteristics.

Executive Summary

The repository contains 71 lock files with a combined size of 13.95 MB. The majority of workflows (83.1%) support manual triggering via workflow_dispatch, while 50.7% run on automated schedules. Safe outputs are heavily utilized, with create-discussion being the most popular (33.8%). The GitHub MCP server is nearly ubiquitous, appearing in 66 of 71 workflows (93%). Lock files are substantial in size, averaging 201.2 KB, reflecting the comprehensive nature of agentic workflow configurations.

Key highlights:

• 82% of workflows are over 100 KB in size
• Average workflow complexity: 6.7 jobs with 56.3 steps per workflow
• Most common trigger combination: schedule + workflow_dispatch (27 workflows)
• Top safe outputs: create-discussion (24), create-pull-request (18), create-issue (17)
• Dominant permission: contents:read appears 263 times across all workflows

Full Report Details

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0.0%
10-50 KB	1	1.4%
50-100 KB	12	16.9%
> 100 KB	58	81.7%

Statistics:

• Smallest: shared/opencode.lock.yml (22.8 KB)
• Largest: poem-bot.lock.yml (371.0 KB)
• Average: 201.2 KB
• Total: 13.95 MB across 71 files
• Median Range: 100+ KB (most files fall into this category)

Insight: The overwhelming majority (82%) of lock files exceed 100 KB, indicating that agentic workflows are complex configurations with extensive job definitions, permissions, and instructions. Only a single workflow is under 50 KB.

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Example Workflows
workflow_dispatch	59	83.1%	cli-version-checker, smoke-codex, dev
schedule	36	50.7%	cli-version-checker, copilot-agent-analysis, daily-news
pull_request	11	15.5%	smoke-codex, changeset, scout
issue_comment	11	15.5%	mergefest, pdf-summary, scout
issues	10	14.1%	pdf-summary, scout, issue-classifier
push	5	7.0%	go-pattern-detector, tidy, arxiv
workflow_run	3	4.2%	dev-hawk, smoke-detector, ci-doctor
discussion_comment	3	4.2%	scout, plan, q
discussion	2	2.8%	scout, q
pull_request_review_comment	2	2.8%	scout, q

Key Finding: workflow_dispatch dominates with 83.1% adoption, indicating strong preference for manual control alongside automated triggers. Over half (50.7%) of workflows run on schedules, showing active use of automated execution.

Common Trigger Combinations

Combination	Workflow Count	Pattern Type
schedule + workflow_dispatch	27	Automated with manual override
workflow_dispatch (only)	17	Manual-only
pull_request + schedule + workflow_dispatch	5	PR automation with scheduling
issues (only)	3	Issue-triggered only
workflow_run (only)	3	Chained workflows
Full stack (6 triggers)	3	Maximum flexibility
issue_comment (only)	2	Comment-driven

Pattern: The most popular pattern is combining scheduled automation with manual override capability (27 workflows), allowing both regular execution and on-demand runs.

"Full Stack" Workflows: Three workflows (arxiv, context7, opencode) implement all six major triggers (issue_comment, issues, pull_request, push, schedule, workflow_dispatch), providing maximum activation flexibility.

Schedule Patterns

Total Unique Schedules: 25 distinct cron patterns

Schedule (Cron)	Time	Description
0 0 * * *	12:00 AM	Daily at midnight
0 9 * * 1-5	9:00 AM	Weekdays only
0 9 * * *	9:00 AM	Daily morning
0 12 * * *	12:00 PM	Daily at noon
0 18 * * *	6:00 PM	Daily evening
0 0,6,12,18 * * *	4x daily	Every 6 hours
0/10 * * * *	Every 10 min	High-frequency monitoring
0 9 * * 1	9:00 AM Mon	Weekly reports
0 12 * * 0	12:00 PM Sun	Sunday updates

Popular Times:

• Morning hours (6-10 AM): 7 schedules
• Midday (12 PM): 4 schedules
• Evening (6-10 PM): 5 schedules
• Late night (midnight-3 AM): 4 schedules
• High frequency: 1 workflow runs every 10 minutes

Insight: Workflows favor morning execution (6-10 AM) for daily reports and checks. One workflow uses aggressive 10-minute intervals, likely for continuous monitoring or smoke testing.

Safe Outputs Analysis

Safe Output Types Distribution

Type	Workflows Using	Percentage	Purpose
create-discussion	24	33.8%	Posting analysis reports and findings
create-pull-request	18	25.4%	Automated code changes and updates
create-issue	17	23.9%	Tracking bugs, tasks, or findings
add-comment	16	22.5%	Responding to existing threads
create-pull-request-review-comment	2	2.8%	Inline PR code review
update-issue	2	2.8%	Modifying existing issues

Total Safe Output Instances: 79 across 71 workflows (some workflows use multiple types)

Key Finding: create-discussion leads adoption at 33.8%, making discussions the preferred medium for sharing workflow outputs. This aligns with the repository's focus on audits and reports that benefit from threaded discussions.

Safe Output Usage Patterns

• Report Workflows: Primarily use create-discussion (examples: daily-news, daily-repo-chronicle, audit-workflows)
• Maintenance Workflows: Use create-pull-request for automated fixes (examples: tidy, changeset)
• Monitoring Workflows: Use create-issue for alerting (examples: dev-hawk, smoke-detector)
• Interactive Workflows: Use add-comment to respond to user input (examples: scout, q, plan)

Multi-Output Workflows: Several workflows combine multiple safe output types:

• Discussion + Issue creation for comprehensive reporting
• PR creation + Comment for explaining changes
• Issue updates + Comments for tracking resolution

Structural Characteristics

Job Complexity

Metric	Value	Notes
Average Jobs per Workflow	6.7	Moderate complexity
Maximum Jobs	16	Highest: unknown workflow
Average Steps per Workflow	56.3	High step count
Maximum Steps	101	Very comprehensive workflow
Minimum Steps	~10-15	Estimated for simpler workflows

Insight: The average workflow has nearly 7 jobs with 56 steps total, indicating sophisticated orchestration with multiple stages, error handling, and output generation.

Average Lock File Structure

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

• Size: ~201 KB
• Jobs: ~7 jobs (activation, agent, detection, outputs, error handling)
• Steps: ~56 steps across all jobs
• Permissions: 3-4 permission types (typically contents:read, issues:read, discussions:write)
• Triggers: 2 triggers (commonly schedule + workflow_dispatch)
• Timeout: ~12 minutes average
• Safe Outputs: 1-2 types (discussion or PR creation)
• MCP Servers: GitHub MCP server + optionally 1-2 others

Timeout Configuration

• Average Timeout: 12.1 minutes per job
• Common Values: 10, 15, and 20 minutes
• Purpose: Provides sufficient time for AI agent processing, API calls, and output generation

Note: The 12-minute average suggests workflows are designed for moderate AI tasks that complete within reasonable timeframes while preventing runaway executions.

Permission Patterns

Most Common Permissions

Permission	Occurrences	Type	Usage
contents:read	263	Read	Repository file access
pull-requests:read	124	Read	PR metadata and content
issues:read	122	Read	Issue metadata and content
issues:write	71	Write	Create/update issues
discussions:write	61	Write	Create/update discussions
pull-requests:write	54	Write	Create/update PRs
actions:read	47	Read	Workflow run metadata
contents:write	29	Write	Commit changes
discussions:read	14	Read	Read discussion content
security-events:read	8	Read	Security scanning access

Permission Distribution

• Total permission declarations: 815 across all workflows
• Read-only permissions: 576 (70.7%)
• Write permissions: 239 (29.3%)
• Average permissions per workflow: 11.5

Security Pattern: Workflows favor read permissions (70.7%) with selective write access, following the principle of least privilege. Write permissions are granted primarily for safe output generation.

Permission Groupings

Minimal (Read-only):

• contents:read only
• ~5-10% of workflows

Standard (Read + Safe Outputs):

• contents:read, issues:read, pull-requests:read
• issues:write or discussions:write for outputs
• ~60% of workflows

Elevated (Code Modification):

• contents:write for committing changes
• pull-requests:write for PR creation
• ~25% of workflows

Special Purpose:

• actions:read for workflow analysis
• security-events:read for security audits
• ~10% of workflows

Tool & MCP Patterns

Most Used MCP Servers

MCP Server	Workflows Using	Percentage	Purpose
github	66	93.0%	GitHub API operations (issues, PRs, discussions)
playwright	2	2.8%	Browser automation for web testing
deepwiki	1	1.4%	Wikipedia knowledge access
arxiv	1	1.4%	Academic paper search
context7	1	1.4%	Context management (likely experimental)

Key Finding: The GitHub MCP server is nearly universal (93%), appearing in 66 of 71 workflows. This makes sense given that most agentic workflows interact with GitHub resources (issues, PRs, discussions, repositories).

MCP Server Combinations

• GitHub only: ~63 workflows (89%)
• GitHub + Playwright: 2 workflows (browser automation for smoke tests)
• GitHub + Domain-specific: 3 workflows (arxiv, deepwiki, context7 for specialized knowledge)

Insight: Most workflows rely solely on the GitHub MCP server, with specialty servers used sparingly for specific use cases like academic research (arxiv) or web testing (playwright).

Common Tool Configurations

Based on lock file analysis, common tool patterns include:

• Bash tools: Present in all workflows for file operations and system commands
• GitHub API tools: 93% of workflows via MCP
• Web tools: WebFetch/WebSearch in research-oriented workflows
• File operations: Read, Write, Edit tools standard across workflows
• Task orchestration: Task tool for complex multi-step operations

Concurrency Patterns

Most workflows use concurrency groups to prevent simultaneous executions:

• Common pattern: group: "gh-aw-${{ github.workflow }}"
• Issue-specific: Some add issue/PR number for per-item concurrency
• Purpose: Prevents resource conflicts and duplicate work

Interesting Findings

1. Bimodal Trigger Strategy

The repository demonstrates a clear "scheduled automation + manual override" philosophy, with 27 workflows (38%) using both schedule and workflow_dispatch triggers. This pattern enables:

• Regular automated execution for monitoring and reports
• On-demand runs for debugging and immediate needs
• Flexibility without sacrificing automation

2. Discussion-First Output Culture

With 33.8% of workflows using create-discussion, this repository has embraced GitHub Discussions as the primary medium for sharing AI-generated insights. This is higher than create-issue (23.9%) or create-pull-request (25.4%), suggesting that:

• Workflows produce analysis and reports more than actionable changes
• Threaded discussions are valued for context and collaboration
• The "audits" category is likely heavily used

3. "Swiss Army Knife" Workflows

Three workflows (arxiv, context7, opencode) implement all 6 major trigger types, making them maximally flexible. These appear to be experimental or multipurpose agents that can respond to any GitHub event type.

4. Large Lock Files Are The Norm

With 82% of lock files exceeding 100 KB and an average of 201 KB:

• Agentic workflows are complex, multi-stage processes
• Extensive prompt engineering and instructions are embedded
• Lock files include detailed job orchestration and error handling
• This complexity reflects the sophisticated nature of AI-powered automation

5. High-Frequency Monitoring

One workflow runs every 10 minutes (0/10 * * * *), indicating active continuous monitoring, likely for:

• Smoke testing of critical functionality
• Health checks of API endpoints or services
• Rapid response to repository changes

6. Permission Discipline

The 70.7% read vs 29.3% write permission ratio shows strong security practices:

• Most workflows are read-only observers and analyzers
• Write permissions granted judiciously for safe outputs
• Follows least-privilege principle for AI agents

7. Job Orchestration Complexity

With an average of 6.7 jobs and 56.3 steps per workflow:

• Workflows include activation, execution, detection, and output stages
• Error handling and artifact management are standard
• Multi-stage pipelines are the norm, not the exception

8. MCP Server Monoculture

The GitHub MCP server's 93% adoption rate indicates:

• Strong alignment with GitHub-native automation
• Limited need for external integrations in most workflows
• GitHub's API provides sufficient functionality for most agent tasks

Historical Trends

First Analysis: This is the initial statistical analysis of lock files in this repository.

Baseline Metrics Established:

• 71 total lock files as of November 4, 2025
• Average size: 201.2 KB
• Future analyses can track growth and pattern changes

Future Tracking Opportunities:

• Growth in lock file count over time
• Evolution of trigger patterns
• Changes in safe output preferences
• Introduction of new MCP servers
• Permission pattern shifts

Recommendations

1. Consider Lock File Size Optimization

With 82% of files over 100 KB and an average of 201 KB, there may be opportunities for:

• Shared instruction libraries: Extract common patterns into reusable components
• Template consolidation: Identify redundant configurations across workflows
• Modular design: Break large workflows into smaller, composed pieces

Potential Impact: 20-30% size reduction while maintaining functionality

2. Standardize Schedule Patterns

With 25 unique cron schedules, consider:

• Time slot consolidation: Align similar workflows to common execution times
• Resource optimization: Prevent execution spikes by staggering schedules
• Documentation: Create a schedule registry showing what runs when

Benefit: Improved resource utilization and easier mental model of automation

3. Expand MCP Server Usage

Only 5 MCP servers are in use, with GitHub dominating at 93%. Consider:

• Specialized integrations: Add MCP servers for Slack, email, or project management
• Data sources: Integrate additional knowledge bases beyond arxiv/deepwiki
• Testing tools: Expand playwright usage for comprehensive testing

Opportunity: Workflows could leverage external data and tools more effectively

4. Discussion Category Analysis

Since create-discussion is the top safe output (33.8%), perform follow-up analysis:

• Which discussion categories are most used? (data shows empty results - may need category extraction fix)
• Are discussions being actively monitored and responded to?
• Could some discussions become issues for actionability?

Next Step: Re-run analysis with improved category extraction

5. Document "Full Stack" Workflow Pattern

The three "Swiss Army Knife" workflows (arxiv, context7, opencode) with 6 triggers are unusual:

• Document the use case: Why does one workflow need all triggers?
• Evaluate necessity: Could these be split into specialized workflows?
• Consider maintenance: Multi-trigger workflows may be harder to maintain

6. Establish Permission Guidelines

The healthy 70/30 read/write ratio should be codified:

• Create permission templates: Standard sets for common workflow types
• Audit write permissions: Regular reviews of elevated access
• Document rationale: Explain why each permission is needed

Benefit: Maintain security discipline as workflow count grows

7. Monitor Timeout Patterns

The 12-minute average timeout warrants tracking:

• Identify long-running workflows: Which consistently approach timeout?
• Optimize slow operations: Can caching or parallel execution help?
• Set appropriate limits: Align timeouts with actual execution needs

8. Create Workflow Type Taxonomy

Based on trigger patterns, establish workflow categories:

• Monitors (schedule only): Health checks, smoke tests
• Interactive (issue/PR/comment triggers): User-facing agents
• Hybrid (schedule + manual): Reports with override capability
• Reactive (workflow_run): Post-CI actions and analysis

Benefit: Easier navigation and consistent naming/organization

Methodology

Analysis Tools

• Bash scripts: File discovery and basic statistics
• Python 3: YAML parsing and data aggregation
• Regular expressions: Pattern extraction from lock files
• JSON: Structured data storage for analysis results

Data Collection Process

1. Discovery: find command to locate all .lock.yml files
2. Size analysis: File size calculation and distribution
3. Content parsing: Regex-based extraction of triggers, permissions, and configurations
4. Statistical aggregation: Counting, averaging, and ranking patterns
5. Report generation: Markdown formatting with tables and insights

Lock Files Analyzed

• Total: 71 lock files
• Location: .github/workflows/*.lock.yml
• Combined content: 13.95 MB of YAML configurations
• Analysis date: November 4, 2025

Cache Memory Usage

• Scripts: Stored in /tmp/gh-aw/cache-memory/scripts/
• Data: Analysis results in /tmp/gh-aw/cache-memory/data/
• History: Snapshot saved to /tmp/gh-aw/cache-memory/history/2025-11-04.json
• Patterns: Reusable extraction patterns for future analysis

Limitations

• Category extraction: Discussion category parsing returned empty (needs improvement)
• Workflow names: Some metrics report workflow basenames without .lock.yml context
• Engine detection: Lock files don't clearly indicate AI engine (Claude/Copilot/etc.)
• Cost analysis: No token usage or execution cost data in lock files

Future Improvements

• Enhanced YAML parsing with PyYAML library
• Job dependency graph analysis
• Execution history correlation (link locks to actual runs)
• Cost and performance metrics integration

---

Analysis Date: November 4, 2025
Repository: githubnext/gh-aw
Lock Files Analyzed: 71
Total Size: 13.95 MB

Generated by Lockfile Statistics Analysis Agent using automated YAML parsing and statistical analysis

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 week ago.