gframework-batch-boot

name

gframework-batch-boot

description

Repository-specific bulk-task workflow for the GFramework repo. Use when Codex should start from the normal GFramework boot context and then continue a repetitive or large-scope task in automatic batches without waiting for manual round-by-round prompts, especially for analyzer warning cleanup, repetitive test refactors, documentation waves, or similar multi-file work with an explicit stop condition such as changed-file count, warning count, or timebox.

GFramework Batch Boot

Overview

Use this skill when gframework-boot is necessary but not sufficient because the task should keep advancing in bounded batches until a clear stop condition is met.

Treat AGENTS.md as the source of truth. This skill extends gframework-boot; it does not replace it. If the task's defining requirement is that the main agent must keep acting as dispatcher, reviewer, ai-plan owner, and final integrator for multiple parallel workers, prefer gframework-multi-agent-batch and use this skill's stop condition guidance as a secondary reference.

Context budget is a first-class stop signal. Do not keep batching merely because a file-count threshold still has headroom if the active conversation, loaded repo artifacts, validation output, and pending recovery updates suggest the agent is approaching its safe working-context limit.

Startup Workflow

1. Execute the normal gframework-boot startup sequence first:
   • read AGENTS.md
   • read .ai/environment/tools.ai.yaml
   • read ai-plan/public/README.md
   • read the mapped active topic todos/ and traces/
2. Classify the task as a batch candidate only if all of the following are true:
   • the work is repetitive, sliceable, or likely to require multiple similar iterations
   • each batch can be given an explicit ownership boundary
   • a stop condition can be measured locally
   • the task does not primarily need the orchestration-heavy main-agent workflow captured by gframework-multi-agent-batch
3. Before any delegation, define the batch objective in one sentence:
   • warning family reduction
   • repeated test refactor pattern
   • module-by-module documentation refresh
   • other repetitive multi-file cleanup
4. Before the first implementation batch, estimate whether the current task is likely to stay below roughly 80% of the agent's safe working-context budget through one more full batch cycle:
   • include already loaded AGENTS.md, skills, ai-plan files, recent command output, active diffs, and expected validation output
   • if another batch would probably push the conversation near the limit, plan to stop after the current batch even if branch-size thresholds still have room

Baseline Selection

When the stop condition depends on branch size or changed-file count, choose the baseline carefully.

1. Prefer the freshest remote-tracking reference that already exists locally:
   • origin/main
   • or the mapped upstream base branch for the current topic
2. Do not default to local main when refs/heads/main is behind refs/remotes/origin/main.
3. If both local and remote-tracking refs exist, report:
   • ref name
   • short SHA
   • committer date
4. If only a local branch exists, state that the baseline may be stale before using it.
5. When the task is tied to a PR or topic branch rather than main, prefer that explicit upstream comparison target over a generic main.

For changed-file limits, measure branch-wide scope against the chosen baseline, not just the current working tree:

• use git diff --name-only <baseline>...HEAD
• do not confuse branch diff size with git status --short

For changed-line limits, also measure branch-wide scope against the chosen baseline:

• prefer git diff --numstat <baseline>...HEAD
• treat "changed lines" as added + deleted summed across the branch diff
• do not use working-tree-only line counts as a substitute for branch-wide scope

For shorthand numeric thresholds, use a fixed default baseline:

• compare the current branch's cumulative diff against remote origin/main
• include all commits reachable from HEAD that are not already in origin/main
• do not reinterpret shorthand thresholds as "this batch only" or "current unstaged changes only"
• only use another baseline when the user explicitly names it in the prompt

Stop Conditions

Choose one primary stop condition before the first batch and restate it to the user.

When the user does not explicitly override the priority order, use:

1. context-budget safety
2. semantic batch boundary / reviewability
3. the user-requested local metric such as files, lines, warnings, or time

Common stop conditions:

• the next batch would likely push the agent above roughly 80% of its safe working-context budget
• branch diff vs baseline approaches a file-count threshold
• warnings-only build reaches a target count
• a specific hotspot list is exhausted
• a timebox or validation budget is reached

If multiple stop conditions exist, rank them and treat one as primary.

