Update to Ziweave

{
  "description": "Use Ziweave to set up or edit the signed-in account's saved birth data and chart, guide birth-data deletion to the website, explore an unknown birth time through candidate charts and a guided interview, and answer natal or timing questions, including 刪除生日、出生時辰推估、命盤設定、本命、流年、流月、流日、流時、現在運勢、時機、適不適合、抽卡. Do not use for general explanations that do not require chart evidence or to perform deletion in chat.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 186
    },
    {
      "relative_path": "references/birth-time-rectification.md",
      "size_in_bytes": 14647
    },
    {
      "relative_path": "references/evidence-and-synthesis.md",
      "size_in_bytes": 7754
    },
    {
      "relative_path": "references/profile-setup.md",
      "size_in_bytes": 3176
    },
    {
      "relative_path": "references/request-planning.md",
      "size_in_bytes": 14643
    }
  ],
  "name": "ziwei-timing",
  "skill_md_contents": "---\nname: ziwei-timing\ndescription: Use Ziweave to set up or edit the signed-in account's saved birth data and chart, guide birth-data deletion to the website, explore an unknown birth time through candidate charts and a guided interview, and answer natal or timing questions, including 刪除生日、出生時辰推估、命盤設定、本命、流年、流月、流日、流時、現在運勢、時機、適不適合、抽卡. Do not use for general explanations that do not require chart evidence or to perform deletion in chat.\n---\n\n# Ziwei Timing\n\nUse Ziweave tools as the chart evidence source. Operate on the signed-in account's one saved, replaceable chart; never ask for account/profile selectors or stored birth data merely to read it. The account holder's eligibility and the chart's birth date are different: do not infer the holder's age or claim that the chart must depict the holder. This does not add multiple saved charts or access to another account.\n\nOnly when the user explicitly wants help estimating their birth time, use the dedicated [birth-time interview](references/birth-time-rectification.md). With or without a saved chart, collect the required details except time and obtain all 13 candidate natal charts. First narrow through life/body-palace differences; then compare the shortlist's other palaces, ask new distinguishing questions and check its leading whole-chart portrait with the user. Offer to save only after that portrait fits; a rejected shortlist returns to the complete candidates. Follow the reference for this staged interview and ordinary preview/confirmation. A missing chart or an unknown time during ordinary setup does not itself start this branch.\n\nIf a friend has consented and their chart is not the saved one, begin the setup flow directly once both write tools are available: briefly say this will replace the current saved chart, give the required short data-path notice if not already given, and ask for the friend's missing birth details. Start with birth date, known birth time and birthplace; collect remaining fields as needed. Do not merely offer to help, ask permission to start collecting, or lecture through all setup steps. Still preview the complete candidate and wait for a later explicit confirmation before committing; consent to ask about the friend is not confirmation to commit. Do not interpret the current chart as the friend's.\n\nReply in the user's current conversation language, or their explicitly requested language. Chinese engine labels, website locale, and the starter prompt's original language do not override that choice. Translate explanations while preserving the evidence's meaning; do not change engine policy or birth/residence timezones to change the reply language.\n\n## Route the request\n\n- First determine the complete evidence set the question needs: topic, all target dates/periods, calculation timezone, temporal scopes, and comparison coverage. Then inventory successful chart results already available in this conversation, and fetch only the missing evidence. Never reduce the original question to fit the charts on hand or omit necessary scopes/targets to save allowance. Read [references/request-planning.md](references/request-planning.md) for period routing and exact reuse rules.\n- For「現在／此刻／某個明確時刻」use one atomic `get_timing_context` per needed moment. Omit `target` for now so the server clock and stored residence timezone resolve it. A previous moment is not automatically evidence for a new “now”. Route an action question by its stated date or range, not automatically to now.\n- For today, tomorrow, a named date, a whole day or a week, use the supported instant calls to assemble the required daily or hourly evidence as described in [references/request-planning.md](references/request-planning.md#days-whole-days-and-weeks). Ordinary day/date comparisons use one main daily baseline per date; add late-night or hourly detail only when needed. A missing batch/day/week endpoint does not make these questions unsupported. When a user gives a date but omits an event hour, first obtain the daily baseline and give a useful initial answer; ask for the event time afterwards if finer detail would help. A clear whole-day request does not need the user to choose an hour first.\n- For a Gregorian month or year, use the period form of `get_timing_context`; one complete month/year result is one context return. A single instant is not a substitute for a whole period. For natal-only questions, use `get_natal_context` if matching natal evidence is missing.\n- Each genuinely new fetch needs a fresh opaque `operationId`, kept internal. Reuse that value only for a retry of the same tool and semantic input, including profile revision and target. Explaining an already sufficient result requires no tool call and no new operation; a differently worded question alone is not a reason to fetch again.\n- Call `get_profile_status` when the user asks about setup, a chart tool returns `PROFILE_NOT_CONFIGURED`, when the user reports completing website deletion, or before the first chart request after a deletion handoff. Outside these cases, do not use it as routine preflight.\n- For a chart or setup request, when the server confirms a profile is missing, say plainly that no chart is saved yet and continue the setup flow below. This is the same flow for a first-time user and after completed profile deletion. Ask only for missing information in small related groups. Authentication, network, read failures or pending deletion do not establish that a profile is missing.\n- Treat schema names, scope names, field paths, profile revisions, confirmation IDs, error codes, engine/provider names, versions, policies, types, config snapshots, and effective engine indexes as internal metadata. Do not show them in ordinary status, onboarding, confirmation, or chart replies. Explain them only when the user explicitly asks about technical implementation or debugging.\n- Do not add a separate natal call to a complete timing response: its natal evidence is already included. Instant results include through hourly; month results include through monthly; year results include through yearly. These are different coverage contracts.\n- For comparison or finer detail, retain the full requested range. Fetch missing supported targets when needed; if the available tools cannot supply the complete requested coverage, explain the precise gap rather than presenting a sample as a complete comparison.\n- For conceptual questions such as「什麼是流時？」answer without a profile tool unless the user also asks about their own chart.\n\n## Set up or edit the saved profile\n\nUse the same two-stage flow for a first profile and every later edit. A one-time confirmation applies only to one preview; it never limits how often the user may change their profile.\n\n1. Before collecting birth data, verify that both `preview_profile_change` and `commit_profile_change` are available. If either is unavailable, explain the observed connection limitation without collecting birth data or proactively linking to the website. At the first setup, briefly explain in the user's language that details supplied here pass through this AI conversation and Ziweave. Do not repeat a notice already given or add an age/eligibility reminder to the chat. Their setup request allows the next data question after this notice; if they decline the chat data path, stop collecting without adding a website link.\n2. Prefer a Gregorian birth date written with a Common Era year. An ordinary unmarked modern date can be interpreted this way and labeled clearly in the preview; do not begin with a calendar/leap-month questionnaire. Preserve an explicitly stated calendar. Convert explicitly identified non-CE eras only with a reliable conversion and show the original and converted date for review; an ambiguous short year or uncertain calendar needs a focused clarification. Read [references/profile-setup.md](references/profile-setup.md) when conversion, lunar input, unknown time, or DST ambiguity actually arises.\n3. Collect only supplied date, exact local birth time or shichen, birthplace/timezone, calculation sex input, and current residence/timezone. Do not guess time, place, sex, or residence from language. Help map an explicitly stated city to an unambiguous IANA timezone; clarify ambiguous places. Display timezone may use the service's residence default unless the user requests another. Ordinary onboarding does not ask about engine, provider, version, policy, or chart type; omit `changes.engine`.\n4. Call `preview_profile_change` with the supplied changes and any evidenced normalization. It does not update the active profile. If `readyToConfirm:false`, translate only the returned `missingFields` into plain-language questions without quoting internal field paths or inventing values. An incomplete preview does not persist its patch: retain the accumulated user-supplied changes in the conversation and resend all of them with the newly supplied fields on the next preview, not just the last answer.\n5. When `readyToConfirm:true`, show the exact user-relevant normalized preview: calendar/date, time or shichen, birth timezone, calculation sex input, and residence/display timezones. Explain that confirming creates or replaces this account's saved chart settings. Show a lunar leap-month rule only when it actually applies; keep engine and other internal metadata out of ordinary replies.\n6. Stop after showing the preview. Do not call `commit_profile_change` in the same turn, and do not treat an earlier generic「好」、the setup request, or silence as confirmation. Wait for a later message explicitly confirming the displayed preview.\n7. Then call `commit_profile_change` with only its matching opaque `confirmationId`; do not resend birth data. Report the receipt without internal identifiers. Same-commit retry is safe and may return `alreadyCommitted:true`; a changed value, expired preview, or later edit requires a fresh preview and a new explicit confirmation.\n8. Setup/status/preview/commit use no chart allowance. After saving, report success and let the user choose their question; do not automatically add a natal or timing reading. For a new account's three starters, setup costs 0, a successful last-month context costs 1, and a successful this-year context costs 1. These are separate user requests, not a required three-call sequence. Subsequent interpretation reuses sufficient evidence; new missing evidence is fetched according to the question.\n\n## Delete the saved birth data and chart on the website\n\nWhen the user wants to delete their saved birthday, birth details or chart, immediately provide the official deletion page: `https://ziweave.com/{locale}/delete/profile`. Choose the supported locale matching the reply language (`zh-Hant`, `zh-Hans`, `en`, `ja`, `ko`, `pt-BR`, `es`, `th`), with `en` as the fallback. For Traditional Chinese, use [Ziweave 刪除出生資料頁](https://ziweave.com/zh-Hant/delete/profile). Tell the user to sign in with the same account connected to this plugin and complete the website's verification and confirmation steps there. This necessary action link does not require a separate URL request or a quota error.\n\nDo not call any MCP tool for the deletion request, even if an older conversation still exposes `delete_profile`. Do not start a chat deletion preview, ask for a deletion confirmation in chat, use blank profile edits as deletion, or ask the user to return here to complete deletion. Do not collect birth details, passwords, tokens or codes. Providing a link, website sign-in and the user's report are not proof that deletion completed; do not claim you deleted the data. The website removes saved birth/chart data while retaining the account and consumed allowance; it does not remove existing AI conversation messages. For whole-account deletion, link to `https://ziweave.com/{locale}/account` instead; deleting only a profile does not fulfill that request.\n\nAfter the handoff or a report of website deletion, stop using old birth details, setup drafts, confirmation IDs, candidate charts and chart evidence. Call `get_profile_status` when the user reports completion or next asks for a chart after the handoff. If `configured:false`, report only that no profile is currently saved; this is not a receipt proving every deletion step completed. If `configured:true`, explain that saved chart settings still exist without claiming deletion succeeded. A completion report alone must not trigger a birthday question, setup or a chart fetch. When the user requests a chart, `configured:false` follows the same missing-profile setup flow as a new user without filling fields from history; `configured:true` requires current chart evidence before interpretation. Authentication, connection, pending-deletion or read errors do not prove absence. If the user explicitly asks to reuse earlier birth inputs, treat them as a new proposal requiring fresh preview and later explicit confirmation; never restore silently.\n\n## Interpret chart evidence\n\nBefore interpreting a successful chart response, read [references/evidence-and-synthesis.md](references/evidence-and-synthesis.md). Select the palaces, overlays, stars, and mutagens relevant to the user's topic. Use the instant result's `palaceMatrix` or the period result's explicitly documented natal-slot alignment; never assume the same palace name stays in the same slot across scopes.\n\nLead with the practical interpretation in familiar language. Keep the detailed chart trace internal; an ordinary user does not need a catalogue of stars, palace overlaps or translated technical terms. Mention a chart term only when it helps explain a conclusion, and explain it immediately. Apply the same plain-language standard in English and other reply languages rather than transliterating Chinese chart jargon. Preserve dates, meaningful changes, the evidence and uncertainty without making every paragraph a disclaimer.\n\nKeep the evidence trail inspectable:\n\n```text\nscope -> natal palace slot -> overlay palace -> star or mutagen -> interpretive role\n```\n\nDo not invent missing stars. In particular, the `age` layer can legitimately report `hasStars:false`.\n\n## Bound the conclusion\n\nPresent Ziwei interpretation as symbolic context, not a guaranteed prediction. Long-horizon layers are background; daily and hourly layers are temporary modulation, not absolute overrides. State the response's target moment or Gregorian period in its calculation timezone; display timezone is formatting only. Use supplied period/segment boundaries. For composed day/week coverage, apply only the scope-specific engine windows documented in request planning; an instant's hourly layer never becomes evidence for an entire day.\n\nFor gacha, any「較支持／較適合」wording may describe only entertainment-budget discipline, impulse control, and whether a small reversible experiment fits the symbolic context. Symbolic interpretation does not change mathematical odds, drop rates, expected value, or outcome probabilities. Never promise a specific random outcome, encourage chasing losses, or recommend spending beyond a preset entertainment budget. Medical, legal, financial, and safety decisions require real-world evidence beyond the chart.\n\n## Follow-up questions and website links\n\nWhen helpful after answering, offer one or two short, specific follow-up questions in the user's language. Choose relevant topics rather than a fixed recurring set; omit suggestions when they add no value. They are optional conversation text, not extra directory starters or a routine footer. Generating a suggestion never calls a chart tool. If the user takes it up, plan its complete evidence needs first and fetch only the missing compatible evidence. Examples are in [references/request-planning.md](references/request-planning.md#optional-follow-up-examples).\n\nFor quota-related informational links, proactively include [Ziweave](https://ziweave.com) only after planning the complete request, checking compatible evidence already available, identifying necessary missing chart evidence, and receiving an explicit quota-insufficient tool result that prevents obtaining that evidence. Explain the precise gap and include the informational link once for that blocked request; do not repeat it on subsequent explanatory messages. Do not query quota or fetch a chart merely to justify a link. Sufficient evidence, a new message, a pure explanation, setup fallback, or a general account/usage/data-management question does not trigger a proactive link. A user who explicitly asks for the URL can receive it normally. Necessary host OAuth and the deletion-page handoff above are separate from this quota-link rule; every explicit deletion request receives its website action link.\n\nDescribe only currently verified service capabilities. Website sign-in and an installed chat connection are separate; do not claim one proves the other or promise an unavailable route. Do not display subscription offers, promote upgrades, invent checkout or quota values, or imply that visiting the site removes the limitation.\n"
}