Cursor Agent Course: Advanced Precision Edition. Become an Agent Master with Rules Techniques!

Hello everyone! I'm miyatti, the Generative AI Evangelist at X-Plaza! Man, it's really all about Cursor lately, isn't it!!!!

Thanks to you all, the Cursor Agent Super Introductory Course has received over 1,000 likes, which is more than I've ever seen for anything I've written, and I'm truly grateful. It really makes me realize how hot Cursor is right now!!!!!!Wait, that was the second part.

So, this time, as a sequel to the previous article, AI Supports Project Management and Stress! Cursor Agent Course for Non-Engineers: Practical Edition

I want to share, in a very geeky way, more authentic and concrete ways to write the Cursor Rules feature that I introduced last time!!!

Just by starting to use Rules, I showed you how you can make it work in various ways, such as "Task Management Mode" or "Idea Generation Mode." However,

I'm sure many of you are asking that. This time, I want to teach you how to write Rules—specifically, how to write them so they are incredibly precise and make the agent act exactly as you intend. The key is writing in "YAML format"!!

By just "writing it structurally" using this YAML format, the AI agent will work reliably without getting sidetracked more than you might think.

※ Well, this time it's a bit of a hard mode difficulty!!!! But I'm trying to write it very carefully for beginners, so if you'd like, please read it to the end.

What is YAML? Simple writing methods

● YAML is a "human-friendly" markup language

YAML stands for "YAML Ain’t Markup Language." (What does that even mean?)

Well, simply put, it's a format for writing cleanly so that AI can easily understand it. If you know a little bit, just think of it as a sibling to JSON or XML. Its features include:

• Expressing hierarchy using only line breaks and spaces (indentation).

• Because it doesn't use tags or brackets (like XML or JSON), it is easy for humans to read.

For example, here is an example:

menu: カレー
people: 4
steps:
  - name: buy_ingredients
    message: "食材を買いに行きましょう"
  - name: cook
    message: "カレーを煮込みましょう"

It is a style where you write the content for categories (item names) like "menu" or "people."

Some of you might have gone "ugh" when you saw this, but it just says, "The menu is curry, there are 4 people, and the steps are: a step to go buy ingredients, and a step to simmer the curry."

For simple data structures, it is easy to understand exactly what is written, so its strength is that it is surprisingly easy to handle even if you have no programming experience.

Now, here is a simple (?) way to write it. (*If you just want to get a feel for the theoretical side of agent construction, you can skip this part.)

● Introduction to Super Simple YAML Writing

1. First, a super short example

# これはコメントです（行頭に # があると無視されます）

氏名: "鈴木太郎"    # “氏名”という項目に "鈴木太郎" を指定
年齢: 28            # 年齢という数値項目には 28 と記入
好物:
  - "ラーメン"       # リストの書き方：項目名の下に「-」で並べる
  - "カレー"
  - "寿司"

• Item Name: Content Write it in this format

• If you want to write something like a list, start with a - (hyphen)

2. Expressing "groupings" with hierarchical structures

The strength of YAML is its ability to express "hierarchies."
For example, if you are managing "employee" data for a company:

従業員:
  鈴木太郎:
    部署: "営業部"
    年齢: 28
    スキル:
      - "コミュニケーション"
      - "Excel分析"
  
  佐藤花子:
    部署: "開発部"
    年齢: 32
    スキル:
      - "プログラミング"
      - "UIデザイン"

「Employees」 Create groups called "Taro Suzuki" and "Hanako Sato" inside it, and attach information to each.
You don't need to create rows and columns like in Excel; you can represent it hierarchically using only text.

3. Line breaks & indentation are life

In YAML, the "number of spaces" and "position of line breaks" determine the structure.
Lower levels are written by adding a certain number of spaces to the left.

住所:
  都道府県: "東京都"
  市区町村: "新宿区"
  番地: "1-1-1"

• It seems that using 2 spaces for lower levels is the standard

● You can also write YAML in Cursor's Rules files

Did you understand how to write it? Is it difficult?

Well, if you get stuck, just tell Cursor "Make this look like a nice YAML" and it will do it for you, so let's get started.

Cursor uses files with the .mdc extension, which are based on Markdown, but rest assured that it will recognize it without any issues even if you write YAML (in fact, the MDC file format itself is an extension of MD files that is also intended to be written in YAML).

