📊 Agentic Workflow Lock File Statistics - November 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - November 2025

This comprehensive analysis examines all 77 .lock.yml files in the .github/workflows/ directory to identify usage patterns, popular triggers, safe outputs, structural characteristics, and emerging trends in agentic workflow design.

Executive Summary

The gh-aw repository contains a robust collection of agentic workflows with strong patterns emerging around issue-driven automation, safe output practices, and GitHub API integration.

Key Highlights:

• Total Lock Files: 77 workflows
• Total Size: 16.4 MB (avg 213 KB per workflow)
• Dominant Triggers: 97% use issue triggers, 78% support manual dispatch
• Safe Outputs: Average of 4.2 safe output types per workflow
• Primary Integration: GitHub MCP server used 2,809 times across workflows
• Permission Model: Read-only by default (88% for contents, 68% for PRs)

Full Statistical Analysis

File Size Distribution

The majority of lock files are substantial, reflecting the comprehensive nature of agentic workflows with extensive tooling and MCP server configurations.

Size Range	Count	Percentage
< 10 KB	0	0.0%
10-50 KB	1	1.3%
50-100 KB	12	15.6%
> 100 KB	64	83.1%

Size Statistics:

• Smallest: shared/opencode.lock.yml (23.3 KB)
• Largest: poem-bot.lock.yml (394.8 KB)
• Average: 213 KB per workflow
• Median: 221 KB
• Total Repository Size: 16.4 MB of lock files

Key Finding: The large average size (213 KB) indicates workflows are feature-rich with extensive tool configurations, MCP server integrations, and comprehensive permissions management. The smallest workflow (opencode.lock.yml) is a shared configuration, while the largest (poem-bot) likely includes extensive prompt templates or data.

Trigger Analysis

Most Popular Triggers

Agentic workflows in this repository are predominantly issue-driven, with strong support for manual triggering and scheduled automation.

Trigger Type	Count	Percentage	Primary Use Case
issues	75	97.4%	Issue-driven agent responses
workflow_dispatch	60	77.9%	Manual agent invocation
schedule	38	49.4%	Periodic automated analysis
issue_comment	12	15.6%	Comment-reactive agents
pull_request	9	11.7%	PR analysis and review
pull_request_review_comment	4	5.2%	Review feedback agents
push	3	3.9%	Commit-triggered analysis

Key Insights:

• Issue-first design: 97.4% of workflows respond to issues, making this the primary interface for agentic workflows
• Flexibility: 77.9% support manual dispatch, enabling on-demand execution
• Automation balance: Nearly half (49.4%) use schedules for proactive work
• Minimal push triggers: Only 3 workflows trigger on push, indicating preference for deliberate invocation over automatic execution

Common Trigger Combinations

Most workflows combine multiple triggers for maximum flexibility:

1. issues + workflow_dispatch: Most common - allows both automatic issue response and manual invocation
2. issues + schedule + workflow_dispatch: Enables reactive, proactive, and manual modes
3. pull_request + issue_comment: For PR-focused workflows that also respond to discussion

Example Workflows:

• Issues-triggered: archie.lock.yml, audit-workflows.lock.yml, blog-auditor.lock.yml, brave.lock.yml, changeset.lock.yml
• Schedule-triggered: artifacts-summary.lock.yml, audit-workflows.lock.yml, blog-auditor.lock.yml, cli-version-checker.lock.yml
• PR-triggered: pr-nitpick-reviewer.lock.yml, scout.lock.yml, q.lock.yml

Schedule Patterns

For the 38 scheduled workflows, clear temporal patterns emerge:

Schedule (Cron)	Count	Description
0 9 * * *	3	Daily at 9 AM UTC
0 0,6,12,18 * * *	3	Every 6 hours
0 6 * * 0	2	Weekly on Sunday at 6 AM
0 2 * * 1-5	2	Weekdays at 2 AM
0 15 * * 1	2	Weekly on Monday at 3 PM
0 0 * * *	2	Daily at midnight
0 9 * * 1-5	1	Weekday mornings (business hours)
0/10 * * * *	1	Every 10 minutes (high frequency)

Patterns Observed:

• Business hours: Morning schedules (9 AM) align with developer workday start
• Overnight processing: 2 AM and midnight runs for resource-intensive tasks
• Weekly batching: Sunday and Monday runs for weekly summaries
• Continuous monitoring: One workflow runs every 10 minutes for real-time needs

