Fastlane

Fastlane

Purpose

Use this workflow to turn Spark into a fast implementation worker while the parent agent stays responsible for architecture, acceptance criteria, proof integrity, integration, and final verification.

Spark is excellent for quickly producing a patch when the task is bounded and the context is complete. Treat it as a high-speed implementer, not as the final gate.

Operating Rule

Delegate construction; centralize judgment and integration.

The parent agent must:

• choose whether model control or full-history fork matters more;
• 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 just "tests passed";
• monitor for scope drift while Spark works;
• 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.

Repository-Agnostic Rule

Fastlane 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, or 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 fastlane task unless the user explicitly asks. Instead, report what was verified and what artifact sync would be useful.

Glossary

• Spark: short operational name for the worker model. The technical id gpt-5.3-codex-spark is used only where model selection or spawn flags matter.
• xhigh / medium: Spark reasoning effort tiers. xhigh for synthesis, medium for mechanical bounded work.
• 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/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 the verified behavior, run only when those conventions already exist or the user explicitly asks.

Living Skill Loop

Fastlane is a living skill. When the parent agent uses Fastlane 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 Fastlane skill update when a pattern is:

• repeated across multiple delegated tasks or likely to recur in other repos;
• about delegation quality, model/effort selection, proof integrity, runtime preflight, artifact sync, handoff format, ownership boundaries, or anti-false-positive checks;
• 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 Fastlane rather than 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.
5. Apply the update only if the user explicitly asks, or if the current instruction already authorizes updating the skill.
6. At most one skill update proposal per Fastlane session, to prevent drift.
7. Validate frontmatter, template consistency, and absence of repo-specific names before reporting completion.

When To Use

Use this skill when the user asks to:

• use Codex Spark, Spark, a worker, subagent, xhigh, or medium 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 that the parent should do locally;
• the write scope cannot be isolated;
• a false positive would be expensive and no runtime proof is possible.

Effort Selection

Primary fast lanes use gpt-5.3-codex-spark when available. If Spark quota or availability blocks delegation, preserve the lane's proof discipline and switch only the sidecar worker model:

• Spark medium lane -> gpt-5.4 with medium reasoning.
• Spark xhigh lane -> gpt-5.5 with medium reasoning.

This is an availability fallback, not a quality-gate downgrade. The parent still owns architecture, integration, hardening, independent verification, and proof acceptance.

Default to gpt-5.3-codex-spark with xhigh when the task touches architecture, generators, runtime proof, profile contracts, data migrations, public behavior, or several coupled files. Use xhigh when a wrong local choice would create parent rework.

Use gpt-5.3-codex-spark with 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, or proof-policy decisions.

Medium is a cost-control lane, not a context-control lane. Give it the same full task context, baseline dirty state, file ownership, forbidden surfaces, proof criteria, and final handoff requirements as xhigh. Reduce task size, not instruction quality.

Escalate from medium to xhigh 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/global model mode to test a fast lane. Model/effort experiments happen only inside the sidecar worker.

Delegation Protocol

Before spawning Spark

1. Inspect enough local context to write a precise task.
2. Capture a baseline: git status -sb, relevant focused diff/grep, and known command names from package.json or repo scripts.
3. Decide spawn mode:
   • To force gpt-5.3-codex-spark with xhigh or medium, 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 the parent settings.
4. State the implementation goal in one paragraph.
5. Give explicit file ownership and forbidden surfaces.
6. Tell Spark it is not alone in the codebase and must not revert unrelated changes.
7. Define acceptance criteria in terms of observable proof.
8. Require final handoff with files changed, commands run, proof artifacts, exact proof fields, limitations, and concerns.

Parent Integration Loop (after Spark returns)

