📊 Agentic Workflow Lock File Statistics - November 29, 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - November 29, 2025

This analysis examines all 96 .lock.yml files in the .github/workflows/ directory to understand usage patterns, structural characteristics, and configuration trends across agentic workflows in this repository.

Overview: Key Findings

The repository contains 96 agentic workflow lock files totaling 28 MB, with an average file size of 292 KB. The workflows primarily use scheduled execution (59%) combined with manual triggers (78%), and overwhelmingly rely on the GitHub MCP server (94 workflows). Safe outputs favor create-discussion (32 workflows) for reporting results to the "audits" category (28 workflows). Most workflows request contents, issues, and pull-requests permissions, averaging 7 jobs and 62 steps per workflow.

Complete Statistical Analysis

Executive Summary

• Total Lock Files: 96
• Total Size: 28,050 KB (~28 MB)
• Average File Size: 292 KB
• Analysis Date: November 29, 2025
• Repository: githubnext/gh-aw

File Size Distribution

The majority of workflows are substantial, with 88 of 96 files (92%) being over 200 KB in size.

Size Range	Count	Percentage
< 10 KB	0	0%
10-50 KB	0	0%
50-100 KB	3	3%
100-200 KB	4	4%
200-300 KB	41	43%
300-400 KB	47	49%
≥ 400 KB	1	1%

Statistics:

• Smallest: test-skip-if-match-object.lock.yml (85 KB)
• Largest: poem-bot.lock.yml (489 KB)
• Median Range: 300-400 KB (49% of files)

Trigger Analysis

Most Popular Triggers

The workflows use various trigger types, with manual triggering being most common:

Trigger Type	Count	Percentage	Description
workflow_dispatch	75	78%	Manual trigger via GitHub UI or API
schedule	57	59%	Automated cron-based execution
pull_request	7	7%	Triggered on PR events
push	4	4%	Triggered on push to branches
workflow_run	2	2%	Triggered after another workflow
issues	2	2%	Triggered on issue events

Common Trigger Combinations

Most workflows combine scheduled and manual triggers for flexibility:

Combination	Count	Use Case
schedule + workflow_dispatch	52	Automated with manual override capability
workflow_dispatch only	14	Manual execution only
pull_request + schedule + workflow_dispatch	4	PR analysis with scheduled checks
pull_request + workflow_dispatch	2	Manual PR analysis
workflow_run	2	Chained workflows
push + workflow_dispatch	2	Push-triggered with manual option
issues	2	Issue-triggered automation

Schedule Patterns

Among the 57 scheduled workflows, the most common cron patterns are:

Schedule (Cron)	Count	Description
0 9 * * *	5	Daily at 9:00 AM UTC
0 0,6,12,18 * * *	4	Four times daily (midnight, 6am, noon, 6pm UTC)
0 14 * * 1-5	4	Weekdays at 2:00 PM UTC
0 8 * * *	3	Daily at 8:00 AM UTC
0 13 * * 1-5	3	Weekdays at 1:00 PM UTC
0 11 * * 1-5	3	Weekdays at 11:00 AM UTC
0 10 * * 1-5	2	Weekdays at 10:00 AM UTC
0 0 * * *	2	Daily at midnight UTC
0 9 * * 1	2	Mondays at 9:00 AM UTC
0 6 * * 0	2	Sundays at 6:00 AM UTC

Insights:

• Business hours focus: Most schedules target weekday mornings (UTC timezone)
• Daily patterns: 9 AM UTC is the most popular execution time
• Weekly reports: Several workflows run on Monday or Sunday mornings
• High frequency: A few workflows run every 4-6 hours for continuous monitoring

Safe Outputs Analysis

Safe outputs control what artifacts workflows can create, ensuring controlled interaction with GitHub.

Safe Output Types Distribution

Type	Count	Usage Pattern
create-discussion	32	Primary output method for reports and findings
add-comment	21	Adding context to existing issues/PRs
create-issue	12	Creating actionable work items
upload-asset	9	Attaching files to releases or artifacts
missing-tool	8	Reporting when required capabilities unavailable
create-pull-request	7	Proposing code changes
noop	1	No-operation (analysis only)

Key Finding: create-discussion is the preferred safe output (33% of workflows), indicating a pattern of using GitHub Discussions for audit reports and status updates rather than issues.

Discussion Categories

Among workflows that create discussions, category usage is:

Category	Count	Purpose
audits	28	Analysis reports, security audits, code quality checks
general	2	General discussion topics
announcements	2	Status updates and notifications

87.5% of discussions go to the "audits" category, establishing it as the standard location for workflow-generated reports.

Safe Output Patterns

Common safe output combinations:

• Discussion-only: 17 workflows (pure reporting)
• Discussion + Asset: 11 workflows (reports with attached data)
• Issue creation: 8 workflows (actionable items)
• Comment-based: 21 workflows (augmenting existing conversations)
• PR creation: 7 workflows (automated code changes)

Structural Characteristics

Job Complexity

• Average Jobs per Workflow: 7 jobs
• Average Steps per Job: ~9 steps (62 total steps / 7 jobs)
• Average Steps per Workflow: 62 steps
• Maximum Steps in Single Workflow: 99 steps

Analysis: Workflows are moderately complex with multiple jobs handling different aspects of analysis, data collection, and output generation.

Typical Lock File Structure

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

Characteristic	Typical Value
Size	~292 KB
Jobs	7 jobs
Steps per Workflow	62 steps
Permissions	contents (read), issues (write), pull-requests (write)
Triggers	schedule + workflow_dispatch
Safe Output	create-discussion to "audits" category
MCP Servers	github (primary)
Timeout	15-30 minutes (inferred from typical patterns)

Permission Patterns

