📊 Agentic Workflow Lock File Statistics - October 28, 2025

[github-actions[bot]]

📊 Agentic Workflow Lock File Statistics - October 28, 2025

This analysis examines all 59 .lock.yml files in the githubnext/gh-aw repository to identify usage patterns, structural characteristics, and best practices across agentic workflows.

Executive Summary

The repository contains 59 agentic workflow lock files totaling approximately 11.5 MB of workflow definitions. Most workflows (54%) exceed 200 KB in size, indicating rich, comprehensive agent configurations. The dominant trigger combination is workflow_dispatch + schedule + issues + pull_request (30%), showing workflows designed for both manual and automated execution across multiple GitHub event types.

Key Findings:

• Safe outputs are heavily utilized: 259 safe output declarations across all workflows, with create-pull-request (68 instances) being the most popular
• Pull request workflows dominate: 86% of workflows respond to pull request events
• Flexible execution: 81% support manual triggering via workflow_dispatch
• Scheduled automation: 49% include cron schedules for periodic execution

Full Report Details

File Size Distribution

Size Range	Count	Percentage	Notes
< 10 KB	0	0.0%	-
10-50 KB	1	1.7%	Minimal shared configurations
50-100 KB	7	11.9%	Simple workflows with basic configs
100-200 KB	19	32.2%	Standard workflows with moderate complexity
> 200 KB	32	54.2%	Most common: Rich, full-featured workflows

File Size Statistics:

• Total Files: 59
• Total Size: ~11.5 MB
• Average: 195 KB per workflow
• Smallest: .github/workflows/shared/opencode.lock.yml (23 KB) - shared configuration fragment
• Largest: .github/workflows/poem-bot.lock.yml (361 KB) - complex creative content generator
• Second Largest: .github/workflows/q.lock.yml (292 KB) - question answering workflow
• Third Largest: .github/workflows/unbloat-docs.lock.yml (273 KB) - documentation optimizer

Size by Workflow Category:

• Daily workflows (6 workflows): Average 219 KB - larger due to comprehensive reporting needs
• Smoke test workflows (6 workflows): Average 186 KB - smaller, focused on testing
• Regular workflows (44 workflows): Average 210 KB - standard production workflows

Trigger Analysis

Trigger Type Distribution

Trigger Type	Workflows	Percentage	Use Case
pull_request	51	86.4%	Code review, automated checks, PR analysis
workflow_dispatch	48	81.4%	Manual triggering, testing, on-demand tasks
issues	38	64.4%	Issue triage, classification, automated responses
schedule	29	49.2%	Daily reports, periodic maintenance, monitoring
push	2	3.4%	Rare - most workflows avoid push triggers

Most Common Trigger Combinations

Combination	Count	Percentage	Description
workflow_dispatch + schedule + issues + pull_request	18	30.5%	Most versatile: Responds to all major events plus manual trigger
workflow_dispatch + schedule + pull_request	11	18.6%	PR-focused with periodic execution
workflow_dispatch + issues + pull_request	9	15.3%	Interactive workflows for issues and PRs
issues + pull_request	8	13.6%	Automated responders (no manual trigger)
workflow_dispatch only	4	6.8%	Manual-only workflows
workflow_dispatch + pull_request	3	5.1%	PR workflows with manual override
workflow_dispatch + issues + pull_request + push	2	3.4%	Comprehensive trigger coverage
workflow_dispatch + issues	1	1.7%	Issue-focused with manual trigger

Insight: The prevalence of workflow_dispatch (81%) indicates a strong preference for manual control and testing capability, even in automated workflows.

Schedule Patterns

29 workflows use cron schedules for periodic execution. Common patterns:

Schedule (Cron)	Count	When it Runs	Use Case
0 0,6,12,18 * * *	5	Every 6 hours (midnight, 6am, noon, 6pm)	High-frequency monitoring
0/10 * * * *	3	Every 10 minutes	Very frequent checks
0 6 * * 0	2	Sundays at 6am	Weekly reports
0 2 * * 1-5	2	Weekdays at 2am	Daily business day tasks
0 0 * * *	2	Daily at midnight	Daily reports/cleanup
0 9 * * 1-5	1	Weekdays at 9am	Morning business tasks
0 9 * * 1	1	Mondays at 9am	Weekly start tasks
0 18 * * 1	1	Mondays at 6pm	Weekly summaries
Others	12	Various times	Diverse scheduling needs

Notable Patterns:

• 6-hour intervals (5 workflows): Continuous monitoring workflows
• Weekday-only schedules (4 workflows): Business-hour focused automation
• Weekly schedules (3 workflows): Lower-frequency summaries and reports

Safe Outputs Analysis

