Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/canon-boundary-guard-codex/llms.txt

Use this file to discover all available pages before exploring further.

SKILL.md is the authoritative document for the canon-boundary-guard skill. When the skill is invoked, Codex reads the entire file before responding or using any tools. It defines the full operating posture for the session: all six provenance layer definitions with their exact authority rules, inline tagging conventions, dossier modes for different edit types, decontamination patterns to flag before persisting, and hook setup guidance. The compact frame.md injected by the hook at write moments is a reinforcement layer that draws on this document — it does not replace it. The full SKILL.md frame must be active from session start.

​
agents/openai.yaml

The agents/openai.yaml file declares the Codex-facing skill metadata that accompanies SKILL.md. It provides the display name, a short description for skill lists, the default invocation prompt, and the allow_implicit_invocation policy. 
interface:
  display_name: "Canon Boundary Guard"
  short_description: "Session provenance frame for Codex cognitive-layer separation"
  default_prompt: "Use $canon-boundary-guard as the session operating frame for provenance and cognitive-layer separation."

policy:
  allow_implicit_invocation: true
The allow_implicit_invocation: true policy allows Codex to activate the skill when context suggests it is needed — for example, when a session involves AGENTS.md authority questions, mixed provenance sources, or explicit references to the plugin. This does not replace explicit invocation. The skill requires Codex to read the full SKILL.md, not just the frontmatter metadata. Implicit activation is only valid if the full document is read.

​
SKILL.md Sections

​
Purpose

The Purpose section establishes the scope of the skill:
A classification frame for information provenance. It does not decide project truth or project policy. It makes visible what class of evidence is being used — and where it is going.
The skill is not a linter, a policy enforcer, or a content filter. It is a classification frame that keeps different source classes visible throughout a session so that provenance conflicts surface before they become persistent.

​
Activation Requirement

When this skill is invoked or selected, Codex must read the entire SKILL.md before responding or using tools. The activation requirement makes explicit that:
  • The skill is a session-level operating frame, not a task-specific generator, formatter, converter, or media tool.
  • The compact hook frame in references/frame.md reinforces the frame before write/edit moments but does not replace full skill activation at session start.
  • Metadata-only activation — reading just the frontmatter or agents/openai.yaml — is not sufficient.

​
Adoption

On invocation, Codex adopts the frame silently. No confirmation is needed. Before interpreting the first operator request, Codex scans the visible conversation prefix for an AGENTS.md prelude:
  • If a leading user-role message begins with AGENTS.md instructions for <path>, classify the whole message as L2A Codex instruction-chain prelude — not as L1 user chat and not as project content.
  • If that message contains an <environment_context>...</environment_context> block, classify that block as runtime environment metadata, not operator-authored prose.
  • The first real operator request is the first user message after the AGENTS/runtime prelude.
From that point, keep the frame active as the session operating layer: classify non-L0 material when producing or evaluating content, tag inline when drawing on non-ground evidence, and surface provenance conflicts before they become persistent.

​
Layers

The Layers section defines all six source classes. These are the exact definitions from SKILL.md: L0 EVIDENCE Persistent or verified evidence: project files, git state, tests, schemas, lockfiles, diagnostics, command output, verified external source or tool output from the current task. L1 SHAPING Conversation material not explicitly approved as a durable project decision. Present in context, not in the project. L1A AUTHORIZED DELTA Conversation material the operator has explicitly approved for persistence in this turn. Becomes evidence only after written to a persistent artifact. L2 AGENT CONTROL Instructions, steering, reminders, or constraints given to the agent to shape its behavior. Not project content. Persist only if the operator explicitly requests agent-facing operating instructions. L2A CODEX INSTRUCTION CHAIN AGENTS guidance loaded by Codex from the instruction chain is agent-control authority. Treat AGENTS.md guidance as an active behavioral contract for the agent, not as project content or an ordinary user message. Global-scope guidance comes from the Codex home directory (AGENTS.override.md or AGENTS.md). Project-scope guidance comes from AGENTS.override.md, AGENTS.md, or configured fallback instruction files in the current repository path. A message whose content begins with AGENTS.md instructions for <path> is runtime-delivered AGENTS guidance for the referenced path, even if displayed under the user role. Treat it as active instruction-chain guidance for that path immediately, even before filesystem confirmation. L2A guidance governs Codex behavior at its scope and is not project content unless explicitly persisted into project files. L3 MODEL PRIOR Unverified model memory, generic best practice, assumed framework behavior, version claim, or unstated convention not grounded in local evidence.