Workflows request specific GitHub API permissions for their operations.

Most Common Permissions

Permission	Count	Typical Access Level
contents	93	read (code access)
issues	81	write (issue management)
pull-requests	80	write (PR management)
actions	44	read/write (workflow artifacts)
discussions	13	write (discussion creation)
security-events	6	write (security scanning)
repository-projects	3	write (project boards)

Permission Distribution Insights

• Near-universal: 97% of workflows require contents permission (repository read access)
• Issue/PR management: 84% need issues and 83% need pull-requests permissions
• Discussions: Only 14% explicitly request discussions permission (may inherit from broader scopes)
• Security: 6% of workflows interact with security scanning features
• Conservative approach: Workflows request minimal necessary permissions

Tool & MCP Patterns

Most Used MCP Servers

MCP Server	Count	Purpose
github	94	GitHub API interactions (issues, PRs, commits, etc.)
playwright	5	Browser automation and web scraping
deepwiki	1	Wikipedia knowledge access
context7	1	Research paper access (arXiv)
arxiv	1	Scientific paper retrieval

Key Finding: The GitHub MCP server is virtually universal (98% of workflows), reflecting the repository-centric nature of these agentic workflows.

Tool Usage Patterns

Common tool allowlists (inferred from patterns):

• Bash tools: Universal (for file operations, git commands, npm/pip installs)
• GitHub API tools: 94 workflows (via mcp__github__)
• Web tools: Limited to specific research/analysis workflows
• File operations: Read, Write, Edit tools in all workflows
• Cache memory: Available for persistent state across runs

Interesting Findings

1. Discussion-First Culture

The strong preference for create-discussion (32 workflows, 33%) over create-issue (12 workflows, 13%) suggests a deliberate pattern: workflows report findings to Discussions rather than cluttering Issues. The "audits" category serves as a structured knowledge base.

2. Hybrid Automation Strategy

52 workflows (54%) use both schedule and workflow_dispatch triggers, enabling:

• Regular automated execution (scheduled)
• On-demand execution for testing/investigation (manual)
• Flexibility to adjust frequency without code changes

3. Consistency in Structure

The tight clustering around 200-400 KB file sizes and similar job counts suggests workflows follow established patterns from templates or shared configurations. This consistency:

• Simplifies maintenance
• Enables code reuse
• Establishes best practices

4. GitHub-Centric Architecture

With 94 of 96 workflows (98%) using the GitHub MCP server, these agentic workflows are deeply integrated with GitHub's ecosystem. Only 5 workflows extend beyond GitHub APIs (using Playwright, arXiv, etc.).

5. Moderate Complexity Sweet Spot

At 62 steps per workflow on average, these workflows balance:

• Sufficient capability: Complex multi-stage analysis
• Maintainability: Not so complex as to be brittle
• Performance: Complete within reasonable timeouts (typically 15-30 minutes)

6. Weekday-Focused Scheduling

Many workflows run on weekdays only (* * 1-5 patterns), suggesting:

• Respect for team availability to respond to findings
• Alignment with business hours
• Reduced noise during weekends

Recommendations

Based on this analysis, here are recommendations for workflow authors:

1. Follow the Discussion Pattern

For audit-style reports, use create-discussion with category "audits" rather than creating issues. This keeps Issues focused on actionable work items.

2. Standard Trigger Combination

For most workflows, use: schedule + workflow_dispatch to enable both automated execution and manual testing.

3. Permission Minimization

Request only necessary permissions. The common pattern is:

permissions:
  contents: read
  issues: write
  pull-requests: write

4. Optimal Scheduling

• For daily reports: Use morning hours (8-10 AM UTC) to align with work start
• For weekly summaries: Monday or Sunday mornings
• For continuous monitoring: Every 4-6 hours

5. Size Management

If your lock file exceeds 400 KB, consider:

• Splitting into multiple focused workflows
• Extracting reusable patterns to shared imports
• Simplifying complex agent prompts

6. Leverage GitHub MCP Server

The GitHub MCP server (mcp__github__) provides comprehensive GitHub API access. Use it as the primary integration point rather than raw API calls.

Historical Trends

Note: This is the first comprehensive analysis. Future runs will track trends in:

• Lock file count growth
• Average size changes
• New MCP server adoption
• Safe output pattern evolution
• Trigger preference shifts

Methodology

Data Collection

• Tool: Python scripts with regex-based YAML parsing
• Lock Files Analyzed: 96 files
• Data Sources: .github/workflows/*.lock.yml and .github/workflows/*/*.lock.yml

Analysis Approach

1. File system scanning for all .lock.yml files
2. Content extraction via regex patterns on frontmatter and YAML structure
3. Statistical aggregation using Python Counter and collections
4. Cross-validation of patterns across multiple files

Cache Memory Usage

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

• Script reusability across workflow runs
• Historical trend tracking
• Pattern library building

Limitations

• Frontmatter-based trigger extraction (may miss dynamic configurations)
• Estimated step-per-job ratios (actual distribution varies)
• Timeout values not directly extracted (typical patterns inferred)

Repository Snapshot

• Repository: githubnext/gh-aw
• Analysis Date: November 29, 2025
• Total Workflows: 96 agentic workflows
• Primary Purpose: Automated code analysis, repository maintenance, CI/CD monitoring

---

Key Takeaway: This repository demonstrates a mature agentic workflow ecosystem with consistent patterns, GitHub-centric architecture, and a discussion-first approach to reporting. The 96 workflows represent approximately 1.8 MB of human-written workflow definitions that expand to 28 MB of locked configurations, showcasing the complexity hidden behind simple workflow files.

Generated by Lockfile Statistics Analysis Agent on 2025-11-29

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 3 days ago.