Safe outputs are a critical security feature that allows agentic workflows to produce outputs without requiring write permissions to the repository code. The analysis shows 259 safe output declarations across all workflows.

Safe Output Types Distribution

Safe Output Type	Count	Percentage	Primary Use Case
create-pull-request	68	26.3%	Code changes, automated fixes, refactoring
create-issue	64	24.7%	Bug reports, suggestions, tracking items
create-discussion	63	24.3%	Reports, summaries, audit findings
add-comment	59	22.8%	PR reviews, issue responses, feedback
update-issue	5	1.9%	Issue state updates, adding information

Key Observations:

• Balanced distribution: All major safe output types are used extensively (~22-26% each)
• PR creation leads: Slight preference for creating pull requests, suggesting code-focused workflows
• Discussion creation is popular: 24% usage shows discussions are a valued output channel for reports and audits
• Comment addition is common: Used in nearly every workflow for contextual feedback

Safe Output Combinations

Many workflows use multiple safe output types to provide flexible response options:

• 31 workflows use 3 or more safe output types (multi-modal output capability)
• 19 workflows use all 4 major types (create-discussion, create-issue, add-comment, create-pull-request)
• 5 workflows use update-issue in addition to other types (state management)

Most Common Combinations:

1. create-discussion + create-issue + add-comment + create-pull-request (19 workflows) - Full flexibility
2. create-discussion + create-issue + add-comment (12 workflows) - Read-only oriented
3. create-issue + add-comment (8 workflows) - Issue-focused

Discussion Categories

Discussion categories are not consistently extracted from the lock files in this analysis, suggesting they may be dynamically determined or configured elsewhere. Manual inspection of specific workflows would be needed for category distribution.

Structural Characteristics

Job and Step Complexity

• Average Steps per Workflow: 56.2 steps
• Maximum Steps in Single Workflow: 101 steps in poem-bot.lock.yml
• Step Distribution:
  • Smallest workflows: ~15-20 steps (shared configs, test workflows)
  • Typical workflows: 50-60 steps (standard agent workflows)
  • Largest workflows: 80-100 steps (complex multi-stage workflows)

Note: Job counting requires refinement as current analysis shows 0 jobs per workflow. Lock files likely use a different job structure than standard GitHub Actions workflows. Further investigation needed.

Timeout Patterns

Workflow step timeouts show a clear pattern of short, bounded execution times:

Timeout (minutes)	Step Count	Percentage	Use Case
10	138	51.1%	Most common: Standard agent execution
20	59	21.9%	Extended processing time
5	55	20.4%	Quick tasks, simple checks
15	11	4.1%	Moderate complexity tasks
30	5	1.9%	Long-running analysis
60	1	0.4%	Maximum timeout (rare)
12	1	0.4%	Custom timeout

Key Insights:

• 10-minute default: Over half of all steps use 10-minute timeout, indicating this is the standard agent execution window
• Conservative timeouts: 93% of steps complete within 20 minutes, showing efficient agent design
• Rare long timeouts: Only 2% of steps need 30+ minutes, suggesting most tasks are well-scoped

Permission Patterns

Permission Pattern	Count	Percentage	Security Posture
permissions: read-all	5	8.5%	Read-only access to all repository data
Explicit permissions	54	91.5%	Fine-grained permission control

Security Observation: The overwhelming majority (91.5%) of workflows use explicit permission declarations rather than broad read-all or write-all permissions, demonstrating strong security practices.

The workflows with read-all permissions:

1. ci-doctor.lock.yml (2 occurrences)
2. copilot-agent-analysis.lock.yml (2 occurrences)
3. daily-news.lock.yml (2 occurrences)
4. smoke-detector.lock.yml (2 occurrences)
5. technical-doc-writer.lock.yml (2 occurrences)

These appear to be analysis and reporting workflows that need broad read access to repository data.

Concurrency Patterns

Most workflows use concurrency groups to prevent multiple simultaneous runs:

Common Patterns:

• group: "gh-aw-${{ github.workflow }}" - Standard pattern for agentic workflows
• group: "gh-aw-copilot-${{ github.workflow }}" - Copilot-specific workflows
• group: "gh-aw-claude-${{ github.workflow }}" - Claude-specific workflows

This ensures that each workflow type runs serially, preventing resource conflicts and duplicate work.

Tool & MCP Patterns

Engine Distribution

Analysis of engine references across lock files:

Engine/Model	References	Notes
claude	284	Generic Claude model references
claude-code	83	Claude Code-specific references
claude-*	34	Various Claude model versions
claude-3-5-sonnet-20241022	6	Specific model version references

Observations:

• Claude dominates: Claude-family models are referenced 407 times total
• Copilot presence: 42 workflows mention copilot
• GPT minimal: Only 2 workflows reference GPT models

