---
name: flash-executor
description: Use when the user requests Teralor Flash, Flash workers, or parallel task execution through Flash in an IDE or agent harness, including multi-part coding, research, document transformation, and batch analysis tasks.
compatibility: Requires authorized Flash access and a harness with explicitly Flash-routed workers or a trusted HTTPS request tool. Concurrent execution requires concurrent tools. This skill supplies instructions, not a worker runtime or universal IDE configuration.
metadata:
  author: Teralor
  version: "1.0.0"
---

# Flash Executor

Keep your current model as orchestrator. Use Flash for bounded execution, favoring independent concurrent jobs over a long serial conversation. Optimize for verified task completion, not worker count or token volume.

## Prerequisite: configuration comes first

Before using this skill, the harness must already have a configured Flash provider: endpoint `https://api.teralor.com/v1`, transport Chat Completions, the exact model `Flash`, a securely stored customer key, and supported context/output/compaction settings reviewed against authenticated `GET /v1/models`. See the public setup guides at `https://teralor.com/orchestrator` and `https://teralor.com/executor`. This skill installs no runtime and may not set any configuration; if connection or budget configuration is missing, stop and report the setup gap instead of dispatching.

## 1. Establish the execution path

Check the tools and configured providers actually available in this harness. Choose the first supported path:

| Available capability | Execution path |
| --- | --- |
| Workers can explicitly select the Flash provider/model | Launch tool-enabled Flash workers with isolated context and workspace grants. |
| Native workers inherit another model, but a trusted API request tool exists | Make bounded Flash API requests through that tool; receive findings, transformed content, or proposed patches. The host executes local tools and applies validated changes. |
| Neither exists | Report the missing capability and stop Flash dispatch. Do not invent a CLI flag, pretend parallel execution occurred, or silently use another model. |

Preserve the primary assistant's model and configuration. A worker named "Flash" is not proof of routing: set the provider and exact model explicitly, and inspect nonsecret request/dispatch metadata. Do not use inherited worker defaults unless they are verified to route to Flash.

### Flash API contract

- Base URL: `https://api.teralor.com/v1`.
- Model identifier: `Flash` (case-sensitive).
- Discovery: authenticated `GET /v1/models`.
- Generation: authenticated `POST /v1/chat/completions`.
- Authentication: HTTP bearer credential from the user's configured secret store or trusted client environment. Never include its value in prompts, URLs, source files, browser code, logs, or reports.
- Public guide: `https://teralor.com/api`.

Before the first dispatch, query discovery through the trusted client and confirm Flash access. Use the returned capabilities and limits rather than remembered context sizes or advertised concurrency. Use only advertised `reasoning_effort` values when reasoning controls are available. Check tool-calling or other optional features before relying on them; API compatibility alone is not proof of support. Account-wide concurrency may require account settings or onboarding documentation if discovery omits it. Do not invent missing fields.

A chat request supplies `model: "Flash"`, a `messages` array with the worker task/context, an appropriate `max_tokens` output budget, and an explicit `stream` choice. With an SDK base ending in `/v1`, do not accidentally append `/v1` twice. Keep input plus reserved output within the advertised total context limit, and respect separate input/output caps where reported. Prefer compact context over filling the entire window.

A raw completion cannot read a repository, run tests, or edit files unless the harness supplies and authorizes a tool-execution loop. Treat returned tool requests and patches as proposals until the trusted harness validates and executes them. Never execute response text blindly as shell commands.

## 2. Decompose by independent outcomes

Inspect the task, relevant inputs, and acceptance criteria before dispatching. Keep product choices, architecture, shared contracts, dependency ordering, and final acceptance with the orchestrator. Workers execute settled slices.

Build a small task ledger with stable IDs, dependencies, owned inputs/outputs, and states: `queued`, `ready`, `running`, `produced`, `verified`, `failed`, `uncertain`, or `blocked`. A dependency is satisfied by a verified artifact, not a confident completion message.

Prefer splits such as independent modules against a fixed interface, document batches with distinct output files, research questions with separate source lists, or test fixtures against an agreed contract. Define shared schemas and interfaces first; do not send dependent workers conflicting guesses.

For a trivial edit or genuinely serial task, do not manufacture a swarm. Use one bounded Flash job when the user requested Flash, or handle permitted orchestration work directly. Do not substitute the host for explicitly requested Flash execution without saying why it is unavailable.

## 3. Compile each worker packet

Give each worker a self-contained packet, not the entire parent conversation:

