Restaurant Meal Finder — Smart Dining Recommendations

Do NOT activate when the user is simply logging a meal they already ate (→ diet-tracking-analysis) or asking for a weekly meal plan (→ meal-planner).

How This Skill Connects to Other Skills

health-profile.md (body data) + health-preferences.md (food prefs)
  + PLAN.md (calorie target) + diet-tracking daily logs (remaining budget)
    → restaurant-meal-finder ← YOU ARE HERE
      ├── Step 0: resolve location (multi-location: 家/公司/etc.)
      ├── Step 1: web search nearby restaurants → cache to data/nearby-restaurants.json
      ├── Step 2: recommend meals (dedup + context-aware) from cached restaurants
      └── Step 3: user picks → hand off to diet-tracking-analysis

Upstream dependencies:

• weight-loss-planner / PLAN.md → daily calorie target
• diet-tracking-analysis → today's intake + recent days' meal patterns
• exercise-tracking-planning → today's exercise (for calorie/protein adjustment)
• health-preferences.md → food likes/dislikes, allergies, diet mode
• health-profile.md → body stats, diet config, location, schedule
• USER.md > Language → language and region

Downstream handoff:

• After the user picks a meal, offer to pre-log it via diet-tracking-analysis

Data Dependencies

data/nearby-restaurants.json Schema

This skill owns this file. It is the single source of truth for the user's nearby restaurant options, organized by location.

{
  "active_location": "公司",
  "locations": {
    "公司": {
      "address": "北京市海淀区中关村腾讯众创空间",
      "updated_at": "2026-03-16",
      "source": "web_search"
    },
    "家": {
      "address": "北京市昌平区回龙观东大街",
      "updated_at": "2026-03-14",
      "source": "web_search"
    }
  },
  "restaurants": [
    {
      "name": "沙县小吃（中关村店）",
      "location": "公司",
      "type": "快餐",
      "cuisine": "闽菜/快餐",
      "distance": "步行 5 分钟",
      "platforms": ["到店", "美团外卖", "饿了么"],
      "price_range": "人均 15-25 元",
      "meals": [
        {
          "name": "蒸饺 8 个 + 紫菜蛋花汤",
          "calories": 450,
          "protein": 20,
          "carbs": 55,
          "fat": 15,
          "price": "约 18 元",
          "tips": "蒸饺比煎饺少约 100 kcal"
        },
        {
          "name": "馄饨（小碗）+ 卤蛋 1 个",
          "calories": 400,
          "protein": 22,
          "carbs": 45,
          "fat": 14,
          "price": "约 15 元",
          "tips": "不喝汤底可以再省 50 kcal"
        },
        {
          "name": "拌面 + 蒸蛋",
          "calories": 480,
          "protein": 18,
          "carbs": 60,
          "fat": 16,
          "price": "约 16 元",
          "tips": "少放酱料减 50 kcal"
        }
      ],
      "visits": [
        {
          "date": "2026-03-10",
          "meal": "蒸饺 8 个 + 紫菜蛋花汤",
          "rating": 4,
          "note": "分量刚好，汤很鲜"
        }
      ],
      "visit_count": 1,
      "last_visited": "2026-03-10",
      "user_rating": 4,
      "tags": ["工作日午餐", "性价比高"]
    }
  ],
  "recent_recommendations": [
    {
      "date": "2026-03-15",
      "meal_slot": "lunch",
      "restaurant": "沙县小吃（中关村店）",
      "meal": "蒸饺 8 个 + 紫菜蛋花汤",
      "accepted": true
    }
  ]
}

Top-level fields

• active_location — the user's current context label (e.g., "公司", "家", "出差"). Auto-set based on time of day or user statement.
• locations{} — map of saved location labels to their details:
  • address — the actual address/neighborhood
  • updated_at — date of last web search for this location (ISO date)
  • source — how restaurants were found ("web_search", "user_provided")
• restaurants[] — flat array of all restaurants across all locations, each with a location field linking to its location label
• recent_recommendations[] — rolling log of last 14 days of recommendations (auto-prune older entries). Used to avoid repetition.

Restaurant fields