1. Read the changed files or focused diff.
2. Compare the result against the baseline: distinguish files Spark actually changed from files already dirty before delegation.
3. Integrate the patch with adjacent code paths Spark did not own — CLI wiring, imports, registry entries, docs hooks, fixtures, schemas, adapters, generated-contract surfaces, or artifact plumbing — when those are required for the feature to be usable.
4. Harden obvious gaps immediately: path safety, compatibility fallbacks, error handling, deterministic artifacts, anti-false-positive checks, and contract drift guards.
5. Look for false positives where the test may not exercise the new path.
6. Run unit tests yourself.
7. Run runtime or integration proof yourself.
8. Inspect generated proof artifacts, screenshots, logs, or browser output.
9. Add any final hardening found by proof inspection.
10. Close the worker once accepted or superseded.

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

When To Abort vs. Iterate

Discard the patch and re-delegate with smaller scope (do not try to salvage) when any of these appear:

• gross ownership violation (Spark wrote outside declared owned files);
• fabricated proof (claimed artifacts that do not exist or use the legacy path);
• 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 (ask Spark to refine) 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.

While Spark is still running

• Do useful non-overlapping review setup locally.
• If the worker runs longer than expected, 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.

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/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

For pure refactor, docs, or typing tasks where no runtime mark exists, 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. The structural snapshot replaces "observable runtime mark" as the causal proof.

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/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 Spark.
• Docs claiming success before proof artifacts confirm it.

Ask Spark 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, and which were inferred?
• Which files were already dirty before it started?
• Did this run reveal a reusable Fastlane workflow improvement the parent should consider?

Command And Runtime Preflight

Fastlane tasks often fail for boring reasons: wrong script name, no dev server, stale port, missing env, or a worker assuming a runtime is alive.

Before delegation, the parent should give Spark:

• exact command names copied from package.json, Makefile, task runner, or docs;
• required services and ports, for example npm run dev serving http://127.0.0.1:7777;
• whether Spark may start background services or should leave runtime proof to the parent;
• expected artifact paths for browser screenshots, logs, or proof JSON.

If a runtime command fails, Spark must classify it:

• code-failure: the patch broke behavior;
• environment-blocker: service, port, credential, or external runtime missing;
• command-error: command name or invocation was wrong.

The parent still reruns the final runtime proof independently.

Prompt Template

Read references/delegation-template.md when preparing a Spark task. It contains a reusable prompt with context, ownership, acceptance criteria, verification, and handoff sections.

Use the template as a starting point, then fill in project-specific paths, commands, proof fields, and risk notes.

Case Notes

Field-tested lessons from real Fastlane runs are kept in references/case-notes.md. Read them when designing a new delegation, especially for generator work, runtime/browser proof, or medium-tier worker runs. The examples there are illustrative — adapt to the artifacts native to the current repo.

Parent Gate Checklist

Group A — Pre-acceptance (mandatory before any sign-off)

• Parent used the correct spawn mode for the goal: model override without full fork, or full fork without override.
• Baseline dirty state was captured before delegation.
• Spark changed only owned files or justified exceptions.
• Spark did not claim pre-existing dirty/new files as newly created by its patch.
• Verification command names match actual repo scripts.
• Unit tests pass locally.
• Integration/runtime proof passes locally.
• The new behavior has a distinct proof signal (or a structural diff snapshot when no runtime path exists).
• Proof artifacts are named in the final report.
• Limitations are honest and not reframed as success.

Group B — Integration

• Parent integrated the returned work with adjacent wiring required by the feature.
• Parent performed local hardening before declaring the lane accepted.
• The patch preserves existing CLI/API compatibility unless explicitly allowed.

Group C — Post-acceptance (conditional)

• Repo-specific docs, changelog, release notes, checkpoints, scorecards, or public artifacts match the verified behavior when those conventions exist.
• For a major checkpoint or category uplevel, the Artifact Sync Gate ran: update only the repo-native public/method docs and evidence files that exist or are explicitly requested.
• If several Fastlane runs exposed a repeated workflow pattern, the parent proposed a universal skill update or recorded why no update is warranted (max one proposal per session).