How to use CODEX to track consumer goods prices - By Ian Han
Updated: Aug 4

<goal>
Create a reusable Codex skill named `daily-product-price-check`.
The skill must create or update a recurring automation that checks the live price of a user-provided product every day.
The default schedule is 10:00 am in the `Australia/Sydney` timezone unless the user specifies another time, timezone, or cadence.
</goal>
<context>
Users may ask Codex to monitor, watch, track, schedule, or check a product’s price regularly.
A typical request contains:
- A product URL
- An optional current, previous, or target price
- An optional preferred schedule or timezone
Retail product prices may be dynamically rendered. Cached search results, search snippets, and static HTML can therefore contain stale or incorrect prices.
A price should only be treated as confirmed when it is obtained from:
- A fresh render in an installed browser
- A reliable live product API for the exact product
- An equivalent live rendered source matching the user-visible product page
The default timezone must be `Australia/Sydney`, not fixed AEST, because Sydney switches between AEST and AEDT.
The skill should use Codex heartbeat/thread automations unless the user explicitly requests a standalone cron or workspace job.
</context>
<instructions>
1. Create the skill with this identity:
- Name: `daily-product-price-check`
- Folder: `daily-product-price-check`
- Trigger it when a user asks to monitor, watch, schedule, track, or check a product price daily or on a recurring schedule.
2. Extract the product URL from the user’s request.
- If no URL is provided, ask the user for it.
- Do not create the automation until the product URL is known.
3. Look for a comparison baseline in the request, including:
- Previous known price
- Current user-reported price
- Target price
- Discount threshold
4. If no baseline is provided:
- Report the observed price.
- Do not claim that the price has changed or remained unchanged.
5. Find and use the `automation_update` capability.
- Search for the tool if it is not already available.
- Inspect existing automations before creating a new one.
6. Prefer updating an existing matching automation over creating a duplicate.
- Match using the product URL, automation name, or automation prompt.
7. Create or update a heartbeat automation attached to the current Codex task.
- Only create a standalone cron or workspace job if the user explicitly requests one.
8. Schedule the automation:
- Default: every day at 10:00 am
- Default timezone: `Australia/Sydney`
- Respect any alternative cadence, time, or timezone supplied by the user.
- Use timezone-aware recurrence when supported.
- If UTC is required, calculate the conversion carefully and explain it.
- Account for Sydney daylight-saving changes.
9. Give the automation a descriptive name containing the retailer or product when identifiable.
- Example: `Daily product price check - Target jumper`
10. Build the automation prompt using this template:
Check the current live listed price for this product:
[PRODUCT_URL]
Use a real installed-browser render instead of a cached or static page path.
Report:
- Product name
- Current price in the product’s local currency
- Price in AUD if the local currency is different
- Whether the product is discounted
- Whether the price has changed from [BASELINE_PRICE], if known
- Discount or price-change amount
- Discount or price-change percentage
- Source link
- How the price was verified
11. Add these negative instructions to the automation prompt:
- Do not rely on cached search snippets.
- Do not rely on static HTML alone.
- Do not assume a previously observed price is still current.
- Do not confirm a price unless it appears in a fresh browser render, a reliable live product API, or an equivalent live rendered source.
- If rendered information conflicts with cached or static information, trust the rendered information.
- Never guess a price.
- If a live check cannot be completed, report: “unable to confirm current live price”.
12. Treat cached and static sources as weak evidence.
13. If browser access is blocked, sandboxed, unavailable, missing browser binaries, or rejected by the retailer:
- Mark the result as unconfirmed.
- Explain what prevented verification.
- Do not silently substitute cached search results or stale HTML.
14. When confirming the automation:
- State whether it was created or updated.
- State the interpreted schedule.
- State the timezone.
- Include the product or retailer name where identifiable.
</instructions>
<output_format>
Create a valid Codex skill folder containing:
daily-product-price-check/
└── SKILL.md
The `SKILL.md` file must contain:
1. YAML frontmatter with only:
- `name`
- `description`
2. A concise Markdown body containing:
- Overview
- Workflow
- Automation prompt template
- Verification rules
- Reporting requirements
- Timezone handling
When the skill creates or updates an automation, return a concise confirmation in this form:
Automation: [created or updated]
Name: [automation name]
Product: [product name or URL]
Schedule: [recurrence and local time]
Timezone: [timezone]
Baseline: [price or “not provided”]
Verification: Fresh installed-browser render or equivalent live source required
</output_format>

Comments