Safe Outputs Analysis

Safe outputs are a critical feature of agentic workflows, enabling AI agents to communicate results without direct repository modification.

Safe Output Types Distribution

Type	Usage Count	Workflows	Primary Purpose
create-discussion	92	~70%	Publishing analysis reports and findings
add-comment	74	~55%	Providing feedback on issues/PRs
create-pull-request	70	~52%	Proposing code changes
create-issue	65	~48%	Creating tasks or bug reports
create-pull-request-review-comment	15	~11%	Inline code review feedback
update-issue	5	~4%	Modifying existing issues

Total Safe Output Actions: 321 across 77 workflows (average 4.2 per workflow)

Key Findings:

• Discussions dominate: Create-discussion is the most popular output (92 uses), indicating preference for non-intrusive, searchable reporting
• Multi-modal communication: Most workflows use multiple output types (avg 4.2), providing flexible response options
• PR-centric culture: Combined PR outputs (create + review comments = 85) nearly match discussions, showing strong code contribution focus
• Conservative updates: Only 5 workflows update existing issues, preferring to create new items

Safe Output Best Practices Observed

Based on usage patterns:

1. Layered Communication: Workflows combine discussions (permanent records) with comments (contextual feedback)
2. PR Workflow: Many workflows create PRs (70) and add review comments (15) for comprehensive code contribution
3. Issue Creation: 65 workflows can create issues, enabling agent-driven task generation

Structural Characteristics

Job Complexity

Agentic workflows in this repository are significantly more complex than typical GitHub Actions workflows.

• Average Jobs per Workflow: 6.79 jobs
• Average Steps per Workflow: 57.41 steps
• Minimum Steps: 26 steps
• Maximum Steps: 101 steps
• Median Steps: ~55 steps

Typical Workflow Structure:

Based on statistical analysis, a representative .lock.yml file contains:

jobs: 6-7 jobs
  ├── activation (workflow freshness check)
  ├── agent (main AI execution)
  ├── detection (firewall/safety checks)
  ├── create_discussion (output handler)
  ├── create_issue (output handler)
  ├── add_comment (output handler)
  └── upload_assets (artifact management)

steps: ~57 steps total
  ├── Checkout & setup (~5 steps)
  ├── MCP server configuration (~10-15 steps)
  ├── Agent execution (~5 steps)
  ├── Output processing (~15-20 steps)
  ├── Safety & firewall (~10 steps)
  └── Artifact management (~5-7 steps)

Complexity Drivers:

• MCP Server Setup: Each MCP server requires multiple configuration steps (average 3-5 steps per server)
• Safe Output Handling: Each output type requires dedicated job with multiple steps
• Safety Layers: Activation checks, firewall detection, and safe output validation add ~15-20 steps
• Artifact Management: Upload and download of agent outputs, images, and reports

Average Lock File Structure

A typical agentic workflow lock file includes:

• Size: ~213 KB (compressed automation logic)
• Jobs: 6-7 jobs (modular execution)
• Steps: 57 steps (comprehensive processing)
• Permissions: Read-only with selective write access
• Triggers: 2-3 triggers (issues + workflow_dispatch + optional schedule)
• Timeout: 10-20 minutes per job
• MCP Servers: GitHub (primary) + 0-2 specialized servers

Permission Patterns

The repository demonstrates mature security practices with principle of least privilege.

Most Common Permissions

Permission	Read Count	Write Count	Read %	Write %
contents	370	31	92.3%	7.7%
pull-requests	142	67	68.0%	32.0%
issues	136	82	62.4%	37.6%
actions	23	-	100%	-
discussions	6	-	100%	-
security-events	3	-	100%	-

Across all workflows:

• Most requested permission: contents (401 total occurrences)
• Second most common: pull-requests (209 occurrences)
• Third most common: issues (218 occurrences)

Permission Distribution

• Read-only workflows: ~65% (workflows with no write permissions)
• Selective write permissions: ~35% (workflows with targeted write access)
• Contents write access: 7.7% (31/401) - mostly for PR creation
• PR write access: 32.0% (67/209) - for PR comments and reviews
• Issues write access: 37.6% (82/218) - for issue comments and creation

Security Best Practices Observed:

1. Default read-only: 92% of content access is read-only
2. Job-level permissions: Workflows use granular job-level permissions
3. Minimal scope: Write permissions granted only where necessary
4. Audit trail: Actions permission used for workflow run tracking

