[lockfile-stats] Lockfile Statistics — 2026-08-21

[github-actions[bot]]

Analysis of all .github/workflows/*.lock.yml compiled agentic workflow files in this repo, generated in a single analyzer script run (see Methodology).

Executive summary

Metric	Value
Lockfiles analyzed	286 (0 skipped/malformed)
Total size	42,077,905 bytes (~40.1 MB)
Avg / min / max size	147,125.5 / 88,259 / 231,646 bytes
Avg jobs per workflow	7.33 (max 14, total 2,095)
Avg steps per workflow	142.16 (max 202, total 40,659)
Avg script steps per workflow	97.59 (max 133, total 27,910)

File size distribution

Sizes are fairly tight around the mean (min 88 KB, max 232 KB, ~2.6x spread), consistent with all lockfiles sharing a large common compiled boilerplate (safe-outputs runtime, MCP gateway wiring, prompt assembly) with per-workflow content adding relatively little marginal size.

Trigger analysis

Trigger	Workflows
workflow_dispatch	279
schedule	192
pull_request	41
issues	5
issue_comment	3
workflow_call	2
deployment_status / workflow_run / discussion / discussion_comment / push / pull_request_review_comment	1 each

Top trigger combinations:

Combination	Count
schedule + workflow_dispatch	189
workflow_dispatch only	48
pull_request + workflow_dispatch	36
workflow_call + workflow_dispatch	2
pull_request only	2

Almost every workflow (279/286, 97.6%) carries workflow_dispatch for manual re-runs, and scheduled cron jobs (192) are the dominant automation pattern — the classic gh-aw "daily/periodic agent" shape.

Schedule cadence: all sampled crons are daily or weekday-daily (* * * or * * 1-5) at scattered minute/hour offsets — no two workflows share an exact minute+hour except a cluster of 3 at 7 5 * * * — suggesting offsets are deliberately jittered to avoid runner contention.

Safe outputs analysis

Safe output type	Workflows using it
create-issue	138
create-discussion	91
add-comment	75
create-pull-request	60
create-pull-request-review-comment	16
update-issue	11
other (noop / missing-tool / missing-data / report-incomplete, etc.)	280

The "other" bucket is dominated by baseline safety/utility outputs (noop, missing_tool, missing_data, report_incomplete) that appear in nearly every workflow's safe-outputs config as fallback handlers, not a distinct content-producing output type.

Discussion categories (for the 91 workflows using create-discussion):

Category	Count
audits	78
announcements	5
artifacts	2
dev	2
research	2
general	1
daily-news	1

audits dominates — consistent with this very workflow's own category — suggesting a large fleet of periodic auditor-style agents publishing findings as discussions.

Structural characteristics

• 286 workflows compile to 2,095 total jobs, 40,659 total steps, 27,910 script/run steps.
• Job count per workflow tops out at 14; step count tops out at 202 — the largest workflows are notably more complex than the ~7 job / ~142 step average.

Permission patterns

All 286 lockfiles declare permissions: {} at the top level (zero standing permissions), with 286/286 landing in "none/unset." This confirms gh-aw's design of granting no default GITHUB_TOKEN scopes at the workflow level — any GitHub write access is mediated entirely through the safe-outputs pipeline rather than direct token permissions.

Timeout distribution

Timeout (minutes)	Workflows
45	287*
10	29
5	2

*Count exceeds 286 because some workflows declare timeout-minutes on more than one job.

Tool & MCP patterns

Engine	Workflows
copilot	154
claude	49
pi (copilot/gpt-5.4)	22
codex	8
codex (gpt-5.4)	5
copilot (claude-haiku-4.5)	3
crush / opencode / goose (copilot/claude-sonnet-4.5)	3 each
claude (claude-sonnet-4.6)	3
(long tail of one-off engine/model pins)	remainder

Copilot-backed engines are the majority (~54%), with Claude-family engines (claude, plus copilot-hosted claude-sonnet/haiku/opus variants) a strong second cluster once pinned-model variants are combined.

MCP servers: the safeoutputs server is present in effectively all 286 workflows (it backs the safe-outputs pipeline itself), the github MCP server appears in 117 workflows, and agenticworkflows in 42. Beyond these three, per-server counts could not be reliably enumerated this run — see Methodology/limitations below — so no long-tail server table is included to avoid reporting noise as fact.

Interesting findings

1. Universal zero-permission model: 100% of workflows run with permissions: {}, pushing all write access through the safe-outputs broker — a strong, consistent security posture across the whole fleet.
2. workflow_dispatch is nearly universal (97.6%) even though most workflows are schedule-driven, implying manual re-run/debugging is treated as a first-class requirement by convention.
3. audits-category discussions dominate create-discussion usage (78 of 91, ~86%), suggesting this reporting pattern (periodic agent → discussion audit) is the single most common "publish findings" idiom in the repo.
4. create-issue (138) is the single most common content-producing safe output, ahead of create-discussion and add-comment combined with create-pull-request — issue creation is the primary way these agents surface actionable work.
5. Size is remarkably uniform (88KB–232KB) across 286 files despite very different job/step counts (up to 14 jobs / 202 steps), implying compiled boilerplate — not workflow-specific logic — is the dominant contributor to lockfile size.

Historical trends

No prior-day summary existed in /tmp/gh-aw/cache-memory/history/ before this run, so no trend deltas are available. This run's summary has been saved as the baseline for future comparisons.

Recommendations

• Consider trimming compiled boilerplate (safe-outputs/MCP gateway wiring) if lockfile size becomes a review or diff-noise concern, since it — not workflow logic — dominates file size.
• Given audits-category discussions are the dominant reporting idiom, a shared "audit discussion" template/skill could reduce duplication across the ~78 workflows using it.
• Improve engine/model labeling consistency (some engine strings embed literal unresolved template expressions, e.g. claude (${{ needs.activation.outputs.model_size }})) so fleet-wide engine analytics stay accurate.

Methodology & limitations

Single-script compact JSON analysis: one Python analyzer script parsed all 286 .lock.yml files in one pass and wrote a compact JSON summary, which was then used as the sole basis for this report (no per-file inspection outside that script).

Limitation: PyYAML was not installable in this sandboxed run (no network egress to PyPI), so the analyzer used a dependency-free, indentation-based structural fallback parser instead of a full YAML parser. Triggers, permissions, timeouts, job/step/script counts, engine IDs, and safe-outputs config were extracted with targeted, verified patterns against real gh-aw lockfile structure (e.g. the gh-aw-metadata header comment and GH_AW_SAFE_OUTPUTS_CONFIG JSON blob) and cross-checked for consistency. MCP server/tool enumeration proved unreliable under this fallback (matched JSON schema field names as false positives) and has been deliberately limited to the three servers that were unambiguous (safeoutputs, github, agenticworkflows) rather than reporting a noisy long tail.

Generated by 📊 Lockfile Statistics Analysis Agent · agent · 77.3 AIC · ⌖ 7.75 AIC · ⊞ 6.7K · ◷

• expires on Aug 22, 2026, 12:25 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Lockfile Statistics Analysis Agent.

A newer discussion is available at Discussion #54908.