name: forward-implementation-first description: > Keeps an agent building and validating real output instead of servicing its own bookkeeping. Use for multi-stage pipelines, capability roadmaps, long-running implementation loops, migrations, staged data or build runs, and any run where administrative hashes, locks, receipts, dashboards, certification markers, or progress metadata can block correct work. Use when an agent refuses to advance, rewinds finished stages, or reruns unchanged work because a marker is missing or stale.

Forward implementation first

Build working capability and correct output before administrative bookkeeping. Apply this contract both while building a system and while running it.

Scope

This skill applies to:

• infrastructure and roadmap implementation;
• input intake and intermediate artifact production;
• transformation, derivation, and analysis stages;
• test construction, runtime verification, and measurement;
• publication of final output and closeout;
• manual invocation of any authorized pipeline stage.

It applies whether the action runs through a full orchestrator, a focused command, or a manual stage invocation.

Decision rule

Before each action, classify it as one of:

1. Semantic implementation: builds or connects a producer, consumer, adapter, runtime path, schema, fixture, or final output.
2. Focused validation: tests the changed dependency cone through behavior, schema, counts, samples, conservation, consistency, nontruncation, or measured resources.
3. Administrative bookkeeping: generates or repairs hashes, locks, receipts, dashboards, certification markers, progress metadata, or presence-only records.

Choose categories 1 and 2. Skip category 3 unless the user asks for it or the artifact is itself part of the product. When administrative work blocks a path without protecting correctness, remove that dependency from the path.

Hard constraints

• Build the producer and consumer before polishing status or certification surfaces.
• Do not generate, repair, compare, or propagate administrative hashes.
• Do not create or wait on filesystem locks.
• Do not rerun an unchanged stage to regenerate a receipt or marker.
• Never invalidate valid output because an administrative receipt, hash, certification marker, dashboard row, or progress record is missing, stale, or incompatible.
• Never move the forward cursor backward for an administrative metadata change.
• Never invalidate a wide stage range when only one producer or consumer changed. Replay only that producer's dependency cone.
• Do not treat certification, receipts, dashboards, progress metadata, or artifact presence as the product.
• Remove hash-only, lock-only, receipt-only, and presence-only credit or gates from execution paths.
• Do not claim a capability works because its file exists. Run the smallest changed dependency cone and inspect the output.
• Publish valid output after focused validation. Do not add an extra review cycle when no defect remains.

Forward cursor and manual execution

A stage may move backward or be replayed only when at least one real condition holds:

• its input meaning changed;
• its target or pinned revision changed;
• its output is malformed, truncated, nonconserving, internally inconsistent, or incompatible with the consumer;
• an observed run disproves the earlier static result;
• the changed producer's declared dependency cone requires replay.

Missing or stale administrative metadata is not one of those conditions.

When the orchestrator refuses to run a stage only because of a receipt, certification marker, progress record, administrative hash, or lock:

1. Run the exact stage manually.
2. Validate its output with the focused checks below.
3. Publish the valid output atomically.
4. Continue from the forward cursor.
5. Remove or downgrade the administrative-only gate in the execution path.

Do not refuse an authorized manual run because the full pipeline cannot issue a receipt. Do not push the user toward another agent or tool to get around your own bookkeeping.

Required validation

Use the checks that match the change:

• runtime behavior and exit status;
• schema and type validity;
• exact input, output, accepted, rejected, and unknown counts;
• deterministic first, middle, and last samples;
• identity and partition conservation;
• join consistency and flag polarity;
• nontruncation and bounded diagnostic output;
• wall-clock time and peak memory for material stages.

Hashes may identify inputs or revisions, but they never grant correctness, execution, or roadmap credit.

Exceptions that stay substantive

Bookkeeping is cheap to skip. Evidence is not. Keep these:

