Structured Gist

---
name: structured-gist
version: "0.6.0"
benchmark: word_count_reduction_pct
description: Render explanatory or process-recap prose as a nested lecture-note outline instead of paragraphs — fixed role ladder concept (-) → attribute (▸, a named property) → enumerator (I./A./i./a.) → explanation (↪, one prose sentence, usually a leaf). No plain bullets. Render modes — block (fenced, literal glyphs; default on every surface) and responsive (opt-in real GFM nested list for GitHub bodies and chat replies; glyph-free, role carried by typography). One granularity level (standard); skim and deep are archived. Independent of caveman (structure vs wording). Opt-in report preset (`/structured-gist report`, alias `findings`). Use for "what I did and why" recaps, concept/cause-chain explanations, and human-facing GitHub prose. NOT for code, commits, bot-template fixed fields, footers, or single-fact answers. Triggers — "structured-gist", "sg", "gist this", "outline this", "bullet this", "notes mode", "break this down", "give me the gist", "make this skimmable", "condense this", "sg report".
---

# structured-gist — hierarchical lecture-note output

Replace paragraph printouts (esp. "what I did + my reasoning" recaps) with a nested, easily skimmable outline. Concept, attribute, and enumerator nodes carry structure with terse content; the `↪` hook-arrow carries the prose explanation (usually a branch leaf). Marker type conveys meaning on a fixed depth-ladder — never random. Structure only — wording untouched (independent of caveman).

Full detail beyond this file lives in `reference/` — this file is the ~2-minute read; each `## ` section below links out where there's more.

## Activation

On-demand: `/structured-gist [block [width N|auto]|responsive]`. One granularity level, `standard` (see `## Granularity`). No mode → `block` (default, all surfaces) — override explicitly with `responsive` when a GitHub issue/PR/comment body or chat-app reply needs a real GFM nested list instead of a fenced block. `width` sets the block-mode R11 line budget; omitted → 64, or the width the operator's AGENTS.md names for that surface. See `## Render modes`.
Lexicon triggers: "structured-gist", "sg", "in structured-gist", "gist mode", "gist this", "outline this", "bullet this", "notes mode", "structure this", "break this down", "distill this", "give me the gist", "make this skimmable", "tighten this up", "condense this" (+ optional mode word).
Elevatable: repo repository instructions may mandate as session default (+ default mode), like caveman.
Off: "stop structured-gist" / explicit prose request.

**Session-summary preset (v0.3): `/structured-gist summary` (alias `session-summary`).** A standalone invocation that emits a session-summary / handoff-shaped outline in one call, without the caller specifying structure — a quick end-of-session recap. It is self-contained (does NOT call the `handoff` skill; `handoff` is the fuller session-end retro, this is the terse inline outline). Canonical shape — the handoff sections are `-` concepts, their contents are `▸` attributes / enumerators / `↪` leaves:

```text
- Session summary
    ▸ Changed
        a. <area> — <what changed>
    ▸ Decisions
        ↪ <decision + one-line rationale>
    ▸ Next
        i. <ordered next step>
    ▸ State
        a. branch <name>
        b. PR <#/status>
    ▸ Open questions
        ↪ <question still unresolved>
```

(Enumerators under a `▸` attribute sit at depth 2, so they take the lowercase family — `a.`/`i.` — per the depth-keyed ladder below; the `▸` occupies depth 1.)

**Preset-omission contract (applies to every preset below).** A preset supplies optional branch names, not required slots — omit any branch the source does not support, the summary preset included. A preset never changes the marker ladder or adds a role.

**Report preset (v0.5.0b1): `/structured-gist report` (alias `findings`).** A standalone, finding-first invocation: one top concept per supported finding, multiple findings allowed as peers — never one packaging root. A finding is never invented when the source establishes none. Optional branches — Question, Method, Observed, Inferred, Next — are included only when source-supported; omit the rest per the preset-omission contract above. No generic Intro/Background/Conclusion heading — context stays nested under the finding it belongs to. Under Method, ordered steps take the lowercase ordinal family (`i.`/`ii.`) and unordered components the lowercase nominal family (`a.`/`b.`); Method itself is a named `▸` branch, never an ordinal node. Granularity and render mode apply unchanged; no new marker roles are introduced.

```text
- <finding>
    ▸ Method
        ↪ <how it was checked>
    ▸ Observed
        a. <what was seen>
    ▸ Next
        ↪ <follow-up action>
```

