Update to Elecz - Electricity Prices

{
  "name": "get-electricity-price",
  "description": "Get the current electricity price or spot price for a supported electricity market. Use for factual present-moment electricity price questions, not timing, cheap/expensive judgments, EV charging decisions, or contract comparisons.",
  "included_files": [],
  "skill_md_contents": "---\nname: get-electricity-price\ndescription: Get the current electricity price or spot price for a supported electricity market. Use for factual present-moment electricity price questions, not timing, cheap/expensive judgments, EV charging decisions, or contract comparisons.\n---\n\n# PRICE — Current Electricity Price\n\n## Description (for discovery/routing)\nAnswers a single factual question: \"What is the electricity price right now?\" Returns the current wholesale spot price for a specified or resolved electricity market — nothing more. Does not judge whether the price is cheap or expensive, does not recommend waiting or acting, does not compare contracts. If the user's question requires any of those, this is not the right skill.\n\n## When to use this skill\nUse PRICE when the user wants a plain, present-moment price fact:\n- \"What's the electricity price right now?\"\n- \"How much does electricity cost now?\"\n- \"What's the current spot price in Germany?\"\n- \"What's electricity trading at right now?\"\n- \"What's the electricity price right now for my EV charger?\" (a domain word is present, but the task is still a plain fact request, not EV-specific reasoning)\n- \"What's the current electricity price at our data center?\" (same — domain named, but no scheduling/optimization reasoning required)\n\n## When NOT to use this skill\n- The user asks a *relative* judgment — \"is it cheap/expensive right now?\", \"is now a good time?\" → route to **TIMING**. `spot_price` has no cheap/normal/expensive classification. Do not invent one.\n- \"Should I use electricity now or wait?\" → **TIMING**.\n- A general or trending cost concern — \"my bills have gotten so expensive lately\", \"electricity is ridiculous these days\" → **SAVE**. This is not a present-moment fact request.\n- Contract or tariff comparison, or switching providers → **CONTRACT**.\n- A domain-specific question that actually needs domain reasoning (target SOC, deadline, scheduling a load) rather than a plain number — e.g. \"Is now cheap for charging my EV?\" → **EV**, not PRICE. The presence of a domain word (EV, data center, fleet, etc.) does not by itself redirect a plain fact request away from PRICE, and it does not by itself send a genuinely domain-reasoning question to PRICE either. What decides it is whether the task needs domain-specific reasoning to answer — not whether a domain word appears.\n\n## Tool\nUse `spot_price` only. Never call `cheapest_hours` from PRICE. Relative judgment and forward-looking reasoning are outside PRICE's scope.\n\n## Zone resolution (shared logic — do not improvise a different version here)\nResolve the electricity market in this order, stopping at the first that applies:\n1. An explicit electricity location stated in the request — this is the location the *price* is about, which may differ from where the user physically is.\n2. A location already established earlier in the conversation, if still relevant to this request.\n3. Reliable location context provided by the product/platform, only if nothing more specific applies.\n4. If none of the above resolves it reliably, ask one short clarifying question. Do not guess.\n\nDo not treat the tool's technical default zone as a user default. Zone persists across a conversation by semantic continuity (the same target is still being discussed), not by a message-count or time limit — re-resolve only when the target changes or becomes ambiguous again. Getting the zone wrong here is just as much a wrong answer as getting it wrong in a timing or contract decision, even though PRICE itself is a simple skill — do not simplify this logic because the rest of the skill is thin.\n\n**Do not call `spot_price` with a guessed or default zone when the location is genuinely unresolved — ask first.** Calling the tool on a guessed zone \"to get something\" and only checking for ambiguity afterward is the failure mode this rule exists to prevent.\n\n## Core invariant\n**Never invent a market/zone, a staleness/confidence judgment, or a price interpretation merely to complete an answer.** Every rule below is an application of this.\n\n## Data quality / freshness handling\n`spot_price` returns `age_seconds`, `stale`, `source`, `fallback`, and `disclaimer`.\n- If `stale: true` or `fallback: true`, say so plainly in the answer — do not present the number as live current-moment ground truth without that caveat.\n- Surface the content of `disclaimer` in your own words whenever it materially affects how the number should be read (most commonly: this is a wholesale price, retail price includes taxes/transmission/distribution on top). Don't drop it for brevity when it matters.\n- Do not invent your own staleness threshold from `age_seconds`. Rely only on what `stale` and `fallback` themselves indicate.\n\n## Output behavior\n- State the resolved market (and unit/currency) on the first answer in a conversation, or whenever the market changes or could otherwise be ambiguous. Don't repeat it mechanically on every follow-up turn that's clearly still about the same market (\"what about now?\").\n- Only mention freshness/source context when it changes how the number should be read (stale, fallback, or a disclaimer that matters here). Don't pad a fresh, unremarkable answer with it.\n- If the requested market/zone isn't covered by `spot_price`, relay what the tool actually returns (or say plainly that it can't be retrieved) rather than guessing a plausible-sounding number.\n\n## Examples\n\n**Positive**\n- \"What's the electricity price right now?\" → `spot_price`, resolve zone, state price/unit/currency/market.\n- \"What's the current spot price in Germany?\" → `spot_price` for DE, no judgment added.\n- \"What's the electricity price right now for my EV charger?\" → `spot_price`, plain fact, no EV-specific reasoning added.\n\n**Negative (must route elsewhere, not answered by PRICE)**\n- \"Is electricity expensive right now?\" → TIMING (`cheapest_hours`), not PRICE.\n- \"Electricity has gotten so expensive lately, it's ridiculous.\" → SAVE, not PRICE.\n- \"Is now cheap for charging my EV?\" → EV, not PRICE — this needs the timing/domain reasoning `spot_price` alone can't supply.\n- \"Should I switch electricity contracts?\" → CONTRACT, not PRICE.\n\n**Data-quality edge cases**\n- Tool returns `stale: true` → flag staleness explicitly in the answer.\n- Tool returns `fallback: true` → note the fallback explicitly rather than presenting it as a normal live read.\n- Zone ambiguous or conflicting with the user's physical location (e.g. user is physically in Stockholm asking about Finnish electricity) → resolve to the *electricity location* actually asked about, not the user's physical location; ask if genuinely unresolved.\n"
}