📊 Agentic Workflow Lock File Statistics - 2025-11-02

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - 2025-11-02

Executive Summary

This comprehensive analysis examines 69 agentic workflow lock files (.lock.yml) in the gh-aw repository, totaling 13.46 MB of configuration. The average lock file is 199.74 KB, with the largest being poem-bot.lock.yml at 371 KB and the smallest being opencode.lock.yml at 23 KB.

Key Findings:

• 100% concurrency control: All 69 workflows implement concurrency settings
• Universal safe outputs: 84% of workflows support all 7 safe output types
• Scheduled automation: 48% of workflows run on schedules (33 workflows)
• Multi-modal triggers: Most workflows support manual dispatch alongside automated triggers
• GitHub MCP dominance: 93% of workflows use the GitHub MCP server
• Conservative permissions: Read-only permissions outnumber write permissions 2:1

Full Report Details

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0%
10-50 KB	1	1.4%
50-100 KB	10	14.5%
100-200 KB	13	18.8%
> 200 KB	45	65.2%

Statistics:

• Smallest: opencode.lock.yml (22.76 KB) - shared MCP configuration
• Largest: poem-bot.lock.yml (371.38 KB) - creative content generation workflow
• Average: 199.74 KB
• Total: 13.46 MB across all lock files

Observation: The vast majority (65%) of lock files exceed 200 KB, indicating comprehensive configurations with extensive prompt instructions, multiple jobs, and rich MCP integrations.

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Primary Use Case
workflow_dispatch	56	81.2%	Manual execution via GitHub UI
schedule	33	47.8%	Automated recurring tasks
pull_request	8	11.6%	PR review and analysis
issue_comment	8	11.6%	Interactive issue responses
issues	6	8.7%	Issue triage and automation
workflow_run	3	4.3%	Workflow monitoring
discussion_comment	3	4.3%	Discussion interactions
discussion	2	2.9%	Discussion monitoring
pull_request_review_comment	2	2.9%	PR review responses
push	2	2.9%	Code change detection

Key Insights:

• Manual control: 81% of workflows support workflow_dispatch, enabling on-demand execution
• Automation first: 48% use schedule for proactive monitoring and maintenance
• Event-driven: 25% respond to issues, PRs, or discussions for interactive assistance

Common Trigger Combinations

Combination	Count	Use Case
schedule, workflow_dispatch	27	Automated reports with manual override
pull_request, schedule, workflow_dispatch	5	PR analysis with scheduled checks
pull_request, workflow_dispatch	1	PR-focused with manual option
issue_comment, issues, workflow_dispatch	1	Issue handling workflows
push, workflow_dispatch	1	Code change automation

Most Versatile Workflows:

1. scout.lock.yml - 7 triggers: discussion, discussion_comment, issue_comment, issues, pull_request, pull_request_review_comment, workflow_dispatch
   • Universal assistant responding to all GitHub interaction types
2. q.lock.yml - 6 triggers: Same as scout minus workflow_dispatch
   • Automated Q&A bot without manual invocation

Schedule Patterns

Schedule (Cron)	Count	Description
0/10 * * * *	3	Every 10 minutes (high-frequency monitoring)
0 9 * * 1	1	Every Monday at 9 AM (weekly reports)

Note: Most scheduled workflows use GitHub's default schedule handling rather than explicit cron expressions in the analyzed content.

Safe Outputs Analysis

Safe Output Types Distribution

All workflows support the safeoutputs MCP server for GitHub integration. The following safe output types are available in 58 workflows (84%):

Safe Output Type	Count	Purpose
create_discussion	58	Create GitHub Discussions for reports
create_issue	58	Create issues for findings or tasks
add_comment	58	Comment on issues, PRs, discussions
create_pull_request	58	Generate PRs with code changes
update_issue	58	Modify existing issues
create_pull_request_review_comment	58	Comment on PR diffs
missing_tool	58	Report missing functionality

Key Insight: The uniform adoption (84%) indicates workflows are built on a common template that includes all safe output capabilities, even if not all are used in practice.

Discussion Categories Usage