**Activation is verify-don't-assume (same bar as caveman).** Attempt the real Skill call (`/structured-gist`, or the mode in effect) — do not assume it loaded. On success, state so. On `Unknown skill` (skill not loaded at container start), emit exactly one line — `structured-gist NOT loaded → emulating from SKILL.md` — then apply the outline rules manually from this file. NEVER claim "structured-gist active" without a successful Skill call; a false claim of this exact form shipped in a session recap on 2026-06-27. The missing skill never blocks the turn — emulate and continue.

**Recommended: pair with a Stop-hook activation nudge, not a blocking gate.** A model can simply forget to invoke structured-gist on a long recap/explanation — there is no in-session signal forcing the check. The fix is advisory, not blocking: a Stop hook that reads the session transcript, and if the final assistant turn is long (word-count heuristic) AND no `Launching skill: structured-gist` backed call appears anywhere in the transcript, emits one stderr nudge line. It never blocks the turn — same fail-open contract as every other advisory hook (judgement-class checks are Stop advisories, not CI-hard gates). A consumer repo wiring this hook should model it on `stop_structured_gist_activation_guard.sh` alongside a claim-vs-call guard (audits false activation *claims*) and a rule-compliance guard (audits outlines already emitted) — three independent Stop-hook checks, not overlapping: claim-vs-call, output-quality, and activation-was-skipped. Cron-silent (`CLAUDE_INTERACTIVE=1` gate) and fail-open on missing jq/python3/transcript is the recommended contract. A hook cannot itself invoke the `Skill` tool (hooks are shell, not model turns) — it can only nudge the next turn's model into doing so; a blocking variant (exit nonzero to force another turn) was considered and rejected as unnecessarily coercive for a judgement-class check. This skill ships one optional hook itself — a statusline script (`hooks/structured-gist-statusline.sh`) that prints the installed version, not wired by default. The activation-nudge guidance above is for a consumer repo's own `.claude/hooks`.

## When — primary target

Default-render as outline when active:
- agent **process/recap prose** — "what I did and why" (the main case)
- explanations — concept / system / trade-off / cause-chain

NOT only on explicit "explain X". NOT on the carve-outs below.

## Marker taxonomy

**Consistent depth-ladder — marker type conveys meaning, never random.** Deepen one rung per nesting level; never skip rungs. **No plain bullet** — parts, steps, and evidence are all enumerable, so every sub-item enumerates.

The role ladder, outer to inner: **Concept → Attribute → Enumerator → Explanation.** Each answers a different question about its parent, so each has its own marker.

| role | marker | answers | word budget |
|---|---|---|---|
| **concept** | `-` (L1 only) | "what is this?" — a top concept, claim, or outcome | ~≤3 words |
| **attribute** | `▸` | "what does the parent *have*?" — a named property of the parent | ≤4 words |
| **enumerator** | `I. II.` / `A. B.` at **depth 1** · `i. ii.` / `a. b.` at **depth ≥2** | "the parent is *composed of* these ordered/grouped parts" | ≤6 words deep tiers |
| **explanation** | `↪` (hook arrow) | "what needs explaining or qualifying about the parent?" (e.g. why / how) — the one LONG prose sentence | no cap |

Who/what/where/when/why/how/whether are content prompts, not marker selectors — asking "why" does not pick `↪` by itself. Match by the role criteria above instead: top claim → concept, named property → attribute, ordered or grouped part → enumerator, explanation → `↪`.

**Attribute vs. enumerator (the distinction).** If a child reads naturally as "the parent *has a* ___" — a purpose, a component, a constraint, a property — it is an **attribute** (`▸`), not an enumerator. Enumerators are for genuinely ordered or grouped *parts/steps/evidence*. Rendering an attribute as a sibling `-` concept (flattening) or as an enumerator (mislabeling it a part) both lose the parent-attribute relation; `▸` preserves it. Example: "Marker ladder" is an attribute *of* structured-gist (`▸ Marker ladder`), not a peer concept and not a step.

**Ordinal vs nominal** picks the enumerator family, by the content:
- **ordinal** (roman: `I.`/`i.`) when ORDER matters — a sequence, steps, a ranking.
- **nominal** (letter: `A.`/`a.`) when items are distinct GROUPED peers, order-agnostic.

