Tempofastlane

TempoFastlane

Purpose

Convert a worker model into a fast, bounded implementer while the parent agent owns architecture, acceptance criteria, proof integrity, integration, and final verification. Eliminate Temporal Inheritance Bias (TIB) from every delegation, scoping, and iteration decision so that the worker is dispatched on empirical wall-clock grounds rather than on human-derived planning priors inherited from the training corpus.

The worker is excellent at quickly producing a patch when the task is bounded and the context is complete. It is a high-speed implementer, not the final gate. The parent enforces ownership, proof, integration, and hardening.

Operating Rule

Delegate construction; centralize judgment and integration. Apply temporal calibration before any delegation, scoping, or iteration decision is made.

The parent protects its cognitive budget. A frontier parent may run on a premium high-reasoning model, but it should spend that reasoning on translating the human idea into mission, architecture, lane contracts, proof design, integration, and synthesis. It should write routine code only when the edit is smaller than delegation overhead or when it is repairing an integration gap found during final proof.

The parent agent must:

• decide whether model control or full-history fork matters more;
• choose the smallest capable worker lane for the task;
• take a baseline snapshot before delegation;
• define the exact mission and write scope;
• include all critical context and constraints;
• provide exact verification commands, not guessed script names;
• require causal proof, not merely "tests passed";
• monitor for scope drift while the worker runs;
• inspect the returned patch;
• integrate the returned work into the surrounding system;
• perform wiring and hardening before reporting acceptance;
• run independent verification;
• harden gaps before accepting;
• record actual wall-clock duration (Te) per phase to recalibrate temporal

priors used by future delegations.

Temporal Operating Rule (TEMPONIZER)

Pre-execution duration estimates produced by language model agents are calibrated to human workflows present in training corpora rather than to the agent's effective runtime behavior. This is Temporal Inheritance Bias (TIB). Across repeated operational sessions, agents predict durations such as "approximately 30 minutes" or "approximately 3 hours" while measured wall-clock completion times are minutes or seconds, yielding large estimate-to-actual ratios. TIB corrupts effort selection, abort/iterate decisions, parallelism, and overall delegation strategy.

Correction heuristic: apply Tc = alpha(phi) * Tp for every duration claim, where Tp is the inherited intuitive estimate, phi is the operational phase, alpha(phi) is the phase-aware scalar, and Tc is the corrected prediction.

Operational phases:

• GEN: pure text or code generation, no external I/O.
• IO: tool calls, API requests, disk or network operations.
• DBG: integration work, debugging, multi-file reasoning.
• PAR: parallel execution of independent subtasks.

Initial prior: alpha(phi) ~= 0.05 as a starting point. Recalibrate online from measured Te per phase.

Calibration loop: estimate -> execute -> measure -> recalibrate. Every execution emits a measured Te from initiation to final output, which updates alpha(phi) for future runs. Without the loop, TIB persists.

Behavioral rules:

• Never assert a duration in minutes or hours without first identifying phi,

applying alpha(phi), and reporting the corrected figure in the smallest unit that fits.

• When uncertain, prefer underestimating and measuring over inheriting human

intuition.

• Treat parallelism as the default execution shape, not as an advanced

optimization. Issue independent tool calls in the same batch.

• The wall-clock is authoritative. The intuitive duration is a corpus artifact,

not a measurement.

Repository-Agnostic Rule

TempoFastlane is universal. Never assume a specific repository, framework, artifact name, proof format, docs layout, branch policy, or release ritual.

Before delegation, infer the current repo's conventions from local files and commands. Use repo-native names, such as its test scripts, proof artifacts, changelog, release notes, checkpoint docs, snapshots, screenshots, and generated outputs, only after discovering them locally.

If the repo has no docs, changelog, checkpoint, scorecard, or proof artifact convention, do not invent one as part of the delegated task unless the user explicitly asks. Instead, report what was verified and what artifact sync would be useful.

Glossary

• Worker lane: operational name for the delegated model tasked with

construction, audit, research, or support work under a parent-owned contract.

• Spark: gpt-5.3-codex-spark, a research preview lane for near-instant

compact text/code iteration when available.

• Coder lane: gpt-5.3-codex for substantial bounded code-only work when

Spark is not needed.

• xhigh / high / medium / low: reasoning effort tiers. Use the lowest tier

that can satisfy the proof contract without increasing parent rework.

• fork_context: spawn flag controlling whether the worker inherits the

parent's full conversation history. true inherits and forces parent model settings. false allows explicit model and effort overrides but requires the parent to embed all needed context in the prompt.

