Best practices
Scout is most useful when you treat them less like a search box and more like a teammate: give them a clear goal, the context they need, and a safe surface to work on. This page collects the habits that consistently produce the best results.
If you're new to Scout, start with Using Scout for the mechanics, then come back here.
Write prompts Scout can act on#
The biggest single lever on output quality is the prompt itself.
Lead with intent, then constraints#
A good prompt usually has three parts:
- What you want Scout to do (the action).
- Why you want it (the goal or audience), so Scout can make sensible trade-offs.
- Any non-negotiables (length, format, components to use, things to avoid).
| Less effective | More effective |
|---|---|
| "Fix the homepage." | "On the homepage, rewrite the hero headline and subheadline to lead with our new self-serve pricing message. Target: developers evaluating us for the first time. Keep the headline under 8 words and the CTA copy unchanged." |
| "Translate this." | "Translate the Hero and FAQ sections of this composition into German and French. Leave the other sections in English. We'll handle them in a separate pass next week." |
| "Set up an A/B test on the hero." | "Set up an A/B test on the homepage hero. Variant A keeps the current headline. Variant B uses 'Ship your CMS in a day'. 50/50 traffic split, with variant A as the default." |
Name things explicitly when you mean a specific thing#
Scout will use the currently open entity, locale, and release as defaults. That is fast when you mean "this", but ambiguous when you don't.
- Say "the Pricing composition" instead of "the pricing page" if you have both a composition and a project map node.
- Say "in the German locale" rather than "in German" when you're editing from a different locale.
- Use component, parameter, and pattern names as they appear in your project. Scout matches on names.
One outcome per turn#
Bundling unrelated work into a single turn ("translate this, then add SEO, then create a related blog entry") makes Scout's plan harder to follow, harder to inspect, and harder to roll back if one step goes wrong. Prefer one outcome per turn, and let the thread carry the longer arc.
Batch work across many similar entities is the exception; that's exactly what batch edits are for.
Don't over-specify what Scout already knows#
Scout already knows your content model, your components, your locales, and your AI guidance. You don't need to restate brand voice or component definitions in every prompt; that's what AI guidance and skills are for. Spend the prompt budget on what's specific to this task.
Give Scout the right context#
A prompt is the question; context is the working set. Scout has several ways to take in context, so pick the one that fits.
Use the open editor as context#
When you open Scout from a composition, entry, or pattern, Scout picks up that entity, its locale, and the active release automatically. Saying "this entry" or "translate this to German" works because Scout already knows what you're looking at. See How Scout works with your context.
Attach files and URLs#
For one-off context (a brief, a competitor page, a reference image, a transcript), use attachments or URL attachments. They live with the prompt and don't pollute the rest of the thread.
- Use images for visual references (a layout you're matching, a design crit screenshot).
- Use
.mdor.txtfor briefs, transcripts, or lists you want Scout to follow. - Paste a URL when the source is a public page; Scout's reader strips boilerplate and hardens against prompt injection.
Layer guidance and skills#
Anything you find yourself re-explaining belongs higher up the stack, not in every prompt.
- Put content standards (brand voice, banned phrases, format rules) in AI guidance. It applies to every AI-assisted edit automatically.
- Put repeatable procedures ("how we launch a landing page", "how we run an SEO audit") in skills. Scout loads them on demand when the request matches.
- Keep prompts short and task-specific. If you find yourself typing the same setup paragraph more than twice, promote it.
Reference other content instead of pasting it#
If you need Scout to base new work on existing content, point at it rather than copying it in. "Create a landing page like /marketing/spring-sale but for our summer campaign" gives Scout access to the real entity (including its structure and field values) instead of a flattened paste.
Pick the right apply mode#
The apply mode controls what happens when Scout decides to edit something. Choose deliberately.
| Situation | Recommended mode | Why |
|---|---|---|
| Quick single-entity edits, exploring an idea, iterating on copy | Autonomous | The feedback loop is faster. You see the change immediately and can undo or re-prompt. |
| Batch edits across many entities (translation, SEO, restructuring) | Review changes | The Pending edits dialog lets you inspect each entity before anything is applied. Apply per entity or all at once. |
| Anything inside a release, especially close to launch | Review changes | Reviewing the full set of edits in one place beats catching issues entity-by-entity. |
| First few runs with a new external MCP server | Review changes | You're still learning what the server's tools do. Reviewing edits gives you a chance to spot anything unexpected before it lands. |
| Anything destructive (deletes, large rewrites, schema changes) | Review changes | Pending deletes are surfaced with a soft-destructive treatment. Even if you usually run autonomously, switch for the destructive turn. |
You can switch modes whenever you like. Previously-applied edits stay where they are.
Apply mode only covers Uniform edits
Pending edits and Review changes apply to edits Scout makes inside Uniform. Tool calls Scout makes through an external MCP server run against the external system directly and are not queued for review — once Scout invokes a connected server's write tool, that change happens in the external system right away.
Plan before tackling complex tasks#
For multi-step work (building out a new content type with several patterns, a project-wide rename, restructuring an entire release, setting up a personalization across many components), ask Scout for the plan before they make any edits. A good first turn:
"Don't make any edits yet. Lay out the steps you'd take to [task], including which entities you'd create or modify, in what order, and any decisions you need from me."
Then review the plan, push back on anything wrong, missing, or risky, and only then tell Scout to execute it ("Looks good, go ahead" or "Do steps 1–3 first and stop").
Why it pays off:
- You catch misunderstandings before they become edits. Wrong entity ids, missed steps, ambiguous slots, or bad assumptions are easy to spot in a plan and expensive to spot in a diff.
- Scout follows their own plan more reliably than they reason through an open-ended request, because each step is concrete and already agreed.
- Planning pairs naturally with Review changes. Use the plan as the first checkpoint and the Pending edits dialog as the second.
- It surfaces missing context early. If Scout needs to know your locale strategy, naming convention, or which pattern to use, you'll see those questions in the plan rather than discovering them after the fact.
Skip planning for quick single-entity edits where iterating is cheap. Reach for it whenever you'd struggle to predict what Scout is about to do.
Iterate with Scout, don't fight them#
The first reply is rarely the final answer. Treat each turn as a probe.
Stop early if they're heading the wrong way#
If Scout starts down a path that's clearly wrong, click Stop while they're still generating. It's much cheaper than letting the turn complete and undoing the result. Refine your prompt with the missing constraint and try again.
Refine rather than restart#
If the result is close, follow up in the same thread with a targeted correction:
- "Keep the structure but rewrite the second paragraph in a more conversational tone."
- "Same translation, but skip the testimonials. They're being replaced next week."
- "Move the testimonial section above the feature grid."
That preserves the working context (the entity, the locale, the release) and is usually faster than starting over.
Start a new thread when the goal changes#
If the task is unrelated, open a new thread. Mixing tasks pollutes context, and Scout may keep referring back to the previous entity or carry over assumptions you've moved past.
Use suggested replies as nudges#
The suggested replies under Scout's messages are a good "what's next?" prompt when you're not sure. Treat them as suggestions, not commands; type your own if none of them fit.
Work safely with edits, deletes, and external systems#
Review before you publish#
All Scout edits land as drafts; nothing publishes itself. Before publishing or releasing:
- Skim the activity rows to see what Scout actually did, not just the summary they wrote.
- In Review changes mode, expand the per-field diff in the Pending edits dialog, especially for localized fields and rich text, where surface-level summaries hide formatting changes.
- For batch edits, spot-check 2–3 entities at random instead of trusting that "the first one looked fine".
Be intentional about deletes#
Scout surfaces pending deletes with a red treatment and a deliberate Apply delete button; they are never one-click. If you don't recognize a delete in the dialog, discard it and ask Scout to explain what they were trying to do.
Scale up: skills, guidance, and batch work#
Promote anything you do more than twice#
The clearest signal that something belongs in a skill or in AI guidance is repetition. Some heuristics:
- "I always have to remind Scout to use sentence case." → AI guidance, project level.
- "Every translation request needs the same five rules." → Skill, on-demand, triggered by "translate".
- "We always create landing pages from the same pattern with the same first three sections." → Skill, on-demand, triggered by "create a landing page".
- "Our SEO definition of done is the same every time." → Skill, always-included.
Calibrate strictness to risk#
Match how prescriptive you are to how fragile each step is.
- Be strict about things that are risky or irreversible: slug formats, OG image dimensions, naming conventions, required SEO fields.
- Leave room for judgment where multiple approaches are valid: headline phrasing, ordering of optional sections, illustrative copy.
This applies to prompts, skills, and guidance alike. Over-constraining Scout produces wooden output; under-constraining them produces inconsistent output.
Use batch edits, then review#
For repetitive work across many entities ("add an SEO description to every product page", "translate all blog entries into French"), prefer a single batch prompt over running the same prompt 30 times. Combined with Review changes, the Pending edits dialog groups everything by entity so you can apply or discard per-entity without losing your place. See working at scale.
Organize your threads#
Threads are cheap. Use them.
- One thread per task. Unrelated tasks deserve their own thread so context stays clean.
- Keep follow-ups in the same thread. Continuing a task preserves the working context: the entity, locale, release, and any reasoning Scout has built up.
- Pin Scout when you're going to be moving between editors and dashboards on the same task; unpin them when you want the full workspace back.
- Remember that only the active thread runs. Scout doesn't process other threads in the background.
Debug when something goes wrong#
Even with good prompts, Scout occasionally surprises you. A short triage routine before you escalate:
- Re-read the activity rows. Scout almost always tells you what they did. Look for an unexpected tool call or a step that operated on the wrong entity.
- Open the activity inspector on the suspicious step. The raw input/output JSON usually shows exactly why: wrong locale, wrong entity id, an ambiguous slot, a missing field.
- Check your context. Was the right entity open? The right locale selected? Were you inside the release you thought you were in? See How Scout works with your context.
- Give targeted feedback. Thumbs-down with a comment tells the team building Scout exactly what went wrong on that reply. It's the fastest path to fixing systemic issues.
- For reproductions, share the thread data. From the chat's manage menu, Download thread data captures the full thread (as JSON). Attach it when you reach out to Uniform support.
If you find yourself correcting Scout the same way more than twice, that's a signal. Fold the correction into AI guidance or a skill so you don't have to keep saying it.