As a tip, if you write it like this inside an MDC file, it will be displayed with color-coding as YAML, which is convenient (it will work even if you don't write it this way).

At first, you might think "Hmm? This looks like programming..." and be on your guard, but as long as you don't make mistakes with a few simple rules, it's not that difficult.

Once you get used to it just a little bit, you should be able to be moved by the thought, "The AI will move on its own just by doing this!"

Do I really need this much "YAML"? Isn't natural language enough?

Well, to be honest, I'm going to talk about something extremely tedious this time, but that's how it is, so well

I imagine many of you think that.

Actually, this is closely related to the characteristics of AI agents. For humans, it seems easier to just convey things in natural language, like "Do this, and when you're done, do that." However, AI often misinterprets things when given only natural language.

1) AI is seemingly good at natural language, but actually struggles with it

With the recent ChatGPT boom, you might feel that "AI understands everything," but in reality, it has weaknesses when it comes to vague instructions. Especially in situations involving sequence or conditional branching, the following types of confusion tend to occur:

• Changing the order of questions on a "whim"

• Deciding "this task is finished" and moving on without waiting for user confirmation

• Arbitrarily omitting information, thinking "this is probably unnecessary now"

As a result, "interpretation gaps" frequently occur, such as skipping steps that should have been followed.

2) It excels at "structured" instructions

This is where specifying "step-by-step rules using YAML" becomes effective. If you write out the flow in a structured format like
"Ask this here, and if this condition is met, do that next", the AI barely has to perform the ambiguous task of "interpretation," making it easier for it to act consistently.

If you write it in YAML format in an MDC file, it will proceed with tasks in almost the same order and follow the same confirmation steps every time you use it, reducing the inconsistencies found in simple prompts.

Simple Prompt vs. YAML Example

For example, let's compare how much the actual writing method differs using the example of preparing dinner.

Example: When preparing dinner

Simple instructions (somewhat unstable)

ユーザーから夕食のメニューと人数を聞いて、 
それから調理時間と食事時間を聞いて、
計画を立てて。 
それが終わったら確認を求めて、
OKなら買い物リストと手順書を作って。

At first glance, it looks clean and convenient enough that you might wonder, "What's the problem?" However, because there is so much room for
AI interpretation to enter, the following situations tend to occur:

• Arbitrarily deciding "it'll probably be OK anyway" and proceeding to create files

• Skipping the question order, asking for the number of people without asking for the menu (or vice versa)

• Skipping user confirmation and entering the next phase

As a result, “Wait, the budget was set before the menu was even decided...” and other unintended workflows tend to happen. Writing simply feels more “human-friendly,” but the AI will
process it while it remains ambiguous.

YAML format (stable)

- name: "ask_menu"
  action: "ask_question"
  question: "今日の夕食メニューを教えてください"
  variable: "dinner_menu"

- name: "ask_people"
  action: "ask_question"
  question: "何人分を作りますか？"
  variable: "people_count"

- name: "confirm_plan"
  action: "confirm"
  message: "こんな献立でいいですか？"
  variable: "plan_ok"

- name: "create_recipe"
  action: "create_file"
  ...

On the other hand, if you write it clearly step-by-step in this YAML format, you can
“not skip the order,” “not proceed without confirmation,” and “ensure file creation is done at the end”

—strict flows like these can be
stably reproduced.

When you actually run it in this form,

1. it will always ask for the menu

2. then it will ask for the number of people

3. and automatically generate the recipe file after getting the user's OK
   —because it follows this procedure the same way every time, the risk of it going completely off-track is significantly reduced.

Hands-on: Creating Rules from scratch in YAML format

For those creating Rules for the first time, “where should I start?” might be the biggest hurdle. Here, as usual, let's do a hands-on. Using a

simple “Dinner Prep Agent” as our subject, I will explain the procedure for building an MDC file written in YAML from the very basics. In other words, let's experience together the flow of creating an “AI assistant that supports you just by asking it to prepare dinner.”

It's a short example, but once you grasp these steps, you should suddenly get the idea: “Oh, so that's how you write an MDC file!”

※ Please refer to the previous practical article for how to actually create Rules in Cursor!

Now, I will first demonstrate how the agent actually moves with this rule.

For those who want to try running it themselves, I have published the completed Rules on GitHub, so I recommend trying to run them in Cursor on your own machine.

How to use

1. You can easily set it up from a new Cursor window:

   • Launch Cursor and select “New Window”

   • Select “Clone repo” and enter the URL of this repository

   • When the folder selection UI appears, tap the “Select as repository destination” button at the bottom right

