📊 Agentic Workflow Lock File Statistics - 2026-02-13

[github-actions[bot]]

This comprehensive statistical analysis examines all 149 agentic workflow lock files (.lock.yml) in the repository's .github/workflows/ directory, providing insights into structure, patterns, and usage characteristics.

Executive Summary

• Total Lock Files: 149 workflows
• Total Size: 8.61 MB
• Average File Size: 59.2 KB
• Analysis Date: 2026-02-13
• Change from 2026-02-11: +2 workflows, -0.08 MB total size

Key Findings:

• Nearly all workflows (95%) use workflow_dispatch for manual triggering
• 73% of workflows run on schedules, primarily during weekday business hours
• 95% of workflows create GitHub discussions for reporting results
• Average workflow has 6 jobs with 12.3 steps each
• Most workflows use GitHub MCP (100%) and Safe Outputs MCP (94%)

---

File Size Distribution

Size Range	Count	Percentage	Notable Examples
< 10 KB	0	0%	-
10-50 KB	12	8.1%	firewall, test-workflow, example workflows
50-100 KB	135	90.6%	Most common range
> 100 KB	2	1.3%	smoke-claude, smoke-copilot

Size Statistics:

• Smallest: codex-github-remote-mcp-test.lock.yml (22.8 KB)
• Largest: smoke-copilot.lock.yml (101.0 KB)
• Median: ~59 KB
• Standard Range: 50-75 KB (90.6% of files)

View Size Analysis

The tight clustering around 50-75 KB suggests:

1. Consistent workflow structure and complexity
2. Similar instruction sets and configurations
3. Standard MCP server setups across workflows
4. Predictable lock file generation patterns

The two outliers >100KB are smoke test workflows with extensive test matrices and step sequences.

---

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Primary Use Case
workflow_dispatch	134	89.9%	Manual execution via UI/API
schedule	109	73.2%	Automated periodic runs
issue_comment	14	9.4%	React to issue comments
pull_request	14	9.4%	PR creation/updates
issues	13	8.7%	Issue creation/updates
pull_request_review_comment	6	4.0%	PR review comments
discussion_comment	5	3.4%	Discussion interactions
discussion	4	2.7%	Discussion events
workflow_run	2	1.3%	Triggered by other workflows
push	1	0.7%	Code push events

Common Trigger Combinations

The most frequent multi-trigger patterns:

1. schedule, workflow_dispatch - 100 workflows (67.1%)

   • Automated daily/weekly runs with manual override capability
   • Most common pattern for recurring analysis tasks

2. pull_request, schedule, workflow_dispatch - 6 workflows

   • Combine PR automation with scheduled reviews
   • Examples: PR triage, code quality checks

3. pull_request, workflow_dispatch - 3 workflows

   • PR-focused with manual trigger option

4. Multi-event responders - 3 workflows

   • Listen to: discussion, discussion_comment, issue_comment, issues, pull_request, pull_request_review_comment
   • Examples: AI moderator, universal triage agents

View All Trigger Combinations

Combination	Count
schedule, workflow_dispatch	100
pull_request, schedule, workflow_dispatch	6
pull_request, workflow_dispatch	3
discussion, discussion_comment, issue_comment, issues, pull_request, pull_request_review_comment	3
issue_comment, issues, workflow_dispatch	2
issue_comment, pull_request_review_comment	2
issue_comment, issues, pull_request	1
issues, schedule, workflow_dispatch	1
discussion_comment, issue_comment	1
issues, workflow_dispatch	1

Schedule Patterns

Most Common Schedule Times (weekday business hours):

Schedule (Cron)	Count	Description	Time (UTC)
0 14 * * 1-5	4	Weekdays at 2 PM	Daily (Mon-Fri)
0 13 * * 1-5	4	Weekdays at 1 PM	Daily (Mon-Fri)
0 11 * * 1-5	4	Weekdays at 11 AM	Daily (Mon-Fri)
0 9 * * 1-5	3	Weekdays at 9 AM	Daily (Mon-Fri)
0 15 * * 1-5	2	Weekdays at 3 PM	Daily (Mon-Fri)
0 10 * * 1-5	2	Weekdays at 10 AM	Daily (Mon-Fri)
0 16 * * 1-5	2	Weekdays at 4 PM	Daily (Mon-Fri)

Schedule Distribution:

