codex-in-claude: Skill for Claude Code

Separating Context from Constraints

Audit agent-consumed instruction documents — skills, system prompts, CLAUDE.md/AGENTS.md, MCP tool and resource descriptions, slash-command prompts — for separation of binding rules from context. This skill is audit-first: authoring workflows (skill-creator, superpowers:writing-skills) own document creation, and this skill composes with them as a quality lens. The product is a structural clarity audit; behavioral risk is the rationale for the rules, not the deliverable.

Core Concept

Every statement in an instruction document plays one of three roles:

1. Binding rules — statements that direct behavior; if the agent ignores one, its behavior is wrong.
2. Load-bearing facts — definitions, domain facts, tool semantics, and environment details that inform correctness; not rules, but their loss makes output wrong.
3. Discretionary context — rationale, examples, background, and framing; degrades gracefully if lost.

Apply this two-question litmus test to each statement:

1. Does this statement direct behavior or inform it? Direct means go to the binding-rules class; inform means go to question 2.
2. If it were lost, would output be wrong (load-bearing fact) or just less informed (discretionary context)?

Mixing these roles fails for three reasons. Rules camouflaged as narration are lost under long-context pressure. Interleaved rules are not individually checkable. Readers cannot distinguish negotiable flavor from requirements.

Rules

Each rule below has an id and is checkable by an auditing agent.

• R1 Distinguishability. Make every binding rule structurally distinguishable from context. Treat a document with labeled sections or rules distributed across multiple paragraphs as long-form, and place its rules in a dedicated labeled section. Treat a single flat description without sections as compact, and mark its rules inline with imperative sentences, list items, or explicit mandatory wording. Keep rule sections free of discretionary context and load-bearing facts; place those statements in context, semantics, or similarly informative sections. A "rule" that cannot fail is context in disguise and belongs elsewhere. One finding per misplaced statement, even when both directions of the defect are present.
• R2 Explicit strength. Every rule signals whether it is mandatory (must/never) or a default with override conditions (prefer X unless Y). Defaults and defeasible guidance are legitimate rules, not failed constraints. Only ambiguous strength is a finding — a hedge ("generally", "try to") that leaves the reader unable to tell whether the statement binds.
• R3 Verifiability. Each rule is checkable against some observable evidence: output, tool calls, repository state, or process artifacts. When an unverifiable rule does not reveal the author's intended safeguard, request an author decision instead of inventing a definitive rewrite. "Be concise" fails. "Chat responses of four sentences or fewer unless asked" passes. "Never run destructive commands without confirmation" passes via tool traces.
• R4 Atomic obligations. Independently checkable obligations are stated separately. Condition–action–exception clauses sharing one trigger may stay together as a single unit.
• R5 Reachable precedence. Where two rules in the document can actually conflict on a realistic input, precedence is explicit. Two rules conflict only when they prescribe incompatible outcomes for the same decision; shared words or adjacent fields alone do not create a conflict. A restriction on the representation of one field does not restrict unrelated fields unless the document explicitly restricts the whole input object. When the document does not determine which rule wins, present every plausible precedence choice and mark the choice as an author decision. Speculative pairwise precedence for unreachable conflicts is not required and is not a finding.