• name — full name including branch if known
• location — which saved location this restaurant belongs to (must match a key in locations{})
• type — category (快餐, 便利店, 轻食, 火锅, etc.)
• cuisine — cuisine style (闽菜, 西北, Japanese, Mexican, etc.)
• distance — approximate distance or travel time from the associated location
• platforms — how to order (到店, 美团外卖, 饿了么, Uber Eats, DoorDash, etc.)
• price_range — approximate per-person cost
• meals[] — pre-screened meal combos suitable for the user (typically 3–6 per restaurant, covering different calorie budgets and variety). Each with:
  • name — combo description (e.g., "蒸饺 8 个 + 紫菜蛋花汤")
  • calories, protein, carbs, fat — nutritional estimates for the combo
  • price — approximate total price
  • tips — (optional) calorie-saving tip
• visits[] — (optional) visit records, each with date (ISO), meal (what was ordered), rating (1–5, optional), note (optional)
• visit_count — (derived) total visits, auto-updated
• last_visited — (derived) date of most recent visit
• user_rating — (optional) average of visit ratings
• tags[] — (optional) user-generated labels like "工作日午餐", "聚会好去处"

meals[] — building and growing over time

Store 3–6 pre-screened meal combos per restaurant, covering a range of calorie budgets (300–700 kcal). Unlike the old schema which only had 1–2 static combos, having more options enables the skill to rotate recommendations and avoid repetition.

How meals[] grows:

• Initial discovery (Step 1): build 2–3 combos from web search results and nutritional knowledge
• User feedback: "他家还有拌面挺好的" → estimate calories and add to meals[]
• Delivery app screenshots: user shares a menu → add suitable dishes
• Post-visit: user orders something new at a cached restaurant → add it

Never fabricate dish names. Only add dishes from verified sources.

Core Flow

Step 0: Resolve Location

The user may eat at different places on different days. This skill supports multiple saved locations (e.g., "公司", "家", "健身房附近").

Resolution order:

1. User's current message — if they mention a location ("我在公司附近", "I'm near home"), match to a saved location label or treat as a new location.
2. Time-based inference — if locations has "公司" and "家", default to "公司" on weekday lunch hours, "家" on evenings/weekends. Use health-preferences.md > ## Scheduling & Lifestyle for the user's work schedule if available.
3. active_location — fall back to the last-used location in data/nearby-restaurants.json.
4. health-profile.md — may contain city or address.

If no location is saved at all (first activation), ask the user:

你平时在哪附近吃饭？可以告诉我一两个常去的地方（比如公司附近、家附近），我帮你搜一下，以后就不用每次都搜了。

English equivalent:

Where do you usually eat? Give me one or two spots (near office, near home) and I'll search nearby options for each. I'll save them so we don't have to search again.

Single-ask rule applies — ask at most once. If the user only gives one location, that's fine — more can be added later.

Adding a new location later:

• User says "我搬家了" / "今天在另一个地方" → add a new location label, search, and save. Don't overwrite existing locations.
• User says "删掉XX那个地点吧" → remove the location and its restaurants from the cache.

After the user provides a location, save the address to health-profile.md under ## Location so other skills can also benefit.

Step 1: Discover Nearby Restaurants (Web Search)

When to search:

• First time the skill is activated (no data/nearby-restaurants.json exists)
• User adds a new location not yet in locations{}
• User explicitly asks to refresh ("帮我重新搜一下", "I moved", "换个地方了")
• The active location's updated_at is > 30 days old

When NOT to search (use cache):

• The resolved location exists in locations{} and its data is < 30 days old
• User names a specific restaurant already in the cache

How to search:

Use web search to find restaurants near the user's location. Run 2–3 targeted searches:

1. General nearby dining: "{location}" 附近 餐厅 推荐 or restaurants near {location}
2. Delivery options: "{location}" 外卖 推荐 or food delivery near {location}
3. Healthy/diet-friendly options (optional): "{location}" 轻食 健康餐 or healthy restaurants near {location}

From search results, extract:

• Restaurant names (prefer specific branches, not just chain names)
• Restaurant type/cuisine
• Approximate distance
• Available ordering platforms
• Price range
• Popular menu items