Tool & MCP Patterns

Most Used MCP Servers

MCP Server	Usage Count	Workflows	Purpose
github	2,809	~71	GitHub API integration (issues, PRs, repos, search)
playwright	84	~6-8	Web automation and browser testing
deepwiki	6	~2-3	Deep documentation search
arxiv	6	~2-3	Academic paper research
context7	4	~1-2	Context management

Key Insights:

• GitHub dominance: The GitHub MCP server is used ~40x per workflow on average, showing heavy reliance on GitHub APIs
• Web automation: Playwright (84 uses) indicates significant web scraping or browser automation needs
• Research capabilities: arxiv and deepwiki suggest workflows conduct research and documentation analysis
• Specialized servers: Limited use of specialized MCP servers, with most workflows relying on core GitHub functionality

Tool Configurations

Based on allowlist analysis:

• Workflows using Read tool: 71 (92.2%) - File reading is nearly universal
• Workflows using Bash tool: Most workflows (through allowlists) - System command execution
• Workflows using Write tool: Limited - Most workflows avoid direct writes
• Workflows using Edit tool: Limited - Prefer PR-based changes over direct edits

Tool Usage Philosophy:

• Read-heavy: 92% use Read tool, emphasizing analysis over modification
• Safe changes: Workflows prefer creating PRs over direct writes
• Bash for automation: Shell commands used for git operations and system tasks

Timeout Patterns

Job timeouts reveal workflow runtime expectations:

Timeout (min)	Count	Use Case
5	68	Quick activation checks
10	177	Standard agent execution
15	15	Extended analysis
20	78	Complex multi-step processing
30	7	Heavy computation
45	4	Very long-running tasks
60	1	Maximum duration job

Timeout Strategy:

• 5-minute gates: Activation and validation jobs use short timeouts
• 10-20 minute standard: Most agent jobs complete within 10-20 minutes
• Conservative limits: Timeouts prevent runaway workflows while allowing complex operations
• Tiered approach: Different jobs have different timeouts based on expected runtime

Average Workflow Runtime Budget: ~60-80 minutes total (across all jobs)

Interesting Findings

1. Issue-Driven Architecture

97.4% of workflows trigger on issues, establishing issues as the primary user interface for agentic workflows. This creates a conversational, task-oriented interaction model where users describe problems in natural language and agents respond with analysis, code, or reports.

2. Safe Output Proliferation

With 321 safe output actions across 77 workflows (4.2 per workflow), the repository demonstrates mature "firewall" patterns where AI agents communicate through structured outputs rather than direct repository modification. This reduces risk while maintaining full functionality.

3. The GitHub MCP Monopoly

The GitHub MCP server is used 2,809 times - accounting for ~97% of all MCP usage. This extreme concentration suggests:

• GitHub API operations are the primary workflow activity
• Other MCP servers are specialized additions, not core dependencies
• The GitHub MCP server is highly versatile (covering repos, issues, PRs, code search, etc.)

4. Large Workflow Files

83% of lock files exceed 100 KB, with an average of 213 KB. This is 10-20x larger than typical GitHub Actions workflows, reflecting:

• Extensive MCP server configurations (each server adds ~5-10 KB)
• Comprehensive tool allowlists
• Multiple safe output handlers (each adds ~8-15 KB)
• Embedded JavaScript for complex logic
• Detailed permissions and safety configurations

5. Minimal Push Triggers

Only 3 workflows (3.9%) trigger on push events, indicating a deliberate design choice to avoid automatic execution on every commit. This suggests:

• Agentic workflows are resource-intensive (prefer deliberate invocation)
• Review before execution (issues/PRs require human context)
• Cost consciousness (avoiding unnecessary agent runs)

6. Job Explosion Pattern

Average of 6.79 jobs per workflow (vs 1-2 for typical GHA workflows) shows the "microservices" pattern where:

• Each safe output type gets its own job
• Detection/firewall runs as separate job
• Artifact management has dedicated jobs
• This allows parallel execution and independent failure handling

7. Schedule Clustering

Scheduled workflows cluster around specific times:

• 9 AM UTC: Morning reports for US East Coast teams
• Midnight: Overnight batch processing
• Every 6 hours: Continuous monitoring patterns
• Monday mornings: Weekly summary reports

