BASIC is the shortest practical shape of the Gaiish method. It asks four questions: what are you trying to achieve, what does the model need to know, what should it do, and what should come back? You can write the answers in four labelled blocks or use the questions as a quick check before you press send.
The four parts
- Goal
- The outcome behind the request. Name the decision, change or deliverable, and say who will use it when that changes the answer.
- Context
- The situation and source material the model cannot infer. Paste the document, describe the audience, and include the relevant facts already known.
- Action
- The primary verb: draft, compare, extract, explain, plan or rewrite. If the work has an order, number the actions.
- Output
- The artefact you expect back. Name its format, sections, length or fields so the result can be used without another round of guessing.
When BASIC is enough
Use BASIC for a self-contained task with a clear audience and a result you can inspect yourself: turning notes into an email, summarising a meeting, planning a weekend, or asking for first-pass ideas. It is deliberately light. It gives the model the purpose, the missing background, the verb and the shape of the answer without making a small request feel like a specification.
BASIC is not a lower standard of thinking. It is a decision about how much structure the task needs. Move to the full method when you need explicit constraints and validation; move to PRO when role, knowledge boundaries, process or handoff matter.
Example 1 — a meeting summary
Summarise these meeting notes.
GOAL: Give the project sponsor a concise record of decisions and next actions. CONTEXT: [paste the meeting notes] The sponsor did not attend. The team has a launch review on Friday. ACTION: Extract decisions, open questions and actions from the notes. OUTPUT: Use three headings: Decisions, Open questions, Actions. For each action include an owner and due date only when the notes name one.
Why this works better
The conversational version names a topic but not a use. BASIC supplies the absent audience, the reason the summary matters, the categories to extract and a rule for missing ownership. That gives the model a useful stopping point and makes omissions visible to the reader. It can improve instruction adherence and reduce ambiguity; it does not guarantee a correct summary.
Example 2 — a customer email
Write a nice email telling customers about the delay.
GOAL: Help customers understand the delayed shipment and choose whether to wait or cancel. CONTEXT: Orders placed 3–10 June are delayed by a warehouse issue. The new estimate is 18 June. Customers can cancel for a full refund. Audience: people who have already received an order confirmation. ACTION: Draft a customer email that explains the delay and presents both options plainly. OUTPUT: Subject line plus a 120-word email. Put the new date and cancellation option in the first two paragraphs. Use a calm, accountable tone.
Why this works better
“Nice” leaves the model to invent the situation, remedy, tone and length. The BASIC version supplies the facts a customer needs, tells the model what decision the email must support and puts the important information where it belongs. The instruction is still small enough to write in a minute, but the result is reviewable against the brief.
A BASIC prompt in four lines
GOAL: State the outcome and who will use it. CONTEXT: Paste the material and name the situation. ACTION: Use one clear primary verb. OUTPUT: Name the artefact, format and useful limits.
Write it down with Gaiish SyntaxTry the Prompt BuilderBrowse more examplesUse the Prompt Library