⚠️ NEVER FABRICATE RESTAURANT DATA. Only include restaurants that appear in actual search results with verifiable names and addresses. If web search returns no usable restaurant results for the area (common for smaller neighborhoods where data is locked inside apps like 大众点评 or 美团), do NOT invent restaurant names, addresses, or menus. Instead, follow the "Web search returns limited results" edge case below.

Then build meals[] for each restaurant:

• Pre-screen 2–3 meal combos per restaurant that fit typical calorie budgets (400–700 kcal)
• Use nutritional knowledge to estimate calories and macros for each combo
• Add a calorie-saving tip for each meal where relevant
• Calorie/macro estimates for verified real restaurants are fine to generate from nutritional knowledge
• Meal/dish names must come from search results, the user, or widely known chain menus — never invented
• Set each restaurant's location field to the current location label
• More combos can be added over time as the user provides info or visits the restaurant (see "meals[] — building and growing over time")

Save the results to data/nearby-restaurants.json, adding to the restaurants[] array and updating the relevant entry in locations{}.

Present the discovery results to the user conversationally:

帮你搜到了附近这些可以吃的地方：

1. 🥟 沙县小吃 — 步行 5 分钟，人均 15-25 元
2. 🍜 兰州拉面（中关村店） — 步行 8 分钟，人均 20-30 元
3. 🏪 便利蜂 — 步行 3 分钟，人均 15-25 元
4. 🥗 轻食沙拉店 — 美团外卖 30 分钟，人均 35-50 元
5. 🍱 黄焖鸡米饭 — 步行 6 分钟 / 饿了么外卖，人均 20-30 元

已经帮你记下来了，以后问我吃什么直接从这里面推荐。想现在就选一个吗？

Step 2: Recommend Meals from Cached Restaurants

This is the main loop — every time the user asks "吃什么？" after the initial setup, this step runs directly from cache without re-searching.

Silently gather context:

1. Remaining calorie budget — Read today's meal logs from data/meals/{today}.json. Subtract total logged calories from the daily target (from PLAN.md). If no logs yet, use the full daily target.

2. Meal slot — Determine which meal this is (breakfast, lunch, dinner, snack) based on current time and health-profile.md > Meal Schedule. This affects calorie allocation.

3. Dietary constraints — From health-preferences.md and health-profile.md: diet mode, allergies, dislikes, cuisine preferences.

4. Cached restaurants — Read data/nearby-restaurants.json. Filter to restaurants matching active_location.

5. Recent recommendations — Read recent_recommendations[] to know what was suggested recently.

6. Recent life context — Gather signals from other data sources to understand the user's current state:

   • Recent diet pattern — from data/meals/ logs over the last 3–5 days: are they eating too much of one food group? High sodium streak? Mostly fast food? Under-eating protein?
   • Exercise today — from exercise logs: did they work out today? Higher calorie budget may be appropriate.
   • Emotional state — from recent conversation tone or explicit mentions ("今天好累", "心情不好", "加班到很晚"): suggest comfort food within budget, or lighter options if they mention feeling heavy/bloated.
   • Day type — weekday rush (fast, cheap, nearby) vs weekend leisure (can travel further, try new places, higher budget).

Then recommend — rotating from meals[]:

Each restaurant has multiple pre-screened combos in meals[]. Pick different ones each time — check recent_recommendations[] to avoid suggesting the same combo as last time at the same restaurant.

If the user names a specific restaurant (in the cache or not)

Provide 2–3 meal combos from the restaurant's meals[], ranked by fit. Prefer combos not recently recommended:

沙县小吃 — 推荐点餐方案

你这顿还剩约 650 kcal 的预算：

方案 1（推荐）： 蒸饺 8 个 + 紫菜蛋花汤 约 450 kcal | 蛋白 20g · 碳水 55g · 脂肪 15g | 约 18 元 💡 蒸饺比煎饺少约 100 kcal

方案 2： 馄饨（小碗）+ 卤蛋 1 个 约 400 kcal | 蛋白 22g · 碳水 45g · 脂肪 14g | 约 15 元 💡 不喝汤底可以再省 50 kcal

If the restaurant is NOT in the cache, use nutritional knowledge to recommend, and ask if they want to add it to the list.