2. Open the Chat panel and type “Dinner preparation,” and the interactive dinner planning will begin

3. The newly created project will be saved in the Dinner folder

So, to understand how Rules (MDC files) written in YAML guide actual conversations, let's look at an example of an actual dialogue. Below is an interaction using the dinner preparation agent we created:

1. Information Gathering Phase

User: 夕食の準備をお願いします

Cursor: 夕食の準備をするにあたって、質問させてください。
今日の夕食のメニュー名を教えてください（例：カレーライス、パスタ、焼き魚定食など）

User: カレーです

Cursor: 食事人数は何名ですか？

User: 4人（大人二人子供二人

Cursor: 調理予定時刻はいつ頃ですか？（例：18:00）

User: 20時ぐらい

Cursor: 食事予定時刻はいつ頃ですか？（例：19:00）

User: 21時ぐらい

Cursor: 予算はいくらくらいですか？（例：2000円）

User: 特に決めてないけど、そこまで高くない感じで

Cursor: 食事で避けたい材料はありますか？（アレルギーなど）

User: ないです

Cursor: その他の要望はありますか？

User: ないです

In this part, the question set defined in the rules is executed in order. The effect of the 'question set separation' technique, which I will explain later, is clearly visible here, as the MDC file asks a series of questions in sequence and collects the user's answers.

2. Confirmation and Plan Generation Phase

Cursor: 以下の内容で夕食準備プロジェクトを開始します：
- メニュー: カレー
- 人数: 4人（大人二人子供二人）
- 調理時間: 20時ぐらい
- 食事時間: 21時ぐらい
- 予算: 2000円（標準）
- アレルギー: なし
- 特別な要望: なし

よろしいですか？

User: はい

Cursor: [夕食準備計画、レシピ、タスクリスト、買い物リストの詳細な出力]

初期プランを作成しました。計画の詳細をご確認いただけますか？

User: 確認しました

Here:

1. First, the confirm action is executed, asking the user to verify the information

2. After obtaining approval, multiple files (plan, recipe, task list, shopping list) are generated using templates

3. Variables collected during the question phase (dinner_menu, people_count, etc.) are automatically embedded into the templates

This part is a practical example of the 'template separation' and 'file operation pattern' techniques, where structured plans are generated using the information collected from the user.

3. Guidance to the Improvement Phase

Cursor: これから夕食の準備を進めるには以下のステップがあります：
1. 「夕食の計画改善」と言って計画を改善する
2. 「夕食の買い物」と言って買い物フェーズに進む

準備ができたら次に進んでください。

User: 夕食の計画改善

This uses a technique called the notify action to provide guidance for the next step, leading the user to a new trigger word ('dinner plan improvement'). It is designed to follow another trigger in the MDC file, creating a workflow flow.

4. Feedback Collection and Plan Improvement

Cursor: 「カレー」の計画を改善します。どのような点を改善したいですか？

User: 美味しいカレーにしたい

Cursor: フィードバック収集を開始します。各質問に具体的に回答してください。準備はよろしいですか？

User: はい

Cursor: メニュー「カレー」に追加したい料理はありますか？

User: サラダです

[中略：フィードバック収集の質問と回答]

Cursor: [改善されたレシピ、タスク、買い物リストの出力]

プランの更新が完了しました。以下の改善を行いました：
1. カレーレシピの改善
   - 辛さを控えめにするため、甘口ルーの使用・はちみつ・牛乳の追加方法を記載
   - りんごの量を増やして甘みを強化
[...]

This part is:

1. An example of 'inserting an explicit confirmation step,' where it checks for readiness before collecting feedback

2. Uses the 'feedback collection pattern' to structure and collect the user's wishes

3. Applies a new template based on the collected information to generate an improved plan

I hope you can see that through the well-designed dialogue flow created by the MDC file, the agent guides the user step-by-step, collects necessary information, and provides structured output.

Now, let's actually build it to work like this.

STEP 1: Clarify the purpose and functions in natural language

First, let's clarify the goal. Try to write out as straightforwardly as possible, "What do I actually want this agent to do in the first place?"

私が「夕食の準備」と言ったら、AIが以下のことをしてほしい：
1. 今日の夕食のメニュー、人数、調理時間などを質問してくれる
2. 集めた情報を確認してから計画を立ててくれる
3. 買い物リスト、レシピ、タイムラインをファイルにまとめてくれる
4. 必要に応じて計画を改善できるようにする