• Daily (specific times): 73 workflows
• Weekday business hours (9 AM - 6 PM UTC, Mon-Fri): 21 workflows
• Every 4-6 hours: 4 workflows
• Every 12 hours: 4 workflows
• Hourly: 1 workflow (0 * * * *)
• Every 30 minutes: 1 workflow (*/30 * * * *)
• Weekly: 7 workflows (various days)

View All 91 Unique Schedule Patterns

The repository uses 91 distinct cron schedules, with times distributed throughout the day to:

1. Spread load across different hours
2. Run different types of analyses at optimal times
3. Stagger workflows to avoid resource contention
4. Support different timezone requirements

Most schedules avoid the top of the hour (minute 0) by using random minute offsets (e.g., 43 11 * * *, 54 7 * * *), which helps distribute GitHub Actions runner load.

---

Safe Outputs Analysis

Safe Outputs enable workflows to communicate results back to GitHub in structured ways. The system uses the mcp__safeoutputs__* toolset.

Safe Output Types Distribution

Type	Workflows	Percentage	Purpose
create_discussion	142	95.3%	Publish analysis reports and findings
missing_data	140	94.0%	Report when required data unavailable
missing_tool	140	94.0%	Report when required tools unavailable
noop	140	94.0%	Log completion when no action needed
create_issue	116	77.9%	Create actionable GitHub issues
add_comment	69	46.3%	Add comments to existing issues/PRs
create_pull_request	53	35.6%	Create PRs with code changes
update_issue	5	3.4%	Update existing issue properties

Key Observations:

• Nearly all workflows (95%) can create discussions for reporting
• Comprehensive error handling: 94% support missing_data, missing_tool, and noop
• Strong issue integration: 78% can create issues, 46% can comment
• Moderate PR automation: 36% can create PRs

Discussion Categories

When workflows create discussions, they're organized into these categories:

Category	Count	Percentage	Typical Content
audits	28	50.9%	Code quality, security, compliance reports
general	15	27.3%	Miscellaneous updates and status
reports	3	5.5%	Structured analysis reports
dev	2	3.6%	Development updates
research	2	3.6%	Research findings
artifacts	2	3.6%	Artifact summaries
security	1	1.8%	Security findings
daily-news	1	1.8%	Daily news digests
agent-research	1	1.8%	Agent behavior research

Total: 55 workflows specify explicit discussion categories (39% of discussion-creating workflows)

The "audits" category dominates, reflecting the repository's focus on automated code analysis and quality monitoring.

---

Structural Characteristics

Job Complexity

Understanding workflow structure and computational complexity:

• Average Jobs per Workflow: 6.0 jobs
• Average Steps per Job: 12.3 steps
• Maximum Steps in Single Job: 58 steps
• Minimum Steps: 1 step
• Typical Job: ~12 steps with standard setup/checkout/execution/output phases

Job Count Distribution:

• Most workflows use a standard multi-job structure
• Jobs typically split into: setup, agent execution, output collection, firewall management

Average Lock File Structure

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

Characteristic	Typical Value
Size	~59 KB
Jobs	6 jobs
Steps per Job	12-13 steps
Permissions	6-7 permissions (mix of read/write)
Triggers	2 triggers (schedule + workflow_dispatch)
Timeout	12.3 minutes per job
MCP Servers	2-3 servers (github, safeoutputs, optional fetch/search)
Concurrency	workflow-based locking

Timeout Configuration

• Average Timeout: 12.3 minutes per job
• Purpose: Prevent runaway agent executions
• Consistency: Most workflows use similar timeout values, suggesting standardized execution expectations

---

Permission Patterns

Workflows request specific GitHub API permissions. Here's what they need access to:

Most Common Permissions

Permission	Total Uses	Primary Purpose
contents	881	Repository code read/write access
issues	463	Create/update issues and comments
pull-requests	380	Access PR data, create/update PRs
discussions	311	Create/update discussions
actions	73	Access workflow run metadata
security-events	12	Access security scanning results
packages	2	Access package registry
statuses	1	Update commit statuses
attestations	1	Create build attestations
id-token	1	OIDC token generation

Permission Distribution

Permission Level	Count	Percentage
Read-only	1,194	56.2%
Write	931	43.8%

Analysis:

• Balanced approach: Majority read-only (56%), significant write access (44%)
• Contents read is nearly universal (881 uses across 149 workflows)
• Issues/PRs write is common, enabling interactive agent behavior
• Discussions write enables primary reporting mechanism

View Permission Strategy

The permission model follows these patterns:

