All posts

Why your prompts get worse in Cowork (and the fix)

The prompt didn't get dumber. The environment got noisier, and nobody told you the rules changed.

I had a prompt I'd used maybe two hundred times in the Claude chat window. A positioning teardown prompt, five paragraphs, very tuned. First week I moved my work into Cowork, I pasted it in and got back something that read like a committee wrote it. Same words, worse output. My first instinct was that the model had changed under me. It hadn't. What changed was that the prompt was no longer the only thing in the room.

The usual take on this is "Cowork prompting needs different prompts," which is close enough to true to be useless. The actual mechanic is narrower: in a chat window your prompt is roughly the whole context. In Cowork your prompt is one input competing with a file tree, open documents, prior turns, whatever a teammate dropped in that morning, and in agent setups the output of whatever ran before you. A prompt written to be self-sufficient gets drowned by a workspace that's also talking. The fix is not better wording. It's telling the prompt which inputs count, and putting the stable parts of the prompt somewhere the workspace can't dilute them.

The failure mode has a shape, and you can spot it

Prompt rot in Cowork doesn't look like a wrong answer. It looks like a generic answer. That's the tell. Wrong means your instructions were bad. Generic means your instructions got outvoted.

Three specific symptoms I now recognise in under a minute:

It averages instead of choosing. You asked for the sharpest of three positioning angles and got a summary of all three. Something else in context (a doc that lists all three neutrally, usually) is pulling toward survey mode.

It uses the wrong voice. Not bad voice, the house voice of whatever file is nearest. If there's a client brief open, you get brief-ese. Your voice instruction is still in the prompt, it's just outnumbered by 4,000 words of evidence about how documents around here sound.

It silently picks an input. You said "the Q3 notes" and there are three files that could plausibly be the Q3 notes. In chat you'd have pasted the right one. In Cowork it guessed, didn't tell you, and the output is confidently about the wrong quarter.

Fix one: name your inputs, explicitly, every time

This is the single highest-leverage change and it costs you one line. Stop referring to context by description. Refer to it by path, and say what to ignore.

INPUTS (use only these):
- ./research/q3-interviews.md  (the raw transcripts)
- ./brand/voice.md             (how we write)

IGNORE: everything else in this workspace, including any
open documents, previous drafts, and other briefs. If you
think you need a file not listed above, stop and ask me
for it by name instead of substituting a similar one.

Drop that block at the top of any prompt you move into Cowork. The IGNORE line does more work than it looks like it should. Without it, "use these files" reads as also use these files. With it, you've made the context boundary an instruction rather than an inference.

The "stop and ask" clause is the refuse-first half. You want the model to surface a missing input, not quietly find the nearest lookalike. Same discipline as flagging [MISSING: REAL NUMBER] instead of inventing a stat. A prompt that stops is cheaper than a prompt that confabulates.

Fix two: stop pasting prompts, start installing them

A pasted prompt is a turn in a conversation. It decays as the conversation grows. A Skill is a file the workspace loads as a rule, and it doesn't decay, because it's not competing for attention in the transcript. Same instructions, different structural position.

This is the real reason your prompts get worse in Cowork: you kept using the chat-window delivery mechanism in an environment that has a better one.

Here's a Skill version of a positioning teardown. The frontmatter matters more than the body, because the description is how Cowork decides whether to load it at all:

---
name: positioning-teardown
description: Use when evaluating or rewriting a positioning
  statement, value prop, or homepage hero. Takes a draft plus
  a named audience file and returns the weakest claim first.
  Do not use for general copy edits.
---

# Positioning teardown

## Inputs you require
1. The draft positioning (pasted or a named file).
2. A named audience/ICP file. If none is provided, STOP and
   ask for it. Do not infer the audience from the draft.

## How to work
- Find the single weakest claim first. Say why it's weak in
  one sentence. No preamble, no summary of the draft.
- Any claim that depends on a number must either cite the
  number's source file or be marked [MISSING: REAL NUMBER].
  Never estimate a metric to make a claim land.
- Rank what's left: keep / sharpen / cut. One line each.
- Rewrite only the lines you marked "sharpen". Leave the
  rest alone so the diff is readable.

## Refuse
- Don't produce three alternative versions. Pick one and
  defend it.
- Don't soften a verdict because the draft is someone's work.

## Output
WEAKEST CLAIM: <one sentence>
KEEP / SHARPEN / CUT: <ranked list>
REWRITES: <only the sharpen lines>
OPEN QUESTIONS: <inputs you needed and didn't get>

