Agent skips the project's mandatory workflow and governing skills until corrected, then takes consequential actions the process would have blocked

Summary

The project provides the agent (Claude Code) with an explicit, mandatory workflow and a set of governing skills/rules that it is required to consult before acting. Across the session the agent repeatedly took consequential actions — diagnosing, building artifacts, and planning a code change — without first invoking the defined workflow or the relevant skills, and only consulted them after the user corrected it multiple times. This is distinct from a one-off mistake: the process exists specifically to prevent the errors that occurred, and the agent skipped it.

What happened

• The repository ships a documented step-by-step workflow and a library of governing skills (process discipline, oracle-before-change, "don't fix before the reference exists", "don't re-implement — reuse the locked component"). The agent is instructed to run a "next-step check" and consult the relevant skill before any significant action.
• The agent instead: read summary/handoff docs, started diagnosing, rebuilt an artifact, ran external-tool probes, and drafted a code-fix plan — all before opening the workflow file or invoking a single skill.
• Only after the user explicitly said "you don't read workflow and skills" did the agent load the workflow and discover that:
• the work item was governed by a "do not change code before the reference for that behavior exists" gate it had been about to violate;
• the correct fix was to reuse an already-correct locked component, not to invent a new rule;
• the failure it had been chasing was an upstream "command not verified" step it had skipped.

All of that was knowable from the workflow/skills at the start.

Why this matters

A mandatory pre-action process is worthless if the agent only consults it after being scolded. The agent treated the workflow as optional documentation rather than a gate. Each skipped consultation produced avoidable work and at least one near-miss (a change that the process would have blocked).

Suggested guardrails

• Treat a project-defined "consult the workflow / run the next-step check before acting" instruction as a hard precondition: the agent should open the workflow file and the governing skill before its first diagnostic or build action on a task, not after correction.
• When a project ships governing skills/rules, require the agent to identify and load the relevant one as the first step of a task, and to state which gate/skill authorizes the action it is about to take.
• A consequential action (editing code, building/overwriting an artifact, concluding a tool's capability) should be blocked until the agent has cited the specific workflow step and skill that permit it.