# Writing effective requests

Neo can infer missing details, but explicit direction improves reliability. The best request is not the longest one; it is the one that makes success and important boundaries clear.

## Include five things

1. **Goal** — what should be true or exist at the end.
2. **Context** — why it matters, who it serves, and the current state.
3. **Inputs** — files, links, examples, facts, or prior work to use.
4. **Constraints** — length, tone, deadline, allowed sources, exclusions, and permissions.
5. **Output** — format, sections, level of detail, and validation needed.

### Before and after

Weak:

> Write a launch plan.

Stronger:

> Draft a four-week launch plan for a small B2B product team. Use the attached positioning notes. Include owners, dependencies, risks, and weekly milestones in a table. Exclude paid media. Flag missing inputs instead of inventing them.

## Ask for the right mode

- **Answer:** “Give me the short answer first.”
- **Teach:** “Explain this progressively, with an example and a short quiz.”
- **Research:** “Use primary sources where possible and cite every material claim.”
- **Decide:** “Compare the options against these criteria and recommend one.”
- **Create:** “Draft the deliverable, then list assumptions and review questions.”
- **Execute:** “Work through the steps, report blockers, and verify the result.”

Combining modes can help: research first, then recommend; inspect first, then edit; draft first, then review.

## Define acceptance criteria

Acceptance criteria turn a preference into a check. Examples include:

- required files, sections, fields, or table columns;
- a maximum word count or reading level;
- tests, calculations, or links that must be checked;
- approved sources or a freshness cutoff;
- details that must remain unchanged;
- actions Neo must not take without approval.

For a long task, ask Neo to restate the criteria before starting.

## Set boundaries clearly

Use direct language:

> You may edit the three files in `/docs`, but do not change application code.

> Draft the email, but do not send it.

> Use only the attached policy as the source of truth. Mark anything it does not answer as unknown.

Boundaries matter most for destructive, external, private, or irreversible actions.

## Supply examples thoughtfully

An example can clarify voice, structure, or quality. Say what should be copied and what should not:

> Match the level of detail and heading structure in this example. Do not reuse its claims or company names.

## Handle uncertainty

Invite honest limits instead of confident guesses:

- “State what you could not verify.”
- “Separate facts, interpretations, and assumptions.”
- “Give a confidence level and explain what would change it.”
- “Ask before proceeding if a missing detail changes the recommendation.”

## Break down complex work

For multi-step requests, use milestones:

1. inspect the inputs;
2. summarize the current state;
3. propose a plan;
4. execute approved work;
5. validate against the criteria;
6. report changes and open questions.

This creates review points before mistakes spread through the rest of the task.

## Reusable template

> **Outcome:** [final result]  
> **Audience/context:** [who and why]  
> **Inputs:** [sources and source of truth]  
> **Scope:** [included and excluded]  
> **Constraints:** [style, timing, permissions]  
> **Output:** [format and detail]  
> **Acceptance criteria:** [checks for success]

Use only the fields that matter. A clear two-sentence request is better than a long template filled with vague language.