Writing effective recipes

A recipe is a set of instructions you write once and get the same shape of output from every time. The shorter the instructions, though, the more the output varies. This article covers how to build the instructions, which specifications matter most when writing in Japanese, and how to test and refine them — ending with examples you can save and use as they are.

#Decide the shape first

Recipes are either for “a single meeting” or for “several meetings”, and which you are building changes how the instructions are written. The difference, and how to choose, are in the creation steps in Recipes (saved instructions).

What matters when writing is that the input your instructions assume matches the input actually supplied. Instructions that say “this meeting” in a recipe for several meetings leave it unclear which meeting is meant, and the output becomes unstable. Conversely, “compare the meetings with each other” in a single-meeting recipe has nothing to compare against. For several meetings, open with something that assumes a set, such as “from the records of the selected meetings”.

#The basic structure of an instruction

For consistent output, this order is easiest to work with.

1. Define the job: start by saying who uses the document, in what situation, and for what. Naming the reader settles the tone and the level of detail.
2. Background: write in the information you would otherwise explain every time — company, product, team structure, the history of a project.
3. Rules: list the conditions you want observed. This is the main thing that keeps the output from drifting.
4. Output format: specify the order of headings, the table columns, the number of items, and the length of each.
5. Example output: where the format matters, paste in a real example, however short.

An example opening:

A meeting has just finished and a follow-up email to the attendees is needed.
Your job is to write an external-facing email setting out the decisions and
next actions. The readers are the client contact and their manager.

When writing rules, imagine you are addressing someone who has just joined. Assumptions that are second nature internally do not carry across unless you write them down. Expressions such as “in the usual format” or “summarise appropriately” mean different things to different people, and do not work as instructions.

#Tips for instructions in Japanese

Japanese documents involve many formal choices that English does not. Unless you specify them, a different choice is made every time, so set them down as rules in the recipe.

#Specify polite or plain form

State whether to write in polite form (desu/masu) or plain form (da/de aru). Without it, the two can end up mixed within a single document. Deciding by purpose — polite form for external documents, plain form for internal records and analysis notes — removes the question.

You can specify the degree of honorific language too. Rules such as “do not use doubled honorifics” or “do not overuse sasete-itadaku” make external text easier to read.

- Write in polite form (desu/masu).
- Avoid excessive honorifics. Use “sasete-itadaku” at most once per email.
- Write only the internal note at the end (the remarks section) in plain form.

#Standardise internal terms and loanwords

Where more than one word refers to the same thing, specify which to use. Decide too whether to use a katakana loanword or its Japanese equivalent.

- Standardise on the following:
  “顧客” (do not use “クライアント” or “お客さん”)
  “持ち帰り事項” (do not use “ToDo” or “アクションアイテム”)
  “見込み案件” (do not use “パイプライン”)
- Include the long vowel mark (“サーバー”, “ユーザー”).
- Expand internal abbreviations (such as short names for meetings) to the
  official name before writing.

#Keep proper nouns consistent

In speech, company and personal names get shortened, and transcription of them varies. Writing the correct form into the instructions makes them consistent in the output.

- Write company names in full. Do not drop the position of “株式会社”.
  e.g. “〇〇商事” → “株式会社〇〇商事”
- Add the honorific “さん” to personal names, and do not also give job titles.
- Replace product names referred to by short forms during the meeting with
  the official names below.
  “新版” → “〇〇 2.0” / “旧システム” → “〇〇 販売管理”
- Where the correct form of a proper noun cannot be confirmed, quote it as
  spoken rather than guessing, and append “【表記要確認】”.

Proper nouns that recur during meetings are better registered in the dictionary at the transcription stage, which saves correcting them in the instructions. How to set that up is in Customising transcription.

#Decide the granularity of bullet points

Without a specified granularity, bullet lists end up mixing one-line items with long paragraphs. Decide the number of items, the characters or sentences per item, and how deep the nesting goes.

- Use a single level of bullets; do not nest.
- Keep each item to one sentence, within 60 full-width characters.
- Use between three and seven items. Beyond seven, break with a heading.
- Do not end on a noun; write the full predicate.

#Decide the format of numbers and units

Specify the format for amounts, periods, headcounts and dates to match your internal documentation standards.

- Use half-width numerals with a separator every three digits (1,200,000円).
- Append “円” to amounts and always state whether tax is included. Where the
  meeting did not say, write “（税区分の記載なし）”.
- Write dates in the form “2026年4月1日”, with the day of the week in brackets.
- Write periods in the form “4月1日〜4月30日”.
- Use “%” for proportions, to one decimal place.
- Do not supply figures that were not stated in the meeting, or estimate them.

#Make it lead with the conclusion

Japanese meetings often work through the background before arriving at a conclusion, and summarising them as they stand puts the conclusion at the end. Where the reader is a decision-maker or a busy manager, specify the order explicitly.

- Put a “結論” heading at the top with the conclusion alone, in no more than
  three sentences. Do not put background or preamble before it.
