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

[github-actions[bot]]

This analysis examined all 89 .lock.yml files in the .github/workflows/ directory to identify structural patterns, usage trends, and characteristics of agentic workflows in this repository. The analysis reveals a mature ecosystem of AI-powered workflows with standardized patterns, diverse triggers, and consistent safety mechanisms.

Key Findings:

• 89 total workflows averaging 231 KB per file, representing ~21 MB of workflow definitions
• Copilot is the dominant engine (55% of workflows) followed by Claude (39%) and Codex (5%)
• 96% adoption of security firewall patterns across workflows
• 49% include cache-memory for persistent state across runs
• Highly consistent structure with average of 7 jobs and 60 steps per workflow

Complete Statistical Analysis

Executive Summary

• Total Lock Files: 89
• Total Size: 21,030,296 bytes (~21 MB)
• Average File Size: 236,295 bytes (~231 KB)
• Analysis Date: 2025-11-21
• Repository: githubnext/gh-aw

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0%
10-50 KB	0	0%
50-100 KB	11	12.4%
> 100 KB	78	87.6%

Size Statistics:

• Smallest: test-claude-oauth-workflow.lock.yml (80 KB)
• Largest: poem-bot.lock.yml (416 KB)
• Median Range: 200-300 KB (most common)

Observation: The overwhelming majority (87.6%) of workflows exceed 100 KB, indicating rich, complex agentic systems with extensive configuration and safety mechanisms.

Trigger Analysis

Trigger Type Distribution

Trigger Type	Count	Percentage	Usage Pattern
issues	327 occurrences	93% of workflows	Most common - workflows respond to issue events
pull_request	119 occurrences	87% of workflows	High PR integration for code review and analysis
workflow_dispatch	70 workflows	79%	Manual triggering widely supported
schedule	44 workflows	49%	Daily/weekly automated tasks
push	2 workflows	2%	Rarely used, most avoid automatic commits

Key Insight: The dominance of issues and pull_request triggers (93% and 87% respectively) shows that agentic workflows are primarily event-driven and human-initiated, rather than fully autonomous.

Common Trigger Combinations

1. issues + workflow_dispatch (67 workflows, 75%) - Most popular pattern allowing both automatic and manual execution
2. schedule + workflow_dispatch (43 workflows, 48%) - Daily/weekly tasks with manual override capability
3. issues + pull_request + workflow_dispatch - Comprehensive event coverage

Schedule Patterns

Most Common Cron Schedules:

Schedule (Cron)	Count	Description	Time (UTC)
0 9 * * *	4	Daily at 9 AM	09:00
0 13 * * 1-5	3	Weekdays at 1 PM	13:00 Mon-Fri
0 0,6,12,18 * * *	3	Every 6 hours	00:00, 06:00, 12:00, 18:00
0 9 * * 1-5	2	Weekday mornings	09:00 Mon-Fri
0 10 * * *	2	Daily at 10 AM	10:00

Insight: Scheduled workflows favor business hours (9 AM - 1 PM UTC) and weekday schedules, suggesting they're designed to support human workflows rather than 24/7 automation.

Safe Outputs Analysis

Safe outputs ensure that AI-generated content is reviewed before being published. This is a critical security feature.

Safe Output Types Distribution

Safe Output Type	Workflows	Percentage	Primary Use Case
create-discussion	29	33%	Publishing reports, audits, analysis to discussion forums
add-comment	20	22%	Responding to issues/PRs with context-specific information
create-issue	16	18%	Creating tracking issues for detected problems

Total workflows with safe outputs: 65 (73% of all workflows)

Discussion Categories Used

When creating discussions, workflows most commonly target:

Category	Count	Purpose
audits	12	Security audits, code quality reports
General	4	General announcements and updates
Audits	3	(Case variant of audits)
dev	2	Development-related discussions
artifacts	2	Build artifacts and releases
security	1	Security-specific reports
research	1	Research findings

Note: There's some inconsistency with category naming (e.g., "audits" vs "Audits" vs "audit") that could be standardized.

Workflows with Multiple Safe Outputs