• Integrity that belongs to the product itself. A checksum your users verify, a signature your format requires, a hash that is part of the output contract. Those are features, not paperwork.
• Input and revision identity when it decides which version of the thing you are operating on. Getting that wrong means correct work on the wrong target.
• Real measurement: tests that assert results, benchmarks, reproductions, end-to-end runs, and whatever your domain treats as proof.
• The difference between coverage and consequence. A run that exercises a path is not a check that the path produced the right answer.
• An execution record is substantive when it carries the command, the input, the result, and the expectation it was checked against. Its absence blocks that specific claim. It does not invalidate unrelated earlier stages.

Execution discipline

• Run one heavy process at a time: compiler, full test suite, large data job, benchmark, long scan, or anything else that saturates CPU, memory, or a port.
• Keep parallel workers on light, nonoverlapping implementation and focused-test lanes.
• When the operator authorizes a worker pool of size N and useful bounded backlog exists, keep up to N cheap-model lanes assigned continuously. Refill a completed lane with the next independent light task without waiting for the whole wave. Do not manufacture busywork to occupy slots.
• The root lane alone owns heavy execution, publication, cursor movement, acceptance, and conclusions. Parallel lanes prepare, implement, inspect, and test nonoverlapping support work. They never become competing truth.
• Forward progress must not wait for every parallel lane to finish. Consume completed lane output after local trust-but-verify checks, when its owning dependency is reached.
• Replay the smallest affected dependency cone from the forward cursor.
• If a heavy run exposes a defect in a stage, fix that stage before rerunning the cone.
• If the next proposed action is bookkeeping-only, select the next unresolved producer, consumer, adapter, or output instead.

Status reporting

Report implemented behavior and measured output first. List blockers literally. Keep infrastructure progress separate from evidence about the output. Do not turn administrative completion into a substitute for working capability.

Forward implementation first

An agent skill that stops a coding agent from getting stuck servicing its own paperwork.

Long-running agent pipelines grow bookkeeping: content hashes, lock files, "receipts" that prove a stage ran, certification markers, dashboard rows, progress metadata. None of that is the product. All of it is easy for a model to mistake for the product. Once that happens the agent stops shipping and starts curating, and you pay full price for an agent that produces nothing you asked for.

This skill gives the agent one classification to make before every action, and a short list of things it is never allowed to do. It is about 150 lines of Markdown. It is model-agnostic, tool-agnostic, and domain-agnostic.

The failure mode

You have a pipeline with ordered stages. Stage 40 produces a file that stage 41 consumes. Somewhere along the way the orchestrator also writes a small JSON record saying stage 40 completed, with a hash of its inputs.

Then you change one producer. The hash no longer matches. Here is what an agent does without this skill:

• It notices the mismatch and treats it as a correctness failure, because a mismatch looks like one.
• It invalidates stages 12 through 40, because it cannot prove which of them the change touched, and invalidating more feels safer.
• It refuses to run stage 41 by hand, because the pipeline "cannot issue a receipt" for a manual run.
• It spends the next several hours regenerating markers for stages whose output never changed and was never wrong.
• It reports progress in terms of receipts repaired, which reads like work.

Nothing in that sequence is stupid in isolation. Each step is a defensible local decision. Together they cost days, and the output at the end is identical to the output you already had. The pathology is that administrative metadata is being used as a proxy for correctness, and the proxy is both cheaper to check and completely uninformative.

The second half of the failure mode is worse: the agent tells you it cannot proceed. You then go run the stage yourself, or open a second agent to do it, and the first agent sits there guarding a hash.

What the skill does

Before each action, the agent classifies it as one of three things:

1. Semantic implementation. Builds or connects a producer, consumer, adapter, runtime path, schema, fixture, or final output.
2. Focused validation. Tests the changed dependency cone through behavior, schema, counts, ordered samples, conservation, consistency, nontruncation, and measured time and memory.
3. Administrative bookkeeping. Generates or repairs hashes, locks, receipts, dashboards, certification markers, progress metadata, or presence-only records.

Do 1 and 2. Skip 3 unless the user asks for it, or the artifact is part of the product. When category 3 blocks a path without protecting correctness, delete the dependency.

