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.