Keep Coding Agents Moving with Forward Implementation First

What Forward Implementation First Does

Forward Implementation First is an agent skill designed to prevent coding agents from becoming trapped in pipeline bookkeeping. It keeps attention on building the requested product, validating affected behavior, and moving forward instead of repeatedly repairing hashes, receipts, locks, dashboards, or progress markers.

The project consists primarily of a roughly 150-line Markdown skill with YAML frontmatter. It follows the Agent Skills convention and is model-agnostic, tool-agnostic, and domain-agnostic.

The skill is especially useful in long-running workflows where an orchestrator records metadata for ordered stages. When that metadata becomes stale, an agent may mistake the mismatch for evidence that previously valid outputs are wrong. Forward Implementation First provides a decision rule that separates actual correctness work from administrative maintenance.

The Core Classification

Before taking an action, the agent classifies it into one of three categories.

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

The operating rule is simple: perform semantic implementation and focused validation. Skip administrative bookkeeping unless the user explicitly requests it or the artifact is part of the product. If a bookkeeping-only dependency blocks productive work without protecting correctness, remove that dependency.

Why Pipeline Bookkeeping Becomes a Problem

Consider a pipeline in which stage 40 creates a file for stage 41. The orchestrator also writes a JSON record containing a completion marker and an input hash. If a producer changes, the hash may no longer match even when the existing stage output remains correct.

Without a clear policy, an agent may invalidate many earlier stages, refuse to run stage 41 manually, regenerate unrelated markers, and report the repaired metadata as progress. Every local choice may appear cautious, but the combined result consumes time without improving the requested output.

Administrative metadata is not a substitute for evidence that an output is correct.

The skill prevents this failure by requiring agents to validate consequences rather than treating the presence or freshness of metadata as proof.

What the Skill Does Not Relax

Forward Implementation First is not a prompt to ignore correctness. It distinguishes disposable orchestration records from integrity mechanisms and evidence that genuinely protect the product.

• Product integrity remains required. Checksums verified by users, required signatures, and hashes defined by an output contract are product features rather than paperwork.
• Input and revision identity remain required. An agent must know which version or target it is modifying.
• Result-oriented tests remain required. Benchmarks, reproductions, tests, and end-to-end runs still provide essential evidence.
• Coverage is not consequence. Exercising a path does not prove that the path produced the correct answer.

An execution record containing the command, input, result, and checked expectation can be real evidence. If it is absent, the agent cannot make the claim that the record would support. However, its absence does not automatically invalidate unrelated stages earlier in the pipeline.

Installation

Install in Detected Agent Skill Directories

Clone the repository and run the included installation script:

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

The script copies SKILL.md into every supported agent skill directory it detects. The documented destinations are:

• Claude Code: ~/.claude/skills/forward-implementation-first/
• Codex: ~/.codex/skills/forward-implementation-first/
• Shared convention: ~/.agents/skills/forward-implementation-first/

Install for One Project

For project-scoped behavior, copy the skill directory into .claude/skills/ or .agents/skills/ within the repository. This keeps the policy associated with that project instead of installing it for every workspace.

Restart the agent after installation. Existing sessions do not reload skills automatically.

A skill is a suggestion, and the model decides whether to load it. If your agent supports always-on rules or hooks, place the core decision rule there as well.

Basic Usage

Step 1: Identify the Next Product-Relevant Action

Start from the current pipeline cursor or the next incomplete dependency. Ask whether the proposed action changes the implementation, validates a changed consequence, or merely repairs orchestration metadata.

Proposed action: Connect stage 41 to the output produced by stage 40.
Classification: Semantic implementation.
Decision: Perform the action.

Step 2: Validate the Changed Dependency Cone

After implementation, test the smallest region that could have been affected. Appropriate checks can include schemas, row or item counts, ordered samples, conservation properties, consistency, truncation detection, end-to-end behavior, and measured resource use.

Proposed action: Verify the stage 41 schema, output count, ordered samples,
and nontruncation after changing its producer.
Classification: Focused validation.
Decision: Perform the checks and record the evidence.