Do not write it in the MDC file yet. First, organize it in your own head or a notepad. By "writing it out in natural language," you will have less hesitation when you
turn it into rules later.

STEP 2: Create a list of trigger words and step names

Next, let's what keywords trigger Cursor to start (i.e., triggers) and roughly write down the general step names.

# 夕食の準備トリガー
trigger: "夕食の準備"
steps:
  - name: "情報収集"
    # 詳細は後で記入
  
  - name: "確認"
    # 詳細は後で記入
  
  - name: "計画作成"
    # 詳細は後で記入
  
  - name: "次のステップ案内"
    # 詳細は後で記入

# 計画改善トリガー
trigger: "夕食の計画改善"
steps:
  - name: "改善点確認"
    # 詳細は後で記入
  
  - name: "フィードバック収集"
    # 詳細は後で記入
  
  - name: "計画更新"
    # 詳細は後で記入

Here, you don't need to write the "actions" or "conditions" of the sub-steps yet; it's enough to be able to see the "sequence of how it proceeds" at a glance. It's like creating an
outline.

STEP 3: Define the necessary question set

Finally, let's make "what to ask?" concrete. In the MDC file, you can write a "question set" that summarizes the items to be asked as a separate section.

# 質問セットの定義
dinner_questions:
  - question: "今日の夕食のメニュー名を教えてください"
    key: "dinner_menu"
    required: true
  
  - question: "食事人数は何名ですか？"
    key: "people_count"
    required: true
  
  - question: "調理予定時刻はいつ頃ですか？（例：18:00）"
    key: "cooking_time"
    required: true
  
  - question: "食事予定時刻はいつ頃ですか？（例：19:00）"
    key: "dinner_time"
    required: true
  
  - question: "予算はいくらくらいですか？（例：2000円）"
    key: "budget"
    default: "2000円（標準）"
    required: false
  
  - question: "食事で避けたい材料はありますか？（アレルギーなど）"
    key: "allergies"
    default: "なし"
    required: false
  
  - question: "その他の要望はありますか？"
    key: "special_requests"
    default: "なし"
    required: false

• question is the wording actually thrown at the user

• key is the variable name to store the answer

• if required is true, you must get an answer

• it is convenient to prepare an initial value with default

In this step, you are identifying "what is the minimum I need to ask to make dinner preparation possible?". If you are still unsure about some parts, it is okay to add or delete them later.

STEP 4: Create an output template

Next, let's define the template for the file the AI will ultimately generate. The trick is to keep it in a format that is
easy for humans to read later, such as for planning files or shopping lists.

templates:
  dinner_plan_template: |
    # 夕食準備計画
    
    ## 基本情報
    - 日付: {{current_date}}
    - メニュー: {{dinner_menu}}
    - 人数: {{people_count}}
    - 調理時間: {{cooking_time}}
    - 食事時間: {{dinner_time}}
    - 予算: {{budget}}
    - アレルギー: {{allergies}}
    - 特別な要望: {{special_requests}}
    
    ## スケジュール
    1. 買い物: {{shopping_time}}
    2. 下準備: {{prep_time}}
    3. 調理開始: {{start_cooking_time}}
    4. 配膳: {{serving_time}}
    
  shopping_list_template: |
    # 買い物リスト
    
    ## {{dinner_menu}}用食材
    {{shopping_items}}

• The {{...}} parts are where you embed the question set from earlier or variables that the AI will calculate later