MCP Server Usage

MCP (Model Context Protocol) server extraction requires refinement. Initial analysis shows MCP configurations are present but specific server names are not consistently captured. Manual inspection suggests common servers include:

• GitHub MCP server (for repository operations)
• Web search/fetch servers
• Custom domain-specific servers

Further analysis needed for detailed MCP server statistics.

Workflow Categorization

By Naming Pattern

Category	Count	Average Size	Purpose
Daily Workflows	6	219 KB	daily-* - Scheduled daily tasks (news, reports, improvements)
Smoke Tests	6	186 KB	smoke-* - Testing different engines (claude, copilot, codex, opencode)
Test Workflows	3	81 KB	test-* - Integration and feature tests
Firewall Workflows	3	165 KB	*.firewall.* - Security-enhanced variants
Regular Workflows	44	210 KB	Standard production workflows

By Function

Analysis & Auditing (13 workflows):

• audit-workflows.lock.yml, blog-auditor.lock.yml, lockfile-stats.lock.yml, safe-output-health.lock.yml, commit-changes-analyzer.lock.yml, copilot-agent-analysis.lock.yml, example-workflow-analyzer.lock.yml, artifacts-summary.lock.yml, etc.

Code Quality & Improvement (12 workflows):

• ci-doctor.lock.yml, daily-test-improver.lock.yml, daily-perf-improver.lock.yml, duplicate-code-detector.lock.yml, semantic-function-refactor.lock.yml, go-pattern-detector.lock.yml, go-logger.lock.yml, tidy.lock.yml, etc.

Documentation (6 workflows):

• technical-doc-writer.lock.yml, unbloat-docs.lock.yml, daily-doc-updater.lock.yml, instructions-janitor.lock.yml, repo-tree-map.lock.yml, video-analyzer.lock.yml

Issue & PR Management (8 workflows):

• issue-classifier.lock.yml, mergefest.lock.yml, plan.lock.yml, security-fix-pr.lock.yml, changeset-generator.firewall.lock.yml

Reporting & Summaries (7 workflows):

• daily-news.lock.yml, daily-repo-chronicle.lock.yml, weekly-issue-summary.lock.yml, notion-issue-summary.lock.yml, daily-firewall-report.lock.yml, github-mcp-tools-report.lock.yml

Research & Development (5 workflows):

• research.lock.yml, scout.lock.yml, dev.lock.yml, dev-hawk.lock.yml, q.lock.yml

Specialized Tools (8 workflows):

• poem-bot.lock.yml, pdf-summary.lock.yml, mcp-inspector.lock.yml, brave.lock.yml, dictation-prompt.lock.yml, schema-consistency-checker.lock.yml, cli-version-checker.lock.yml

Interesting Findings

1. Uniform Large Size: 86% of workflows exceed 100 KB, suggesting the lock file format includes substantial boilerplate or comprehensive configuration. This could indicate opportunities for:

   • Shared configuration inheritance
   • Configuration templating
   • Extraction of common patterns

2. Pull Request Focus: With 86% of workflows responding to pull requests, this repository heavily emphasizes code review and PR-based workflows, making it ideal for:

   • Automated code review
   • PR triage and classification
   • Continuous integration checks
   • Code quality enforcement

3. Safe Output Adoption: The consistent use of safe outputs (259 declarations) across workflows demonstrates mature security practices. The balanced distribution suggests workflows are designed to output in whatever format suits the context best.

4. Trigger Versatility: 30% of workflows support all four major trigger types (workflow_dispatch, schedule, issues, pull_request), showing a "Swiss Army knife" approach where workflows can handle multiple activation patterns.

5. Conservative Timeouts: 93% of steps complete within 20 minutes, with the 10-minute timeout being most common. This suggests:

   • Agents are given bounded execution time
   • Tasks are well-scoped and focused
   • Long-running analyses are broken into smaller steps

6. Named Workflow Patterns: The repository shows clear organizational patterns with prefixes like daily-, smoke-, and suffixes like .firewall., making workflows discoverable and their purpose immediately clear.

7. The "Poem Bot" Anomaly: The largest workflow at 361 KB (poem-bot.lock.yml) is significantly larger than average and includes 101 steps - the most in any workflow. This suggests complex creative content generation requires more elaborate orchestration.

8. Minimal Push Triggers: Only 2 workflows (3.4%) use push triggers, showing intentional design to avoid continuous execution on every commit. This conserves resources and reduces noise.

9. High-Frequency Monitoring: 5 workflows run every 6 hours, and 3 run every 10 minutes, indicating active monitoring and rapid response capabilities for critical workflows.