Some workflows use multiple safe output mechanisms for comprehensive reporting. This pattern is less common but indicates sophisticated workflows that need to communicate through multiple channels.

Structural Characteristics

Job Complexity

• Total Jobs Across All Workflows: 652
• Average Jobs per Workflow: 7.3
• Standard Job Pattern: activation → agent → detection → (safe outputs) → conclusion

Common Job Types:

• activation (85 workflows, 96%) - Entry point and validation
• agent (85 workflows, 96%) - Main AI agent execution
• detection (76 workflows, 85%) - Firewall and safety checks
• conclusion (77 workflows, 87%) - Cleanup and summary
• Safe output jobs: create_discussion, create_issue, add_comment

Insight: The near-universal adoption of the activation → agent → detection → conclusion pattern shows strong standardization across the workflow ecosystem.

Step Complexity

• Total Steps Across All Workflows: 5,300
• Average Steps per Workflow: 60
• Maximum Steps in Single Workflow: 101
• Minimum Steps in Workflow: 26

Typical Workflow Structure:

• 5-10 setup steps (checkout, configure, install dependencies)
• 10-20 agent execution steps (LLM invocation, tool usage)
• 5-10 output processing steps (artifact upload, result formatting)
• 5-10 safety and validation steps (firewall, detection)
• 10-20 conclusion steps (cleanup, reporting)

Average Lock File Anatomy

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

• Size: ~231 KB
• Jobs: 7 jobs
• Steps: 60 steps
• Permissions: contents:read, issues:read, pull-requests:read (read-heavy)
• Triggers: issues + workflow_dispatch (most common)
• Timeout: 10-20 minutes per job
• Concurrency: Workflow-specific group to prevent overlaps

Permission Patterns

Permission Frequency Analysis

Permission	Read	Write	Total Uses	Read/Write Ratio
contents	497	35	532	14.2:1
issues	140	165	305	0.8:1
pull-requests	148	141	289	1.0:1
discussions	0	151	151	0:1

Permission Distribution Insights

• Read-Heavy Pattern: contents permission shows a 14:1 read/write ratio, indicating workflows primarily read code but rarely modify it
• Balanced Issue/PR Permissions: Nearly equal read/write for issues and PRs, reflecting interactive workflows that both read context and post responses
• Write-Only Discussions: Discussions are write-only, used purely as output channels
• Security Posture: The read-heavy approach (91% read, 9% write for contents) demonstrates principle of least privilege

Permission Combinations

Most workflows follow one of these patterns:

1. Read-Only Analysis (35 workflows): contents:read, issues:read, pull-requests:read
2. Interactive Responder (28 workflows): Add issues:write, pull-requests:write
3. Discussion Publisher (29 workflows): Add discussions:write
4. Full Access (5 workflows): Include contents:write for automated fixes

Engine Distribution

The repository uses three primary AI engines to power workflows:

Engine	Workflows	Percentage	Concurrency Group Pattern
Copilot	67	55%	gh-aw-copilot-${{ github.workflow }}
Claude	48	40%	gh-aw-claude-${{ github.workflow }}
Codex	6	5%	gh-aw-codex-${{ github.workflow }}

Note: Some workflows may use multiple engines, so total > 100%

Engine Selection Patterns:

• Copilot: Most popular, likely default choice for general-purpose tasks
• Claude: Strong showing (40%), often chosen for complex analysis and reasoning tasks
• Codex: Minimal usage (5%), possibly deprecated or specialized use cases

Timeout Patterns

Workflow jobs use timeouts to prevent runaway executions:

Timeout (minutes)	Frequency	Percentage	Use Case
10 minutes	206	49%	Standard jobs (default)
20 minutes	99	24%	Complex agent tasks
5 minutes	83	20%	Quick tasks (activation, detection)
15 minutes	16	4%	Extended analysis
30+ minutes	13	3%	Very complex workflows

Average Timeout: ~12 minutes across all jobs

Insight: The clustering around 5-10-20 minute timeouts shows deliberate tiering of job complexity, with most jobs completing quickly (10 min) but allowances for complex AI tasks (20+ min).