If the user asks generally ("吃什么好？")

Pick 3–4 options from the cached restaurant list for the active location, applying these filters in order:

1. Dedup — check recent_recommendations[]. Deprioritize restaurants recommended in the last 2 days, and never suggest the exact same meal combo as last time at the same restaurant.
2. Budget fit — filter to restaurants with menu combos within the remaining calorie budget.
3. Life context — adjust based on recent state:
   • Last 3 days mostly 快餐/高碳水 → lean toward 轻食 or 高蛋白 options
   • Just worked out → can suggest slightly higher calorie options, emphasize protein
   • User mentioned being tired/stressed → suggest simple comfort food within budget, don't push ultra-healthy options
   • Weekend → can suggest further restaurants or new places to try
4. Variety — across cuisine types (don't recommend 3 noodle places), price ranges, and restaurant types.
5. Visit history — weave in visit context per the History-Based Recommendation Logic below.

今天午餐建议 — 剩余预算约 650 kcal

🥟 沙县小吃： 馄饨 + 卤蛋 — 约 400 kcal，15 元 上次推荐的是蒸饺，换个口味 🍜 兰州拉面： 牛肉拉面小碗 + 卤蛋 — 约 550 kcal，25 元 🏪 便利蜂： 鸡胸肉 + 饭团 + 蔬菜沙拉 — 约 480 kcal，22 元 这几天碳水偏多，来点高蛋白

想吃哪个？或者告诉我你在别的地方，我来帮你搭配。

After recommending, append an entry to recent_recommendations[]:

{
  "date": "2026-03-16",
  "meal_slot": "lunch",
  "restaurant": "沙县小吃（中关村店）",
  "meal": "馄饨 + 卤蛋",
  "accepted": false
}

Update accepted to true if the user picks that option. Auto-prune entries older than 14 days.

If the user sends a menu (photo or text)

Analyze the menu items and pick the best 2–3 options that fit the budget. Highlight what to order and what modifications to request. Offer to add suitable combos to the restaurant's meals[] cache.

Step 3: Ordering Guidance

For each recommended meal, include:

• Exact items to order — specific dish names, not vague categories
• Modifications — concrete calorie-saving tweaks (less oil, skip the sauce, half rice, no sugary drink)
• Calorie and macro estimates — approximate but honest; round to nearest 10 kcal
• Price estimate — so the user knows what to expect
• One actionable tip (💡) — the single most impactful modification
• Platform — mention if it's available on delivery platforms when relevant

Calorie Estimation Principles

• Use knowledge of common restaurant portions and cooking methods
• Err slightly high rather than low — restaurant portions are usually larger and higher-calorie than home cooking
• Account for cooking oils, sauces, and hidden calories
• If uncertain about a specific restaurant's portions, state the estimate range (e.g., "约 450–550 kcal")

Step 4: User Selection & Pre-logging

After the user picks a meal option:

1. Confirm the choice briefly: "好的，那就沙县蒸饺套餐！"
2. Offer to pre-log: "要我先帮你记上吗？吃完后可以再调整。"
3. If the user agrees, hand off to diet-tracking-analysis to log the meal
4. If the user doesn't want to pre-log, that's fine — they can log after eating

Visit Tracking & History-Based Recommendations

This skill tracks which restaurants the user actually visits and uses that history to make smarter, more personalized recommendations over time.

Recording Visits (Check-ins)

When to record a visit:

1. User logs a restaurant meal via diet-tracking-analysis — after the meal is logged and the restaurant is in the cache, silently append a visit record to that restaurant's visits[] array. Extract the meal name from the log, use today's date.
2. User explicitly checks in — "我在沙县吃了", "just had lunch at Chipotle" → record the visit.
3. User rates a restaurant — "那家拉面不错" / "上次那个轻食店一般" → record or update the rating.

How to record:

Append to the restaurant's visits[] in data/nearby-restaurants.json:

{
  "date": "2026-03-16",
  "meal": "蒸饺 8 个 + 紫菜蛋花汤",
  "rating": 4,
  "note": "分量刚好"
}

Then update visit_count, last_visited, and recalculate user_rating (average of all visit ratings that have a rating value).

Tagging: If the user describes a restaurant with labels ("这家适合赶时间的时候吃", "good for a quick bite"), save those as tags[]. Tags are free-form and user-driven — don't auto-generate them.

History-Based Recommendation Logic

When the user asks "吃什么？" or requests recommendations, augment the standard Step 2 flow with visit history signals:

Priority 1: Favor visited & liked restaurants

• Restaurants with user_rating >= 4 and visit_count >= 1 get a recommendation boost
• Mention why: "你上次给了 4 星" / "你去过 3 次了，看来挺喜欢的"
• If a highly-rated restaurant fits the current calorie budget and meal slot, prioritize it

Priority 2: Recommend similar restaurants

When the user likes a restaurant, suggest similar unvisited ones from the cache based on:

• Same type (e.g., both are 快餐 or both are 轻食)
• Similar price_range
• Matching tags (e.g., both tagged "工作日午餐")

你挺喜欢沙县小吃的，附近还有一家 黄焖鸡米饭 也是快餐类、价格差不多，要不要试试？

Priority 3: Avoid poorly-rated restaurants

• Restaurants with user_rating <= 2 should be deprioritized (still shown if explicitly asked, but not proactively recommended)
• If the user asks about a low-rated restaurant, gently remind: "你上次给了 2 星，还想去吗？要不试试旁边的 XX？"

Priority 4: Frequency-aware variety

• If the user has visited the same restaurant > 3 times in the last 7 days, suggest alternatives: "这周已经吃了 3 次沙县了，换个口味？"
• Balance between comfort (returning to favorites) and variety (trying new options)

Presenting History Context in Recommendations

When recommending, naturally weave in visit history:

今天午餐建议 — 剩余预算约 650 kcal

⭐ 沙县小吃： 蒸饺 + 蛋花汤 — 约 450 kcal，18 元 去过 3 次 · 评分 4.0 🆕 轻食沙拉店： 鸡胸肉沙拉 — 约 380 kcal，35 元 还没试过，和你喜欢的便利蜂轻食风格类似 🍜 兰州拉面： 牛肉面小碗 — 约 550 kcal，25 元 上次去是 3 天前

Use ⭐ for favorites (rating >= 4), 🆕 for unvisited, no marker for regularly visited.

Preference Detection — Write to health-preferences.md

During restaurant interactions, the user often reveals preferences. Append to the appropriate existing section in health-preferences.md:

• Cuisine/food preferences: "我喜欢吃日料", "I love Thai food" → ## Dietary
• Dining schedule patterns: "午饭基本都在外面吃", "I eat out every day" → ## Scheduling & Lifestyle
• Budget sensitivity: "外卖太贵了" → ## Dietary

Do this silently — never mention file updates to the user.

Managing the Restaurant Cache

Adding restaurants

The user may discover new restaurants over time:

• "我发现楼下新开了一家轻食店" → ask for details, search if needed, add to cache
• The user orders from a new place and logs it → silently ask if they want to add it to their list
• During web search refresh, new restaurants may appear → add them

Removing restaurants

• "那家店关了" / "不想再去那家了" → remove from cache
• If a restaurant appears closed or unavailable during search refresh, remove it

Refreshing

• Auto-refresh when a location's updated_at is > 30 days old (on next activation)
• User says "帮我重新搜一下附近的餐厅" → refresh the active location's restaurants
• Add new restaurants without removing existing ones during partial updates
• Refreshing one location does not affect other locations' data

Locale Adaptation

Follow the same locale resolution as meal-planner (Step 1: User Locale & Food Context):

Chinese (China) — 中国用户

• Search on: 大众点评, 美团, 饿了么, 小红书
• Common types: 沙县小吃, 兰州拉面, 黄焖鸡, 麻辣烫, 便利店, 食堂, 轻食店
• Use kcal, grams, 碗/份/个 as portion units
• Macro labels: 蛋白 / 碳水 / 脂肪
• Common modifications: 少油, 少盐, 饭量减半, 不要含糖饮料, 多加蔬菜

English (US) — American users

• Search on: Google Maps, Yelp, DoorDash, Uber Eats
• Common types: Chipotle, Subway, Chick-fil-A, Panera, Sweetgreen, convenience stores
• Use Cal, oz/cups as portion units
• Macro labels: Protein / Carbs / Fat
• Common modifications: dressing on the side, no cheese, grilled instead of fried, water instead of soda, half portion of rice/bread

Japanese (Japan) — 日本ユーザー

• Search on: 食べログ, Google Maps, Uber Eats Japan
• Common types: コンビニ (7-Eleven, Lawson, FamilyMart), 松屋, 大戸屋, すき家, CoCo壱番屋
• Use kcal, grams
• Macro labels: タンパク質 / 炭水化物 / 脂質
• Common modifications: ご飯少なめ, ドレッシング別添え, 揚げ物→焼き物に変更

Other locales

Adapt to local restaurant search platforms, chains, street food, and dining culture. Use local food terminology.

Interaction Style

Speed over perfection

The user is deciding what to eat right now. If the restaurant cache exists, lead with recommendations immediately. Only the initial setup (Step 0 + Step 1) requires questions and waiting.

Conversational, not clinical

• Good: "这个套餐刚好卡在你的预算里，吃完还有余量加个水果 🍎"
• Bad: "Based on your remaining caloric allowance of 650 kcal, I recommend option A which provides 480 kcal..."

Respect the 80/20 rule

Not every meal needs to be perfectly optimized. If the user is at a birthday dinner or a special occasion, help them enjoy it with minimal damage rather than prescribing the "healthiest" option. "点你想吃的，注意这两个小技巧就行" is better than a lecture.

No judgment

If the user says they're at McDonald's, help them order smart at McDonald's. Don't suggest they go somewhere else unless they ask.

Edge Cases

No calorie target exists: Use the same fallback as meal-planner — ask the user or do a quick TDEE estimate. For an urgent dining decision, a rough estimate (e.g., ~500–600 kcal per meal for a typical adult) is better than blocking the user.

User already exceeded their daily budget: Don't shame them. Acknowledge it matter-of-factly and help them minimize the overage: "今天已经超了一点，这顿尽量控制在 400 kcal 以内就好——来看看有什么轻食选择。"

User is at a restaurant with no obvious healthy options (e.g., BBQ, hot pot, buffet): Help them navigate — portion control tips, what to load up on vs. go easy on, drink choices. "火锅的话，多涮蔬菜和豆腐，蘸料用醋+蒜泥代替麻酱，主食选一小碗米饭就够了。"

User sends a menu photo: Parse the menu items, identify options that fit the budget, and provide the same structured recommendation format. If the photo is unclear, ask for clarification on specific items.

User asks for delivery/takeout platforms: Provide the same recommendations but formatted for ordering: specific dish names, customization notes they can add in the order comments. Reference the platforms field from the cached restaurant data.

Web search returns limited results: Do NOT fabricate specific restaurant names, addresses, or menus. Instead:

1. Ask the user for help: "搜索结果不多，你平时在附近吃哪几家？告诉我店名，我帮你搭配热量合适的点餐方案。" / "I couldn't find many results online. What restaurants are near you? Tell me the names and I'll help you pick calorie-smart meals."
2. Offer general chain guidance: If the user's area likely has common chains (沙县小吃, 兰州拉面, McDonald's, Subway, etc.), you may mention these as possibilities to check — but frame them as suggestions to verify, not as confirmed nearby options. Example: "附近一般会有沙县、兰州拉面这类店，你看看有没有？有的话我帮你配餐。"
3. Offer cuisine-type guidance: If the user describes what type of food is available (e.g., "楼下有个快餐店"), provide calorie-smart ordering strategies for that cuisine type without inventing a specific restaurant.
4. Menu photo fallback: Ask the user to share a menu photo or screenshot from a delivery app: "你在外卖App上截个图发我，我直接帮你挑。"

Always clearly distinguish between verified search results and general suggestions. Never cache unverified restaurants to data/nearby-restaurants.json.

User is traveling / not at their usual location: Ask for a label (e.g., "出差-上海"). Add it as a new location in locations{}, search for nearby restaurants, and set active_location to it. Existing locations are preserved. If the user says they're done traveling, switch active_location back.