Prompting & task briefs

Sonderr will attempt almost anything you type. That’s a strength and a trap: a vague brief gets executed with the agent’s defaults, which are reasonable — but not yours. The workspace rewards specificity the same way a good hire does, and none of it costs configuration. This page is the practical craft of asking: which mode to pick, the four-part brief pattern that works everywhere, real before/after examples, and why the constraints you state up front become the checks your work is judged against.

1 · A brief, not a wish

A wish says what you want. A brief says what you want, for whom, within which limits, and against which example. The difference sounds bureaucratic until you watch both run: a wish makes the agent fill every unstated blank with a default, then you spend three follow-ups pulling the work toward what you actually meant. A brief spends those decisions up front, where changing them is free. This is not a Sonderr quirk — it’s how delegation works — but Sonderr makes it visible, because it shows you its plan, its evidence and its definition of done instead of burying them in prose.

The good news: briefs are cheap. Four sentences beat four paragraphs of politeness. “Please could you maybe look at” carries no information; “investigate why checkout totals round wrong on discounts, then fix it” carries a goal, a symptom and a scope.

2 · Pick the mode before the words

Every composer message runs in one of four task modes, and the mode decides what your words are allowed to cause. Choosing it first shapes how you write:

• Ask — explanation, options, analysis. Write freely; nothing can change your files. This is the mode for “what are my options” questions, and the cheapest place to think out loud.
• Plan — shape work without touching anything. Ask for the plan you want to approve: steps, order, risks. If the plan is wrong, say so here — it’s the lowest-cost moment to be wrong.
• Build — the mode that makes changes. Briefs here need the most structure: goal, constraints, and what “done” looks like, because this is the mode with hands.
• Vision — image understanding and edit_image. Describe what you want to see or change in the image, not what you want in general.

Mode and access are separate controls: project checks and shell commands require Full PC access plus an explicit request in your current message. A stale authorization from an earlier message doesn’t carry, and Sonderr will tell you which boundary is actually missing rather than pretending it can flip it for you. So if the reply says it can’t run something, the fix is usually one sentence — say the thing explicitly.

3 · The pattern: outcome, audience, constraints, references

Studios briefs are documented with four slots — outcome, audience, constraints, references — and the pattern generalizes to nearly everything in the workspace:

• Outcome — the deliverable, described as a state of the world. Not “help with my site” but “a one-page site that loads fast and takes bookings.”
• Audience — who receives it and what they do with it. A changelog for developers reads differently than one for customers; naming the reader decides the register.
• Constraints — the limits that must hold: stack, palette, length, tone, budget of time, things that must not change. This slot is where quality is actually won.
• References — anything the work should be measured against: a file, a URL, a screenshot, “like the old flyer but calmer.”

Four lines, one per slot. Everything else is elaboration you can add when the first result comes back — and because the first result started from real constraints, the iteration loop is short.

4 · Weak brief, strong brief

Three upgrades, side by side. Notice each strong version is shorter than the pile of politeness it replaces:

• Weak: “make my website better.” Strong: “Redesign the pricing page: mobile-first, keep the existing palette, add a FAQ section, target audience is solo developers comparing tools. Reference the current page for content — don’t invent plans we don’t sell.”
• Weak: “find the bug.” Strong: “Totals round wrong when a discount applies to multi-item carts. Reproduce it, find the root cause, propose the fix — don’t apply it yet.” The last sentence is a constraint, and it changes the whole shape of the task.
• Weak: “write something for our blog.” Strong: “Draft a 600-word post announcing the docs expansion. Audience: people who already use the product. Tone: plain, honest, no hype words. Reference the announcement post for facts — anything not in there needs a source or gets cut.”

The strong briefs share one habit: they close doors the agent would otherwise have to guess about. Closing doors is what a brief is for.

5 · Constraints become acceptance checks

Here is the mechanism that makes briefing worth the effort. In Studios, each craft carries per-craft playbooks with a definition of done — five professional rules per track, applied while working and re-run as the final acceptance check. Documents must come out print-ready; websites get mobile-first layouts and accessibility checks as a condition of completion. The constraints in your brief join that system: stated up front, they become checks the work is actually graded against, not vibes you argue about afterwards.

That is also true outside Studios in a softer way — a Build task with explicit constraints produces work that references them, and a follow-up like “check the result against the constraints I gave” is a legitimate, effective prompt. Constraints you leave out become the agent’s defaults: reasonable, generic, and yours to override in the next turn.

6 · Iterating without losing the plot

Long work in Sonderr is built to survive interruption: substantial Build work writes durable checkpoints — goal, current milestone, verified evidence, decisions made, and one exact next action. Use that structure when you iterate. The highest-leverage follow-ups reference the checkpoint spine rather than restarting the conversation:

• “Continue from the current milestone” — resumes along the recorded next action instead of re-deriving the plan.
• “Show me the evidence for step 3 before you continue” — asks for verification, not vibes. The v1.7 workflow direction is exactly this: plan, act, verify, with evidence attached.
• “That constraint changed: keep everything else.” — updates the brief without nuking the work.

And when a task is genuinely huge, say so and let the machinery work: marathon Build tasks run up to 72 hours under the same checkpoint discipline. Your job at that scale is not to type more — it’s to keep the brief honest and check the milestones.

7 · The anti-patterns

The five brief-killers, so you can recognize them in your own composer:

• The pile-on. Ten unrelated asks in one message. The agent will attempt them in order with one context window; split them and each gets real attention.
• The vibe check. “Make it pop.” Pop in which direction? Name the dimension — contrast, density, tone — or accept that you’ve delegated taste to defaults.
• The negation ghost. “Don’t touch the auth code” buried in paragraph six. Constraints late in a wall of text are decorations. Lead with them or list them.
• The stale authorization. Assuming last message’s “yes, run it” still applies. It doesn’t — say it again in the current message. That’s the safety design working.
• The redirect mid-flight. Changing the outcome while a marathon runs without updating the goal. Checkpoints pin the old goal; say “the goal changed, here is the new one” so the checkpoint spine gets rewritten, not ignored.

None of this makes prompting formal. It makes it load-bearing — the brief is the spec the rest of the workspace is honest against.