- Follow the conclusion with “理由”, in no more than three points.
- Put the history and the detail of the discussion in a later “補足” section.
- Where the meeting did not settle on a conclusion, write “未確定” under the
  “結論” heading and give the reason in one sentence.

#Write the background once

The advantage of a recipe is that you can write in the background you would otherwise explain every time. Including the following keeps the quality of the output steady.

• what your company does and who its main customers are
• product names, feature names, and the terms used internally
• for a development team, the languages and architecture in use
• your own role and what you want this document to achieve
• colleagues' names and what they are responsible for
• the background and history of each project

Another approach is to create a “company background” recipe containing only that context, run it at the start of a chat, and then use other recipes in the same thread.

#Include an example of the output

For documents where the format matters, pasting in one real example is more reliable than listing rules. Paste an email you wrote previously, the format of your internal minutes, or the heading structure of a report straight into the instructions.

Follow this format exactly.

---
件名: 【〇〇案件】本日の打ち合わせの御礼と確認事項

株式会社〇〇
〇〇様

お世話になっております。〇〇株式会社の〇〇です。
本日はお時間をいただきありがとうございました。

本日決定した事項は以下のとおりです。
・（項目）
・（項目）

次回までの宿題は以下のとおりです。
・弊社: （内容）（〇月〇日まで）
・貴社: （内容）（〇月〇日まで）

引き続きよろしくお願いいたします。
---

#Work within the data available

A recipe can only see the meeting data stored in Pulse and the material you attach. The scope is described in detail in Asking your notes questions (chat).

What causes trouble when writing instructions is assuming information outside that scope. Asking it to “list the outstanding tasks”, for instance, will not work, because it cannot tell which are already finished. Unless someone said in the meeting that something was done, there is nothing to distinguish them by. Attach whatever material is needed, and include a rule against filling in what is not in the record.

- Do not write anything that is not in the meeting record.
- Where something is unclear, write “記録なし” and do not fill it in.
- Do not supplement explanations with general knowledge.

#Try it and fix it

Instructions are never finished in one go. Accuracy improves by writing, testing, finding where it broke down, and adding a rule to prevent that.

Choosing “Preview” on the recipe editing screen runs it against one meeting or folder as a test. Look at the result, fix the instructions, run it again, and you can compare the effect of the change on the spot.

FigureScreenshot: preview on the recipe editing screen

The instructions field on the left, the test run's result on the right, and a field at the top for choosing the meeting to run against.

#Differences between models

Even with the tone specified in the instructions, output tendencies vary by model. The longer and more complex the document, the more the reasoning model suits; for a quick check during a meeting or a routine list, the standard model means less waiting. What you can specify and how to choose are in Choosing an AI model. Try the same recipe on both models and pick whichever is closer to your own documents.

#Examples: for a single meeting

Instructions you can save and use as they are. Rewrite company names, department names and assessment criteria to match your own situation. Each is structured the same way: explain the purpose at the top, list the rules to observe, then specify the output format at the end.

#Formatting minutes for internal circulation

Produce minutes for internal circulation. The readers are members of the same
department who did not attend, and their manager.

Rules:
- Write in polite form (desu/masu).
- Put “決定事項” first, then “議論の要点” and “持ち帰り事項” in that order.
- Under decisions, write only what was actually decided. Proposals still under
  consideration go under the discussion points.
- Make the take-aways a three-column table: owner / item / deadline. Where no
  deadline was stated, write “未定” rather than inventing a date.
- Use the form of speakers' names used in the meeting (honorific “さん” throughout).
- Write amounts with half-width numerals and “円”, and dates as “YYYY年M月D日”.
- Do not write anything not discussed in the meeting. Where unclear, write “記録なし”.

Output format:
## 会議名 / 日時 / 出席者
## 決定事項
## 議論の要点
## 持ち帰り事項（表）

#Turning sales notes into a daily report

From the record of this sales meeting, produce text to paste into the sales
daily report. The reader is my manager.

Rules:
- Write concisely in plain form (da/de aru). No more than two sentences per item.
- Always produce these headings, in this order: 訪問先 / 面談者 / 目的 /
  先方の反応 / 課題 / 次のアクション.
- Base the customer's reaction on what was said, not on my inference. Where
  nothing was said on a point, write “言及なし”.
- For likelihood of winning and amounts, write only figures the customer
  stated. Do not write our own projections.
- Include our owner and the planned date under next actions.

#Drafting a visit report email

Draft an email thanking them for today's meeting and confirming what was
discussed. The recipients are the attendees from the other company.

Rules:
- Output in the order subject, salutation, body, closing.
- Write in polite form. Do not use excessive (doubled) honorifics.
- Open with one sentence of thanks and get to the point. No more than three
  lines of preamble.
- Summarise what was decided as three to six bullets, one line each.
- Separate what we will do from what we are asking of them.
- Give an explicit date for any request with a deadline. Where the meeting
  gave no date, write “【要確認】” and leave it blank.
