Skip to content

[subagent-optimizer] Optimize release — 2026-05-17 #54

@github-actions

Description

@github-actions

Target Workflow

File: .github/workflows/release.md
Engine: not specified (GitHub Actions-based agentic runner)
7-day token usage: ~772,435 tokens across 1 run (~772,435 avg/run)

Why This Workflow

release.md is the only workflow not optimized in the past 14 days and not already using inline sub-agents. Its prompt body is ~130 lines of dense, rule-heavy prose covering commit classification, semver interpretation, editorial guidelines, and changelog formatting — all handled in a single monolithic agent context. Two clearly independent, data-driven tasks (commit classification and semver bump detection) are strong candidates for extraction to a smaller model, reducing the main-model context load and enabling parallel pre-processing before the synthesis step.


Optimization 1 — Common Tool Prefix (Highest Priority)

No qualifying common tool-call prefix was found across sections. The only tool invocation in the prompt (update_release MCP call) appears in a single section. This optimization does not apply.


Optimization 2 — Inline Sub-Agents

LLM Expert Reasoning

  • Commit classification (§2a, score 8/10) fires the "classifying items into a predefined set of categories" heuristic — reading a TSV and labelling each row as Added/Changed/Fixed/Removed/Security/skip is pure pattern matching, fully independent of other sections, and parallelisable.
  • Semver interpretation (§2b, score 6/10) fires the "checking whether something meets a stated criterion" heuristic — comparing two version strings to determine major/minor/patch is trivially simple for a smaller model.
  • Both §2a and §2b have zero upstream dependencies and can run concurrently, feeding their outputs to the main model for the synthesis step (§2c).
  • Bundling them into one release-classifier sub-agent avoids two round-trips and returns a single structured JSON payload the main model can consume directly.
  • §2c (release body writing) and §2d (changelog update) must stay in the main model — they require nuanced editorial judgment and depend on the classifier output.

Proposed Sub-Agents

1. release-classifier (small)

Extracted task: Classify commits by changelog category and detect semver bump type.
Why small: Pure extractive classification from structured files — no synthesis or judgment required.
Score: 8/10 (independence: 3, model-adequacy: 3, parallelism: 2, size: 2) — bundled with §2b (6/10)
Estimated savings: ~100,000–150,000 tokens/run

Agent definition (copy-paste ready)
## agent: `release-classifier`
---
description: Classify commits by changelog category and detect semver bump type.
model: small
---
Read `/tmp/gh-aw/release-data/commit_subjects.tsv` and `/tmp/gh-aw/release-data/semver_context.json`.

For each line in the TSV (format: `<SHA>\t<subject>`), classify the commit as one of:
- `Added` — new user-visible capability, workflow, input, or output
- `Changed` — behavior change, revised default, or UX improvement users notice
- `Fixed` — bug fix correcting wrong behavior users could hit
- `Removed` — functionality or behavior no longer available
- `Security` — user-relevant security fix or hardening
- `skip` — internal change (CI, build, refactor, deps, formatting, generated files)

From `semver_context.json`, read `current_version` and `previous_version` and output the bump type:
- `major` if the major number increased
- `minor` if only the minor number increased
- `patch` if only the patch number changed
- `first` if there is no previous version

Output a single JSON object to stdout:
{
  "bump_type": "<major|minor|patch|first>",
  "classified_commits": [
    {"sha": "<sha>", "subject": "<subject>", "category": "<category>"}
  ]
}

Invocation change in main prompt:

Before:

## What to Write

Write a concise, human changelog-style markdown body for the release.

Assume the audience is a maintainer or adopter deciding whether to upgrade...
[the main model reads and classifies all commits and infers semver bump inline]

After:

## What to Write

Use the `release-classifier` agent to classify commits and determine the semver bump type.
Then write the release body and changelog entry using the JSON output from that agent.

Estimated Impact

Metric Before After (estimated)
Avg tokens/run ~772,435 ~630,000 (~18% reduction)
Main-model context saved ~120,000 tokens/run
Parallelism opportunity None commit classification + semver detection in parallel

Implementation Steps

  1. Sub-agent: Add the release-classifier agent block at the bottom of .github/workflows/release.md, after all workflow content
  2. Update the ## What to Write section to invoke release-classifier by name and consume its JSON output
  3. Compile: gh aw compile release
  4. Test: gh workflow run release.yml

References

Generated by Daily Sub-Agent Optimizer · ● 6.9M ·

  • expires on May 24, 2026, 4:59 AM 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