Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/shaping-frame-for-claude/llms.txt

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

Inline tags make the provenance of a piece of information visible in the flow of conversation without interrupting it. They are the Level 1 output of the cognitive checkpoint — used when the source weight of a piece of material changes how a sentence should be read, but the material has not yet risen to the level where a full dogana block is warranted. A tag does not ask OP to make a decision. It marks that the sentence it qualifies comes from a source whose weight the reader should factor in. The signal is quiet but precise: a reader who sees [MP] knows that what follows is a model prior, not a verified fact or an OP decision.

​
The Five Inline Tags

TagMeaningWhen to use
[AI]In-session generated proposalWhen an AI-originated idea or suggestion could be read as an established position or decision
[MP]Model prior / general assumption / training patternWhen output reflects training-time patterns rather than session-specific verified facts
[EXT]External material, not yet crystallizedWhen referencing imported material that OP has not yet explicitly approved or promoted
[DSK]State read from disk or toolWhen the output reflects a documented or filesystem state, not a decision or intent
[~]Mixed or uncertain provenanceWhen the source cannot be cleanly attributed to a single origin, or when multiple uncrystallized sources have contributed
OP is never tagged. OP statements are the decisional reference frame — tagging them would misrepresent how the skill treats their weight.

​
Usage Rule

Tag only if the tag changes the weight of the output. If a sentence would be read the same way regardless of whether it carries a provenance marker, do not add one. Do not tag every sentence in a response. Do not add tags to appear diligent or thorough — tags that appear everywhere stop communicating anything. The correct question before tagging is: would a reader interpret this differently if they knew its source? If yes, tag. If no, do not.

​
The MP Signal Rule

The [MP] tag carries a specific signal rule that operates regardless of how the content entered the session. Tag [MP] whenever output contains any of the following phrases — whether they appear in Claude’s own generation or in material that was imported:
  • “standard approach”
  • “best practice”
  • “normally”
  • “usually”
  • “it is known”
  • “typically”
  • “common practice”
These phrases are reliable surface signals of model prior content. They sound authoritative and factual, but they are training-time generalizations — not verified facts about the specific system, codebase, or context being worked on. The [MP] tag makes the distinction visible.

​
Examples in Context

A model prior surfacing as a convention that has not been confirmed for the current environment: 
[MP] this is a general convention, not yet verified in your setup.
An AI-generated architectural option that is still in the fan and not yet approved: 
[AI] one option is to split the auth module into two services — not yet approved.
An imported spec value that OP has not yet confirmed applies to the current context: 
[EXT] per the imported spec, the timeout is set to 30s — this hasn't been confirmed for the current context.
In each case, the tag appears because removing it would allow the sentence to be read as a settled fact or an approved decision. With the tag, the provenance is visible and the weight is calibrated correctly.
Over-tagging destroys the signal. If every sentence in a response carries a provenance tag, the tags stop indicating anything — they become noise, and the reader stops reading them. Tags should stand out because they appear only when the source weight of a sentence actually changes how it should be interpreted. Reserve them for that case exclusively.

Build docs developers (and LLMs) love

Get started for freeTalk to us