Tell the agent a file path names an output, not a file

[AshishKumar4]

What does this change?

An instruction that names a file path for its result has no defined behaviour, because there is no
path to write to.

writeFile takes a workpiece — every write goes inside one specific Gadget, as one of that
Gadget's source files. There is no free-standing file path, and the system prompt never says so. When
a skill or a user says "save it to notes.md", the agent is left to invent a destination: sometimes
it answers in chat, sometimes it writes a .md into a Gadget's source tree where it renders as code
rather than as a document, sometimes it creates the right output. It varies between runs.

This is not hypothetical for skill libraries. In the one this deployment publishes, 93 of 97 skills
end by naming a file path for their deliverable.

The standard-formats section is where the mapping belongs: it already lists the deployment's formats
with their nouns and blueprint IDs immediately below, and it is already the place that tells the
agent to instantiate a format rather than build an equivalent.

Why is this obviously correct and trivially verifiable?

Four added lines of prompt text in one function, and no code path changes. The complete effect is the
sentence itself, read in place.

The wording names no particular path convention, so it does not encode any one library's habits — it
states the rule that follows from writeFile requiring a workpiece. It reuses the vocabulary already
present in the surrounding prompt (createGadget, "format", RPC methods), and defers to the format
list rendered directly beneath it rather than hard-coding any blueprint ID or extension.

describeStandardFormats() has no test seam, and neither does any other prompt text in this file;
adding one would mean extracting the method purely to assert prose, which would be a larger and
less obvious change than the patch itself. Verified with pnpm lint (lint plus type-check) and
pnpm test, both clean.

Checklist

Checking every item does not guarantee acceptance. Maintainers determine whether
a pull request meets the contribution policy.

• This is a small, concrete change; it is not a feature, refactor, or low-value cleanup.
• I understand that maintainers decide whether the change is obviously correct and trivially verifiable.
• I have read and followed the contribution guidelines.

[ask-bonk]

I've reviewed the change thoroughly. My assessment:

Correctness verified:

• The claim that writeFile operates inside a gadget (via the workpiece/gadget parameter) with no free-standing file path is confirmed in agent.ts:462, agent.ts:719, and resolveWorkpieceRoot in overseer.ts:1610.
• The added text is placed in describeStandardFormats(), immediately above the rendered format list it defers to ("use the matching format below") — an appropriate location.
• The vocabulary reuses existing prompt terms: createGadget, "format", and "RPC methods" (consistent with agent.ts:692 and overseer.ts:2231, where instantiated gadgets are populated by calling their RPC methods).
• It hard-codes no blueprint ID, extension, or path convention; notes.md appears only as an illustrative quote of a user instruction.
• No code paths change — the effect is the prose itself.

Minor observations (non-blocking):

• The sentence is long and chains several clauses with em-dashes and a parenthetical, but it matches the density of the surrounding prompt paragraph, so it's stylistically consistent.
• The -- (ASCII double-hyphen) is used in the new lines while the format-list line below uses — (em-dash); this matches the existing convention in this same paragraph (which uses --), so it's internally consistent.
• No test coverage, but as the PR notes, no prompt prose in this file is tested and adding a seam would be a larger change than the patch. This is a reasonable judgment.

I found no actionable issues introduced by this change.

LGTM!

github run