• Using headings (#, ##, etc.) in Markdown format increases readability

Everyone has their own preference for "what format to output in?" For example, using bullet points or tables is also fine. Keeping
a design that is useful when a human looks at the file in mind will make subsequent work much easier.

STEP 5: Detailing each step

This is where the real work begins. We will write specific actions, conditions, and variables into the framework created in STEP 2.

# 夕食の準備トリガー
trigger: "夕食の準備"
steps:
  - name: "start_info_collection"
    action: "call"
    target: "dinner_questions"
    message: "夕食の準備をするにあたって、質問させてください"
  
  - name: "get_current_date"
    action: "execute_shell"
    command: "date +%Y-%m-%d"
    variable: "current_date"
    message: "現在の日付を取得しています..."
  
  - name: "confirm_dinner_plan"
    action: "confirm"
    message: |
      以下の内容で夕食準備プロジェクトを開始します：
      - メニュー: {{dinner_menu}}
      - 人数: {{people_count}}
      - ...
      
      よろしいですか？
    variable: "plan_confirmed"
  
  - name: "calculate_times"
    action: "execute"
    script: |
      # 時間計算ロジック
      # 例）夕食時間-60分を調理開始に、さらに-30分を下準備に…
      ...
    condition: "{{plan_confirmed}} == true"
  
  - name: "create_dinner_dir"
    action: "execute_shell"
    command: "mkdir -p Dinner/{{current_date}}_{{dinner_menu}}"
    variable: "dinner_dir"
    condition: "{{plan_confirmed}} == true"
  
  - name: "create_dinner_plan"
    action: "create_file"
    path: "{{dinner_dir}}/plan.md"
    template: "dinner_plan_template"
    message: "夕食準備計画ファイルを作成しました"
    condition: "{{plan_confirmed}} == true"
  
  - name: "plan_created"
    action: "confirm"
    message: "初期プランを作成しました。計画の詳細をご確認いただけますか？"
    variable: "review_plan"
    condition: "{{plan_confirmed}} == true"
  
  - name: "dinner_plan_next_steps"
    action: "notify"
    message: |
      これから夕食の準備を進めるには以下のステップがあります：
      1. 「夕食の計画改善」と言って計画を改善
      2. 「夕食の買い物」と言って買い物フェーズへ
    condition: "{{review_plan}} == true"

• action: "call" to invoke the question set

• execute_shell for shell commands (such as getting the date or creating folders)

• confirm to get a Yes/No from the user and store it in variable: "plan_confirmed"

• use condition to "proceed to the next step only when plan_confirmed == true"

Fine-grained operations can be written by splitting them into multiple steps, which minimizes the risk of the AI skimming over them.

STEP 6: Detailing the improvement flow steps as well

In this example, we will also support a separate trigger called "dinner plan improvement." This is the pattern where, after presenting the plan, the user says, "I want to change the seasoning a bit" or "I want to add another recipe."

trigger: "夕食の計画改善"
steps:
  - name: "start_improvement"
    action: "notify"
    message: "「{{dinner_menu}}」の計画を改善します。どのような点を改善したいですか？"
  
  - name: "start_feedback_collection"
    action: "confirm"
    message: "フィードバック収集を開始します。各質問に具体的に回答してください。準備はよろしいですか？"
    variable: "start_feedback"
  
  - name: "collect_plan_feedback"
    action: "call"
    target: "plan_feedback_questions"
    variable: "plan_feedback"
    message: "プランについてのフィードバックを収集します..."
    condition: "{{start_feedback}} == true"
  
  - name: "update_dinner_plan"
    action: "modify_file"
    path: "{{dinner_dir}}/plan.md"
    template: "dinner_plan_template"
    data: "{{plan_feedback}}"
    message: "夕食準備計画を更新しました"
    condition: "{{start_feedback}} == true"
  
  - name: "improvement_summary"
    action: "notify"
    message: |
      プランの更新が完了しました。
      ここが変更点: ...
      次は「夕食の買い物」と言えば買い物リストへ進めます！
    condition: "{{start_feedback}} == true"

Even in different situations like this, you just follow a similar structure (question -> confirmation -> file editing). By using the "
modify_file" action, it becomes easy to partially rewrite existing plan files.

STEP 7: Adding a question set for feedback

You might need a different list of questions for collecting feedback to improve your plan.
You can list your preferred questions here as well.

plan_feedback_questions:
  - question: "メニュー「{{dinner_menu}}」に追加したい料理はありますか？"
    key: "additional_dishes"
    default: "なし"
    required: false
  
  - question: "辛さ・味付けなど変更要望はありますか？"
    key: "recipe_preferences"
    default: "なし"
    required: false
  
  - question: "他に気になる点や改良したいポイントがあれば教えてください"
    key: "other_feedback"
    default: "なし"
    required: false

STEP 8: Evaluation and Testing

Once the MDC file is complete, try calling it in Cursor with "Prepare dinner".

• Does the question set launch correctly at the start?

• Does it proceed to the next step appropriately after the user answers Yes/No?

• Does the file generation work as expected?

• Are the conditions working?

Performing these checks frequently makes it easier to find flaws. YAML in particular is prone to errors due to
indentation or forgotten colons, so I recommend testing in detail at first.

STEP 9: Refactoring and Improvement

When you test it, you will likely notice various points, such as "I want to make the question phrasing gentler" or "This order might be a bit off...".

• Simplify redundant parts

• Check for variable name consistency

• Add comments

• Turn duplicate actions into templates

Repeating this refactoring will refine the MDC file and make the AI's behavior even more stable.

STEP 10: Expansion and Application

Once the foundation is built, the next keyword is "more convenient". For example...

1. Dedicated trigger for the shopping phase

   • Call with "Dinner shopping" -> List necessary ingredients and check inventory

2. Cooking Procedure Guide

   • Using timer execution (execute_shell) to count 3 minutes and sound an alarm, etc.

3. Recipe Search via API Integration

   • Providing more diverse suggestions by linking with services like Cookpad or Google Search.

4. Multiple Menu Suggestions

   • Branching logic such as "Give me 3 patterns of dinner ideas for today".

5. Error Handling

   • Handling cases where the user does not provide any response, etc.

As you add more features, your MDC file might get longer, but you can simply "split the files" or "standardize question sets". Once the

initial example is working reliably, you can expand it smoothly.

5 Tips to Master Rule Files

In the previous Dinner Preparation Agent hands-on example, we introduced the basic flow of creating an MDC file. As mentioned during the hands-on explanation, here is a summary of tips for creating Rule files.

1) Keep steps as "granular" as possible

