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.

Surface triggers are observable events in the conversation that force a compact snapshot of all active tracked elements before Claude responds to content. They give you a real-time view of what is in motion at the exact moment the session shifts — a new constraint arrives, direction changes, or a phase boundary is crossed. Unlike the cognitive checkpoint, which fires when a specific element crosses a threshold, a surface trigger fires based on what is happening in the conversation, not what any individual piece of material is doing. The snapshot it produces is a complete read of all elements currently in Candidate, Tracked, Quarantined, or Needs verification state.

​
The Five Surface Trigger Events

A surface trigger fires when any of the following occurs:
  1. OP introduces a new constraint or EXT material — the weight landscape shifts and the existing tracking state needs to be visible before the new material is integrated.
  2. OP changes direction or scope — elements that were heading toward a decision may no longer be relevant, or may have their weight reclassified. The snapshot makes this visible before proceeding.
  3. OP asks for orientation — explicit orientation requests such as “where are we”, “what have we decided”, or “recap” are direct calls for the snapshot. Claude emits it before answering.
  4. A new artifact or spec opens — before a structural output is started, all in-motion elements must be surfaced to prevent unvetted material from silently entering the artifact.
  5. The conversation shifts phase — when the session moves from shaping to decision, or from decision to writing, the snapshot confirms what is actually settled and what is still open.

​
Snapshot Format

When a surface trigger fires, Claude emits a compact snapshot block drawn from references/snapshot.md before responding to content: 
Active tracking:
- [element] | source | state | next threshold | decision needed?
...
No active tracking: —

​
Field Definitions

element — the proposal, constraint, name, or hypothesis being tracked. Written as a short label on one line. This is the thing whose weight is in motion, not a full description of its history. source — the origin of the element: EXT, AI, MP, or DSK. Omit the source field only if it genuinely does not change how the element should be weighted. In practice, source almost always matters. state — the current weight state of the element. Only active states appear in the snapshot: Candidate, Tracked, Quarantined, Needs verification. Crystallized and Rejected elements are closed — they do not appear. next threshold — the nearest crossing from the threshold vocabulary that this element is approaching. This makes the risk visible without narrating it: 
proposal → premise
premise → constraint
constraint → decision
decision → artifact
draft → spec
provisional phrase → naming
local compromise → architecture
AI/MP/EXT → implicit OP
factual hypothesis → technical foundation
decision needed? — yes or no. If yes, a brief statement of what decision is required before the element can advance state. This is not a full dogana — it is a pointer to where OP attention is needed.

​
Ordering Rule

When a surface trigger fires, the output order is: snapshot → dogana (if triggered) → content If reviewing the snapshot reveals that an element is actively crossing a threshold, the dogana block fires between the snapshot and the content response. The snapshot comes first so that OP has the full weight picture before any checkpoint fires.

​
Example Snapshot

A mid-session snapshot from a backend service design session with three elements in motion: 
Active tracking:
- separate auth module | AI | Tracked | local compromise → architecture | yes: OP confirm before opening spec
- DB schema v2 | EXT | Candidate | proposal → premise | no
- default timeout 30s | MP | Quarantined | factual hypothesis → technical foundation | yes: verify with DSK before using as constraint
In this example: the auth module split is an AI proposal that has gained enough weight to be approaching an architecture-level decision; the DB schema is external material still in the fan; and the 30-second timeout is a model prior that is Quarantined because it is grounding a technical decision without verification.
If no elements are currently in Candidate, Tracked, Quarantined, or Needs verification state — that is, everything in the session is either Crystallized or Rejected — write No active tracking: — and continue directly to the content response. The snapshot is never omitted; it reports the actual state, even when that state is empty.

Build docs developers (and LLMs) love

Get started for freeTalk to us