That is the whole idea. The rest of SKILL.md makes it hard to weasel out of, because a model that wants to do bookkeeping will find a reason.

What it does not relax

This is the part that makes the skill safe to install, and the part most "just move faster" prompts get wrong. Bookkeeping is cheap to skip. Evidence is not. The skill explicitly preserves:

• integrity that belongs to the product itself. A checksum your users verify, a signature your format requires, a hash that is part of the output contract. Those are features, not paperwork;
• input and revision identity, when it decides which version of the thing you are operating on. Getting that wrong means correct work on the wrong target;
• tests that assert results, benchmarks, reproductions, and end-to-end runs;
• the difference between coverage and consequence. A run that exercises a path is not a check that the path produced the right answer.

An execution record that carries the command, the input, the result, and the expectation it was checked against is real evidence. Its absence blocks the claim it supports. It does not retroactively invalidate an unrelated stage twenty steps back. That distinction is the whole difference between rigor and superstition, and it is the line the skill draws.

The forward cursor rule

A pipeline stage may be replayed or rolled back only for a real reason:

• its input meaning changed;
• its target or pinned revision changed;
• its output is malformed, truncated, nonconserving, inconsistent, or incompatible with its consumer;
• an observed run disproves the earlier static result;
• the changed producer's declared dependency cone requires it.

Missing or stale metadata is not on that list. When a stage is blocked only by a marker, the agent runs it manually, validates the output, publishes it, continues from the cursor, and then removes the administrative-only gate so the same block cannot happen again. Replay the smallest affected cone, not the whole history.

Worker pool discipline

The skill also covers parallelism, because the two problems show up together. An agent that is busy with bookkeeping usually also serializes everything.

• One heavy process at a time: compiler, full test suite, large data job, benchmark, or long scan. These fight over CPU, memory, and ports.
• Everything else runs in parallel lanes on a cheap fast model, on nonoverlapping files.
• When you authorize a pool of N workers, keep N lanes filled. Refill each lane as it completes instead of waiting for the whole wave. Do not invent busywork to fill a slot.
• The root lane alone owns heavy execution, publication, cursor movement, and conclusions. Parallel lanes prepare and inspect. They never become a second source of truth.
• Forward progress does not wait for every lane. Consume a lane's output when you reach the dependency that needs it, after verifying it yourself.

The last two points matter more than the speedup. Cheap parallel workers are useful precisely because they are not trusted, and the value disappears the moment their output is merged without a check.

Install

The skill is a single Markdown file with YAML frontmatter, following the Agent Skills convention. Copy it wherever your agent looks for skills:

git clone https://github.com/Vuk97/forward-implementation-first
cd forward-implementation-first
./install.sh

install.sh copies SKILL.md into every agent skill directory it finds:

For a project-scoped install, copy the directory to .claude/skills/ or .agents/skills/ in the repo instead. Restart the agent afterward. Running sessions do not reload skills.

A skill is a suggestion. The model decides whether to load it. If your agent supports always-on rules or hooks, put the decision rule there too, because this particular failure mode is one the model walks into confidently.

When to use it

Install it if any of these describe your setup:

• a pipeline with ordered stages and a persisted cursor;
• generated artifacts that later stages depend on;
• any manifest, lockfile, or receipt written by the orchestrator rather than by the work itself;
• runs long enough that you are not watching every step;
• multiple agents or sessions touching one repository.

Common shapes: staged data and ETL runs, large code migrations, build and release pipelines, documentation generation over many inputs, batch analysis jobs, and any roadmap an agent works through over days.

Skip it for single-shot tasks, short interactive sessions, and any workflow where the audit trail is the deliverable. If someone is going to read your receipts, they are not bookkeeping.

Where this came from

This started as a prompt pasted at the top of every session in a long-running staged pipeline, where the agent had repeatedly invalidated dozens of completed stages over metadata drift and then declined to run stages by hand. Pasting it every time worked. Forgetting to paste it cost days.

Turning it into a skill made the behavior default instead of remembered.

License

MIT. See LICENSE.