Update to Revelata deepKPI

{
  "description": "Pressure-test any analyst report on a US public company. Upload a PDF of a sell-side report and say \"Pressure test this\" — the skill extracts the analyst's key arguments, pulls granular SEC filing data via deepKPI to build supporting and counter-evidence for each claim, then produces an interactive HTML report with Revelata dark branding, Chart.js visualizations (blue palette), source attribution (amber = analyst, cyan = SEC), and clickable provenance hyperlinks to the exact filing passages. Use whenever the user mentions \"pressure test\", \"pressure-test\", \"critically analyze\", \"triangulate\", \"fact-check\", or \"challenge\" in the context of an analyst report, research note, or investment thesis. Also triggers when the user uploads a PDF that looks like a sell-side report and asks for analysis, counterpoints, or a second opinion on it.\n",
  "included_files": [
    {
      "relative_path": "evals/evals.json",
      "size_in_bytes": 1567
    },
    {
      "relative_path": "references/chart-patterns.md",
      "size_in_bytes": 2782
    },
    {
      "relative_path": "references/double-check.md",
      "size_in_bytes": 19435
    },
    {
      "relative_path": "references/html-template.md",
      "size_in_bytes": 25953
    }
  ],
  "name": "pressure-test",
  "skill_md_contents": "---\nname: pressure-test\ndescription: >\n  Pressure-test any analyst report on a US public company. Upload a PDF of a sell-side\n  report and say \"Pressure test this\" — the skill extracts the analyst's key arguments,\n  pulls granular SEC filing data via deepKPI to build supporting and counter-evidence\n  for each claim, then produces an interactive HTML report with Revelata dark branding,\n  Chart.js visualizations (blue palette), source attribution (amber = analyst, cyan = SEC),\n  and clickable provenance hyperlinks to the exact filing passages. Use whenever the user\n  mentions \"pressure test\", \"pressure-test\", \"critically analyze\", \"triangulate\", \"fact-check\",\n  or \"challenge\" in the context of an analyst report, research note, or investment thesis.\n  Also triggers when the user uploads a PDF that looks like a sell-side report and asks\n  for analysis, counterpoints, or a second opinion on it.\n---\n\n# pressure-test\n\nTake an analyst report and rigorously test every argument against SEC filing data.\nThe output is an interactive HTML report that a portfolio manager can open in a browser\nand use to form an independent view — every number is clickable back to its source.\n\n## Data source\n\nSee `../_common/data-source-rules.md` for the runtime routing table and the canonical\ninventory of deepKPI operations.\n\n## Hard stop if deepKPI access fails\n\nSee `../_common/connection-failure.md`. STOP and ask before falling back.\n\n## When this skill triggers\n\n- User says \"pressure test this\" (or similar) with an uploaded analyst report\n- User uploads a sell-side PDF and asks for critical analysis, counterpoints, or fact-checking\n- User asks to \"triangulate\" or \"challenge\" an investment thesis\n\n## Chat pacing and verbosity\n\nKeep the **conversation** thin; put the depth in the **HTML report**.\n\n- After reading the PDF, state the **4–6 main arguments** you will pressure-test\n  (short titles or one line each — this is the roadmap for the user).\n- Treat each request as self-contained: **do not reference, compare to, or borrow from any other analyst reports** you may have analyzed earlier in the same chat/session unless the user explicitly asks you to do so. Assume you are pressure-testing **only the report(s) uploaded with the current request**.\n- Also state you'll pull **market reaction context** (price on report date vs today),\n  then move straight into data pulls.\n- Do **not** narrate every tool call, intermediate table, or reasoning step in chat.\n  Avoid dumping raw deepKPI responses into the thread.\n- While pulling data, use a **brief progress line per argument**, e.g.\n  `Pulling SEC data for 2/5: [short argument title]…` then continue silently until\n  the next argument or until the HTML is ready.\n- **Automatically build and save the HTML report** when pulls and drafting are\n  complete. Do **not** ask whether to generate the file unless the user explicitly\n  asked for a non-HTML deliverable only.\n- **Before presenting the HTML**, run the **pressure-test double-check** pass\n  (see below). In chat, a single line is enough, e.g. `Running pressure-test QA on the draft HTML…`\n- After the artifact is **double-checked** and any **Critical** issues are\n  addressed (or explicitly accepted by you as the authoring agent): **present**\n  the file (`present_files` or equivalent) and add **1–2 sentences** on the\n  sharpest takeaway — no full recap.\n\n## High-level workflow\n\n1. **Read the report** — extract the analyst's 4-6 key arguments/claims\n2. **Identify the company** — resolve the ticker/name to a CIK via deepKPI\n3. **Pull SEC data** — for each argument, search deepKPI for the most granular\n   metrics that can confirm or complicate the claim\n4. **Build evidence pairs** — for each argument, write a \"supports the thesis\"\n   card and a \"complicates the thesis\" card, grounded in specific numbers\n5. **Write the synthesis** — 2 paragraphs that weave the evidence into a nuanced\n   take the analyst didn't give you\n6. **Generate the HTML** — an interactive, dark-themed report with Chart.js charts,\n   source attribution, and provenance links (**default deliverable — produce it without asking**)\n7. **Double-check the draft HTML** — mandatory QA pass before the user sees the file;\n   structured review only (see **Step 7**)\n8. **Revise and iterate** — you decide which findings to fix; re-run the double-check\n   after material edits until **Overall: Pass** or remaining issues are only **Suggested** / **Optional**\n9. **Deliver** — present the final HTML to the user (**short wrap-up only**)\n\nEach of these steps is detailed below. Follow **Chat pacing and verbosity** for what to say in-thread vs. what belongs only in the HTML.\n\n## Dependencies\n\nThis skill relies on the `kpi` skill for **KPI** retrieval and on the `filing`\nskill when you need **verbatim SEC filing passages** or **full filing markdown**\n(not just structured metrics). Consult the `kpi` skill for metrics workflow,\nprovenance, and gaps; consult the `filing` skill when claims must be checked\nagainst exact filing language. Use the `company-summary` skill for **business\ndescription**, **segment structure**, or **thematic** lists when helpful (not\nrequired for every run). Use the `implied-metric` skill when filling Q4 or\nsegment gaps. This skill handles the analytical framework and HTML output.\n\nFor the mandatory QA rubric on the finished HTML, read **`references/double-check.md`**\n(internal to this skill — not a separate user-facing skill).\n\n## Scope\n\nThis skill works for **US public companies** with SEC filings indexed in deepKPI.\nIf the report covers a non-US company or a private company, tell the user that\ndeepKPI doesn't have coverage and offer to do a qualitative analysis instead\n(without the data-backed evidence cards and provenance links).\n\n---\n\n## Step 1: Read the analyst report\n\nRead the uploaded PDF. Extract:\n\n- **Company name and ticker**\n- **Report metadata**: author/firm, date, rating action (upgrade/downgrade/initiation),\n  price target if applicable. Store the firm name internally for source pills and claim\n  banners, but **do not surface the firm name in the footer or synthesis**.\n- **4-6 key arguments** the analyst makes. These are the claims you'll pressure-test.\n  Look for: revenue/growth commentary, margin trends, segment performance, balance\n  sheet / leverage, competitive positioning, specific catalysts or risks.\n\nWrite each argument as a 1-2 sentence summary. You'll use these as the section\nheaders in the final report. **In chat**, share this list once as the identified\nmain arguments; do not pre-write full evidence cards in the thread.\n\n## Step 1.5: Market reaction context (price move since publication)\n\nGet the stock **close price** on:\n\n- **Report date** (use the report's publication date; if only a date is given, use that day's close)\n- **Current date** (most recent close)\n\nCompute percent move: \\(\\\\Delta\\\\% = (P_\\\\text{now}/P_\\\\text{report} - 1)\\\\times 100\\\\).\n\n### Reporting rules (keep concise)\n\n- Add a small **\\\"Price since report\\\"** box near the top of the HTML with the two closes and the \\(\\\\Delta\\\\%\\\\).\n- Keep the commentary **blunt and non-narrative**: factual finance language only.\n- If price data cannot be retrieved reliably in the current environment, state that in the HTML box and continue with the SEC pressure test.\n\n## Step 2: Resolve the company in deepKPI\n\nUse the `kpi` skill workflow:\n\n1. Call `query_company_id` with the company's official registrant name (not brand)\n2. Call `list_kpis` (free) to see every available metric\n3. Scan the KPI list to plan your searches — map each analyst argument to the\n   most granular KPIs available\n\n## Step 6: Generate the HTML report\n\nRead `references/html-template.md` in this folder for the complete HTML/CSS/JS template.\n\nThe report structure includes:\n\n- Header link label: **\\\"Analysis Pressure Test (GitHub)\\\"**\n- Title: \\\"[Company] ([Ticker]): Pressure-Testing the [Firm] [Action]\\\"\n\n## Step 7: Double-check the draft HTML (mandatory)\n\nAfter the draft HTML file is written (saved path known), you **must** run the\n**pressure-test double-check** before `present_files` / showing it to the user.\n\n1. **Read** `references/double-check.md` (internal QA reference for this skill).\n2. **Execute the procedure** in that document against the draft HTML:\n   - If your host can invoke a **separate reviewer agent**, give it that doc plus\n     the HTML path (and the analyst PDF path when available) and collect its output.\n   - Otherwise, **perform the same pass yourself** in a distinct step: read the HTML\n     end-to-end, build the claim graph, run rules **R1–R12**, and emit the **exact\n     output format** specified there (structured review — **do not rewrite** the\n     HTML inside the double-check output).\n3. Pass the **source PDF path** into the double-check whenever you still have it;\n   otherwise R1 and R8 must appear under **`Not checked`** in the review.\n\n**You** (the authoring agent) **own revisions**: use the review's severity-ranked\nfindings to patch the HTML. Typical loop:\n\n- Fix all **Critical** before delivery. **Fail** overall → treat as blocking until\n  addressed or the user explicitly waives QA (only if they say so).\n- **Needs Revision** → fix Critical, then re-run Step 7 on the updated file.\n- **Pass** with only **Suggested** / **Optional** → you may still polish, then deliver.\n\nRe-running Step 7 after substantive edits is **recommended** so regressions do not\nship.\n\n---\n\n## Reference files\n\n| File | When to read |\n|------|-------------|\n| `references/html-template.md` | Always — contains the full HTML/CSS/JS template |\n| `references/chart-patterns.md` | When building charts — palette, dash patterns, examples |\n| `references/double-check.md` | **Always after draft HTML exists** — mandatory internal QA rubric and output format |\n"
}