Attributes are inherently nominal (a property has a name, not a position) — there is no ordinal `▸` variant.

**Advisory attribute-name lexicon (not linter-enforced).** Names commonly source-supported: Purpose, Mechanism, Actor, Location, Timing, Certainty. Scope names a boundary and Trigger names an initiating condition — neither is a catch-all for every "where" or "when". "Whether" names a proposition to resolve, not a degree of confidence; a degree of confidence is Certainty. Prefer the source's own property names over this list, and omit any name the source does not support — this vocabulary is advisory guidance, not something the linter checks.

**A `▸` occupies a depth rung like any marker.** Enumerators directly under a concept sit at depth 1 (uppercase `I.`/`A.`); enumerators directly under a `▸` attribute sit at **depth 2**, so they take the lowercase family (`i.`/`a.`) — the ladder is keyed by absolute depth, not by "first enumerator encountered." (Linter rule R1.)

A child-set is one family — never mix `I.` and `A.`, or `▸` and an enumerator, as siblings. Emit literal glyphs (GFM collapses real ordered lists to `1.`). Indent rule: see `## Spacing`.

**No-self-nesting (never nest a marker directly under the same marker).** Concepts live only at L1 and enumerators already alternate roman↔letter by depth, so neither can self-nest; the rule bites on attributes: **a `▸` MUST NOT be the direct child of a `▸`.** To express a property-of-a-property, interpose a different node type — a non-leaf `↪` hook (see below) or an enumerator — never `▸`→`▸` directly. Linter rule R8.

**Leaf marker is `↪` (hook arrow), NOT `→`.** The plain `→` is reserved for inline cause-effect (`X → Y`) inside a node's text — the caveman wording convention — so it MUST NOT appear as a marker. `↪` always starts its own indented line (structure); `→` only ever sits mid-line (wording). Distinct glyphs, distinct jobs.

**Preserve source relation wording.** Keep the source's own relation wording and keep its endpoints identifiable. An association, correlation, or uncertain link is not rewritten as a causal `→`.

## Length gradient

Word budget — terse by default at EVERY level (recursive):
- every enumerator node = terse **concept** (denotes, does not explain); it embeds its meaning in hierarchy + short content, NOT prose
- higher tiers = fewest words; deeper nodes MAY use a few more *only when needed*
- the long explanatory sentence does NOT sit in an enumerator node → it rides a `↪` leaf
- a shallow node wordier than its own descendants = anti-pattern

**Connective-clause test (any depth).** A node carrying a reasoning connective — `because`, `since`, `so that`, `given that`, `as a result`, `which means`, or a parenthetical doing the same job (`(…, never verified against …)`) — is two nodes wearing one marker. Split it: the claim stays on the enumerator node; the reasoning moves to a `↪` child. This applies at L1 same as any deeper rung — a summary/`Net assessment`-style top bullet is not exempt just because it sits high in the tree.

**Delimiter-split test (R9, any depth).** The same split is forced by *punctuation*, not just connective words. A structural node — concept `-`, attribute `▸`, or enumerator — that appends content after a **spaced dash** (` - ` / ` — `), a **colon**, a **semicolon**, an **arrow** `→`, or inside a **parenthetical** `(…)` is two nodes wearing one marker — **unless the tail is only 1–2 words** (a terse qualifier like `scope: user dir` or `(default)` stays inline). When **>2 words** follow the delimiter, split: the head stays on the node, the tail drops to a nested child — a `↪` leaf when it explains, an enumerator when it is a genuine part. Exemptions: the `↪` leaf itself (the prose home — a colon/dash/arrow *inside* a `↪` sentence is fine), **intra-word hyphens** (`lecture-note` is one word, not a delimiter — only a space-flanked dash counts), inline code (`` `file:line` `` never counts), and **HTML entities** (`&amp;` / `&#x27;` — the trailing `;` is not a prose semicolon). Linter rule R9. A *chained* mid-line `→` (`X → Y; Z → W`) packs multiple facts under one marker and trips R9 the same way, while a **single** `X → Y` causality idiom (≤2-word tail) stays exempt — worked before/after: `examples/splice-to-subtree.md`.