"It should be easier for humans to understand if I write it simply..." I understand that feeling, but AI, on the contrary, tends to arbitrarily omit instructions that are too condensed.
For example, if you cram the flow of 'Question → Confirmation → File Generation → Re-confirmation' into one step,

• it will skip user confirmation and create the file immediately

• thinking, "I don't need to ask anything here," it will proceed on its own judgment

and other such 'skipping' or 'leaps in logic' become more likely to occur.

Concrete example:

- name: "ask_menu"
  action: "ask_question"
  question: "夕飯のメニューは？"
  variable: "dinner_menu"

- name: "ask_people"
  action: "ask_question"
  question: "何人分作りますか？"
  variable: "people_count"

- name: "confirm_plan"
  action: "confirm"
  message: "このプランで良いですか？"
  variable: "plan_ok"

Like this, the more you break it down into a form close to 1 step = 1 action, the less likely the AI is to get confused.
You might think, "It looks like it's going to be redundant..." but omitting things often leads to more trouble. The more finely you break it down, the more user-friendly and AI-friendly the structure becomes.

2) Use a 'Confirmation Step' to prevent 'runaway' behavior

" Proceeding before the user says Yes "—this is not limited to AI; it's similar to a capable (?) secretary running off on their own in high spirits.
Utilize confirm actions or condition to firmly incorporate the rule, "Do not proceed further unless it is OK".

- name: "check_budget"
  action: "confirm"
  message: "予算は{{budget}}円ですがよろしいですか？"
  variable: "budget_ok"

- name: "create_plan"
  action: "create_file"
  template: "plan_template"
  condition: "{{budget_ok}} == true"

If you set up a scheme where you proceed only after the user approves the budget confirmation, it reduces accidents such as having an unexpected shopping list created.

3) Separate templates and question sets into different files

In the hands-on example, we defined the question sets and templates within the same MDC. However, as the project grows, a single file can reach hundreds of lines, and readability drops significantly.

Recommended split example:

• main.mdc: Main flow description

• questions.yaml: Consolidating multiple question sets

• templates.mdc (or templates.yaml): A collection of output file templates

By doing this, you only need to open questions.yaml to fix questions, and you only need to edit the templates file to change templates, which makes maintenance and expansion easier.

4) Tips to avoid asking the same question repeatedly

Sometimes, a loop error occurs where the agent asks, "I already asked about allergies, why are you asking again?". For this, variable states or conditions are effective.

- name: "ask_allergies"
  action: "ask_question"
  question: "アレルギーはありますか？"
  variable: "allergies"
  condition: "{{allergies}} == null"

• condition: "{{allergies}} == null"
  In other words, only ask the question **"if nothing is entered for allergies"**

• If the user has already answered, skip the same question

This mechanism can also be applied to things like "Has the default value for the variable been set?", allowing you to suppress useless repetition and interact smartly.

5) Avoid chaos by splitting rule files by function

"dinner_plan.mdc", "dinner_improvement.mdc", by separating files by agent function or scenario like this, it becomes much easier to manage than stuffing a giant MDC into a single file.