1. Read-heavy workflows: Analysis and reporting workflows that don't modify repository state
2. Write-enabled workflows: Automated fix generators, PR creators, issue triagers
3. Minimal security exposure: Only 12 workflows access security-events
4. Targeted permissions: Workflows request only what they need

The high read:write ratio (56:44) suggests a security-conscious approach with explicit write permissions only where needed.

---

Tool & MCP Patterns

Model Context Protocol (MCP) servers provide tools and capabilities to agentic workflows.

Most Used MCP Servers

MCP Server	Count	Percentage	Purpose
github	149	100%	GitHub API operations (issues, PRs, commits, etc.)
safeoutputs	140	94.0%	Structured outputs (discussions, issues, PRs)
fetch	62	41.6%	Web content fetching and scraping
brave-search	2	1.3%	Web search capabilities

MCP Adoption:

• Universal GitHub MCP: Every workflow uses GitHub MCP for repository operations
• High Safe Outputs adoption: 94% use structured output mechanisms
• Moderate web access: 42% of workflows fetch external web content
• Limited search: Only 2 workflows use web search (likely specialized research agents)

Common Tool Configurations

From observed patterns:

1. Standard Toolset (all workflows):

   • Bash execution
   • File read/write operations
   • GitHub API access via MCP

2. Extended Toolset (94% of workflows):

   • Safe output creation (discussions, issues, PRs)
   • Error handling tools (missing_data, missing_tool)
   • Completion signaling (noop)

3. Specialized Tools (subset):

   • Web Fetch (42%): External documentation, API data
   • Web Search (1.3%): Research and discovery tasks

---

Concurrency Patterns

Concurrency controls prevent multiple workflow runs from interfering with each other.

Pattern	Count	Percentage	Behavior
workflow-based	147	98.7%	$\{\{ github.workflow }} - One run per workflow type
custom	1	0.7%	Custom group identifier
ref-based	1	0.7%	$\{\{ github.ref }} - One run per branch/tag

Analysis:

• Near-universal workflow-based locking (99%)
• Standard pattern: group: $\{\{ github.workflow }}-$\{\{ github.ref }}
• Prevents multiple instances of same workflow running simultaneously
• Ensures sequential execution for stateful workflows

---

Interesting Findings

1. Standardization is High

   • 90.6% of files fall in the 50-100KB range
   • 98.7% use identical concurrency patterns
   • 100% use GitHub MCP
   • Suggests strong workflow generation templating

2. Dual-Trigger Design Dominates

   • 67% use schedule + workflow_dispatch
   • Enables both automation and manual intervention
   • Reflects operational flexibility requirement

3. Schedule Time Diversity

   • 91 unique cron schedules spread across 24 hours
   • Minute offsets avoid top-of-hour clustering
   • Sophisticated load distribution strategy

4. Error Handling is Universal

   • 94% include missing_data and missing_tool handlers
   • Workflows designed to gracefully fail and report issues
   • Production-grade reliability focus

5. Discussion-First Reporting

   • 95% create discussions vs 78% create issues
   • Discussions preferred for reports, issues for tasks
   • "Audits" category receives 51% of categorized discussions

6. Permission Precision

   • Read-heavy (56%) but substantial write access (44%)
   • Targeted permissions per workflow needs
   • Security-conscious design

7. Timeout Consistency

   • Average 12.3 minutes per job
   • Suggests predictable agent execution time
   • Prevents resource exhaustion

8. Minimal File Count Growth

   • +2 workflows since Feb 11 (1.4% growth)
   • -0.08 MB total size (optimization or cleanup)
   • Stable, mature workflow ecosystem

---

Historical Trends

Comparing to previous analysis (2026-02-11):

Metric	Feb 11	Feb 13	Change	Trend
Total Files	147	149	+2	📈 +1.4%
Total Size	8.69 MB	8.61 MB	-0.08 MB	📉 -0.9%
Avg Size	60.5 KB	59.2 KB	-1.3 KB	📉 -2.1%
workflow_dispatch	130	134	+4	📈 +3.1%
schedule	107	109	+2	📈 +1.9%

Key Observations:

• Slight growth: 2 new workflows added
• Size optimization: Total size decreased despite more files
• Trigger consistency: New workflows follow standard patterns (dispatch + schedule)
• Stable architecture: No significant structural changes

View Historical Safe Outputs Comparison

Safe Output	Feb 11	Feb 13	Change
create_discussion	140	142	+2
create_issue	113	116	+3
missing_data	140	140	0
missing_tool	140	140	0
noop	140	140	0
add_comment	41	69	+28
create_pull_request	53	53	0
update_issue	5	5	0

