gurume-cli

name

gurume-cli

description

Use the `gurume` CLI to search Japanese restaurants on Tabelog. Trigger this whenever the user wants to find, recommend, or research restaurants/eateries in Japan — by area (Tokyo, Osaka, Kyoto, 三重, etc.), by cuisine (ramen, sushi, yakiniku, izakaya...), or with a vague request like "where should I eat in Shibuya" or "any good unagi spots near Tokyo Station". Use this even when the user does not explicitly mention Tabelog or the `gurume` tool, as long as the intent is finding Japanese restaurants.

gurume CLI

gurume is a CLI wrapper around Tabelog (Japan's largest restaurant review site). Use it instead of guessing restaurants from memory or scraping the web — its data is current and structured.

When to use

Trigger this skill whenever the user wants to find restaurants in Japan. Typical signals:

• Mentions a Japanese place name (Tokyo, 大阪, Shibuya, 三重, 京都駅, ...)
• Mentions Japanese cuisines (ramen, sushi, unagi, yakiniku, izakaya, 寿司, ラーメン, ...)
• Asks for restaurant recommendations / "where to eat" in Japan
• Plans a trip to Japan and asks about food

Do not trigger for: non-Japan restaurants, recipes, food delivery apps, or general food trivia.

Workflow

1. Resolve the cuisine (if any)

If the user mentions a specific cuisine, map it to one of Tabelog's supported cuisine names. The full list is in references/cuisines.md — read that file when you need the mapping. Cuisine names must be passed in Japanese (e.g. ラーメン, not ramen).

If the user's request doesn't fit the fixed list (e.g. "tonkotsu ramen", "omakase sushi", "okonomiyaki"), drop --cuisine and put the extra detail into --keyword instead. Cuisine + keyword can be combined in the CLI, but the MCP tool intentionally rejects keyword + cuisine; prefer the shared behavior of either supported cuisine-only search or best-effort keyword search.

2. Resolve the area

Pass the area in Japanese where possible (東京, 大阪, 渋谷, 京都, 三重). Romaji sometimes works, but Japanese is more reliable. Use the most specific area the user gave you — 渋谷 returns better results than 東京 if the user said "Shibuya".

3. Run the search

Default invocation — use JSON output so you can parse results cleanly:

gurume search --area <area> [--cuisine <jp-cuisine>] [--keyword <jp-keyword>] \
              --sort ranking --limit 10 --output json

Flag guidance:

• --sort ranking (default): good general "best of" results. Use review-count when the user wants popular/famous places, new-open for newly opened spots.
• --limit: 10 is plenty for a conversational reply. Bump to 20+ only if the user asks for a long list.
• --output json: preferred for agents. It returns status, items, meta, applied_filters, warnings, and structured error fields. Use legacy --output json-list only if you specifically need the old list-only shape.

4. Present results

After running, parse the JSON envelope. If status is error, surface error.message and error.suggested_action instead of inventing restaurants. Otherwise summarize items for the user. For each restaurant include:

• Name (keep the Japanese name; add a romaji/English hint only if it helps)
• Cuisine / area
• Rating and review count if present
• A one-line note (price range, station, what stands out)
• The Tabelog URL so they can click through

When the envelope includes warnings, account for them in your answer. When the command used both --area and --keyword, check meta.area_filter_confidence first. Treat low, missing, or unavailable confidence as low confidence unless the result URLs prove the requested area. Do not present broad keyword results as clean area-scoped recommendations. If the user asked for Osaka and the JSON includes non-/osaka/ URLs, say that the CLI returned mixed-area results and either keep only the clearly Osaka URLs or ask whether they want a broader keyword list. This mirrors the MCP tool's warning that keyword searches may need suggestion validation and cuisine-specific filtering. If MCP suggestions return a cuisine-like value that is not in gurume list-cuisines, keep using keyword search.

Then ask if they want to narrow down (different area, cheaper, dinner only, etc.).

Examples

User: "Looking for good ramen in Tokyo, ideally tonkotsu."

gurume search --area 東京 --cuisine ラーメン --keyword 豚骨 --sort ranking --limit 10 --output json

User: "Any famous sushi places in Osaka?"

gurume search --area 大阪 --cuisine 寿司 --sort review-count --limit 10 --output json

User: "Where should I eat dinner near Kyoto Station?" (no specific cuisine)

gurume search --area 京都駅 --sort ranking --limit 10 --output json

User: "I want sukiyaki in Mie prefecture."

gurume search --area 三重 --cuisine すき焼き --sort ranking --limit 10 --output json

Other commands (rarely needed)

• gurume list-cuisines — print the supported cuisine list. You usually don't need to run this because references/cuisines.md already has it cached; only re-run if the user suspects the list is outdated.
• gurume tui / gurume mcp — interactive TUI and MCP server. Don't invoke these from this skill; they're for the user to run themselves.

Notes & gotchas

• Tabelog HTML is the upstream source, so results occasionally contain odd encoding or missing fields. Handle missing keys gracefully when summarizing.
• The CLI hits the network — if it fails, surface the error to the user rather than fabricating restaurants.
• --area + --keyword can be broad even when applied text looks area-specific. Use URL evidence before claiming a result belongs to the requested area.
• Reply to the user in the same language they used (often Traditional Chinese, Japanese, or English).