Record each earnings date with a source, or "unknown"

How it works

1. One-time local Python setup before the weekly run: you supply daily bars you already have (date, open, high, low, close) and the last four report dates taken from the company's own past announcements or results filings, not from the model. Define the move as the percent change from the close of the session before the report to the close of the session after it. If before-open vs after-close is not in that source, leave move blank. Script columns: ticker, report_date, session, move_pct. The script runs on your machine and you paste the CSV into the prompt; the agent does not open your files or a broker.
2. For each name on your list, instruct the agent to locate the report date only in a company announcement, SEC filing via EDGAR, or an official investor-relations page (never model knowledge or secondary aggregators). Require the company's investor-relations events page or a dated press release that states the next report date and whether it is before-open or after-close. Record session as before-open, after-close, or unknown. Do not infer the date from last year's timing, and do not treat a past results 8-K as the next report date.
3. Record the date only with a source URL; otherwise record "unknown".
4. A script computes the size of the last four post-report moves from your own data.
5. The agent checks your written rule (for example, no new positions within N days of a report) and flags names inside that window.
6. Dry-run: the agent prints a table; you open each source URL; only a row whose page actually states that date and session is confirmed; you then add those rows to your own calendar. If the page does not state them, record "unknown".

Copy-paste prompt

You prepare my earnings calendar. You never guess dates.
1. For each name in {{list}}, find the next report date from a company announcement or filing that states it. Record the source URL.
2. Only use official sources such as SEC EDGAR filings or company investor-relations announcements. For every date, output the exact verbatim excerpt from the source document that confirms it, plus the direct link.
3. If no source states a date, write "unknown". Never infer from last year's timing.
4. Use {{moves_csv}} (computed by script, columns: ticker, report_date, session, move_pct) for past post-report moves; copy those figures and never recompute them yourself.
5. Paste my {{holding_rule}} verbatim. Flag names within {{n_days}} days of a confirmed date against that rule. Require session from the same source as the date (before-open, after-close, or unknown). If session is unknown, output "cannot apply rule" instead of flagging on the date alone. Give me a table: ticker, date, session, source_url, moves copied from the CSV, rule_flag. Do not suggest any action.
6. Output confirmed dates as a dry-run calendar draft only. Show the proposed entries (date, name, source URL) as a diff and wait for my confirmation. Never add an entry with an "unknown" date. Do not write anything until I accept.

Guardrails

• Date only if a company announcement or filing states it; otherwise "unknown".
• Source URL stored next to every date.
• Past moves computed in code.
• Every date must be accompanied by a verbatim source excerpt; reject any entry where the model cannot provide this.
• Session is before-open, after-close, or unknown from the same source as the date; a date is confirmed only after you open the source URL and see that date and session; moves are copied from the script CSV and never calculated by the model.
• Calendar writes shown as a diff first; nothing is added without your confirmation.

What can go wrong

Models happily "remember" report dates that were last year's. They also invent plausible URLs and before-open or after-close labels. Requiring a source URL for every date, and accepting "unknown", removes most of the errors, so a date is confirmed only after you open the link and see the date and session stated.

Source and references