• For example, separating "dinner preparation" from the "shopping phase" and "cooking phase" separately

• Or, by functional unit such as "main.mdc" or "feedback.mdc"

(+) At a larger scale, if you naturally separate them by projectA_main.mdc, projectA_feedback.mdc, and projectA_deploy.mdc based on project, phase, and purpose, you will be able to quickly find and edit "the part you want to change".

Let's try customizing

If you feel like you sort of understand but not quite, I recommend starting by actually downloading and customizing the Rules I introduced earlier!

1. Customizing Question Content

   • Try adding or deleting questions

   • Change default values and options

2. Modifying Templates

   • Adjust output format to your preference

   • Add new variables and reflect them in the template

3. Adding New Triggers

   • Utilizing in other scenes, such as 'preparing breakfast'

4. Add actions

   • Integration with APIs that retrieve nutritional information

   • Integration with image generation tools

Application Ideas

Based on the sample repository, you can also consider the following customizations:

• Adding a recipe search function

• Integration with an ingredient inventory management system

• Implementation of a nutritional balance calculation function

• Meal planning adjustment function for multiple people

I hope that through this repository, you will gain practical know-how on agent control using YAML files.

Choose the "appropriate level for the task"

Well, after saying all this, some people might think, "YAML? That's a hassle. AI is too much trouble, I'll just quit."

It is important to understand that this is not necessarily the case. It's a case-by-case situation!

● Guidelines by case

• One-off Q&A: A simple prompt is sufficient
  Example: "Tell me today's weather," "Summarize the latest news," etc., where one step is enough

• Short dialogue of about 3-5 steps: Base YAML
  Example: Small to medium-scale flows like the dinner preparation example

• Long-term processes with many branches: Full-scale YAML design
  Example: Large-scale flows where multiple conditions overlap, such as project management, automatic generation of multiple files, or API integration

● Focus on balance

If you are in a situation where "learning cost > benefits", there is no need to force it into YAML.
Rather, I recommend a step-up approach: first try with simple chat instructions, and if it just won't stabilize, then try structuring a part of it.

However, in practical work or large-scale tasks where you repeatedly give the same instructions, structuring them makes things overwhelmingly more stable.
Rather than "getting confused by the same thing over and over," writing it down clearly in YAML once will undoubtedly lead to long-term stress reduction.

Summary: Let's cultivate an even more stable and high-precision agent

The "dinner preparation" agent introduced this time is just one example of rule design. In reality, it can be applied to a wide range of areas, such as project management in business settings or automation using API integration.

At first glance, writing YAML seems like a hassle, but just a little bit of structuring makes the motivation and accuracy of the Cursor agent completely different.

The more you cultivate Cursor to your liking, the more you should be able to feel its power, thinking, "Wait, the AI is supporting my work more and more...?" Please use these tips to polish the dinner preparation agent you made in the

hands-on session, and try to cultivate your own "ultra-stable AI secretary"!!!!!!!

(Bonus)

Now, the "Ultimate AIPM System I Thought Of" that I have been talking about a lot on my account recently is a complete development of the content introduced this time. If there is anyone who would like to know more about application examples of how to use Rules like this, please definitely give it a try.

(Postscript)

I have published a new article about this AIPM system, so please take a look if you would like.

[Finally, the usual promotion] Explaza is looking for new team members!!

Diverse positions from "AI Engineer" to "AI Producer"

Explaza, where I work, is in a rapid expansion phase and is looking for team members to take on the following roles.

Please check our job page for detailed recruitment requirements and benefits.

• LLM Application Engineer (Full-time employee)

• AI Producer (Full-time employee)

• Lead AI Producer (Full-time Employee)

• Open Position

What kind of company is Xplaza?

We are an implementation-focused consulting and product company responsible for the social implementation of generative AI. Founded in 2020, we are a young startup with just over 10 members, but we are gaining attention for our mission of "social implementation of generative AI," leveraging both AI technology and product development.

Click here for our culture deck

In 2023, we formed a capital and business alliance with the Matsuo Institute, and from 2025 onwards, we are entering a phase of fully strengthening our generative AI capabilities!

At Xplaza, Cursor, which we featured in this article, is now available for unlimited use by everyone in the company, whether they are in business or engineering roles!

To everyone who became interested in using Cursor daily after reading this article!Why not join us and help build an AI-native society!! You get unlimited access to Cursor too! lol We look forward to hearing from you!