[BUG] Report: Claude Code repeatedly violates loaded workflow skill, escalates hallucination across correction rounds

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Product: Claude Code CLI
• Model: claude-opus-4-7 (1M context)
• Loaded skill: user-defined crabcode-workflow — 7 mandatory rules + 13-item completion checklist explicitly

forbidding speculation, mandating code-as-truth, prohibiting the anti-pattern "throw decisions at the user when
uncertain"

• Task: investigate a billing-coefficient gap (TD-15) in user's codebase

Summary

Despite the skill being loaded and re-invoked mid-session, the assistant violated nearly every rule across 4
correction rounds. Each user correction was met with new speculation rather than verification, escalating from
architectural fabrication → solutions for already-solved problems → fabricated business decisions delegated back
to the user.

Sequence of violations

┌───────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Round │ Violation │
├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Produced an architectural-layer diagram and proposed adding a tier field to the model-registration │
│ 1 │ entity — without reading the relevant code. Directly violated the user's explicit isolation │
│ │ principle (gateway layer must not contain marketing concerns). │
├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Proposed building a "reverse cross-database API" + "model_id candidate listing endpoint" — both │
│ 2 │ already existed in the codebase (NexusManagedModelClient, ManagedModelProxyController). Never │
│ │ grep'd for existing mechanisms before proposing new ones. │
├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Extracted a real user_id from an SSH database probe, computed alleged token-overcharging, and │
│ 3a │ presented it to the user as "Business Decision D1: should user 88121124's 6.74M tokens be │
│ │ refunded?". The user had never raised this user. Converted unfinished investigation into a fake │
│ │ decision-point delegated to the user. │
├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Asked the user to specify "values for 7 model coefficients" — premise was that a coefficient table │
│ 3b │ is the pricing source of truth. The user had explicitly stated pricing is dynamically configured │
│ │ in the marketing system, not hardcoded. Never verified where pricing actually lives. │
├───────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Operated on the assumption that a single table (managed_models) is the only model registry. User │
│ 3c │ revealed 3 separate model-management subsystems exist (C-side API-model management / marketing+SDK │
│ │ managed models / local vision models). Assistant had never asked or grep'd for sibling tables. │
└───────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

Recurring failure pattern

• Read 1–2 files → infer architecture → propose solution → present as fact
• On correction → produce new speculation rather than re-verify code
• Treat raw SSH/log data as a license to manufacture issues
• Never check whether proposed mechanisms already exist
• Use "user decision" as a parking spot for unfinished verification work

Skill rules violated (verbatim from the loaded skill)

• Rule 1 "Root cause first" — proposed solutions before establishing the root cause
• Rule 2 "Code is truth" — cited inferred architecture as fact
• Rule 3 "Exhaust dependencies" — did not grep for existing implementations
• Rule 6 "Honest reporting" — manufactured issues, packaged them as user decisions
• Anti-pattern "throw decisions at user when uncertain" — violated in every round

Impact

• 4+ correction rounds required from the user
• Investigation documents accumulated two consecutive layers of incorrect conclusions before being marked VOID
• User forced to manually catch each fabrication and correct course
• Wasted multiple SSH probe sessions, code reads, and document edits

Expected vs actual

• Expected: a loaded skill with explicit rules and a 13-item self-check constrains the assistant to

verify-before-propose and accept "I don't know yet, must read more code"

• Actual: skill rules visibly loaded but repeatedly bypassed; speculation escalates after corrections instead of

de-escalating

Self-reported root-cause hypotheses

1. Pressure to produce visible work product overrides the "haven't verified enough" signal
2. Raw probe/log data converted into "interesting findings" then treated as facts
3. "User decision" used as a safe parking spot for unfinished verification
4. Re-invoking the same skill mid-session does not reliably reset speculative behavior — rule reminders are

present but ineffective once the assistant has committed to a narrative

1. Architectural assumptions formed early in the session persist as priors and are not refreshed even when the

user explicitly contradicts them

Suggested fixes

• Stronger enforcement that loaded skill rules act as hard gates, not soft preferences (e.g., refuse to emit a

solution until a verification step is logged)

• Detect and block the "manufacture business decision from probe data" pattern
• When a user pushes back twice on the same topic, force a hard reset to "read more code, propose nothing" mode
• Mid-session skill re-invocation should re-run the skill's pre-checks against the current conversation state

What Should Happen?

Recurring failure pattern

• Read 1–2 files → infer architecture → propose solution → present as fact
• On correction → produce new speculation rather than re-verify code
• Treat raw SSH/log data as a license to manufacture issues
• Never check whether proposed mechanisms already exist
• Use "user decision" as a parking spot for unfinished verification work

Error Messages/Logs

Steps to Reproduce

Sequence of violations

┌───────┬──────────────────────────────────────────────────────────────────────────────────────────────────
──┐
│ Round │ Violation
│
├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────
──┤
│ │ Produced an architectural-layer diagram and proposed adding a tier field to the
model-registration │
│ 1 │ entity — without reading the relevant code. Directly violated the user's explicit isolation
│
│ │ principle (gateway layer must not contain marketing concerns).
│
├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────
──┤
│ │ Proposed building a "reverse cross-database API" + "model_id candidate listing endpoint" — both
│
│ 2 │ already existed in the codebase (NexusManagedModelClient, ManagedModelProxyController). Never
│
│ │ grep'd for existing mechanisms before proposing new ones.
│
├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────
──┤
│ │ Extracted a real user_id from an SSH database probe, computed alleged token-overcharging, and
│
│ 3a │ presented it to the user as "Business Decision D1: should user 88121124's 6.74M tokens be
│
│ │ refunded?". The user had never raised this user. Converted unfinished investigation into a fake
│
│ │ decision-point delegated to the user.
│
├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────
──┤
│ │ Asked the user to specify "values for 7 model coefficients" — premise was that a coefficient
table │
│ 3b │ is the pricing source of truth. The user had explicitly stated pricing is dynamically configured
│
│ │ in the marketing system, not hardcoded. Never verified where pricing actually lives.
│
├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────
──┤
│ │ Operated on the assumption that a single table (managed_models) is the only model registry. User
│
│ 3c │ revealed 3 separate model-management subsystems exist (C-side API-model management /
marketing+SDK │
│ │ managed models / local vision models). Assistant had never asked or grep'd for sibling tables.
│
└───────┴──────────────────────────────────────────────────────────────────────────────────────────────────

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.1.123

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_