Concurrency Patterns

Concurrency groups prevent multiple workflow runs from interfering with each other:

Concurrency Pattern	Count	Purpose
gh-aw-${{ github.workflow }}	84	Workflow-level locking (general)
gh-aw-copilot-${{ github.workflow }}	67	Copilot-specific locking
gh-aw-claude-${{ github.workflow }}	48	Claude-specific locking
gh-aw-codex-${{ github.workflow }}	6	Codex-specific locking

Pattern: Nearly all workflows (96%) use workflow-specific concurrency groups, often combined with engine-specific groups. This prevents:

• Multiple runs of same workflow executing simultaneously
• Race conditions in state management
• Resource contention for LLM API calls

Tool & GitHub Actions Patterns

Most Used GitHub Actions

Action	Usage Count	Purpose
actions/github-script@v8	1,278	JavaScript automation and API calls
actions/upload-artifact@v5	743	Persist agent outputs and results
actions/download-artifact@v6	531	Retrieve outputs from previous jobs
actions/setup-node@v6	165	Node.js environment for agents
actions/checkout@v5	133	Repository checkout
actions/cache@v4	39	Cache dependencies and memory
actions/setup-go@v5	18	Go environment setup
actions/setup-python@v5	13	Python environment setup
astral-sh/setup-uv	11	Modern Python package installer

Key Observations:

1. Heavy GitHub Script Usage (1,278 occurrences): Most workflow logic is JavaScript-based using github-script
2. Artifact-Centric Architecture: Upload (743) and download (531) actions show workflows heavily use artifacts for inter-job communication
3. Node.js Dominance: With 165 setup-node uses, Node.js is the primary runtime environment
4. Multi-Language Support: Go (18), Python (13), showing polyglot workflow capabilities

MCP Server Usage

• Total MCP Server Mentions: 961 across all files
• Average per Workflow: ~11 MCP server references

While specific MCP servers aren't individually tracked in this analysis, the high frequency of mentions (961) indicates extensive use of Model Context Protocol for structured AI-agent interactions.

Feature Adoption Analysis

Security & Safety Features

Feature	Workflows	Adoption Rate	Purpose
Firewall Detection	85	96%	Security scanning and XPIA protection
Agent Job	85	96%	Main AI agent execution
Activation Job	85	96%	Workflow validation and initialization
Conclusion Job	77	87%	Cleanup and result summary
Detection Job	76	85%	Output validation and safety checks
Cache Memory	44	49%	Persistent state across runs

Insights:

• Near-Universal Firewall (96%): Strong security posture with XPIA protection
• Standardized Structure (96%): activation + agent + detection pattern is near-universal
• Cache Memory Adoption Growing (49%): Nearly half of workflows use persistent state

Workflow Naming Patterns

The repository follows consistent naming conventions:

Pattern	Count	Examples
test-*	12	test-claude-oauth-workflow, test-secret-masking
daily-*	8	daily-news, daily-code-metrics, daily-team-status
smoke-*	4	smoke-claude, smoke-copilot, smoke-detector
copilot-*	5	copilot-pr-nlp-analysis, copilot-session-insights
Descriptive names	60	grumpy-reviewer, semantic-function-refactor, etc.

Pattern Analysis:

• Test Workflows (13%): Significant investment in testing infrastructure
• Daily Automation (9%): Scheduled workflows for recurring tasks
• Smoke Tests (4%): Engine validation workflows
• Descriptive Naming (67%): Most workflows use clear, purpose-driven names

Interesting Findings

1. High Standardization Despite Diversity

With 89 workflows serving different purposes, there's remarkable consistency:

• 96% use the activation → agent → detection → conclusion pattern
• 96% implement firewall security
• 79% support manual triggering via workflow_dispatch
• Average structure: 7 jobs, 60 steps, 231 KB

This suggests strong governance and templates in workflow creation.

2. Security-First Architecture

• 96% of workflows include firewall detection jobs
• Read permissions outnumber write permissions 14:1 for repository contents
• Safe outputs used in 73% of workflows
• XPIA (Cross-Prompt Injection Attack) protection is standard

