AIYING • V1.0 REGULAR VIEW
CLAUDE COMPLETE • POST #04
How to Give Claude a Clear Task
Define the result, supply useful context and make success checkable.
By Ravindra Dastikop
You upload a proposal and ask Claude: “Improve this.”
The result is more polished. But what did you want improved? The language, the scope, the commercial terms or its alignment with the client’s latest feedback?
A fluent revision can still miss the task. Before adding more instructions, identify what a useful result would actually look like.
1. A prompt is a working brief
A prompt is the instruction or request you give Claude. It can be a single sentence or a structured brief.
A simple task may need very little explanation:
Rewrite this paragraph in plain English for a first-year student. Preserve the technical meaning.
A task involving conflicting documents, financial commitments or external actions needs more context and clearer boundaries. Length alone is not a measure of prompt quality.
2. Six useful elements of a task brief
The following checklist is an AIYING synthesis. Use the elements that matter for the task.
| Element | Question to answer |
|---|---|
| Outcome | What should be accomplished? |
| Context | Who is this for, and why is it needed? |
| Inputs | Which sources should inform the work? |
| Output | What form should the result take? |
| Boundaries | Which constraints, permissions and uncertainties matter? |
| Checks | What evidence would make the result acceptable? |
3. Worked example: revise a client proposal
In our fictional consulting engagement, the original proposal contains a six-week delivery schedule. Meeting notes record a request for four weeks. An approved decision document confirms a five-week schedule with reduced scope.
“Update the proposal using the latest feedback” leaves an important question unanswered: which source establishes the commitment?
A clearer brief could read:
Task: Prepare a revised client proposal draft reflecting approved changes.
Context: I am the consultant preparing the draft for internal review before client submission.
Inputs: Use Original_Proposal, Meeting_Notes and Approved_Decisions. For changes explicitly covered by Approved_Decisions, use that document as the authority. Treat meeting requests without recorded approval as unresolved.
Outputs: Provide a revised proposal draft, a change log and a list of unresolved questions. In the change log, identify the supporting document and section for each material change.
Boundaries: Preserve original terms unless an approved change supersedes them. Flag contradictions within the approval record. Leave unsupported commercial decisions unresolved. Keep the original files unchanged and do not send the proposal.
Checks: Verify the scope, fee and delivery schedule against the approval record. Report missing evidence and any checks you could not complete.
This brief makes the desired result easier to assess. It does not guarantee that Claude will interpret every source correctly.
4. Define the evidence, not just the tone
Instructions such as “be professional” can help with presentation. They do not establish factual accuracy.
For source-based work, ask for evidence that a reviewer can inspect:
- The document and section supporting a material change.
- A clear distinction between source facts and suggestions.
- Conflicts or missing information that remain unresolved.
- A record of checks completed and checks still needed.
Then inspect the cited material yourself. A source reference can be incorrect or fail to support the associated claim.
5. Add an example when words leave room for interpretation
Anthropic recommends relevant examples to clarify expected behavior and output. For our fictional change log, one example might be:
| Item | Original | Revised | Evidence |
|---|---|---|---|
| Delivery | Six weeks | Five weeks | Approved_Decisions, delivery section |
This row is illustrative. If you include a fictional example in a real prompt, label it clearly so its values are not mistaken for facts about the engagement.
6. State what to do with uncertainty
“Ask questions if needed” leaves considerable discretion. Identify the gaps that would materially affect the result.
If missing information would change the scope, price or delivery commitment, list the question before finalizing that section. Complete supported sections and mark the unresolved ones clearly.
This lets useful work proceed while preserving decisions that require your attention.
7. Give feedback that points to the defect
If the result is wrong, identify the mismatch between the brief and the output.
The draft uses the four-week request from the meeting notes. The approved decision specifies five weeks. Correct the delivery section and check the remaining dates for the same error. Report any conflicts you find.
Specific feedback gives the next revision a clear target. Retain the original acceptance criteria when reviewing the correction.
8. Reusable task brief
TASK Accomplish: [specific outcome] CONTEXT Audience and purpose: [who needs this and why] INPUTS Use: [documents, data or authorized sources] Source priority, where relevant: [which source governs which decision] OUTPUT Return: [deliverables, structure and level of detail] BOUNDARIES Respect: [constraints and action permissions] Handle missing information by: [clarification, flagging or stated assumptions] CHECKS The result is acceptable when: [observable criteria] Provide: [supporting evidence and remaining limitations]
Shorten this brief for simple requests. Add detail where ambiguity would affect the result. A prompt cannot supply unavailable tools, grant technical permissions or replace enforced access controls.
9. Your practical accomplishment
- Choose one task you expect to perform this week.
- Write your usual request.
- Revise it using the task brief.
- Identify three observable acceptance criteria.
- Try the revised request with non-sensitive sample material.
- Check the output and record one remaining weakness.
Your accomplishment is a usable task brief and an inspected result. If you compare versions, record the model, inputs and conditions. A single comparison is an observation, rather than proof of a general improvement.
Continue with Claude Complete
- Previous: #03 — Models, Plans and Usage Limits Explained
- Start here: #01 — A Map of the Claude Ecosystem
- Next planned post: #05 — Context, Memory, Instructions and Projects: What Carries Forward?
