Verified 2026-08-05 What was checked, and when — not a guarantee it is still true.

The contract: every rule on one page

This page is generated from the rules on every other page, in order, with no additional prose. If you read nothing else, read this. Each rule links to the page that explains it and carries the same confidence badge.

Every rule on the site, grouped by the page that explains it. Generated — this page cannot disagree with the others.

Where should my skill write files, and which path forms work?

• Treat a folder the user connected as a separate mount with its own rules, not as part of the workspace. Measured
• Do not assume a connected project gives you a folder mount. It does not. Measured
• Write files using bare or relative filenames, not absolute paths. Measured
• Do not leave anything you want the user to see in the working directory alone. Measured
• Never pass an absolute session path to the file tools. It is denied, not translated. Measured
• Treat your own skill's files as read-only at runtime. Measured
• Treat the uploads location as read-only and write everything to the outputs location. Measured

Why did my skill's output never reach the user?

• Do not rely on writing a file to a directory as the act of delivering it. Measured
• Write the deliverable to a stated path, then present it with whichever delivery tool the session offers; if none exists, state the path and stop. From binary
• State the path of what you produced even when a delivery tool worked. Inference
• Never call a tool that writes to the user's own disk from inside a skill. From binary
• Do not hand-copy files into the outputs location before presenting them. From binary
• Assume the session filesystem does not outlive the session. Measured
• Assume your skill may run in either of two lanes, and never assume which one. Measured

Why does deleting a file fail, and what should my skill do?

• Treat needing a delete as a design smell, because getting one interrupts the user. Measured
• Do not assume that approval to delete in one location applies anywhere else. Measured
• Do not move files between mounts with a rename. Copy, then verify. Measured
• Expect removing a file or a directory to fail with a permission error on every Cowork mount. Measured
• Expect the agent to ask for delete permission on its own the first time a removal fails. From binary
• Do not treat a file vanishing from its old path as evidence that it was deleted. Measured

What does my skill's shell see?

• Do not use the inline shell-execution syntax in skill instructions and expect it to run. From binary
• Do not rely on arbitrary outbound network access from shell commands. From binary
• Do not plan on installing packages at runtime. Inference
• Do not assume the sandbox has no third-party libraries. It ships a large preinstalled stack. Measured
• Do not expect to read or write anything outside your own session. Measured
• Do not pass configuration to your skill's shell commands through the environment. Measured
• Do not assume the shell tool has the same name it has in the CLI. Measured

How should my skill detect that it is running in Cowork?

• For behaviour rather than reporting, branch on which tools exist instead of on the environment. Measured
• Do not hard-fail when a runtime marker is missing. Fall through to the next check. Measured
• Do not detect Cowork with a bare environment-variable check. Measured
• Detect the runtime with an ordered sequence of checks, not a single environment test. Measured
• Remember your skill spans two execution contexts, and test the one you are actually in. Measured

Will my plugin's hooks and scripts run in Cowork?

• Do not use a hook to export environment variables for your skill's shell commands. Measured
• Expect plugin hooks to fire in Cowork. Measured
• Install a plugin through the Cowork application if you want Cowork sessions to see it. Measured
• Do not write into your plugin's own directory at runtime. Measured
• Expect plugin files to be present as a mounted directory, and find it rather than hardcoding it. Measured
• Use the plugin-root token for file-tool reads, and discover the mounted path at runtime for anything you execute. From binary

What changes when my skill dispatches sub-agents?

• Always name the agent type when dispatching a sub-agent. Measured
• Do not plan to resume a finished sub-agent. Dispatch a fresh one with the context restated. From binary
• Do not use a sub-agent to get around a path restriction or a permission prompt. Measured
• Put everything a sub-agent needs in its prompt. It cannot ask you for more. Inference
• Write sub-agent fan-out so that a dispatch being queued or refused is handled, not fatal. From binary
• Write sub-agent prompts with relative paths, exactly as you would the main thread. Measured

What can change without any version bump?

• Detect capabilities at the moment you use them, and state a clear fallback when they are missing. Measured
• Do not assume configuration is fixed for the lifetime of a session. From binary
• Never write a skill that depends on the exact wording of the system prompt. From binary
• Do not treat 'the version has not changed' as evidence that behaviour has not changed. Measured
• Assume tool availability and defaults are served to the session, not shipped in the application. Measured
• Write down which behaviours your skill depends on, in the skill itself. Inference
• Do not hardcode a tool name your skill merely hopes is present. Measured