Summary

When the assistant invokes a Skill that's already been loaded earlier in the session, the full skill body re-renders in the user's transcript — even though the content is already in the model's context and the user has already seen it. The first invocation makes sense; the repeats are pure noise.

Suggest: a flag that lets a Skill invocation render compactly (a one-line "skill re-loaded" confirmation) when the skill is already loaded in the session, while still putting the content in front of the model.

The flag preserves current default behavior. If the team later decides the compact rendering should be the default for repeats, a flag-based implementation makes that a one-line change.

Motivating use case: discipline hooks

The scenario where this stings hardest is a PreToolUse hook that gates a high-stakes tool call on a skill having been read. For example, a plugin that ships:

• A skill (~24KB) describing how to compose a git commit message — formatting rules, footer requirements, evidence-block conventions, command-shape guidance.
• A PreToolUse hook on Bash(git commit *) that denies the call unless the assistant invoked that skill since the most recent user prompt.

The hook works — every commit is gated on the skill being loaded fresh in the current turn. The first such load per session is genuinely useful: the user sees the rules being applied to their commits. But on a branch with five commits across five user messages, the user sees the same ~24KB block five times. Same content, no new information.

The same pattern applies to:

• A pre-PR security review skill enforced by a hook on gh pr create.
• A pre-merge design review skill enforced by a hook on git merge / gh pr merge.
• Any "consult this guidance before this high-stakes tool call" pattern.

What the user sees today

The hook denies the first git commit of each turn until the model invokes the skill. The deny-and-retry loop produces this in the transcript on every gate-fire:

Skill(example-developer:example-craft) ⎿ Successfully loaded skill

Base directory for this skill: /Users/.../skills/example-craft

Example Craft

[continues for ~600 lines / ~24KB]

⏺ Bash(git add foo && git commit -F - <<'EOF' ... EOF) ⎿ [main abc1234] feat(scope): subject

The first time the user sees this in a session, it's useful — they can read the rules. The fifth time, it's noise.

Proposed shape

A flag — concretely: Skill(name, quiet="if-already-loaded") or similar — that lets the caller request compact rendering when the skill is already loaded in the session.

Semantics:

• Skill not yet loaded in this session → render the full body (status quo, regardless of flag).
• Skill already loaded → render a one-line confirmation, e.g. Skill(example-developer:example-craft) — re-loaded (already in context). The model still receives the skill content as it does today; only the rendering changes.

This keeps the audit trail (the user always sees that the skill was invoked) while removing the redundant body.

Adjacent ergonomics worth considering at the same time:

• settings.json knob: skillOverrides.<name>.compactOnRepeat: true lets a user opt a particular skill into compact-on-repeat without plugins having to opt in per call.
• Hook-emittable field: A PreToolUse hook can return a hint that the next Skill invocation by the model should use the compact form. Useful for discipline hooks specifically — only the model-driven repeats triggered by the hook get compacted.

These are strictly additive to the flag.

What's been tried

• hookSpecificOutput.additionalContext — caps at 10K characters; above that the content is written to a session file and replaced with a preview + path. The model has to choose to call Read on the path; there's no enforcement and skills with substantive content are often too large to fit in the budget.
• suppressOutput — only suppresses the debug log, not the user-visible transcript.
• Trimming the skill — possible but lossy; rules that "should always be loaded before a commit" are exactly the ones too important to drop.

Edge cases

• After context compression, a previously-loaded skill may have been summarized out. If the harness can detect that, the next invocation should render full again regardless of the flag. If not, the flag still produces a usable result — at worst the user re-reads a skill body the model has effectively forgotten.
• User explicitly wants to re-read: /<skill-name> slash invocations should keep full rendering — the flag is for model-driven repeats, not user-driven ones.

Honest limitations

This change removes transcript noise; it doesn't fix attention drift. A model that ignores already-in-context content is no better off than a model that ignores re-rendered content. The ask is about ergonomics, not about a bulletproof discipline guarantee.

Prior art

The superpowers plugin hits a similar wall from a different angle: it loads its using-superpowers skill body via a SessionStart hook's additionalContext so the rules are in context for the whole session (session-start hook). That works for "load once at boot," but not for "load before this specific tool call." A flag for compact-on-repeat would let both patterns shed transcript noise.