• Proof artifact: any repo-native file that records observable runtime

behavior: log, screenshot, JSON status file, generated output snapshot.

• Artifact Sync Gate: the parent's final pass to align repo-native public

docs, changelog, or evidence files with verified behavior. Run only when those conventions already exist or the user explicitly asks.

• TIB: Temporal Inheritance Bias.
• Tp / Tc / Te: inherited estimate, corrected estimate, measured execution

time.

• alpha(phi): phase-aware temporal scalar.

Living Skill Loop

TempoFastlane is a living skill. When the parent agent uses it several times in a row, or sees the same failure mode more than once, it should look for improvements to the universal workflow.

Propose a skill update when a pattern is:

• repeated across multiple delegated tasks or likely to recur in other repos;
• about delegation quality, model and effort selection, proof integrity, runtime

preflight, artifact sync, handoff format, ownership boundaries, anti-false-positive checks, or temporal calibration;

• expressible without project-specific names, paths, domains, or one-off

commands.

Do not update the skill for:

• a repo-specific convention that belongs in that repo's docs;
• a one-off bug fix;
• a preference that has not improved proof or reduced rework;
• a memory that only makes sense with private conversation context.

Update protocol:

1. Name the reusable lesson in one sentence.
2. Explain why it belongs in TempoFastlane rather than in the current repo.
3. Propose the smallest universal wording change.
4. If the lesson is already covered by existing wording, edit it. Do not append

a duplicate.

1. Apply the update only if the user explicitly asks, or if the current

instruction already authorizes updating the skill.

1. At most one skill update proposal per session, to prevent drift.
2. Validate frontmatter, template consistency, and absence of repo-specific

names before reporting completion.

Temporal feedback into the loop: when measured Te diverges from Tp in a stable per-phase pattern across runs, propose updating the default alpha(phi) prior used in this skill. Subject to the one-proposal-per-session limit.

When To Use

Use this skill when the user asks to:

• use Codex Spark, GPT-5.3-Codex, a worker, subagent, xhigh, high, medium, or

low for fast implementation;

• test a delegated implementation workflow;
• split implementation from verification;
• make a bounded code change where the parent can continue as quality gate.

Avoid this workflow when:

• the task is unclear or exploratory only;
• the next step is immediately blocked on analysis the parent should do locally;
• the write scope cannot be isolated;
• a false positive would be expensive and no runtime proof is possible.

Model And Effort Selection

Effort is chosen on temporal-corrected grounds, not on intuitive task size. Compute Tc = alpha(phi) * Tp and assess parental rework risk before selecting a tier.

Choose the worker by lane fit first, then reasoning effort:

• coder: gpt-5.3-codex medium/high for bounded code-only implementation,

debugging, focused refactors, tests, and repo-native patches.

• spark: gpt-5.3-codex-spark medium/xhigh for near-instant compact

iteration when Spark is available.

• fastworker: gpt-5.4 low or gpt-5.4-mini medium for low-risk mechanical

support lanes.

• auditer: gpt-5.4 high or gpt-5.5 high for proof-gap hunting, edge-case

review, and security-shaped checks.

• parent: gpt-5.5 or gpt-5.4 high/xhigh for mission synthesis,

architecture, final proof, and integration judgment.

Use low or medium only when all of these are true:

• the task is bounded and mechanical;
• the write set is small and explicitly owned;
• the existing pattern is clear;
• acceptance criteria are observable;
• the parent can cheaply inspect and rerun verification;
• the worker is not being asked to make product, architecture, model-selection,

or proof-policy decisions.

Low and medium are cost-control lanes, not context-control lanes. Give them the same full task context, baseline dirty state, file ownership, forbidden surfaces, proof criteria, and final handoff requirements as high or xhigh. Reduce task size, not instruction quality.

Escalate model or effort when:

• the worker must infer missing architecture;
• the patch crosses ownership boundaries;
• the proof path is subtle or easy to fake;
• the first attempt produces broad rewrites, guessed commands, or vague handoff

claims;

• parent review finds a causal proof gap.

Never change the parent or global model mode to test a fast lane. Model and effort experiments happen only inside the sidecar worker.

Temporal note: a task that "feels large" is often GEN with alpha ~= 0.05 and suits medium. A task that "feels small" but contains DBG phases requires xhigh. Size intuition is Tp inflated by TIB; do not let it drive tier choice.

Delegation Protocol

Before Spawning The Worker

1. Inspect enough local context to write a precise task.
2. Capture a baseline: git status -sb, relevant focused diff or grep, and

known command names from package.json or repo scripts.

