This is the receipt layer. Official docs establish product facts. Practitioner configs show concrete patterns real teams published. Coding Fox opinions are labeled as opinions, because useful guidance is not the same thing as vendor documentation.
The guide is opinionated, but it should never blur product facts with field advice. Treat each badge as a proof tag: what kind of evidence supports the claim, how recently it was checked, and what could make it wrong.
| Proof tag | Means | How to use it |
|---|---|---|
| Verified | Directly supported by current official docs, product pages, source repos, or release notes. | Best source for product facts. Still check the date when the feature moves quickly. |
| Practitioner | Public config, repo, talk, or writeup from someone showing real work. | Good pattern signal. Do not treat it as vendor truth or copy it without checking your repo. |
| Caveat | Depends on version, plan, feature flag, platform, org policy, or local configuration. | Assume your environment may differ until you verify it locally. |
| Experimental | Preview, beta, rolling rollout, undocumented, or fast-changing behavior. | Useful to know, risky to standardize. Recheck before building process around it. |
| Opinion | Coding Fox operating advice derived from docs, field use, and tradeoff calls. | Use it when it helps your workflow. Challenge it when your evidence says otherwise. |
The bar is simple: product facts need primary sources; workflow advice needs enough evidence to explain why it is worth trying.
| Claim type | What counts as evidence | What gets flagged |
|---|---|---|
| Product behavior | Official docs, release notes, source repos, or product UI observed directly. | Anything versioned, gated by plan, platform-specific, or recently shipped. |
| Security and safety | Official security docs, repo code, command behavior, and concrete permission boundaries. | Any advice that could grant tools broader access, write to production, or hide review steps. |
| Workflow advice | Repeatable local use, public practitioner examples, and clear failure modes. | Advice that sounds good but cannot name the tradeoff, check, or stopping point. |
| Comparisons | Same task, same constraints, visible acceptance criteria, and separate verification. | Claims based only on preference, novelty, or one lucky run. |
Use these as the truth layer for Claude Code behavior. The product moves fast, so dated details on this site should be checked against these pages.
| Source | What it supports |
|---|---|
| Claude Code overview | Product map: terminal, IDE, desktop, browser, MCP, customization, agents, routines. |
| Claude Code changelog | Latest Claude Code version tracking, May 29-30 operator upgrades, command renames, and fast-moving behavior that should not be trusted from memory. |
| Claude Code best practices | Context discipline, explore-plan-code, verification, subagents, parallel sessions, adversarial review. |
Memory and CLAUDE.md | Instruction loading, concise memory guidance, auto memory, imports, and caveats. |
| Claude Code skills | Progressive disclosure, SKILL.md, dynamic context, and moving procedures out of always-loaded memory. |
| Claude Code Dynamic Workflows | Opus 4.8 / /effort ultracode, workflow orchestration, subagent fan-out, limits, and usage caveats. |
| Introducing Dynamic Workflows in Claude Code | Launch framing from Anthropic: use cases, research-preview availability, auto mode recommendation, and caution about higher usage. |
| Introducing Claude Opus 4.8 | Model announcement, pricing, Opus 4.8 coding/agentic framing, and the Dynamic Workflows launch note. |
| Claude Code hooks | Lifecycle automation and hook caveats. Command hooks run with user permissions, so review them like code. |
| Claude Code MCP | Tool/data integration via MCP and when to use live systems instead of copying from dashboards. |
| Claude Code security | Prompt-injection, permissions, user responsibility, MCP trust, and sandbox framing. |
OpenAI's Codex surface is split across CLI, app, cloud, mobile, skills, hooks, MCP, and repo instructions. Start here before trusting summaries.
| Source | What it supports |
|---|---|
| Codex CLI docs | Local terminal coding agent behavior, install, command surface, local operation. |
OpenAI openai/codex repo | Implementation-level truth for releases, install paths, issues, and changelog. |
Codex AGENTS.md guide | Instruction discovery, global/project layering, overrides, fallback names, and byte limits. |
| Codex MCP | MCP setup, shared CLI/IDE config, server instructions, and examples. |
| Codex skills | Reusable workflows and plugins as distribution units. |
| Codex hooks | Lifecycle hooks, trust review, managed hooks, and project-local behavior. |
| Unrolling the Codex agent loop | How Codex's harness/agent loop works and why scoped, verified work matters. |
| Running Codex safely at OpenAI | Governance, approvals, telemetry, managed config, and safety posture. |
| Source | What it supports |
|---|---|
| Model Context Protocol | MCP as an open standard for connecting AI apps to external tools and data. |
| Agent Skills specification | Portable SKILL.md format, progressive disclosure, and reusable workflows across products. |
These are not vendor truth. They are useful because real teams published concrete patterns you can inspect.
| Source | Why it is worth reading |
|---|---|
| Trail of Bits Claude Code config | Security-shop defaults for config, sandboxing, hooks, MCP, and workflow discipline. |
These are the opinions this site is built around. They are deliberately practical.
Put facts that prevent mistakes in CLAUDE.md / AGENTS.md. Put procedures in skills. Put proof in tests and reports.
Exploration, logs, file inventory, and noisy research belong in subagents or separate threads.
Separate files, separate acceptance criteria, separate verification. Otherwise use one strong agent.
A completion report needs commands, screenshots, tests, changed files, and remaining risks. Confidence is not evidence.