**Double-marker test (R10, any depth).** A node's *content* must not begin with a second marker glyph. Emitting `▸ • target` or the terminal-rendered `- • target` (dash concept + bullet) or `- → foo` puts two markers on one line — the exact defect that made a fresh emulation render un-skimmable in a plain terminal (no markdown to collapse the leading `-`) while the same outline was clean in the Claude Code app. Pick ONE marker per node from the depth-ladder; never prefix the content with `•`, `→`, `↪`, `▸`, or another `-`. This bites emulation most: when the skill is not loaded and you render from this file by hand, indent with spaces and lead with a *single* ladder glyph — do not fall back to markdown `-`/`•` bullets. A mid-text causality arrow (`X → Y` inside a node) is fine — R10 fires only on a *leading* stray glyph, so the caveman single-arrow idiom is preserved. Arrow (`↪`/`→`) markers are the one legitimate leading glyph and are exempt. Linter rule R10.

## Hook-arrow `↪` — the explanatory node

- `↪` is the ONLY place prose explanation lives — enumerator + attribute nodes carry meaning by structure + terse content
- **usually a leaf** — one key cause-effect / elaboration per branch, rare, not every line
- **may be a non-leaf branch-summary** (v0.3): an `↪` MAY carry deeper children when it previews the subtree below it — a one-line "here's the gist, detail follows." A non-leaf `↪` MUST be the **first child** of its parent (a summary precedes the detail it introduces); an `↪` placed after its siblings stays a leaf. Linter rule R4.
- **subtree-preview guideline** — use a non-leaf `↪` only when the branch genuinely benefits from a one-line orientation before the reader descends, OR as the interposer that lets an attribute nest under another attribute without `▸`→`▸` (the no-self-nesting escape hatch). Do not summary-preview every branch; that reinflates the outline back toward prose.
- always starts its own indented line; never glued mid-line (that is the plain `→` inline-causality role, which `↪` deliberately does not share)
- **not caveman-compressed** — even when enumerator wording is compressed, the `↪` explanation stays a full, readable clause

## Nest by dependency

- a child **belongs-to / depends-on** its parent → a real tree, not a flat list dump
- nesting depth mirrors the actual dependency structure of the content

**Observed-versus-inferred (advisory).** When the source distinguishes observation from inference, preserve that distinction. Use separate branches only when grouping would blur status; otherwise keep the attribution explicit inside the `↪`. Never infer evidential status from wording alone, and never manufacture missing evidence.

## Granularity

One level: `standard`. Surface the tree through L3 as the content needs. Keep the concept spine and its enumerated parts. Surface a `↪` where it carries a cause, a qualifier, or a hedge.

`skim` and `deep` are archived (v0.6.0). The controlled benchmark scores `standard` only, so the other two have no current evidence behind them. Archived specs and examples: `docs/archive/granularity/` at the repository root. If a caller asks for `skim` or `deep`, render at `standard` and say the level is archived.

**Granularity and render mode are independent.** Granularity controls how much of the tree is surfaced. Render mode (`block`/`responsive`/`inline`, `## Render modes` below) controls only the display container. Neither changes the marker ladder or which linter rule fires: the same 15 rules gate every render mode.

## Spacing

**Indent: 4 spaces per rung** (L1=0, L2=4, L3=8, `↪`=parent content +4) — single source of truth for indent, referenced by Marker taxonomy above. 2-space steps render too tight past L2.

**Block-mode line wrap (R11, v0.3.6).** Target max physical line width **64 chars including indent by default (`width N` / `STRUCTURED_GIST_WIDTH` override, v0.5.0b2)** — fits typical phone-portrait monospace. A narrow viewport soft-wraps an overflowing line back to column 0, wrecking the indent ladder (user screenshot, 2026-07-22 — "notes flagship", "existing " landed at column 0). When a node's content would overflow, hard-wrap it yourself: every continuation line carries leading whitespace **identical** to the marker line's indent — no deeper hanging indent, no marker glyph on the continuation. Applies to every node type, `↪` leaves included (their uncapped prose is the usual overflow case). `inline` and `responsive` modes are UNAFFECTED — GitHub, and the chat-app renderer respectively, wrap markdown themselves; hard-wrapping there would inject spurious line breaks (in `responsive`, a real GFM list item, the wrap is delegated to whatever box width the renderer has, which is the entire point of that mode — see `## Render modes`). Full spec + worked wrap: `reference/render-modes.md`.