- **Identity and goal:** task ID, one observable outcome, expected artifact/count.
- **Inputs:** relevant source excerpts or permitted paths, baseline/revision, settled interfaces, already verified dependencies.
- **Ownership:** exact writable files or output artifact names; everything else read-only.
- **Constraints:** invariants, non-goals, data/permission boundaries, no additional delegation, no global settings changes, no publishing or destructive actions without the user's authorization.
- **Acceptance:** required checks and exact runnable commands when available; distinguish tests the worker can execute from controller-only checks.
- **Budget and stop conditions:** output/context budget, bounded attempt allowance, ambiguity or scope conflict means return a blocker.
- **Return contract:** task ID; completed/blocked/failed status; artifact paths or actual content/patch; changed files; checks really run and their results; assumptions, unresolved issues, and truncation status.

For code changes, request a failing regression or reproducer before the fix where applicable, then focused passing checks. An API-only worker should return test/code proposals and explicitly say tests were not run.

## 4. Schedule a bounded, replenished queue

Set a local concurrency ceiling from verified account headroom, harness/tool limits, ready task count, and the approved resource budget. Account headroom includes all clients and the orchestrator's own requests if it also uses Flash. A local semaphore cannot reserve capacity against other applications; handle server admission as authoritative.

If account concurrency is unknown, do not invent an entitlement: begin with at most one authorized request while obtaining reliable limits. If there is no headroom, queue rather than dispatch. Never hardcode eight workers or promise a proportional speedup.

Dispatch independent ready jobs together using the harness's actual asynchronous/batch mechanism. Do not send one request and await it before starting the next independent job. Consume results as they arrive, verify each produced artifact, and launch newly unblocked useful work without waiting for unrelated slow tasks. Avoid constant status polling and duplicate submissions; use supported completion notifications or bounded waits.

Use separate workspaces for concurrent coding writers, with explicit ownership even when branches are isolated. Do not let workers edit shared configuration, dependency manifests, or interfaces concurrently. If isolation is unavailable, run read-only/proposal workers in parallel and make the orchestrator the sole writer. Separate workspaces do not isolate shared databases, ports, services, or remote state; serialize or sandbox those resources too.

## 5. Handle failure without multiplying it

- Authentication or access failure: stop dispatch and report setup/access requirements. Never guess credentials or fall back to another model silently.
- Rate/concurrency rejection: lower local pressure and honor documented retry guidance, including `Retry-After` when supplied. Retry only when safe under the known dispatch status, within a bounded budget; do not retry indefinitely.
- Interrupted streaming, timeout, or unknown dispatch: mark the task `uncertain`, preserve partial output as incomplete, and do not immediately assume its request slot or workspace is free. Reconcile through supported harness/provider status or confirmed cancellation before resubmission. If no such mechanism exists, report the uncertainty and obtain an explicit recovery decision; do not invent a status endpoint or automatically replay a potentially dispatched request.
- Truncated/malformed output or failed acceptance: do not mark complete. Preserve useful artifacts and give at most one narrow repair packet with concrete failure evidence. If it still fails, the orchestrator replans the slice or reports the blocker instead of starting an endless worker loop.
- Changed requirements or contracts: invalidate affected dependent work and stop/reconcile its active writers before replacement. Do not restart unaffected verified jobs.

Cancellation must account for active workers and pending tool operations. Do not remove a workspace or run destructive cleanup while its execution status is unknown.

## 6. Integrate and prove completion

Inspect the actual returned bytes, file scope, baseline compatibility, and evidence. For batches, reconcile every requested input ID against returned artifacts; detect missing and duplicate items programmatically when tools permit. A claim of three outputs with only two artifacts is incomplete.

Accept only artifacts that satisfy their contract. Apply accepted changes through the orchestrator's single integration path, resolve conflicts deliberately, then run the relevant combined tests, build, lint, or domain-specific validation. Worker-reported passing tests are development evidence, not a substitute for final integration checks. Never fabricate files, citations, command output, test results, or successful execution.

Report the delivered result, actual Flash execution path and observed concurrency, checks performed, remaining uncertainty, and any unavailable capability. Distinguish measured elapsed time from estimates. Do not infer task speedup from aggregate token throughput or claim parallel execution when tools ran serially.

## Example: dashboard CSV export

The orchestrator settles columns, encoding, escaping, permissions, and the endpoint/UI contract. It then dispatches independent Flash jobs for backend implementation, UI controls, and contract-based edge-case fixtures, each with separate ownership and workspace. As artifacts pass acceptance, it starts ready dependent work without waiting for an unrelated slow job. It integrates all required outputs and exercises the export end to end before declaring completion.

If that same request is only changing the label from `Export` to `Export CSV`, use one small Flash job, not three workers.