Note what the Refuse section is doing. Those two lines are precisely the behaviours that creep back in when a prompt gets diluted. Writing them as prohibitions, inside a loaded file, is more durable than writing them as preferences inside a pasted paragraph.

Fix three: the output contract is the anti-drift mechanism

Loose prompts drift fastest in a noisy workspace, because "write a positioning teardown" has a thousand valid shapes and the workspace will happily suggest one. A fixed output block has one shape. If the output comes back in a different shape, you know instantly that something pulled the model off your instructions, and you know to check your inputs rather than rewrite your prose.

Treat the output contract as a diagnostic, not just formatting. It's the cheapest drift alarm you can install.

Where it lives	Survives a long session	Survives a teammate's edits	Good for
Pasted in chat	No, decays with turns	No	One-off exploration
Pinned in a project doc	Partly	Partly	Shared reference prose
A Skill file	Yes	Yes, it's version-controlled	Anything you run twice
Inline in an agent step	Yes for that step	Yes	Deterministic pipeline work

The rule I follow now: if I'll run it twice, it's a Skill. If I'll run it once, paste is fine. Most prompt rot I see is someone running a paste-grade prompt fifty times.

Fix four: a handoff file, for when an agent runs before you

Agent and OpenClaw setups add a worse version of the same problem. Your prompt isn't competing with documents, it's competing with the last step's output, which arrives with the authority of something the system just produced. If step one summarised the interviews badly, step two inherits the bad summary as fact.

The fix is a handoff file with provenance baked in, so step two can tell the difference between evidence and inference:

handoff/
  00-inputs.md        # the literal source files used, by path
  01-extract.md       # raw pulls, quoted, with line refs
  02-claims.md        # each claim + which quote supports it
  99-open.md          # what's missing, unresolved, or guessed

And in 02-claims.md, one format, no exceptions:

CLAIM: Buyers distrust per-seat pricing for small teams.
SUPPORT: 01-extract.md L14, L31, L58 (3 of 9 interviews)
CONFIDENCE: medium, small n
NUMBER USED: none  [if a number appears here and has no
source file, write [MISSING: REAL NUMBER] and move on]

Every downstream prompt then opens with "read 99-open.md first, and treat anything listed there as unknown." That one line stops the most expensive agent failure there is, which is confident laundering of a weak upstream step into a clean-looking final deliverable.

The honest failure modes of all of this

Skills can load when you don't want them to. A vague description means your teardown Skill fires during a casual question and you get a verdict when you wanted a chat. Write descriptions with a "do not use for" clause.

Over-specified output contracts make the model stupid in a specific way. If you force a rigid block on genuinely exploratory work, you get the block filled competently and the insight dropped. Save contracts for repeatable work.

IGNORE lists can cut off something you needed. You'll occasionally get an output that's worse because you walled off a file that mattered. That's the correct trade, because that failure is visible and the dilution failure isn't.

None of this fixes a bad prompt. If the chat-window version was mediocre, installing it as a Skill gives you reliable mediocrity. Fix the thinking first.

Try it on something you can check today

Take one prompt you've run more than five times. Do this in order:

1. Run it in Cowork as-is. Save the output. 2. Add the INPUTS / IGNORE block. Run again. Compare. 3. If step 2 helped, convert it to a Skill with a Refuse section and an output contract. 4. Delete the pasted version so you stop reaching for it.

If you want something pre-built to test the pattern against, the four free Skills at /skills/ are all written in this shape, frontmatter with a "do not use for" clause, a refuse section, a fixed output block. The four free prompts at /free/ are the paste-grade versions of the same jobs. No email gate on either, so you can diff them against your own and see whether the structure is what's helping or whether I'm just talking.

Where the Hub fits

The free material covers the method completely. If you read this, add the INPUTS / IGNORE block, and convert your two or three most-run prompts into Skills using /skills/ as the template, you have the whole fix. Nothing in the paid library makes that work better. Use the free material.

What the paid library is actually for is depth in one discipline. A single pack is thirty-odd prompts in one lane, SEO or content or market research, each already written with named inputs, a refuse clause, and a fixed output block, each with a tip from running it rather than from imagining running it. You're buying the part that takes the longest, which is the hundred small decisions about what a good output looks like in that specific job. If you only need one discipline done properly, buy one pack and ignore the rest of the ladder. If you need the method and not the volume, you already have it above.