**Blank line between siblings** — omitted in `block` and in `responsive`, was required only in the deprecated `inline` mode. In `responsive` each node IS a real GFM list item, so the renderer spaces siblings correctly with no blank lines. In `block` mode monospace already puts each line on its own row. (The old inline rule existed because its literal glyphs were *not* real list items and collapsed vertically without a blank-line separator — one more reason inline is retired.)

## Emphasis taxonomy

Applies to **markdown-rendered modes** (`responsive`, and the deprecated `inline`). In `block` mode everything inside the fence is literal, so no emphasis is used there.
- L1 top concepts → **bold** (the scannable concept spine)
- inline + sparing, deeper: `code` → literal tokens (paths, ids, values, verbatim errors) · *italic* → term-of-art first mention · ~~strike~~ → rejected/deprecated
- `<u>underline</u>` → definition anchor (best-effort; surface lacks `<u>` → fall back *italic*)
- never alters the marker ladder or nesting

## Leaf preservation

Code blocks + tables = intact leaf nodes under the owning node. Never flatten into node text.

## Hedge preservation

Preserve source hedges with the claim they govern, including in collapsed output. Keep the hedge in the claim text or in an immediately attached `↪`. Use a certainty branch only when the hedge's scope is unambiguous. Never turn a hedged source claim into an unhedged heading.

## Carve-outs

- single-fact / no hierarchy → no forced nesting
- security / irreversible-action warnings → plain clarity wins (align caveman auto-clarity)
- non-explanatory status ("done", tool results)
- code / commit messages / bot-template fixed fields (A–G) / footers / markers
- explicit prose request → prose that turn

Note: *which* GitHub surfaces should render as `responsive` outlines, and which template/footer scaffolding stays verbatim, is a consuming repo's authoring **policy**, not a rule of this skill — this skill only supplies the `responsive` render mechanism (see `## Render modes`). Policy owner: the consuming repo.

## Render modes

Same outline, two active containers, **scoped by surface**. The structure (ladder / nesting / `↪`) is identical; only the wrapper differs. Render mode is a presentation choice, independent of granularity (`## Granularity` above) and of the linter's structural rules — see the independence note there.

| surface | mode |
|---|---|
| monospace/terminal + committed `.md` fences, faithful spacing, copy-paste clean | `block` — ONE fenced ` ```text ` code block, whole outline; R11 hard-wrap applies |
| **any markdown-rendering surface** — GitHub issue/PR/comment bodies AND chat-app replies (Claude Code app/web, or any variable-viewport renderer) — **opt-in via explicit `responsive` mode; `block` is the default everywhere as of this change** | `responsive` — real GFM list items, 2-space/rung real list nesting, no fence; **glyph-free since v0.3.9**: the renderer already draws a bullet per item, so carrying `▸`/`↪` inside the content produced `• ▸` double markers (render-layer R10). Role moves to typography — attribute → `- **Bold Name**`, enumerator → literal label content (`- a. tool execution`), explanation leaf → plain prose item (no `↪`). The renderer wraps to its own box width — R11 does NOT apply |
| ~~GitHub prose via literal-glyph 4-space rungs~~ | `inline` — **DEPRECATED (v0.3.8).** Its ≥6-space (depth-2+) rungs render as **indented code blocks** on GFM (wide, non-wrapping, horizontal-scroll boxes) and its depth-1 `▸` lines as emoji-led paragraphs — the exact GitHub-rendering mess `responsive` fixes. Retained only so pre-v0.3.8 committed outlines still lint; never pick it for a new GitHub body. |

Full spec (fence-tag rationale, per-mode cost tradeoffs, block-mode line-wrapping, responsive-mode worked example, why `inline` breaks on GFM): `reference/render-modes.md`.

## Worked example

Same "Agentic harness" tree, two ways — pick the one matching your surface's default from `## Render modes` above (**`block` is the default everywhere**; `responsive` is opt-in for GitHub/chat). Attributes (`▸`/bold) name properties of the concept; enumerators (`I.`/`A.`/`a.`) are ordered/grouped parts; the explanation leaf carries the prose. Note `Capabilities` groups an attribute; its parts are enumerated below it — attribute, then its composition.