Treat file-count or line-count thresholds as coarse repository-scope signals, not as a proxy for AI context health. When they disagree with context-budget safety, context-budget safety wins.

Shorthand Stop-Condition Syntax

gframework-batch-boot may be invoked with shorthand numeric thresholds when the user clearly wants a branch-size stop condition instead of a long natural-language prompt.

Interpret shorthand as follows:

• $gframework-batch-boot 75
  • means: stop when the current branch's cumulative diff vs remote origin/main approaches 75 changed files
• $gframework-batch-boot 75 2000
  • means: stop when the current branch's cumulative diff vs remote origin/main approaches 75 changed files OR 2000 changed lines
  • default positional meaning is <files> <lines>
• $gframework-batch-boot 75 | 2000
  • may be interpreted as the same OR shorthand in plain-language chat
  • when restating, planning, or documenting the command, normalize it to $gframework-batch-boot 75 2000
  • prefer the no-pipe form because | is easy to confuse with a shell pipeline

When shorthand is used:

• report the resolved thresholds explicitly before the first batch
• report that the baseline is remote origin/main, unless the user explicitly overrides it
• if two numeric thresholds are present, treat file count as the default primary metric for status reporting unless the user says otherwise
• stop when either threshold is reached or exceeded, even if the other threshold still has headroom

Batch Loop

1. Inspect the current state before the first batch:
   • current branch and active topic
   • selected baseline
   • current stop-condition metric
   • current context-budget posture and whether one more batch is safe
   • next candidate slices
2. Keep the critical path local.
3. Delegate only bounded slices with explicit ownership:
   • one file
   • one warning family within one project
   • one module documentation wave
4. For each worker batch, specify:
   • objective
   • owned files or subsystem
   • required validation commands
   • output format
   • reminder that other agents may be editing the repo
5. While workers run, use the main thread for non-overlapping tasks:
   • queue the next candidate slice
   • inspect the next hotspot
   • recompute branch size or warning distribution
6. After each completed batch:
   • integrate or verify the result
   • rerun the required validation
   • recompute the primary stop-condition metric
   • reassess whether one more batch would likely push the agent near or beyond roughly 80% context usage
   • decide immediately whether to continue or stop
7. Do not require the user to manually trigger every round unless:
   • the next slice is ambiguous
   • a validation failure changes strategy
   • the batch objective conflicts with the active topic

Task Tracking

For multi-batch work, keep recovery artifacts current.

• Update the active ai-plan/public/<topic>/todos/ document when a meaningful batch lands.
• Update the matching traces/ document with:
  • accepted delegated scope
  • validation milestones
  • current stop-condition metric
  • next recommended batch
• Keep the active recovery point concise; archive detailed history when it starts to sprawl.

Delegation Defaults

• Prefer worker subagents for independent write slices.
• Prefer explorer subagents for read-only hotspot ranking or next-batch discovery.
• Keep each worker ownership boundary disjoint.
• Avoid launching a new batch when the expected write set would push the branch beyond the declared threshold without a deliberate decision.

Completion

Stop the loop when any of the following becomes true:

• the next batch would likely push the agent near or beyond roughly 80% of its safe working-context budget
• the primary stop condition has been reached or exceeded
• the remaining slices are no longer low-risk
• validation failures indicate the task is no longer repetitive
• the branch has grown large enough that reviewability would materially degrade

When stopping, report:

• whether context budget was the deciding factor
• which baseline was used
• the exact metric value at stop time
• completed batches
• remaining candidate batches
• whether further work should continue in a new turn or after rebasing/fetching

Example Triggers

• Use $gframework-batch-boot 75 to keep reducing analyzer warnings until the branch diff vs baseline approaches 75 files.
• Use $gframework-batch-boot 75 2000 to keep reducing warnings until the branch diff approaches 75 files or 2000 changed lines.
• Use $gframework-batch-boot and keep reducing analyzer warnings until the branch diff vs origin/main approaches 75 files.
• Use $gframework-batch-boot to continue this repetitive test refactor in bounded batches until the warning count drops below 10.
• Use $gframework-batch-boot and refresh module docs in waves without asking me to trigger every round.