Skill-suitability block leaks into the visible transcript — keep it model-context only

[santoshkumarradha]

What happened

Every time a turn's words match skills on the active shelf, the person's own message in the visible transcript grows a block they never asked for:

Skills suited to this message:
- Use for Codex models/pricing, scheduled tasks, skills, settings, setup, troubleshooting, customization, automations, and self-knowledge—including 'you,' 'your,' 'this app,' or 'this coding agent' when they refer to Codex—and for OpenAI APIs/products and ChatGPT Work. Also use for model choice/migration, prompting, SDKs, Responses, Realtime, agents, evals, and Chat/Work/Codex comparisons. Do not use for generic app/software tasks that merely mention Codex. [/Users/santoshkumar/.codex/skills/.system/openai-docs/SKILL.md — body in this file]
- Build multiple genuinely different versions of a UI piece you describe, rendered behind a visual picker so you can flip through them live and promote the one that feels right. Only runs when explicitly invoked; it does not trigger on its own. [/Users/santoshkumar/.agents/skills/prototype/SKILL.md — body in this file]
- Survey a codebase's animation and motion code as a senior motion advisor, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the animations", "audit the motion", "make this app feel better", or wants a roadmap of animation fixes rather than a review of a single diff. [/Users/santoshkumar/.agents/skills/improve-animations/SKILL.md — body in this file]
Earlier-listed skills win when two skills conflict.

Observed 2026-09-25 on dev@7f136b3 in an ordinary chat turn (no flags). The skill-suitability list exists to inform the model which skills fit the message's words; it is not something the person said or asked to see, yet it is spliced into the user-role message, so every surface that draws the conversation prints it.

Replication

Deterministic (no model).

The splice is pure and needs no model. attachTurnSkillsLocked appends "\n\nSkills suited to this message:\n" + block to user.message whenever turnSkills returns a non-empty block (internal/session/skillturn.go, search Skills suited to this message). With an active shelf holding one skill whose doc shares words with a message, the message content messageContentText(user.message) equals the person's words plus the block; the display path renders that same text (internal/session/chatlog.go builds chat lines from messageContentText). A developer today can run a conversation with a one-skill shelf, send a message using that skill's words, and quote the block appearing in the printed transcript — that wrong output is the evidence.

Field (real models).

Any chat turn with an active skill shelf and a message matching a skill doc; reproduces on the first matching turn. No keys beyond a normal chat's; a couple of minutes of wall time.

Where

• internal/session/skillturn.go — attachTurnSkillsLocked (searchable string: Skills suited to this message; the splice is user.message = textMessage("user", messageContentText(user.message)+block)). The block rides inside the user-role message content, so anything that renders the conversation renders it.
• internal/session/chatlog.go — user messages are rendered from messageContentText(...); the defect is not the skill choice but that the block lives in message text instead of a part the display path strips.
• The person's true words are already kept separately (user.said, asserted in skillturn_test.go), and turnSkillsNotice already emits a dim skills carried: … event that surfaces may draw or ignore — so today two channels carry the same fact, one loud and visible.

The fix

The person's message in the transcript shows exactly the words they typed. Skill suitability is model context only: the block still reaches the model, but no surface prints it. Deliver it to the model in a form the display path does not render (a separate content part, or a tool-shaped entry), and use exactly one surface-visible channel — the existing dim "skills carried" notice — so the loud block and the notice never both appear.

Acceptance

• e2e: through the real chat door with an active shelf and a matching message — the transcript the person sees renders their message as their words only: the string Skills suited to this message: appears nowhere the surface prints, while the model's copy of the message still carries the block (the existing skillturn_test.go assertion on the model's copy stays green), exit 0.
• e2e: the control run — codeaf do --json (or the non-TUI surface) for the same turn emits no text containing Skills suited to this message:, exit 0.
• Unit: the display path — rendering the stored user message for a turn that carried skills never includes the block; the journal/store still hold the person's words unchanged (user.said, already covered by skillturn_test.go).
• The manual page that covers what appears in the transcript (internal/manual/chat/) quotes the new wording — the transcript shows only what the person typed — and the change entry's invalidates names what people believed before.

---

Drafted with CodeAF · reviewed and owned by the author