**`block` — default everywhere, literal glyphs, 4-space rungs, fenced (` ```text `):**

```text
- Agentic harness
    ▸ Purpose
        ↪ a raw text-predictor gains the ability to act
    ▸ Capabilities
        a. tool execution
        b. control loop
    ▸ Output
        ↪ an acting agent
- Control loop
    I. assemble context
    II. emit tool calls
    III. harness executes
        ↪ side effects hit the real world: files, shell, network
    IV. repeat until done / budget cap
```

**`responsive` — opt-in for GitHub/chat, glyph-free since v0.3.9, 2-space real-list nesting, no fence:**

```
- **Agentic harness**
  - **Purpose**
    - a raw text-predictor gains the ability to act
  - **Capabilities**
    - a. tool execution
    - b. control loop
  - **Output**
    - an acting agent
- **Control loop**
  - I. assemble context
  - II. emit tool calls
  - III. harness executes
    - side effects hit the real world: files, shell, network
  - IV. repeat until done / budget cap
```

**Do not mix them.** Never carry `block`'s literal `▸`/`↪` glyphs or its 4-space rungs into a `responsive` reply — the glyph doubles up with the renderer's own bullet (`• ▸`) and the 4-space rungs render as GFM code blocks past depth 1. Negative example + full detail: `reference/render-modes.md` `## Responsive mode`.

In both trees, `Purpose`, `Capabilities`, `Output` are **attributes of** the agentic harness, not peer concepts and not steps; `Control loop` is a separate concept whose children are genuinely ordered steps (`I.`–`IV.`). More examples: `examples/{standard,attribute,report}.md`.

## Caveman coexistence

Orthogonal — caveman = wording, structured-gist = structure.

On public reader-facing prose surfaces specifically, `write-like-scientist` (renamed from `dom-write`) — not caveman — owns the wording inside nodes and `↪` leaves (see `## Composition with the other output layers`); caveman stays out of those surfaces entirely, so the coexistence table below applies only where caveman is the active wording layer (non-public, computer-facing surfaces).

**Independence (load-bearing)**: structured-gist NEVER invokes, activates, or implies caveman, and changes no wording itself. caveman OFF → nodes use normal prose. caveman *separately* active → caveman compresses the enumerator wording, **but never the `↪` leaf** (its job is to stay a readable explanation). The structure (ladder / nesting / `↪`) is identical either way. Token throughput restructures, it does not compress — that is the independence test.

Invariants across ALL 6 caveman modes:
- structure (markers + indent + `↪`) unchanged — markers stay **Latin even under wenyan** (localizing to 一/甲 would break the taxonomy + cross-surface scan)
- the structural leaf marker is `↪`; the plain `→` in the wording column below is the inline cause-effect glyph (`X → Y`), a DIFFERENT role — they never swap
- enumerator wording delegated to caveman; the `↪` leaf is exempt from compression

| caveman mode | enumerator wording | markers | ↪ leaf |
|---|---|---|---|
| (none) | normal EN | Latin | readable |
| lite | tight EN | Latin | readable |
| full | fragments | Latin | readable |
| ultra | abbrev + `→` | Latin | readable |
| wenyan-lite | semi-文言 | Latin | readable |
| wenyan-full | 文言文 | Latin | readable |
| wenyan-ultra | extreme 文言 | Latin | readable |

Carve-outs align: when caveman auto-clarity yields for security/irreversible warnings → structured-gist also yields to plain clarity. 's ownership of public-surface wording, and the caveman compose-per-node steps: `reference/composition.md`.


- The benchmark scorer never calls a model, network, or randomness at scoring time; if those are unavailable it cannot fail for their absence.

## Limitations

- The robustness axis measures structural conformance only — a perturbation-stability term was designed twice and cut twice with recorded proofs (`benchmarks/scoring.md`).
- Slop reduction is non-deterministic: the linter enforces marker structure, nesting, node length, and delimiter splicing, not sentence quality — a compliant outline can still carry jargon or a weak claim inside a node's text. The tool improves skimmability; it does not remove bad prose.
- The linter checks structure, not truth — a well-formed outline can still misrepresent its source content, and no rule catches that.
- Accepting the hedge rule in general requires comparing source against output for both hedge retention and claim attachment — structural linting alone establishes neither, so general enforcement is deferred to the held hedge-fidelity backlog item; the shipped fidelity check covers only declared statements in this repo's own example and fixtures.
- Relation-wording preservation is enforced only over those same declared statements, not over arbitrary sources.

## Install

`/plugin marketplace add domattioli/structured-gist`, then `/plugin install structured-gist`. Full detail: `reference/install.md`.