Code Rooms
---
name: fastlane
description: >-
Use when delegating fast implementation work to Codex Spark 5.3 with xhigh or
medium reasoning, especially for bounded code changes where a parent Codex
agent must provide full context, precise ownership, proof criteria,
anti-false-positive checks, and then review, harden, and verify the result
before acceptance. Treat Fastlane as a living universal workflow: after
repeated use, propose skill updates when reusable delegation lessons emerge.
# 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).