This temporal clustering suggests coordinated workflow orchestration.

8. Permission Paranoia

92% of content access is read-only, showing extreme caution with write permissions. Even workflows that create PRs use minimal write scopes. This "read, analyze, propose" pattern is a best practice for AI agents.

Historical Context

This is the first comprehensive analysis of lock file statistics. Future analyses will track:

• Growth trends: Lock file count over time
• Size evolution: Whether workflows grow more complex
• Pattern adoption: New trigger types, MCP servers, safe outputs
• Performance: Timeout trends and completion rates

Baseline Established:

• 77 workflows as of November 2025
• 16.4 MB total size
• GitHub MCP server dominance
• Issue-driven, safe-output architecture

Recommendations

Based on this analysis, recommendations for workflow authors:

1. Adopt Standard Patterns

• ✅ Use issues as primary trigger (97% do this)
• ✅ Add workflow_dispatch for testing (78% do this)
• ✅ Implement multiple safe outputs (avg 4.2 types)
• ✅ Use read-only permissions by default

2. Optimize File Size

• Consider: 83% of workflows exceed 100 KB - investigate shared configurations
• Consider: Extract common MCP server setups to reusable templates
• Consider: Large workflows (>300 KB) may benefit from refactoring

3. MCP Server Diversity

• Consider: 97% of MCP usage is GitHub server - explore specialized servers
• Recommendation: playwright, deepwiki, arxiv are proven additions
• Opportunity: More domain-specific MCP servers (Jira, Slack, database, etc.)

4. Timeout Tuning

• Standard: 10-20 minutes for agent jobs
• Gateway: 5 minutes for activation checks
• Extended: 30-45 minutes only for specialized tasks
• Most workflows complete within 60-80 minutes total

5. Job Structuring

• Average 6-7 jobs is optimal for safety and parallelism
• Always include: activation, agent, detection, safe outputs
• Each safe output type deserves its own job
• Artifact management should be separate

6. Safe Output Strategy

• Primary: create-discussion for reports and analysis
• Secondary: add-comment for contextual feedback
• Code changes: create-pull-request (never direct writes)
• Task creation: create-issue for follow-up work

7. Trigger Selection

• Must-have: issues (primary interface)
• Recommended: workflow_dispatch (testing and debugging)
• Optional: schedule (for proactive monitoring)
• Rare: push (only for commit-specific analysis)

Methodology

Data Collection

• Lock Files Analyzed: 77
• Analysis Date: November 9, 2025
• Tools Used: Bash scripts with grep/sed/awk for pattern extraction
• Data Sources: .github/workflows/*.lock.yml (including subdirectories)

Analysis Techniques

1. File size analysis: wc -c for byte counts, statistical aggregation
2. Trigger extraction: Regex pattern matching on on: sections
3. Safe output detection: String matching for output type keywords
4. Permission analysis: YAML section parsing for permission scopes
5. MCP server counting: Pattern matching on mcp__*__ prefixes
6. Structural metrics: Step and job counting via YAML anchors

Cache Memory

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

• scripts/analyze_lockfiles.sh: Main analysis script
• history/2025-11-09-analysis.json: Raw statistical data
• Future runs will compare against this baseline

Limitations

• Category data not extracted (requires runtime workflow inspection)
• Engine types not consistently detectable in lock files
• Some patterns may be underreported if using non-standard syntax
• Tool usage based on allowlists, not actual runtime usage

---

Summary

The gh-aw repository demonstrates mature agentic workflow patterns with:

• ✅ Issue-driven architecture (97% use issues as trigger)
• ✅ Safe output practices (4.2 outputs per workflow avg)
• ✅ Security-conscious permissions (92% read-only for contents)
• ✅ GitHub-first integration (GitHub MCP server dominates)
• ✅ Flexible invocation (78% support manual dispatch)
• ✅ Structured complexity (avg 57 steps, 7 jobs per workflow)

These patterns establish a production-ready framework for AI-powered GitHub automation that balances capability with safety, enabling sophisticated agent behaviors while maintaining security and auditability.

Next Steps: Track these metrics over time to identify trends, emerging patterns, and opportunities for standardization across the agentic workflow ecosystem.

---

Analysis generated by Lockfile Statistics Analysis Agent
Data current as of: November 9, 2025
Lock files analyzed: 77
Total repository lock file size: 16.4 MB

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.