Hunch Tarot

View saved version →

---
name: daily-tarot
description: Create a personal Hunch tarot card of the day from a confirmed selfie and profile, with the complete reading. Use for daily cards and personal tarot questions, and to arrange recurring daily cards when the user requests them and the chat supports scheduling with Hunch tools and uploaded files.
---

# Daily Tarot

Use the Hunch MCP tools available in this chat. Card generation and readings come from Hunch; never fabricate a generated card, ticket or successful schedule.

## Find and confirm the details

Before asking questions, review the current conversation and use focused, authorised memory, previous-chat search or file-library tools only if the host actually provides them. Find the user's own name, date of birth, stated artwork preference, current question and chosen selfie. Do not claim access to unavailable history or files. Do not extract or infer a birthday, identity, gender, personality or private circumstances from a face. A selfie supplies the artwork reference, not verified profile facts.

Reuse the most recent unambiguous information. Resolve conflicting facts and ask which image to use when several are plausible. Ask only for missing required information. The current creation tool requires name, birthday, gender (woman/man, used as the confirmed artwork option), challenge and a host-resolvable selfie file. Explain the supported artwork options if needed; never silently choose one from appearance.

Present a short filled-in summary with name, birthday, artwork option, question/theme and selfie filename or preview. If no theme is known, propose “What should I pay attention to today?” as an editable default. Say “Hunch uses these details and your photo to create your personal card.” End with “Confirm or edit.” No separate processing-consent checkbox or repeated confirmation for unchanged details already explicitly approved. Pass only approved profile fields and the selected selfie, never the conversation history.

## Create and present one card

1. After confirmation call `hunch_prepare_card` once. Keep its ticket private and preserve it for this request's retries.
2. Call `hunch_create_personal_card` with the ticket, confirmed fields, `consent=true`, and a current host-provided selfie file reference. Allow the host to resolve the file to a fresh download URL. Never invent a URL or reuse an expired download link.
3. While it runs, show “Creating your card…”. The creation call waits for completion. Do not automatically poll or call `hunch_get_personal_card` after it.
4. On completion, show its single artwork widget and send the returned `message` verbatim as normal chat Markdown, preserving the entire reading and all emoji and formatting. The widget itself contains no reading.
5. For an interrupted/unknown result, retain the ticket and explain that creation is still unconfirmed. Check the same request only when the user asks. Never generate a replacement for an uncertain result. On an upload failure before generation, reuse the ticket with a refreshed authorised file reference. Honour quota/errors; do not create tickets to bypass limits.

When asked to reopen a card, use `hunch_get_personal_card` with the existing unexpired ticket and show its full reading. WhatsApp, Telegram and iMessage buttons transfer the same completed card; the user sends the prepared message or presses Start. Opening a button is not confirmed delivery.

## Offer or arrange daily delivery

After a successful first card, unless the user already declined or a schedule exists, offer once: “Would you like a fresh Hunch card here every day? What time and time zone?” Installing the plugin or requesting a single daily card does not authorise a recurring task.

If the user already explicitly requested daily delivery, use that authorisation. Ask only for missing time/time zone, and confirm reuse of the approved profile, selfie and daily theme as part of the setup if that reuse was not already requested. Do not infer a t

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.