1. Decide spawn mode:

• To force a specific worker model or effort, spawn with

fork_context: false and embed full task context in the prompt.

• When full conversation history matters more, use fork_context: true and

omit model/effort overrides because forked agents inherit parent settings.

1. State the implementation goal in one paragraph.
2. Give explicit file ownership and forbidden surfaces.
3. Tell the worker it is not alone in the codebase and must not revert unrelated

changes.

1. Define acceptance criteria in terms of observable proof.
2. Require final handoff with files changed, commands run, proof artifacts,

exact proof fields, limitations, concerns, and per-phase Te if measurable.

1. Issue independent preparation calls in parallel: spawn, baseline capture,

adjacent grep, and command discovery in one batch unless logically dependent.

While The Worker Runs

• Do useful non-overlapping review setup locally.
• If the worker runs longer than the corrected Tc would predict, inspect git

status, focused diffs, or proof artifacts without redoing its assigned implementation.

• Stop or redirect only if it touches forbidden surfaces, changes ownership

boundaries, or appears to be solving the wrong problem.

Parent Integration Loop

After the worker returns:

1. Read the changed files or focused diff.
2. Compare the result against the baseline. Distinguish files the worker

actually changed from files already dirty before delegation.

1. Integrate the patch with adjacent code paths the worker did not own: CLI

wiring, imports, registry entries, docs hooks, fixtures, schemas, adapters, generated-contract surfaces, or artifact plumbing when required.

1. Harden obvious gaps immediately: path safety, compatibility fallbacks, error

handling, deterministic artifacts, anti-false-positive checks, and contract drift guards.

1. Look for false positives where the test may not exercise the new path.
2. Run unit tests yourself.
3. Run runtime or integration proof yourself.
4. Inspect generated proof artifacts, screenshots, logs, or browser output.
5. Add any final hardening found by proof inspection.
6. Record measured Te per phase and update local alpha(phi) priors.
7. Close the worker once accepted or superseded.

The parent must not hand back a raw worker patch when local wiring or hardening is clearly needed. A TempoFastlane run is complete only after the parent has converted the worker's slice into an integrated, verifiable repo state.

When To Abort vs Iterate

Before abandoning a patch on the grounds that "iteration would take too long", compute the corrected Tc for the iteration step. Iteration is almost always cheaper than re-delegation because Tp is inflated by TIB.

Discard the patch and re-delegate with smaller scope when any of these appear:

• gross ownership violation;
• fabricated proof;
• broad unauthorized rewrite of files the patch was not supposed to touch;
• handoff claims pre-existing dirty files as newly created;
• repeated guessed command names after the parent supplied the real ones.

Iterate when:

• ownership was respected but proof signal is weak;
• wiring is missing but the core slice is correct;
• a single anti-false-positive check needs adding.

Proof Contract

For every delegated feature, define two paths whenever possible:

1. Legacy path still works.
2. New path is exercised and leaves a different observable mark.

Examples:

• Generated smoke path: proof contains runtime_smoke.source=generated.
• Fallback smoke path: proof contains

runtime_smoke.source=generated-fallback and fallback_generated=true.

• Cache miss path: log or proof contains cache=miss.
• Migration path: DB schema version changes and migrated data is still readable.

If existing behavior can mask the new path, require a force flag or deterministic setup that makes the new path unavoidable.

When there is no runtime path, substitute the runtime contract with a structural diff snapshot: a before/after capture of a public signature, exported API surface, fixture shape, or generated contract file.

Temporal note on proof: do not reject a proof artifact on the grounds that it executed too quickly. A smoke that completes in seconds is the wall-clock truth correcting TIB, not a suspicious signal. Reject on causal content, not on speed.

Anti-False-Positive Rules

Do not accept:

• "I removed X" if the generator recreates X before the relevant stage.
• "Unit tests cover it" when the claim is about runtime behavior.
• "Smoke passed" if the smoke used the old path.
• "Smoke failed" without checking whether the app, server, or runtime

prerequisite was running.

• A guessed command name when the repo has a different script in package.json.
• A handoff that claims already-dirty files were newly created by the worker.
• Docs claiming success before proof artifacts confirm it.
• A duration claim stated without phase classification and alpha(phi) applied.

Require the worker to explicitly answer:

• What proves the new code path ran?
• Which proof file contains it?
• Which field, log line, status, or output confirms it?
• What could still be masking a false positive?
• Which commands were copied from repo scripts

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: maxkle1nz
• Source: maxkle1nz/codex-fastlane
• License: MIT

Install and usage instructions live in the source repository linked above.