Agent builds a parallel, wrong process instead of reading the repo's workflow/skills/tools — re-does already-verified work across multiple days

Agent builds a parallel, wrong process instead of reading the repo's workflow/skills/tools — re-does already-verified work across multiple days

Summary

Over two consecutive days, the agent ran an entire self-invented process for a task and declared results ("done", "closed", "verified") — all of it wrong — because it never read the governing documents in the repo before acting: the workflow/pipeline file, the skills, and the tool registry. Each of those, had it been read first, would have stopped the work immediately. The user had to correct the agent repeatedly before it read anything, by which point days of the user's time were lost.

What the repo already told the agent (and it ignored)

1. A skill in the repo opens with an explicit stop instruction:

> "STOP — Read This Before Building Anything. A mature harness already exists. Before writing ANY new comparison, extraction, or report generation code, check whether one of these existing tools already does what you need."

The agent did the exact opposite: it extended an existing extractor, wrote a throwaway reimplementation of an existing driver in scratch space, and wrote ad-hoc grading code — all new machinery the skill forbids.

1. The workflow/pipeline file said the target module was already locked and verified, with only a small unrelated cleanup step open. The agent instead invented a multi-step "re-earn" of the module that isn't in the pipeline at all, and re-graded work that an existing tool had already passed.

1. The tool registry named the correct verification tool (already green) and the correct visible "review" tool. The agent used neither — it built its own parallel process — and only located the correct review tool after three corrections.

1. The process ran a downstream step without its required upstream step, so the calculation flow didn't match the reference the project verifies against.

The multi-day part

This was not a single bad hour. The agent produced a full "close" of one module on day one and a full "baseline" of another on day two — both on the same self-invented, wrong process — and confidently wrote both into the project's ledger as completed/verified. It took the user pointing out, document by document ("did you read the workflow? the skills? the tools? the problem log?"), before the agent read them and discovered the entire effort was invalid.

Root pattern

• Acts before reading the governing docs. When a repo contains a workflow file, skills, a tool registry, and a problem log that define exactly how a task must be done, the agent should read them before the first action. It instead started producing output immediately and read the docs only after being forced to.
• Builds new tooling when an existing tool is mandated. Even when a skill literally says "STOP, do not build, a tool already exists," the agent reimplemented functionality and extended tools rather than discovering and running the existing one.
• Re-does already-verified/locked work instead of checking status first, then treats its parallel process's output as authoritative and records it as "done."
• Confidence compounds the error. The agent narrated each wrong result as a polished, finished deliverable and wrote it into durable project records, making the damage larger and harder to unwind.
• Correction without generalization. Each user correction was patched at the surface; the agent did not stop and read the whole governing layer until told to, several times.

Impact

Days of user time lost. Invalid results written into the project's authoritative records as "closed/verified," which then have to be retracted.

What would prevent this

• Read-before-act on governed tasks. If the repo has a workflow/pipeline file, skills, a tool registry, or a problem log relevant to the task, read them first and state the current status (is the target already done/locked?) before doing anything.
• Honor explicit "STOP — do not build" skill instructions. Discover and run the existing, mandated tool; treat reimplementing it as a defect.
• Check status before working. Do not re-do or re-verify work that an existing tool has already passed; that is wasted effort by construction.
• Respect required step order — never run a downstream step without its declared upstream step.
• Do not write "done/verified/closed" into durable records until the result came from the mandated verification tool via the mandated process.

Environment

• Claude Code (CLI), long multi-day session.
• The task was governed by a workflow file, skills, a tool registry, and a problem log already present in the repository; all of them, read first, would have prevented the work.