- This goes outside the company, so use official names rather than internal
  abbreviations or nicknames.

#A report for the department head from a weekly meeting

A longer example, with the background and rules written out in full.

The weekly departmental meeting has just finished. Your job is to produce,
from the record of this meeting, the weekly report submitted to the department
head, who did not attend.

Background:
- This department handles B2B order processing.
- “案件” means a deal before it is won; “契約” means one already signed.
- There are three owners (Tanaka, Sato, Suzuki).

Rules:
- Write in polite form.
- Open with “今週の結論” in no more than three sentences. Do not put the
  background first.
- Then use the headings “進捗”, “懸案” and “来週の予定”, in that order.
- Use bullets under each heading: one sentence per item, within 60 full-width
  characters, three to seven items.
- Half-width numerals; amounts with thousands separators and “円”, stating the
  tax treatment.
- Write dates in the form “2026年4月1日”.
- Add “さん” to personal names. Write company names in full.
- Do not supply figures or projections that were not stated in the meeting.
  Where nothing was said, write “言及なし”.
- For each concern, state the owner and whether a decision is required.

#A review of a one-to-one

Organise the record of a one-to-one I held as the manager into a review for
next time. This will not be shared with the other person.

Rules:
- Clearly separate “what they said” from “my impression”. Always mark the
  impressions with “（解釈）”.
- Quote what they said they were struggling with, close to their own words.
- Where they mentioned changes since last time, pull those passages out.
- Finish with two or three lines on whether I talked for too long, and on the
  balance between questions and explanation.
- Do not write anything amounting to a performance or HR judgement.

#A recruitment interview scorecard

From the interview record, draft a scorecard. This is for a mid-career sales
hire.

Rules:
- Use four criteria: 経験の適合 / 課題解決の進め方 / 顧客との関係構築 /
  入社後に想定される立ち上がり.
- For each, quote one or two things the candidate said as evidence, then give
  two or three lines of assessment. Quotes should follow what was actually
  said rather than paraphrasing the gist.
- Where nothing relevant was said, write “確認できず” and propose one question
  to ask at the next interview.
- Do not write a hire/no-hire decision. Do not touch on age, family
  circumstances, place of origin or anything else that must not form part of
  the selection criteria.

#Examples: for several meetings

In recipes covering several meetings, include an instruction to keep a record of which meeting each statement came from, so you can trace back to the original note later.

#A summary to attach to an approval request

From the records of the selected meetings, produce a summary of how the matter
was considered, to attach to an approval request. The reader is the approver,
who attended none of the individual meetings.

Rules:
- Give the conclusion first, in one paragraph of no more than three sentences.
- Then set out “検討の経緯” chronologically, each item beginning with the date
  of the meeting.
- Present “検討した選択肢” as a table with the columns 案 / 主な利点 /
  主な懸念 / 会議での扱い.
- For amounts, periods and headcounts, give only figures stated in the
  meetings, with the date of the source meeting in brackets.
- End with the unresolved points as bullets.
- Do not supply conjecture or general observations. Do not write anything that
  is not in the record.

#Building an incident timeline

From the records of the selected meetings, produce a timeline of the incident
response. The readers are the development and operations teams, who were not
involved in the response.

Rules:
- Organise it into five parts: 検知 / 一次対応 / 原因の切り分け / 恒久対応 /
  未完了の作業.
- Format each line as 時刻 / 事象 / 誰が対応したか. Where no time was stated in
  the meeting, write “時刻不明” and preserve only the ordering.
- Separate confirmed facts about the cause from hypotheses. Mark hypotheses
  with “（仮説）”.
- Put the preventive measures agreed in the meeting into a table with owners
  and deadlines.
- Do not write anything assessing individual responsibility.

#Organising customer requests for product development

From the records of the selected customer meetings, organise the requests made
of the product. The reader is a product developer who did not attend the
meetings.

Rules:
- Write in plain form.
- Classify requests into four: 機能の追加 / 既存機能の改善 / 不具合の指摘 /
  運用上の相談. Leave anything that fits none of them unclassified.
- For each request, always give:
  customer name (official) / the gist of what was said / the date of the
  meeting it was said in / the reason the customer gave
- Where the same request comes from several customers, combine it into one
  item and list the customer names together.
- Do not apply your own prioritisation. Order simply by how often each came up.
- Do not guess at feature names or specifications that do not appear in the
  record.

#If something is not working

The format changes every time you run it

Either the output format is not specified, or the specification is abstract. Write the heading names and order, the table columns, the number of items and the length per item as concrete figures.

Some of the rules are not being followed

Where the rules are very long, instructions towards the end can be applied less reliably. Move the important rules to the top, or split the recipe in two and run them in stages.

Expressions that should not leave the company appear

State a rule replacing internal abbreviations and nicknames with official names. In recipes for external use, include a rule saying “do not output names used only internally”.

I want different conditions per project

Recipes do not support variables, so create separate recipes with the conditions written in. For details see Recipes (saved instructions).

#Related articles