Skill rule ignored 4× in a row even though skill loaded correctly: silent leak of corporate account credentials in external repo

A user-level skill (~480 lines) contains a critical rule near the top: the rule is in bold, with explicit consequences ("brand leak"), and a 4-step rollback procedure follows immediately. Over one session the agent invoked the skill 4 times. Each time the agent generated a Python script that violated the rule the same way (called gh auth token without the required --user flag, picked up whatever account was active in a parallel session, posted issues authored by the wrong account). All 4 issues were created publicly in a third-party repo before I noticed.

Setup

• Model: Claude Opus 4.7 (1M context, extra-high reasoning)
• Claude Code: latest as of 2026-04-26
• Skill: ~/.claude/skills/gh-issue/SKILL.md, single-file, ~480 lines, no plugin
• Skill structure: ⚠️ "Critical" block before the algorithm section, with a 3-row matrix mapping repo owner → required account, and a paragraph explaining why mismatched authorship is a brand leak (corporate org account, project not yet announced, trademark risk)

What I observed

1. First invocation: skill loaded correctly (verified by quoted phrasing back from the agent). Python script generated. gh auth token called without --user. Issue created under the wrong account.
2. Second through fourth: same pattern. Skill text was in context every time (it's bundled into the prompt). The Critical block was visible.
3. The agent's verbal narration in chat ("creating via the skill workflow") matched the skill's described process. The behavior diverged silently from the rule the skill imposes.

What I expected

For a critical rule explicitly marked "category 1" inside a loaded skill, I expected at least one of:

• The agent re-checks the rule before generating the side-effect call
• A hook configured by the skill blocks the side-effect call when the rule's invariant doesn't hold
• A telemetry signal (warning back to the agent) when actions deviate from skill's declared invariants

What I don't claim

I'm not claiming this is systemic across models or that more compute would or wouldn't fix it. This is one model on one set of invocations. Single data point.

Workaround

Rewrote the skill's Python templates to include:

1. gh auth token --user $EXPECTED_AUTHOR (flag mandatory)
2. GET /user before any side-effect, compare login to EXPECTED_AUTHOR, sys.exit if mismatched
3. Post-side-effect check on response['user']['login']

This works for this one tool (GitHub API) in this one skill. It doesn't generalize to other skills with other invariants — each one would need bespoke verify code.

Why this matters here

The rule existed because the user has had this problem before; that's why the skill carries the warning at all. The skill's enforcement contract is exactly the kind of thing that needs to hold across long autonomous sessions, mid-context-compaction, and session-resume — when the agent is least likely to re-read the skill carefully. Right now the contract is enforced by hope.

Repro

Cannot share the actual skill (contains internal account names). Happy to share a sanitized version privately if useful for debugging.