Category	Count	Purpose
audits	11	Audit reports and analysis
Audits	3	Alternative casing
ideas	2	Feature suggestions
artifacts	2	Build artifacts summaries
dev	2	Development discussions
daily-news	1	Daily updates
security	1	Security findings
research	1	Research findings

Observation: The "audits" category (14 total with both casings) is the primary destination for workflow outputs, aligning with the audit-focused nature of many workflows.

Structural Characteristics

Job Complexity

• Average Jobs per Workflow: 6.68
• Maximum Jobs: 16 jobs (in one workflow)
• Average Steps per Job: 10.6 steps
• Total Estimated Steps: ~71 steps per workflow on average

Interpretation: Workflows are moderately complex with multiple jobs coordinating different aspects of analysis. The high step count indicates detailed, multi-phase operations within each job.

Timeout Configuration

• Average Timeout: 14.71 minutes
• Minimum Timeout: 5 minutes
• Maximum Timeout: 30 minutes

Insight: Conservative timeout settings (under 15 minutes on average) suggest workflows are optimized for quick feedback. The 30-minute maximum accommodates intensive analysis tasks.

Average Lock File Structure

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

• Size: ~200 KB
• Jobs: ~7 jobs
• Steps per Job: ~11 steps
• Timeout: ~15 minutes
• Triggers: 2-3 triggers (commonly schedule + workflow_dispatch)
• Permissions: Contents: read, plus 3-4 additional read permissions
• MCP Servers: GitHub (primary), occasionally playwright/deepwiki
• Safe Outputs: All 7 types configured
• Concurrency: Group-based concurrency control

Permission Patterns

Most Common Permissions

Permission	Count	Type	Usage
contents: read	261	Read	Repository content 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	23	Write	Push changes to repository
discussions: read	14	Read	Read discussions
security-events: read	8	Read	Security scanning results

Permission Distribution

• Read-only focused: 175 read permissions vs 209 write permissions
  • Contents: 261 read, 23 write (11:1 ratio)
  • Issues: 122 read, 71 write (1.7:1 ratio)
  • Pull Requests: 124 read, 54 write (2.3:1 ratio)

Security Posture: Workflows follow least-privilege principles with heavy emphasis on read access. Write permissions are primarily for creating discussions and issues (safe outputs) rather than code changes.

Tool & MCP Patterns

MCP Server Usage

MCP Server	Count	Percentage	Purpose
github	64	92.8%	GitHub API integration
playwright	2	2.9%	Web browser automation
deepwiki	1	1.4%	Wikipedia/knowledge base access
arxiv	1	1.4%	Academic paper research

Observations:

• GitHub dominance: 93% of workflows rely on GitHub MCP for repository operations
• Specialized tools: playwright, deepwiki, and arxiv appear in niche workflows requiring web scraping or research capabilities
• Integration depth: The github MCP server provides extensive tooling (file contents, commits, PRs, issues, discussions, search, etc.)

Firewall-Protected Workflows

4 workflows implement firewall protection:

• dev.firewall.lock.yml
• daily-firewall-report.lock.yml
• firewall.lock.yml
• smoke-copilot.firewall.lock.yml

Purpose: Firewall workflows add security layers for sensitive operations or external integrations.

Interesting Findings

1. Universal Concurrency Control

All 69 workflows (100%) implement concurrency settings, preventing duplicate runs and resource conflicts. This demonstrates mature workflow orchestration practices.

2. Template-Driven Development

The uniform distribution of safe output types (58 workflows with all 7 types) suggests workflows are generated from or follow consistent templates, promoting best practices and maintainability.

3. Schedule vs. Manual Balance

With 27 workflows using schedule + workflow_dispatch combination, there's a clear pattern of "automated by default, manual when needed" - allowing proactive monitoring with manual override capability.

4. Size Inflation

65% of lock files exceed 200 KB, significantly larger than typical GitHub Actions workflows. This is attributed to:

• Extensive prompt engineering instructions embedded in workflows
• Rich MCP configurations and tool allowlists
• Multiple jobs with detailed step definitions
• Comprehensive error handling and safe output configurations

5. Read-Heavy Permission Model

With read permissions outnumbering write permissions significantly for core resources (contents, PRs, issues), workflows emphasize analysis and reporting over modification, aligning with agentic assistant use cases.