Notable: add_comment capability increased significantly (+68%), suggesting more workflows are gaining interactive commenting features.

---

Recommendations

Based on this comprehensive analysis:

1. Maintain Standardization

   • Continue using consistent workflow structure templates
   • Keep file sizes in 50-100KB range for maintainability
   • Preserve dual-trigger pattern (schedule + dispatch)

2. Optimize Schedule Distribution

   • Current 91 unique schedules are well-distributed
   • Continue avoiding top-of-hour clustering
   • Consider consolidating very similar schedules (e.g., multiple workflows at 13:00, 14:00)

3. Monitor Safe Output Usage

   • 94% adoption rate is excellent for missing_data/missing_tool/noop
   • Consider standardizing remaining 6% for consistency
   • Evaluate if all workflows need all safe output types

4. Permission Auditing

   • Current 56/44 read/write ratio is reasonable
   • Periodically review write permissions for necessity
   • Document why each workflow needs write access

5. Size Monitoring

   • Set alerts for files exceeding 100KB
   • Investigate the -0.08MB size reduction to identify optimization techniques
   • Apply similar optimizations to larger workflows

6. Category Organization

   • "Audits" category is heavily used (51% of categorized discussions)
   • Consider subcategories: audits/security, audits/performance, audits/quality
   • Evaluate if "general" (27%) should be more specifically categorized

7. Historical Tracking

   • Continue daily snapshots to /tmp/gh-aw/cache-memory/history/
   • Build trend analysis for workflow count, size, and pattern evolution
   • Create alerts for significant deviations from baselines

8. Documentation

   • Document the standard workflow structure (6 jobs, 12 steps)
   • Create guide for common trigger combinations
   • Explain safe output selection criteria

---

Methodology

Data Collection:

• Source: All .lock.yml files in .github/workflows/ directory
• Files Analyzed: 149
• Analysis Date: 2026-02-13
• Tools Used: Python 3 with PyYAML, bash scripting, grep/awk/sed

Analysis Process:

1. Automated YAML parsing with Python
2. Statistical aggregation using Counter collections
3. Pattern matching for safe outputs and MCP configurations
4. Historical comparison with cached data
5. Manual verification of key findings

Data Accuracy:

• ✅ All 149 files successfully parsed
• ✅ Zero parsing errors
• ✅ Cross-validated with grep/awk results
• ✅ Historical data comparison confirmed trends

Reproducibility:

• Analysis script stored in /tmp/gh-aw/agent/analyze_lockfiles.py
• Can be re-run with: python3 /tmp/gh-aw/agent/analyze_lockfiles.py .github/workflows
• Results stored in /tmp/gh-aw/agent/report.json

Cache Memory Usage:

• Scripts persisted to /tmp/gh-aw/cache-memory/scripts/
• Historical data in /tmp/gh-aw/cache-memory/history/2026-02-13.json
• Enables trend tracking across workflow runs

---

Appendix: Technical Details

View Lock File Structure

A typical lock file contains:

name: workflow-name
on:
  schedule:
    - cron: "0 9 * * 1-5"
  workflow_dispatch:

permissions:
  contents: read
  issues: write
  discussions: write

concurrency:
  group: $\{\{ github.workflow }}-$\{\{ github.ref }}
  cancel-in-progress: true

jobs:
  determine-automatic-lockdown:
    # Security and firewall setup

  agent:
    # Main agent execution
    timeout-minutes: 12
    steps:
      - checkout
      - firewall setup
      - MCP configuration
      - agent execution
      - output collection

  safe-outputs:
    # Process and publish results

  # Additional jobs for cleanup, monitoring, etc.

View Safe Outputs Configuration Example

Safe outputs are configured in the workflow like this:

{
  "create_discussion": {
    "category": "audits",
    "close_older_discussions": true,
    "expires": 168,
    "fallback_to_issue": true,
    "max": 1
  },
  "create_issue": {
    "max": 5
  },
  "missing_data": {},
  "missing_tool": {},
  "noop": {"max": 1}
}

This config allows:

• 1 discussion in "audits" category (auto-closes older, expires in 7 days)
• Up to 5 issues
• Unlimited missing_data/missing_tool reports
• 1 noop completion signal

---

Report Generated: 2026-02-13
Workflow Run: §21979911385
Analysis Agent: Lockfile Statistics Analysis Agent

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 20, 2026, 8:35 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-20T08:35:11.002Z.

Closed by Workflow