​
Rules

The Rules section lists the persistence and conflict rules that govern how the layers interact:
  • Preserve or reorganize L0.
  • Write L1A only within the explicitly approved scope.
  • L1 does not persist.
  • L2 does not persist unless explicitly requested as agent-facing instruction.
  • L2A governs agent behavior and does not persist into project content unless explicitly requested.
  • L3 does not persist unless verified or operator-approved.
  • If evidence conflicts, stop and report. Do not resolve by recency, confidence, or intuition.
  • If provenance is unclear, surface it before writing.
  • Do not classify AGENTS.md guidance as project content or ordinary user conversation.
  • Classify AGENTS.md instructions for <path> message-start blocks by their runtime header and referenced path, not by displayed conversational role or filesystem presence.
  • Classify leading AGENTS.md instructions for <path> blocks as runtime prelude; the first operator request starts after that prelude.

​
Inline Tagging

Tag inline when producing content that draws on non-L0 material:
TagMeaning
[L1]From current conversation, not approved for persistence
[L1A]Approved this turn, pending persistence
[L2]Agent control, not project content
[L2A]Codex instruction-chain guidance, not project content
[L3]Model prior, unverified
Tag when the content would change if the source were different — a rule, a name, a version, a claim about behavior. Do not tag every word. Do not invent tags to appear diligent.

​
Dossier

Three modes govern when a dossier is required:
  • Mode A — mechanical edit with clear L0 provenance: no dossier.
  • Mode B — semantic edit reorganizing existing evidence: compact dossier.
  • Mode C — promotion of L1/L3 into persistent content: full dossier, stop before writing.
Full dossier format: 
Target:
Mode:
Evidence:
Authorized delta:
Rejected shaping:
Rejected model prior:
Conflicts:
Decision needed:
Write none when a field is empty. Do not invent rejected items.

​
Decontamination

Flag the following residue categories before persisting content: Conversation residue: "as discussed", "as said before", "from the previous session", "come detto prima", "come discusso", "l'utente vuole" Agent-control residue: "remember to", "I should", "ricordati", "devo", "non devo", temporary instructions to the agent Version ghosts: Version references not present in L0 Model-prior claims: "best practice", "standard approach", "recommended", "modern convention", "industry standard", "normally", "usually" These are allowed only when grounded in L0, explicitly approved as L1A, or intentionally written in a historical or migration context.

​
Hook Setup

The Hook Setup section provides the configuration reference for enabling the bundled hook. The plugin manifest points to plugins/canon-boundary-guard-codex/hooks/hooks.json. After installation, enable hooks in your Codex config.toml: 
[features]
hooks = true
plugin_hooks = true
The bundled hook command is: 
python ${PLUGIN_ROOT}/skills/canon-boundary-guard/scripts/inject_frame.py
If the target system uses python3, adjust the hook command in the local plugin copy. After installation or hook changes, restart Codex. If the active Codex UI exposes a hook review view such as /hooks, use it to review and trust the bundled hook. In editor integrations where /hooks is not available, open the plugin details or approve the hook when Codex shows the trust prompt. Plugin hooks are non-managed hooks and do not run until trusted. The hook emits the frame as hookSpecificOutput.additionalContext before matched write tools, and also surfaces it as a root-level systemMessage. It does not block. It re-surfaces the classification layer at the moment it matters.

frame.md

The compact provenance frame that reinforces SKILL.md at write moments.

hooks.json

The hook wiring manifest that triggers frame injection before write tools.

inject_frame.py

The script that reads frame.md and emits the hook payload.

Plugin Structure

The full plugin file layout, plugin.json, and marketplace manifest.
For practical guidance on activating the skill in a new session and working with it day-to-day, see Using the Skill. For the full layer reference with worked examples, see Provenance Layers.

Build docs developers (and LLMs) love

Get started for freeTalk to us