6. Minimal Cron Diversity

Only 2 distinct cron patterns detected, with most schedules likely using GitHub's schedule feature without explicit cron expressions. The "every 10 minutes" pattern (3 workflows) indicates high-priority monitoring tasks.

7. Scout & Q: Super Workflows

scout.lock.yml and q.lock.yml stand out as universal assistants responding to 6-7 different event types, making them the most versatile workflows in the repository.

Historical Trends

Comparing with the previous analysis (2025-11-01):

Metric	Previous (11/01)	Current (11/02)	Change
Total Files	68	69	+1 file (+1.5%)
Average Size	196.9 KB	199.74 KB	+2.84 KB (+1.4%)
Total Size	13.08 MB	13.46 MB	+0.38 MB (+2.9%)
Large Files (100-200KB)	16	13	-3 files
Huge Files (>200KB)	42	45	+3 files
Workflows with Schedule	33	33	No change
MCP GitHub Usage	63	64	+1 workflow

Trend Analysis:

• Growth: Repository added 1 new lock file (likely example-permissions-warning.lock.yml or similar)
• Size increase: Average file size grew by 1.4%, with 3 workflows crossing the 200KB threshold
• Stability: Core metrics (schedules, triggers, permissions) remain stable
• MCP adoption: GitHub MCP usage increased by 1, maintaining 93% penetration

Recommendations

1. Standardize Discussion Categories

With "audits" and "Audits" both in use, consider standardizing on lowercase "audits" for consistency across all workflows.

2. Optimize Lock File Sizes

With 65% of files exceeding 200 KB, investigate:

• Extracting common prompt instructions to shared files
• Referencing external documentation instead of embedding full instructions
• Identifying and removing unused safe output configurations

3. Expand MCP Server Diversity

With 93% GitHub MCP usage, explore opportunities to integrate:

• Additional MCP servers for code analysis, documentation, or external APIs
• Custom MCP servers for domain-specific operations
• Broader use of playwright for UI testing workflows

4. Document Trigger Patterns

Create a decision matrix for when to use:

• schedule only (fully automated monitoring)
• workflow_dispatch only (on-demand tools)
• Combined triggers (flexible automation)
• Event-driven triggers (reactive assistants)

5. Right-Size Timeouts

With average timeout at 14.7 minutes but max at 30, review workflows approaching the limit to:

• Identify performance bottlenecks
• Split long-running analyses into multiple jobs
• Consider if timeout increases are justified

6. Leverage Historical Data

The cache memory now contains trend data from 2025-10-26 onwards. Implement automated trend reporting to:

• Track growth patterns over time
• Identify workflows with size creep
• Monitor permission scope changes

Methodology

Data Collection

• Source: All .lock.yml files in .github/workflows/, .github/workflows/shared/, and .github/workflows/shared/mcp/
• Tools: Python 3 with regex parsing, JSON data structures
• Date: 2025-11-02
• Lock Files Analyzed: 69

Analysis Techniques

• File size: OS-level stat() calls
• Trigger extraction: Regex pattern matching on YAML "on:" sections
• Safe outputs: String search for mcp__safeoutputs patterns
• Permissions: Regex extraction of permission declarations
• MCP servers: Pattern matching for mcp__ prefixes
• Statistical calculations: Python Counter and defaultdict for aggregation

Cache Memory

Analysis scripts and historical data are persisted in /tmp/gh-aw/cache-memory/:

• Scripts: scripts/analyze_lockfiles.py (main analysis)
• Historical Data: history/2025-11-02.json (today's results)
• Pattern Library: Reusable regex patterns for common extractions

Limitations

• Cron patterns are under-reported (only explicitly defined schedules captured)
• Steps per job is estimated based on "- name:" occurrences
• Safe output usage doesn't distinguish between configured vs. actively used
• MCP server detection relies on naming patterns (mcp__server__)

---

Generated by Lockfile Statistics Analysis Agent on 2025-11-02 at 03:27 UTC
Analysis based on 69 .lock.yml files totaling 13.46 MB
Cache: /tmp/gh-aw/cache-memory/ | History: history/2025-11-02.json

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.