The security posture is exceptionally strong for AI-powered automation.

3. Copilot Dominates, But Claude is Strong

• Copilot: 55% of workflows
• Claude: 40% of workflows
• Codex: 5% (likely deprecated)

The near-even split between Copilot and Claude suggests:

• No vendor lock-in
• Different engines chosen for different task types
• Healthy competition between AI providers

4. Workflows are Interactive, Not Autonomous

• 93% respond to issues
• 87% respond to pull requests
• Only 2% use push triggers (automatic commits)
• 79% support manual triggering

This shows agentic workflows are designed as AI assistants for humans, not autonomous agents.

5. Cache Memory is Growing (49% Adoption)

Nearly half of workflows use persistent cache memory, indicating:

• Complex, stateful workflows
• Learning from past executions
• Cost optimization (caching LLM results)

6. Artifact-Heavy Architecture

• 743 artifact uploads
• 531 artifact downloads
• ~8 artifacts per workflow on average

Workflows extensively use GitHub Actions artifacts for:

• Inter-job communication
• Output persistence
• Result aggregation

7. Discussion Categories Need Standardization

The analysis found inconsistent naming:

• "audits" vs "Audits" vs "audit"
• "General" vs "general"

A style guide for discussion categories would improve organization.

8. Minimal Use of Push Triggers (2%)

Only 2 workflows use push triggers, showing extreme caution about automatic code modifications. This is a strong safety signal.

Recommendations

Based on this analysis, here are recommendations for the workflow ecosystem:

1. Standardize Discussion Category Names

• Consolidate "audits", "Audits", "audit" → "audits"
• Document canonical category names
• Add validation to prevent case variations

2. Increase Cache Memory Adoption

• Currently at 49%, could reach 75%+
• Benefits: Reduced LLM costs, faster execution, learning from history
• Create templates demonstrating cache memory patterns

3. Document Engine Selection Guidelines

• When to use Copilot vs Claude vs Codex?
• Task-specific recommendations
• Cost/performance trade-offs

4. Sunset Codex (5% usage)

• Only 6 workflows use Codex
• Migrate to Copilot or Claude
• Simplify engine maintenance

5. Create Workflow Complexity Tiers

Define standard tiers based on analysis:

• Tier 1: <50 steps, 10 min timeout, read-only (Simple)
• Tier 2: 50-70 steps, 20 min timeout, write issues/PRs (Standard)
• Tier 3: >70 steps, 30+ min timeout, complex state (Advanced)

6. Optimize Timeout Values

Current distribution: 49% use 10 min, 24% use 20 min

• Review workflows with 30+ min timeouts (3%) - can they be optimized?
• Consider increasing default from 10 to 15 min for complex tasks

7. Expand Smoke Testing

• Only 4 smoke test workflows (4.5%)
• Add smoke tests for: more engines, trigger types, safe outputs
• Increase coverage to 10-15% of workflows

Methodology

Data Collection

• Source: .github/workflows/*.lock.yml files
• Tools: Bash scripts with grep/awk/sed for YAML parsing
• Validation: Cross-referenced counts across multiple scripts

Analysis Approach

• File Size: ls -l and byte counting
• Trigger Patterns: Regex search for on: section keywords
• Safe Outputs: Search for job types and GitHub script environment variables
• Permissions: Pattern matching for permission declarations
• Structure: Count jobs (top-level YAML keys) and steps (- name: patterns)

Cache Memory

Analysis scripts stored in /tmp/gh-aw/cache-memory/scripts/ for reuse:

• comprehensive_analysis.sh - Main analysis script
• detailed_stats.sh - Extended statistics
• Historical data saved to history/2025-11-21-analysis.json

Limitations

• YAML parsing via grep/awk (not full YAML parser) - may miss edge cases
• Engine detection based on concurrency groups (heuristic)
• MCP server usage counted by mentions, not by unique servers
• No semantic analysis of workflow purposes

---

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

AI generated by Lockfile Statistics Analysis Agent