Opus 4 6 Guidelines

Purpose

Operational guidelines for Claude Opus 4.6 sessions on SBX framework artifacts

Rules

OP-001: Use extended thinking for complex analysis, architectural decisions, and multi-step reasoning. Do not use it for simple lookups, file reads, or straightforward edits.

Anthropic Opus 4.6 — extended thinking produces better results for complex problems but adds latency. Reserve it for tasks where deeper reasoning justifiably improves output quality.

Verification: Extended thinking used for decisions, not for trivial operations

OP-002: Maintain consistent YAML indentation (2 spaces), use block scalars (|) for multiline strings, and follow SBX naming conventions (kebab-case for names, UPPER-NNN for IDs).

SBX operational experience — inconsistent YAML formatting causes merge conflicts, grep failures, and parse errors. Opus 4.6 can maintain consistency when explicitly instructed.

Verification: YAML files parse without warnings, consistent indentation throughout

OP-003: Always read the protocol definition before generating a conforming artifact. After generation, verify the artifact has all required fields from the protocol schema.

SBX governance — AG-005 (governance check) + AG-009 (structured output conformance). Reading the protocol first prevents missing required fields, which is the most common conformance error.

Verification: Artifact has all required fields defined in its conforms_to protocol

OP-004: Verify all ID references resolve to existing artifacts. When adding cross_refs, confirm the referenced standard/pattern/technique exists in the knowledge base.

SBX operational experience — dangling references (pointing to nonexistent artifacts) break navigation and create confusion. Cross-reference integrity is a quality signal.

Verification: grep for referenced artifact name returns at least one file

OP-005: For every change, report BEFORE state (what existed), ACTION taken (what was changed), and AFTER state (what exists now). This creates an audit trail for reviewing work.

SBX operational experience — agents that report only the action ("I added X") provide insufficient context for review. Before/After reporting enables meaningful review without re-reading entire files.

Verification: Change descriptions include BEFORE, ACTION, and AFTER sections

OP-006: Group related changes and commit at natural boundaries. Do not commit after every line change. Do not accumulate changes across unrelated tasks into a single commit.

SBX git workflow — atomic commits enable clean revert and review. Too granular commits pollute history; too coarse commits make bisection impossible.

Verification: Each commit corresponds to one ETVX step or one logical change

OP-007: Use sub-agents for independent research queries. Launch multiple research agents in parallel when queries do not depend on each other. Synthesize results in the main context.

Anthropic — parallel tool use in Opus 4.6 enables concurrent research. SBX Decision #0040 used 3 parallel agents to research 13 sources efficiently.

Verification: Independent research queries launch as parallel sub-agents

OP-008: Use three-tier context persistence: CLAUDE.md for permanent project constants, /compact for session compaction, and ETVX task files for cross-session progress.

Claude Code Best Practices — CLAUDE.md is auto-loaded. SBX experience — task files bridge sessions. /compact preserves key context when approaching limits.

Verification: Critical state in memory files, not only in context window

OP-009: Run the verification command, read the actual output, THEN claim the result. Never claim success based on expectation. The word "should" is a red flag indicating unverified state.

SBX operational experience — agents frequently claim "tests pass" without running them, or "file created" without verifying. This is the single most impactful quality rule.

Verification: Agent runs command and reports actual output before any completion claim

OP-010: New knowledge artifacts should target RICH tier: every rule has code examples (Go + TypeScript where applicable), cross-references to related artifacts, and stack-specific patterns section.

SBX knowledge enrichment goal — THIN artifacts (rules only, no examples) provide minimal LLM guidance. RICH artifacts with APPLIED/VIOLATED example pairs dramatically reduce misinterpretation.

Verification: Artifact has examples section with at least one code example per rule

Tags

Overview