10. Shared Configurations: The presence of .github/workflows/shared/ with small lock files (23-81 KB) suggests a pattern of configuration composition and reuse across workflows.

Recommendations

Based on this analysis, here are recommendations for optimizing and improving agentic workflows in this repository:

1. Configuration Optimization

• Extract Common Patterns: With 86% of workflows over 100 KB, consider extracting common configuration blocks into shared templates
• Investigate Lock File Size: Analyze why lock files are uniformly large - opportunities for compression or optimization may exist
• Expand Shared Configs: The shared/ directory pattern shows promise - consider more shared workflow fragments

2. Trigger Strategy

• Document Trigger Choices: Create guidelines for when to use each trigger combination
• Consider Consolidation: 18 workflows use the same 4-trigger combination - could some be merged or parameterized?
• Push Trigger Policy: Document why push triggers are avoided (appears intentional - codify the rationale)

3. Safe Output Consistency

• Standardize Safe Output Types: All workflows should offer at least 2-3 safe output options for flexibility
• Document Category Choices: For create-discussion, establish and document standard categories
• Safe Output Testing: Create smoke tests specifically for safe output functionality

4. Performance & Timeouts

• 10-Minute Standard: Codify the 10-minute timeout as the recommended default
• Timeout Guidelines: Document when to use 5, 10, 15, 20, or 30-minute timeouts
• Monitor Timeout Patterns: Track which workflows frequently approach their timeout limits

5. Security & Permissions

• Permission Audit: The 5 workflows with read-all permissions should be reviewed to ensure they truly need broad access
• Least Privilege: Continue the strong pattern of explicit, minimal permissions
• Firewall Workflows: Consider whether more workflows should have .firewall variants for sensitive operations

6. Monitoring & Observability

• Workflow Health Dashboard: Create a dashboard tracking workflow execution patterns, success rates, and timeout trends
• Safe Output Health: The safe-output-health.lock.yml workflow is valuable - ensure it runs regularly
• Audit Workflows: Continue investing in audit workflows like audit-workflows.lock.yml and lockfile-stats.lock.yml

7. Documentation

• Workflow Catalog: Create a catalog documenting each workflow's purpose, triggers, and outputs
• Naming Conventions: Document the daily-, smoke-, test-, and .firewall. naming conventions
• Onboarding Guide: For new workflow authors, provide templates and best practices from this analysis

8. Testing

• Expand Smoke Tests: Currently 6 smoke test workflows - consider adding more for comprehensive engine coverage
• Safe Output Integration Tests: Test each safe output type in isolation and combination
• Trigger Testing: Ensure workflows respond correctly to all their declared triggers

9. Schedule Optimization

• Consolidate High-Frequency Runs: Consider whether 5 workflows need to run every 6 hours, or if some can be less frequent
• Stagger Schedules: Ensure high-frequency workflows don't all start at the same time (resource contention)
• Weekend Schedules: Only 2 workflows run on weekends - consider if others should adapt for weekday-only operation

10. Future Analysis

• MCP Server Deep Dive: Conduct detailed analysis of which MCP servers are most used and effective
• Job Structure Investigation: Current analysis shows 0 jobs - investigate the actual job structure in lock files
• Cost Analysis: Correlate workflow size, frequency, and complexity with execution costs
• Success Rate Tracking: Track which workflow patterns have the highest success rates

Methodology

Tools Used:

• Bash shell scripts for file traversal and pattern extraction
• grep, awk, sed for text processing and pattern matching
• stat for file size analysis
• Custom analysis scripts stored in /tmp/gh-aw/cache-memory/scripts/

Data Sources:

• 59 .lock.yml files in .github/workflows/ and .github/workflows/shared/
• File metadata (sizes, modification times)
• YAML structure analysis (triggers, permissions, steps, safe outputs)

Limitations:

• Job counting methodology needs refinement (currently reports 0 jobs)
• MCP server extraction is incomplete
• Discussion category extraction did not capture data consistently
• Some lock file structures may use patterns not covered by current regex/grep patterns

Reproducibility:

• All analysis scripts saved to /tmp/gh-aw/cache-memory/scripts/
• Analysis date saved to /tmp/gh-aw/cache-memory/data/last_analysis_date.txt
• Raw data files saved to /tmp/gh-aw/cache-memory/data/

Future Improvements:

• Implement full YAML parser for more accurate structure analysis
• Add historical trend tracking across multiple analysis runs
• Create interactive dashboard for workflow statistics
• Correlate workflow patterns with success rates and execution costs

---

Generated by Lockfile Statistics Analysis Agent on 2025-10-28
Repository: githubnext/gh-aw
Analysis Run: §18863056700
Lockfiles Analyzed: 59
Total Size: ~11.5 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 month ago.