Update to Realize Plugin

{
  "description": "Package the current conversation into a single Markdown file the user can email to Taboola Support so Professional Services can debug what happened. Activates on /realize-plugin:support, and whenever the user wants to escalate to a human, report that the plugin gave a wrong or suspicious answer, or file a bug. Writes one local file after an explicit confirmation — never transmits anything.",
  "included_files": [
    {
      "relative_path": "scripts/build-bundle.js",
      "size_in_bytes": 49646
    },
    {
      "relative_path": "scripts/test-build-bundle.js",
      "size_in_bytes": 29735
    }
  ],
  "name": "support",
  "skill_md_contents": "---\nname: support\ndescription: Package the current conversation into a single Markdown file the user can email to Taboola Support so Professional Services can debug what happened. Activates on /realize-plugin:support, and whenever the user wants to escalate to a human, report that the plugin gave a wrong or suspicious answer, or file a bug. Writes one local file after an explicit confirmation — never transmits anything.\nallowed-tools: [\"Read\", \"Edit(~/.realize-plugin/tmp/**)\", \"Bash(node \\\"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\\\" --preview)\", \"Bash(node \\\"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\\\" --write --complaint-file ~/.realize-plugin/tmp/complaint-*.txt)\", \"Bash(node \\\"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\\\" --write --title-file ~/.realize-plugin/tmp/title-*.txt)\", \"AskUserQuestion\"]\n---\n\n# Support Bundle\n\nTurns the current session into a support case file for Taboola Professional Services (PS).\n\nUsers run the plugin in their own terminal, so PS has no visibility into these conversations. When someone says \"the plugin gave me the wrong number\", PS currently has only that sentence. This skill hands them the actual transcript instead.\n\n## When to use\n\n- The user runs `/realize-plugin:support` — plugin components are namespaced, so a bare `/support` is not a valid invocation.\n- The user says the plugin gave wrong, stale, or suspicious information and wants it looked at.\n- The user asks to talk to a person, open a ticket, or escalate.\n- The user hit an error they can't get past and wants help.\n\n**Not** for answering product questions or diagnosing campaign performance — those belong to the normal skills. This skill only packages evidence.\n\n## The one rule that matters\n\n**The transcript is the deliverable.** Everything above it in the file is mechanically extracted from the transcript by the script — never written from your own recollection of the conversation.\n\nThis is deliberate. If the plugin misread the user, a summary written by the plugin carries that same misreading into the bug report. Only the raw exchange is independent of the bug. So: do not editorialize, do not explain away what happened, and do not \"clean up\" the user's complaint.\n\n**Section 1 (Summary) is not an exception.** It exists because PS pastes it into the case Description, but every line in it is a count, a tool name, or a file path pulled from the log — never a narrative. It reports *which* Realize tools ran, *which* skills were invoked, and *which* knowledge files were read, so PS can tell \"the plugin had the right guidance and still got it wrong\" apart from \"the plugin never read the guidance\". Those are different bugs. Do not add a prose account of what went wrong to that section.\n\n**You write nothing into this bundle.** The case subject is now the user's own complaint text, so there is no field left for your judgment.\n\n## Workflow\n\n### Step 1 — Preview (never skip)\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\" --preview\n```\n\nRun it exactly in this form — path in double quotes, one line. The quotes keep a plugin path with a space in it (`C:/Users/John Smith/…`) in one piece. The pre-approval covers only this command and the Step 4 command, character for character; anything else, including extra flags, raises a permission prompt.\n\nIf the shell reports that `node` is not found, stop: the bundle needs Node.js 18 or later, which Claude Code's native and desktop installs don't include. Tell the user that plainly, and offer the fallback — they can email Support@taboola.com directly with a description of the problem and the account ID.\n\nWrites nothing. Prints what would be captured: session ID, time window, turn counts, Realize actions attempted and how many failed, account/campaign IDs involved, local paths, and estimated file size.\n\n### Step 2 — Show the user what's about to leave their machine\n\nThis file contains their real campaign data — budgets, spend, account IDs — plus their local folder paths. They must see that before a file exists.\n\nPresent the preview in plain language:\n\n> This will save a file containing our whole conversation — **28 messages**, covering **account 1721090**, about **95 KB**.\n> It includes the campaign data shown in this session and your local folder path. Credentials and tokens are removed automatically.\n> Nothing is sent anywhere — the file is saved to your Desktop and you choose whether to email it.\n\nThen confirm with `AskUserQuestion`: create the file, or cancel.\n\nIf the preview says match confidence is **guessed**, tell the user plainly: the exact session couldn't be identified and this may be the wrong conversation. Let them cancel.\n\n### Step 3 — The case subject writes itself\n\n**Do not compose a title.** The script uses the user's own complaint as the email subject, collapsed to one line, capped for a subject header, with the account ID appended for triage. Case intake copies that subject into the case Subject field, and the user's sentence is the most faithful description of their own problem available.\n\n`--title-file` still exists, but only as the fallback for a run where the user gave no description at all. If they described the problem, the description is the subject. A title file follows the same rules as the complaint file in Step 4: it must sit directly in `~/.realize-plugin/tmp/`, named `title-<YYYYMMDD-HHMMSS>-<random>.txt`, and the run is `node \"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\" --write --title-file ~/.realize-plugin/tmp/title-<…>.txt` — one file flag per run, nothing else on the line.\n\n### Step 4 — Write the file\n\n**Never pass the complaint or title as a quoted shell argument.** Write them to files first, then point the script at the files:\n\n1. `Write` the user's description verbatim to a new file `~/.realize-plugin/tmp/complaint-<YYYYMMDD-HHMMSS>-<random>.txt` — the current time plus a few random letters or digits, e.g. `complaint-20261019-141502-k7q2.txt`. A name per run keeps two support runs (two sessions, say) from reading each other's text. That folder is the only place the script reads text from, it only accepts `complaint-…` / `title-…` `.txt` names made of letters, digits, `-` and `_`, and it's the only place this skill may write without a prompt.\n2. Run:\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/skills/support/scripts/build-bundle.js\" --write --complaint-file ~/.realize-plugin/tmp/complaint-<YYYYMMDD-HHMMSS>-<random>.txt\n```\n\nwith the exact file name you wrote, and nothing else on the line.\n\nThis is not a style preference. The shell rewrites this text: `$12.40` arrives as `2.40`, `$500` arrives as `00`, and backticks or `$(…)` **execute**. Complaints in this domain are full of currency amounts, and users paste error text they didn't write. The whole point of the bundle is that the evidence reaches PS unaltered, so it must not pass through the shell.\n\n`--complaint` / `--title` still exist for trivial ASCII with no `$`, backticks, or quotes. When in doubt, use the file form.\n\nThe complaint is the user's own description — use their words. If they ran the command with no description, ask one short question (\"In one line, what went wrong?\") and pass the answer through unedited. Don't write it for them.\n\n`--out <path>` overrides the destination. Default is Desktop, then Downloads, then home folder — skipping any that OneDrive has redirected to the cloud. `--out` must name a new `.md` file directly inside one of those folders; the script refuses anything else. It isn't pre-approved, so the user sees a permission prompt for it.\n\n### Step 5 — Tell them how to send it\n\nThree parts, because case intake maps each one to a different field. The file's own \"How to send this to Support\" section says the same thing — repeat it in chat so they don't have to open the file to know what to do:\n\n> Saved to `C:\\Users\\you\\Desktop\\realize-support-2026-08-09-...md`\n>\n> Email it to **Support@taboola.com**:\n> - **Subject:** *the CPA in the report doesn't match the UI (account 1721090)*\n> - **Body:** copy **Section 1. Summary** from the file\n> - **Attach the file** so Support has the failed actions and full transcript\n\nSay plainly that nothing was sent automatically — sending is their decision.\n\nYou don't need to delete the complaint file — the script removes it once the bundle is written, because it holds the user's description and serves no purpose after that. Files left behind by a cancelled run are removed by the next run once they are a day old. If the script reports it couldn't delete the file, the bundle was still written; tell the user where the leftover file is.\n\n## What the bundle contains\n\n| Section | Purpose |\n|---|---|\n| How to send this to Support | Copy-ready subject, which section is the email body, and the reminder to attach the file |\n| 1. Summary | **Pasted into the case Description.** Opens with the PS-requested prolog, then session facts, Realize tools used, skills invoked, knowledge files read, and any failures. Mechanically extracted — no narrative |\n| 2. At a glance | Session ID, timestamps, turn counts, accounts/campaigns/items involved, actions attempted, **failed count**, plugin + Claude Code version, platform |\n| 3. What the user reported | The `--complaint` text, verbatim. Also the source of the email subject |\n| 4. Failed actions | Every failed Realize action with parameters sent and the error returned |\n| 5. Realize actions attempted, in order | Ordered table of every Realize action and its result |\n| 6. Full transcript | Every message, tool call, and result — with internal reasoning in collapsible blocks |\n\n## Privacy\n\n- **Nothing is transmitted.** The script writes one local file. There is no upload path, by design.\n- **Credentials are stripped**: bearer tokens, `access_token`, `refresh_token`, `api_key`, `password`, `client_secret`, and JWTs.\n- **Business IDs are kept.** `account_id`, `campaign_id`, and `item_id` are preserved on purpose — PS cannot reproduce an issue without them.\n- **Local paths are included** as diagnostics, and the preview says so.\n- Never write the bundle into the plugin repo or any git working tree — it contains customer data. Default destinations are outside the repo; keep it that way.\n\n## Gotchas\n\n- **Session identification** comes from `CLAUDE_CODE_SESSION_ID`. A project folder usually holds several sessions, so the \"newest file\" fallback is genuinely unreliable — that's why the preview reports match confidence, and why `guessed` must be surfaced to the user.\n- **The current turn is mid-write.** The transcript is complete up to roughly the user's command message; the assistant reply being composed right now isn't in it yet. Harmless, but don't promise it captured \"everything including this reply\".\n- **Large sessions get truncated.** Tool results cap at 2,000 characters, user messages at 4,000, internal reasoning at 1,200, and the bundle at 8 MB to stay email-attachable. Truncation is marked inline and never leaves a code fence or `<details>` block unclosed. If a specific large CSV matters to the case, tell the user to attach it separately. Transcripts above 256 MB are refused outright with an explanation rather than crashing.\n- **An unreadable `--complaint-file` is fatal, and that's deliberate.** It exits 1 without writing. Continuing would produce a bundle stating *\"The user did not add a description\"* about a user who did describe the problem — a false statement to support is worse than no bundle. It would also silently drop the email subject, since the subject is derived from the complaint. If you see that error, check the path you wrote to.\n- **The script refuses to overwrite.** If `--out` points at an existing file it exits 1 rather than clobbering it; pick a different file name. `--force` works only when a person runs the script in a terminal, so don't pass it. (An auto-generated default name that collides simply gets a `-1` suffix — no error.)\n- **The script refuses to write inside a git repository**, including this one, and exits 1. The bundle holds customer campaign data and this plugin's repo is public, so a bundle committed by accident is a data leak. If you see that error, choose a path outside the repo — the default destination already is one.\n- **Unit tests:** `node skills/support/scripts/test-build-bundle.js` covers the redaction rules, table-cell safety, truncation, and destination guards. Run it after touching the script; CI runs it too.\n- **No Realize actions in the session** is normal and not an error — it usually means the complaint is about the *content* of an answer, not a failed call. The bundle says so explicitly.\n- **Node.js 18+ is required, and not every install has it** — the native installer and desktop app don't include it. If `node` is missing, follow the fallback in Step 1. Do not add a Python path.\n\n## Example prompts\n\n```\n/realize-plugin:support\n/realize-plugin:support the CPA number doesn't match what I see in the UI\n\"This gave me the wrong budget — how do I report it?\"\n\"Can I get a human to look at this?\"\n\"I want to open a ticket about this.\"\n```\n"
}