Skip to content

[agentic-token-optimizer] Optimize Install Workflows: re-enable path filter and reduce redundant job overhead #51

@github-actions

Description

@github-actions

Target Workflow

Install Workflows (.github/workflows/install-workflows.yml) was selected as the optimization target. It is the highest-frequency workflow not optimized in the last 14 days and not excluded by name rules. It triggered 16 times in the last 7 days, including on commits that did not touch any workflow source files.


Analysis Period

  • Period: 2026-05-09 → 2026-05-15 (7 days)
  • Runs analyzed: 16 (all successful, no failures)
  • Avg duration per run: ~35 s (validate job: ~15 s + install job: ~10 s + runner setup overhead)
  • Total action-minutes consumed: ~9.3 min/week
  • Token usage: N/A — this is a CI workflow with no LLM agent steps

Note: No pre-aggregated token data was available for this workflow (top-workflows.json was empty for this analysis window). Analysis is based on GitHub Actions run metadata.


Token / Efficiency Profile

Metric Value
Runs in last 7 days 16
Avg duration ~35 s
All conclusions ✅ success
Unnecessary runs (non-workflow commits) ~10 of 16 (~62%)
Estimated avoidable action-time/week ~5.8 min
Estimated savings per avoided run ~35 s

Ranked Recommendations

1. Re-enable the commented-out paths trigger filter

Estimated savings: ~10 avoided runs/week (~5.8 action-minutes/week)

The workflow currently triggers on every push to main, because the path filter is commented out:

on:
  push:
    branches:
      - main
    #paths:
    #  - workflows/**

Restoring the filter means the workflow only runs when source workflow .md files actually change — the only case where installation is needed.

Evidence from 16 observed runs:

Commits that triggered unnecessary Install Workflows runs
Run Commit message Workflow file touched?
§25879655683 Revise README header and add CI badge ❌ No
§25879509882 Strengthen README positioning and quick start ❌ No
§25875752669 chore: update release workflow and changelog ❌ No
§25874122332 chore: simplify release asset handling ❌ No
§25872428161 chore: recompile release pipeline ❌ No
§25872402466 chore: remove verification step ❌ No
§25872083529 chore: update release workflow ❌ No
§25871472734 feat: add verification for latest green CI commit ❌ No
§25852720793 Update workflow descriptions in README.md ❌ No
§25880174032 chore: update and recompile agentic maintenance ❌ No

Concrete action: Uncomment lines 7–8 in install-workflows.yml:

    paths:
      - workflows/**

Also consider adding - .github/workflows/install-workflows.yml to the paths list so changes to the installer itself also trigger a run.


2. Merge the validate job into the install job as a pre-step

Estimated savings: ~15 s per run (runner boot + CLI setup overhead)

Currently the workflow runs two separate jobs:

  • validate: checks out code, sets up gh-aw CLI, runs gh aw add + gh aw compile --validate --no-emit
  • install: checks out code again, sets up gh-aw CLI again, runs gh aw add --force + gh aw compile + creates PR

Both jobs independently spin up an Ubuntu runner and install the gh-aw CLI. The validate job's work is fully subsumed by install — the install job already compiles the same files. Merging --validate as a step flag within the install job, or running validation as an early step of the same job, eliminates the duplicate runner boot and CLI install overhead (~15 s per run).

Concrete action: Add --validate to the gh aw compile call in the install job and remove the separate validate job. The needs: [validate] gate can be replaced by ordering steps within a single job.

⚠️ Caveat: If the intent of the two-job split is to show early validation failure before the GitHub App token is provisioned (security boundary), keep both jobs but consider using a job-level output or if: success() condition rather than a full duplicate setup.


Caveats

  • Sampling: 16 runs over 7 days; commit-to-file-change correlation was inferred from commit messages, not verified by diff inspection.
  • Path filter scope: Ensure workflows/** covers all 3 source files (agentic-token-audit.md, agentic-token-optimizer.md, daily-subagent-optimizer.md). If the files are directly in workflows/, the pattern workflows/** or workflows/*.md is sufficient.
  • No token data available: The pre-aggregated token audit files contained no run data for this period. Savings estimates are based on action-minutes only.

References:

Generated by Agentic Workflow Token Usage Optimizer · ● 5.1M ·

  • expires on May 22, 2026, 3:13 PM UTC

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions