Appy Coupons - deals+discounts

View saved version →

---
name: coupon-expiry-reminder-setup
description: Prepare a coupon-expiry reminder when the user asks to be reminded before an offer ends. Show the relevant offer with the `coupons` app tool, resolve an exact reminder time and timezone, and guide the optional widget or host scheduled-task flow. Never claim a button was clicked or a reminder exists without host-visible confirmation.
---

# Coupon expiry reminder setup

Prepare a precise, one-time reminder handoff for a coupon with a stated expiry.

## Inputs

Resolve the target coupon, its explicit expiry date, the desired lead time or reminder date and time, and the user's timezone. Ask when any of these details are ambiguous or when multiple coupons could be the target.

## Workflow

1. Identify the coupon from user-supplied data or model-visible `coupons` structured content. Do not rely on private widget state, including the expanded row.
2. Require an explicit, unambiguous expiry. If the expiry is missing or uncertain, ask the user for it rather than creating a speculative reminder.
3. Resolve an exact future reminder date, local time, and timezone that fall before the stated expiry. For a date-only expiry, do not invent an expiry hour; schedule on an earlier date at a user-approved time.
4. Call `coupons` with the relevant offer before the task handoff. Preserve its facts and append the stated expiry and reminder target to `notes`. Do not call the tool with an empty list.
5. Tell the user to use the widget's task or reminder action if one is visible. The action is runtime-configured and may be absent. Do not say that you selected it.
6. Provide a copy-ready fallback prompt containing the coupon name, code when present, source URL when present, exact reminder timestamp and timezone, stated expiry, and important restrictions. The user can submit it through a host that supports scheduled tasks.
7. Confirm creation only after the host returns explicit confirmation. Otherwise describe the reminder as prepared, not scheduled, and tell the user where confirmation should appear.

## Boundaries

- The `coupons` MCP tool cannot create, inspect, update, or verify scheduled tasks.
- This skill cannot see or click widget-only controls.
- Scheduled-task availability depends on the host, workspace settings, and runtime widget configuration.
- Do not promise that a reminder will run, and do not turn a one-time expiry reminder into recurring coupon monitoring without a separate user request.

## Output

Return the relevant coupon widget, the resolved reminder details, and either task-action guidance or a copy-ready scheduling prompt.

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

View saved version →

---
name: coupon-expiry-triage
description: Triage supplied or previously displayed coupons by expiry when the user asks what expires soon, what is still usable, or what to prioritize. Resolve only explicit, unambiguous dates, order eligible offers by urgency, and present them with the `coupons` app tool. Never invent or independently verify an expiry date.
---

# Coupon expiry triage

Turn coupon expiry information already present in the conversation into an urgency-ordered review.

## Inputs

Use coupon data supplied by the user or returned as model-visible structured content by `coupons`. Establish the reference date, timezone, and urgency window. Use seven calendar days as the urgency window when the user does not specify one, and state that choice.

## Workflow

1. Extract only explicit expiry information from coupon descriptions, notes, and supporting sources already available in the conversation.
2. Resolve relative dates only when their reference date is known. Treat ambiguous numeric dates, unsupported relative phrases, and missing timezones as unknown when choosing an interpretation could change the result.
3. Classify each coupon as expired, ending today, urgent, later, or unknown. A coupon is urgent when its stated expiry falls within the chosen urgency window.
4. Exclude expired coupons from the widget unless the user asks to see them. Order the remaining dated coupons by earliest expiry, followed by coupons with unknown expiry.
5. Preserve each coupon's original facts. Add a concise expiry status to `notes`, without replacing existing restrictions or presenting an unverified date as fact.
6. Call `coupons` only when at least one active-or-unknown coupon remains. Keep the triage order in the input array and include a concise `reason`.
7. Report the next stated deadline, counts by status, the reference timezone, and any dates that need clarification.

## Boundaries

- Do not treat absence of an expiry date as proof that an offer is ongoing.
- Do not claim a coupon is currently valid; say it is not shown as expired based on the supplied terms.
- Do not use private widget state, such as which row the user expanded, to identify a coupon.
- The `coupons` tool cannot verify dates or schedule reminders. If no eligible coupon remains, answer in text instead of calling it with an empty list.

## Output

Return an urgency-ordered coupon widget and a compact expiry summary.

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

View saved version →

---
name: coupon-stacking-plan
description: Build a conservative coupon stacking and fallback plan when the user asks whether supplied coupons can combine or which order to try at checkout. Use explicit merchant terms and cart facts, distinguish confirmed compatibility from unknown compatibility, and present the attempt order with the `coupons` app tool. Never claim an untested stack will work.
---

# Coupon stacking plan

Convert supplied coupon terms into an evidence-based checkout attempt order.

## Inputs

Identify the candidate coupons, merchant, market, checkout channel, relevant cart items and total, user eligibility, and savings goal. Ask for a missing cart fact only when it changes eligibility or ranking.

## Workflow

1. Extract stacking, minimum-spend, product, membership, channel, expiry, and exclusion terms from the information already supplied. Do not substitute general retailer assumptions for missing policy.
2. Classify each relationship as confirmed combinable, confirmed incompatible, or unknown. Reserve confirmed combinable for terms that explicitly allow the combination.
3. Remove offers known to be expired or ineligible. Estimate savings only from explicit discount mechanics and available cart facts; label estimates and omit taxes, shipping, or category assumptions that are not supplied.
4. Build a primary plan from confirmed-compatible offers only. When no combination is confirmed, choose the strongest eligible single offer as the first attempt and keep other offers as fallbacks. Put unknown combinations in a separately labeled checkout test, never in the confirmed plan.
5. Order coupons in the sequence the user should attempt them. Preserve each offer's facts and append a short stacking status and rationale to `notes`.
6. Call `coupons` when the plan contains at least one candidate, using the planned attempt order and a concise `reason`.
7. Explain the primary plan, fallbacks, unknown tests, and the evidence behind each classification. Tell the user to review the checkout total before placing the order.

## Boundaries

- The app can display and copy coupon codes, but it cannot apply codes, inspect a checkout, redeem an offer, or observe whether a merchant accepted a stack.
- Do not call an unknown combination compatible merely because neither coupon says otherwise.
- Do not state a final savings amount when required cart details are missing.
- Do not call `coupons` with an empty plan.

## Output

Return the ordered coupon widget plus a concise primary plan, fallback sequence, and uncertainty notes.

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

View saved version →

---
name: source-backed-coupon-shortlist
description: Find and present current, source-backed coupons when the user asks for promo codes, discounts, or offers for a merchant, product, or category. Use browsing or search before calling the `coupons` app tool, and include only offers supported by opened sources. Requires a host browsing capability; never fabricate current offers or claim a code was successfully tested.
---

# Source-backed coupon shortlist

Build a small, current coupon shortlist from evidence, then present it with the app.

## Inputs

Identify the target merchant, product or category, market, and any material eligibility or cart constraints. Ask only for missing details that would change which offers qualify.

## Workflow

1. Confirm that a browsing or search capability is available. If it is not, explain that this app cannot discover current coupons and ask the user to provide offers or source links for normalization.
2. Search for current offers and open the supporting pages. Prefer the merchant's official promotion, help, membership, or product pages; use reputable secondary sources only when the source type is clear. Treat search snippets as leads, not evidence.
3. Capture only terms supported by the opened source: offer, code, eligibility, minimum spend, exclusions, expiry, market, and redemption channel. Label unresolved details as unknown instead of inferring them.
4. Remove duplicates, expired offers, and entries whose advertised terms cannot be tied to a relevant URL. Rank the remainder by source quality, relevance to the request, and clarity of terms.
5. Map each retained offer to the registered `coupons` tool. Supply non-empty `name` and `description`; use `code`, `notes`, `displayDomain`, and `url` only when supported. Put material restrictions, the source type, and the date checked in `notes`.
6. Call `coupons` only when at least one supported offer remains. Preserve the ranking in the array order and give a concise `reason` for presenting the shortlist.
7. Summarize the search coverage, date checked, strongest source, and any important uncertainty outside the widget.

## Boundaries

- The `coupons` tool only displays supplied coupon objects; it does not search, validate freshness, test codes, or redeem offers.
- Do not describe an offer as working or verified at checkout unless direct evidence establishes that claim. Prefer "listed" or "source-backed."
- Do not invent codes, expiry dates, eligibility, savings, or restrictions.
- Do not call `coupons` with an empty list or raw search snippets.

## Output

Return the coupon widget followed by a short evidence summary and practical caveats.

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