forward-implementation-first README

The project's README from github.com/Vuk97/forward-implementation-first. As one markdown file: README.md.

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:

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:

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:

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.

Parallel work: invariants, not a scheduler

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

Early feedback drew one boundary the first version got wrong: a skill must not act as an orchestrator. Scheduling, resource contention, and worker topology belong to your runtime, and a few lines of Markdown that claim them will fight any real scheduler. So the section is split in two.

Invariants, kept as first-class rules because they hold under any scheduler:

Scheduling policy itself, worker counts, wave sizes, what counts as a heavy process, is not in the skill at all. Your runtime already owns it, and a skill that carries its own policy would fight it. If nothing owns scheduling in your setup, examples/execution-profile.md is a starting profile to copy and edit. The skill never loads it on its own.

The invariants 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:

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

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:

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.

forward-implementation-first (Vuk97/forward-implementation-first)

Searching Database…

这是什么?这是一个智能体技能——一个简短的 Markdown 指令文件——防止 Claude Code 和 Codex 这类编程智能体沉迷于自创的簿记工作(哈希、锁文件、回执、认证标记)而搁置真正的工作、迟迟不交付实际产出。
这是插件,还是我要运行的实际代码?它是一个带 YAML frontmatter 的单一 Markdown 文件(约 150 行),遵循 Agent Skills 约定;它不是程序,只是智能体在行动前加载进上下文的一套规则。
它适用于哪些编程智能体?任何遵循 Agent Skills 约定的智能体;README 明确确认了 Claude Code 和 Codex,这个技能本身与模型无关、与工具无关,无需安装额外依赖。
它在我安装的那一刻就生效吗?不是——你必须重启智能体,因为运行中的会话不会重新加载技能;而且即便如此,加载它也是可选的,因为模型会自行决定是否遵循某个技能。
它究竟修复什么失败情形?它防止智能体把过期的哈希或回执当作正确性错误,否则智能体会使数十个原本完好的流水线阶段失效,并拒绝手动运行步骤,只为“修复”那些从未影响真实输出的元数据。
它会让智能体跳过真正的测试吗?不会——它明确保留产品校验和、修订一致性检查以及行为测试/基准;它只削减与工作是否正确无关的行政性簿记。
它会尝试调度或编排并行智能体吗?不会,它刻意避免充当调度器。它只强制一些不变量——发布由单一写入者负责、在信任 worker 的输出之前先验证——把实际的调度策略留给你的运行时。
什么情况下我应该跳过安装它?单次任务、简短的交互式会话,或任何以审计轨迹本身为交付物的工作流,都应跳过它——在这些场景下,这个技能所不鼓励的“簿记”恰恰就是重点。
Creator
Vuk97
Size
<0.1 MB
Stars
180
Updated
CommitAug 31
Age
1mo
Commits · 90 Days