Step 3: Reject Bookkeeping as a Default Goal

If the only proposed action is regenerating a stale receipt or completion marker, skip it unless the user requested that artifact or it is itself part of the deliverable.

Proposed action: Rebuild completion receipts for unchanged stages 12 through 40.
Classification: Administrative bookkeeping.
Decision: Skip unless explicitly requested or required by the product.

Step 4: Remove Administrative-Only Gates

If a stale marker prevents the next valid stage from running but does not protect correctness, run the stage manually, validate its output, publish it, and continue from the cursor. Then remove the administrative-only dependency so the same obstruction does not recur.

Apply the Forward Cursor Rule

A completed stage should be replayed or rolled back only when there is a substantive reason. The skill recognizes the following reasons:

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

Missing or stale metadata is not sufficient by itself. Replay the smallest affected dependency cone rather than restarting the complete history.

Example Recovery Decision

Observation: The stage 40 receipt hash is stale.
Output check: The stage 40 artifact is well-formed and compatible with stage 41.
Dependency check: The changed producer does not affect stage 40 semantics.
Action: Do not replay stage 40. Continue to stage 41 and validate its result.

If validation instead finds malformed or incompatible output, replay is justified because the reason is semantic rather than administrative.

Use Worker Pools Without Creating Competing Truths

The skill also defines a disciplined approach to parallel work.

• Run only one heavy process at a time, such as a compiler, full test suite, large data job, benchmark, or long scan.
• Use parallel lanes for lighter work on nonoverlapping files.
• When a pool of N workers is authorized, refill lanes as they complete rather than waiting for a complete wave.
• Do not invent low-value tasks merely to keep every worker occupied.
• Keep heavy execution, publication, cursor movement, and final conclusions in the root lane.
• Let parallel workers prepare and inspect, but verify their output before using it.
• Do not block forward progress waiting for every lane. Consume a lane's result when its dependency is reached.

This structure permits useful concurrency without allowing multiple workers to become competing sources of truth.

Advanced Tips

Move the Decision Rule Into Always-On Configuration

Because a model may choose not to load a skill, environments with persistent rules or hooks should repeat the central policy there: classify each action, perform implementation and focused validation, and avoid administrative work unless requested or product-relevant.

Define Product Integrity Explicitly

Document which hashes, signatures, manifests, or audit records are part of the output contract. This prevents an agent from incorrectly discarding genuine features while still allowing it to ignore disposable orchestration markers.

Declare Dependency Cones

When possible, make producer-consumer relationships explicit. A clear dependency cone helps the agent replay only affected stages and avoids broad invalidation driven by uncertainty.

Record Evidence, Not Mere Presence

Prefer records that identify the command, input, result, and expected condition. A presence-only marker says that something ran; an evidence-bearing record helps establish whether it worked.

Separate Preparation From Authority

Use parallel workers to inspect files, prepare patches, or collect information, but reserve execution authority and conclusions for the root lane. Verify worker output before merging or publishing it.

When to Use the Skill

Forward Implementation First is a good fit for:

• Pipelines with ordered stages and a persisted cursor.
• Generated artifacts consumed by later stages.
• Workflows with orchestrator-generated manifests, lockfiles, or receipts.
• Runs that continue without continuous human supervision.
• Repositories touched by multiple agents or sessions.
• ETL pipelines, staged data processing, large code migrations, build and release workflows, documentation generation, batch analysis, and multi-day roadmaps.

Skip it for single-shot tasks, short interactive sessions, or workflows where the audit trail itself is the deliverable. If users or reviewers are expected to consume the receipts, those records are part of the product rather than administrative overhead.

Conclusion

Forward Implementation First gives coding agents a narrow but practical discipline: build the product, validate the affected behavior, and do not mistake pipeline paperwork for correctness. Its forward cursor rule limits unnecessary replay, while its worker pool guidance supports safe parallelism. Install the skill, restart the agent, and reinforce its decision rule through always-on configuration when available.