@telepath-computer/television 0.1.71 → 0.1.72

package/dist/cli.cjs

@@ -50113,8 +50113,8 @@ function getDevPackageDir() {
   return import_node_path7.default.resolve(import_node_path7.default.dirname((0, import_node_url.fileURLToPath)(import_meta.url)), "..");
 }
 function readCLIVersion() {
-  if ("0.1.71".length > 0) {
-    return "0.1.71";
+  if ("0.1.72".length > 0) {
+    return "0.1.72";
   }
   const devPackageJsonPath = import_node_path7.default.join(getDevPackageDir(), "package.json");
   if (!(0, import_node_fs4.existsSync)(devPackageJsonPath)) {
@@ -50123,8 +50123,8 @@ function readCLIVersion() {
   return JSON.parse((0, import_node_fs4.readFileSync)(devPackageJsonPath, "utf8")).version;
 }
 function readWorkflowHelpText() {
-  if ('# Television\n\nTelevision is a persistent artifact screen for agents. Use it when the user\nshould be able to inspect, revisit, and refine a file-backed result instead of\nonly reading a chat reply.\n\nIf you lose context, run:\n\n```bash\ntv help\n```\n\nThat command prints this full skill as one blob. There is no topic-scoped help\nin the current implementation.\n\n## Mental model\n\n- A **screen** is a named viewer surface with a layout.\n- An **artifact** is a file-backed result that can exist independently of any\n  screen. It can be unplaced, attached to one screen, or attached to multiple\n  screens.\n- **Screen membership** is separate from artifact identity: attaching/detaching\n  controls which screens show an artifact; deleting removes the artifact\n  globally. The CLI create commands require `--screen` so in-progress artifacts\n  are visible immediately.\n- An **internal artifact** is a Television-managed bundle. You create a pending\n  bundle, edit files in that bundle, then commit it.\n- An **external artifact** is a pointer to an existing absolute file on disk.\n  Television displays that file but does not own or delete it.\n- **Pending** means a create or edit is staged but not yet committed.\n- **Trash** means metadata and committed internal bundles moved out of the live\n  tree. There is no restore workflow in the current scope.\n\nThe core workflow is:\n\n1. Decide whether the result should be internal or external.\n2. Decide whether the user should be taken to the new screen or artifact now, or whether the work should happen in the background.\n3. Create or stage the artifact with the CLI.\n4. For internal artifacts, edit files in the pending bundle.\n5. Commit when the validation rules are satisfied.\n\n## Focus model\n\nTelevision separates state changes from focus.\n\nThere are two kinds of focus:\n\n- **Screen focus** is persistent. It decides which screen the TV is currently showing.\n- **Artifact focus** is transient. It may switch screens first, then scroll the artifact into view and briefly highlight it.\n\nImportant consequence:\n\n- there is a persisted focused screen\n- there is **not** a persisted focused artifact\n\nState-change commands can optionally trigger focus, but they do not imply it.\n\nAgent-facing create and attach commands require an explicit focus decision:\n\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`\n- `tv create-internal-artifact`, `tv create-external-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n\nUse this decision rule:\n\n- use `--focus-screen` when the user likely wants to go to the new screen immediately\n- use `--focus-artifact` when the user likely wants to inspect the new artifact immediately\n- use `--no-focus` when the work should happen in the background while keeping the current screen and artifact context unchanged\n\nHeuristic examples:\n\n- use a focus flag for requests like "show me", "open it", "put it on screen", "take me there", or "let me review it"\n- treat user language like **active**, **current**, **showing**, **visible**, **switch to**, **change to**, **go to**, or **show me that** as focus intent for the relevant screen or artifact\n- requests like "switch to the other screen", "show me that artifact", or "change to that screen" should usually translate to `tv focus-screen` or `tv focus-artifact`\n- use `--no-focus` for requests like "set this up", "make it in the background", "prepare it", or "wire this in"\n- also use `--no-focus` when the user says things like "in the background", "while I do something else", "while I work on X", or otherwise signals that your work should proceed on a parallel thread decoupled from their main task\n\nDirect focus commands:\n\n- `tv focus-screen --id <screen-id>` sets persistent screen focus\n- `tv focus-artifact --id <artifact-id> [--screen <screen-id>]` sends a transient artifact-focus nudge\n- `tv focus-status` reports the current persistent screen focus and connected client count\n\nImportant communication rule:\n\n- when you use `--no-focus`, explicitly say what you did in chat so the user knows the work happened even though Television did not visibly change\n\nIf you forget these rules or the CLI rejects a command for missing focus intent, run `tv help` and reread this section before retrying.\n\n## User communication during multi-step workflows\n\nWhen you are doing a multi-step artifact workflow, keep the user informed as you\nprogress.\n\nRequired communication style:\n\n- verbalize key actions and decisions as they happen\n- keep the language concise\n- prefer short updates over long explanations\n- frame updates in the user\'s world and goals, not in the internal mechanics of the skill or CLI workflow\n- avoid technical workflow jargon unless the user explicitly asks for it\n- do not write reports, long paragraphs, or chatty summaries while the work is in progress\n- do not use lists unless the user explicitly asks for one\n- optimize for speed and token efficiency\n\nGood examples:\n\n- "Starting the artifact now."\n- "Reviewing the draft and source material."\n- "Updating the HTML and efficiently navigating the artifact creation flow."\n- "The artifact did not pass validation yet; fixing the draft notes and retrying."\n- "Finalizing the artifact now."\n- "Done."\n\nBad examples:\n\n- multi-paragraph progress reports\n- long retrospective narration during execution\n- verbose bullet lists for routine workflow steps\n\n## Internal versus external\n\nUse an **internal artifact** when:\n\n- the artifact is purpose-built for Television\n- Television should own the bundle structure\n- future agents should be able to maintain the result by reading bundle files\n- you need a staged create or staged edit workflow\n\nUse an **external artifact** when:\n\n- a real file already exists on disk\n- the user wants Television to display that existing file\n- you do not need a Television-managed bundle\n\nDecision rule:\n\n- If the result should be maintained as a Television-owned long-lived artifact,\n  choose internal.\n- If the result is already a real file outside Television and should stay that\n  way, choose external.\n\nSupported artifact types:\n\n- `text/markdown`\n- `text/html`\n\n## Internal bundle files\n\nEvery internal artifact bundle contains:\n\n- `artifact.md`\n- `data.json`\n- `memory.md`\n- `public/index.md` or `public/index.html`\n\nFresh pending bundles are intentionally minimal:\n\n- `artifact.md` is blank\n- `memory.md` is blank\n- `public/index.md` or `public/index.html` is blank\n- `data.json` is exactly `{}`\n\nThe scaffold is not commit-valid by itself. Learn the required structure from\nthis skill, not from placeholder content in the scaffold.\n\n### `artifact.md`\n\n`artifact.md` is the contract for the artifact. It explains what the artifact\nis for, what conceptual material it is based on, how it should render, and how\nlater agents should maintain it.\n\nBefore commit, `artifact.md` must be non-empty and contain all of these exact\nheadings:\n\n```md\n## User intent\n## Purpose\n## Data shape\n## Data sources\n## Rendering\n## Update workflow\n## Non-goals\n```\n\nWhat each section should capture:\n\n- `## User intent`: faithful restatement or quotation of what the user actually said they wanted; this is critical and should preserve the user\'s language as closely as practical, including requests, feedback, complaints, constraints, and guidance\n- `## Purpose`: what the artifact is trying to achieve\n- `## Data shape`: the conceptual shape you reasoned about while authoring; for markdown artifacts this will often just be `{}`\n- `## Data sources`: where the underlying facts, notes, or source material came from and how they were obtained\n- `## Rendering`: how `public/index.md` or `public/index.html` should present it\n- `## Update workflow`: how future agents should refresh or modify it\n- `## Non-goals`: what is intentionally excluded, especially application-like runtime behavior\n\n### `data.json`\n\n`data.json` is a **thinking artifact**, not a runtime payload.\n\nIts purpose is to help the model separate:\n\n- reasoning / planning / authoring structure\n- from final presentation in `public/index.md` or `public/index.html`\n\nUse it to capture the pure conceptual shape of what you are about to render.\nThis is an authoring aid for agents, not an application data layer.\n\nHard rules:\n\n- **Do not treat `data.json` as live runtime state.**\n- **Do not write HTML/JS that loads, depends on, or synchronizes against `data.json`.**\n- **Do not build application-like data-driven artifacts.**\n- **We do not support runtime data-backed artifacts at this time.**\n- Artifacts are static markdown or static HTML documents.\n- HTML artifacts may include JavaScript and extra assets under `public/`, but\n  that JavaScript must stay presentation-oriented and self-contained, not\n  driven by `data.json` as an application state container.\n\nFor `text/markdown` artifacts, leave `data.json` as exactly:\n\n```json\n{}\n```\n\nThere is usually little value in separating content from presentation for\nmarkdown artifacts, so prefer `{}` unless there is a very strong authoring\nreason not to.\n\nFor `text/html` artifacts, use `data.json` only when it helps you think clearly\nabout the material before rendering. It may describe the conceptual structure\nof the artifact, but it must not become a runtime contract.\n\nValidation rule:\n\n- `data.json` must exist and contain valid JSON\n\nThe current validator does not require the JSON value to be an object, but an\nobject is the normal choice.\n\n### `memory.md`\n\n`memory.md` is the working scratchpad for later agents. Record decisions,\nlimitations, data-retrieval notes, problems encountered, what changed, and what\nshould be watched during future edits.\n\nRequired validation anchors:\n\n- `memory.md` must contain `## Activity Log`\n- `memory.md` must contain at least one UTC timestamp in exact\n  `YYYY-MM-DDTHH:MM:SSZ` format\n- at least one timestamp must be from the last 30 minutes when you commit\n\nThe minimum required heading is:\n\n```md\n## Activity Log\n```\n\nWhat to record beyond that is up to the artifact and the work performed.\n\n### `public/index.md` and `public/index.html`\n\nThis is the rendered entry file that Television serves.\n\n- Markdown artifacts use `public/index.md`\n- HTML artifacts use `public/index.html`\n- the entry file must match the artifact `type`\n- the entry file must be non-empty before commit\n\nFor HTML artifacts:\n\n- `public/index.html` is a full HTML document, not a body fragment\n- additional public assets may live under `public/`\n- keep paths relative to `public/`\n\n## Quality bar\n\nBuild artifacts that are durable, truthful, and maintainable by later agents.\n\nRequired quality standards:\n\n- be faithful to source data\n- do not invent or hallucinate missing facts\n- do not silently truncate a dataset and pretend it is complete\n- prefer truth over completeness when those goals conflict\n- make limitations, sampling, missing data, and freshness visible\n- keep rendering aligned with the reasoning captured in `artifact.md`, `data.json`, and `memory.md`\n- keep `data.json` as an authoring/thinking artifact rather than a runtime dependency\n- keep the artifact maintainable by a future agent reading only the bundle files\n\nAnti-patterns:\n\n- cursory or low-effort data collection\n- fake data added to make the artifact look complete\n- brittle one-off hacks that a later agent cannot reproduce\n- hidden dependencies that are not documented in `artifact.md` or `memory.md`\n- layout churn during simple data refreshes when the data model did not change\n\n## HTML house style\n\nHTML artifacts should feel intentional and readable inside Television tiles.\n\nTelevision provides a full base stylesheet for HTML artifacts. Only add custom\nCSS when you need something not covered by the built-in styles. Prefer the base\nstyles and theme tokens so artifacts stay visually coherent with the rest of\nTelevision.\n\nHouse-style guidance:\n\n- use semantic HTML first\n- keep the most important information near the top\n- design for small, medium, and large tile sizes\n- avoid horizontal overflow unless there is no reasonable alternative\n- make empty states and error states explicit\n- prefer the built-in HTML styling before inventing custom component chrome\n\n### Elements\n\nStandard elements already have sensible defaults, so you usually do not need to\nstyle from scratch:\n\n- headings (`h1`\u2013`h6`) \u2014 sized and weighted\n- `p`, `ul`, `ol` \u2014 readable defaults\n- `code` and `pre` \u2014 monospace, muted background\n- `blockquote` \u2014 left border, muted text\n- `table`, `th`, `td` \u2014 bordered, striped headers\n- `button` \u2014 styled with border and hover state; use `size="sm"` or `size="md"` when appropriate\n- `hr` \u2014 subtle border\n- `a` \u2014 inherits color by default\n\n### `.prose` class\n\nUse a `.prose` wrapper for document-style HTML where readable vertical rhythm is\nappropriate. Do not rely on `.prose` for dashboards, tables, control surfaces,\nor dense custom layouts.\n\n```html\n<div class="prose">\n  <h1>Title</h1>\n  <p>Some content with proper spacing between elements.</p>\n  <ul>\n    <li>Item one</li>\n    <li>Item two</li>\n  </ul>\n</div>\n```\n\n### CSS variables\n\nUse the existing Television tokens when they are available in the runtime.\nThese are the preferred way to stay aligned with the app theme.\n\nColors:\n- `--color-bg` \u2014 page background\n- `--color-bg-muted` \u2014 subtle background\n- `--color-surface` \u2014 card or panel background\n- `--color-text` \u2014 primary text\n- `--color-text-muted` \u2014 secondary or label text\n- `--color-border` \u2014 border color\n\nSpacing:\n- `--space-4`\n- `--space-8`\n- `--space-12`\n- `--space-16`\n- `--space-24`\n- `--space-32`\n\nFonts:\n- `--font-sans`\n- `--font-mono`\n\nText sizes:\n- `--text-sm`\n- `--text-base`\n- `--text-lg`\n- `--text-xl`\n\nRadius:\n- `--radius-4`\n- `--radius-8`\n\n## Workflows\n\n### Create new internal artifact\n\n1. Decide that the result should be an internal artifact.\n2. Start the pending bundle:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --no-focus\n```\n\n`--screen` is required for internal artifact creation so the artifact has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\n3. Read the returned pending path and edit files there.\n4. Write `artifact.md`.\n5. In `artifact.md`, capture the user\'s language faithfully in `## User intent` before doing the rest of the authoring work. Use direct quotes when helpful, or a close paraphrase when that is clearer, but keep it representative of what the user actually said they wanted.\n6. Think through the artifact in a pure way and write `data.json` only as an authoring aid.\n7. For markdown artifacts, leave `data.json` as `{}` unless there is a compelling authoring reason not to.\n8. Render `public/index.md` or `public/index.html`.\n9. Append a current timestamped activity entry in `memory.md`.\n10. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Update internal artifact with fresh data\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md` before changing anything.\n3. Refresh the underlying facts or source material.\n4. Update `data.json` only if it helps clarify the authoring plan.\n5. For markdown artifacts, prefer to keep `data.json` as `{}`.\n6. Make the minimum rendering changes needed to keep the artifact correct.\n7. Record what changed in `memory.md`.\n8. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\nAvoid unnecessary layout or styling churn during data-only refreshes.\n\n### Modify internal artifact from user feedback\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md`.\n3. Update `artifact.md` if the user intent or non-goals changed.\n4. When the user has added feedback, complaints, corrections, or new guidance, update `## User intent` so it remains a faithful record of what the user actually wants now. Preserve the user\'s language as closely as practical, using direct quotes or close paraphrases.\n5. Update `data.json` only if it improves the authoring model of the artifact.\n6. For markdown artifacts, prefer to keep `data.json` as `{}`.\n7. Adjust `public/index.md` or `public/index.html` as narrowly as possible.\n8. Record the request, decision, and resulting change in `memory.md`.\n9. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Abandon pending work\n\nIf the staged work should be discarded instead of committed:\n\n```bash\ntv abandon-pending-artifact --id "<artifact-id>"\n```\n\n### Create external artifact\n\nUse this when the file already exists on disk and Television should display it\nwithout owning a bundle:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --path /absolute/path/to/file.md --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --path /absolute/path/to/file.html --no-focus\n```\n\n`--screen` is required for CLI creation so the file has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--path` must be absolute\n- the file must already exist and be readable\n- the extension must match `type`\n- external artifacts do not use pending create, pending edit, commit, or abandon\n\n## CLI reference\n\nArtifact commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" (--focus-artifact|--no-focus)\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path (--focus-artifact|--no-focus)\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv list-artifacts [--screen "<screen-id>"] [--unplaced]\ntv get-artifact --id "<artifact-id>"\ntv delete-artifact --id "<artifact-id>"\n```\n\nScreen commands:\n\n```bash\ntv create-screen --name "Screen name" (--focus-screen|--no-focus)\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nScreen membership commands:\n\n```bash\ntv attach-artifact --id "<artifact-id>" --screen "<screen-id>" (--focus-artifact|--no-focus)\ntv detach-artifact --id "<artifact-id>" --screen "<screen-id>"\n```\n\nFocus commands:\n\n```bash\ntv focus-status\ntv focus-screen --id "<screen-id>"\ntv focus-artifact --id "<artifact-id>" [--screen "<screen-id>"]\n```\n\nServer commands:\n\n```bash\ntv status\ntv storage-path\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- `--screen` is required on CLI create commands so new artifacts get immediate screen membership; use `tv attach-artifact` and `tv detach-artifact` for later screen membership changes\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`; `tv create-internal-artifact`, `tv create-external-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv attach-artifact` appends a default-sized card to the right end of the strip; idempotent if the artifact is already on that screen\n- `tv detach-artifact` removes the card from a screen\'s layout; the artifact metadata is never touched, even on the last reference\n- `tv delete-artifact` is the way to globally remove an artifact (detaches from every screen, then trashes the bundle / forgets the external pointer / discards pending-create)\n- `tv list-artifacts` accepts `--screen <id>` to filter by screen membership and `--unplaced` to surface artifacts attached to no screen\n- `tv update-artifact` changes title metadata only\n- `tv focus-screen` sets which screen the GUI is focused on; the change is persisted and broadcast to connected clients\n- `tv focus-artifact` is a transient nudge: clients switch screens if needed, scroll the artifact\'s card into view, and play a brief highlight animation; pass `--screen <id>` to pin which screen, otherwise the server picks one (preferring the active screen when the artifact is there)\n- `tv focus-status` prints the active screen ID and the count of connected GUI clients\n- when the CLI reports an error, follow the directive to run `tv help`\n\n## Deferred or out of scope\n\nThese are not part of the current implementation:\n\n- `tv help <topic>`\n- restore-from-trash\n- pending-listing commands\n- attestation or nonce commands\n- stale pending cleanup or stale trash cleanup\n- markdown editor UI recovery\n- client-side pending presentation work\n- multi-section help output'.length > 0) {
-    return '# Television\n\nTelevision is a persistent artifact screen for agents. Use it when the user\nshould be able to inspect, revisit, and refine a file-backed result instead of\nonly reading a chat reply.\n\nIf you lose context, run:\n\n```bash\ntv help\n```\n\nThat command prints this full skill as one blob. There is no topic-scoped help\nin the current implementation.\n\n## Mental model\n\n- A **screen** is a named viewer surface with a layout.\n- An **artifact** is a file-backed result that can exist independently of any\n  screen. It can be unplaced, attached to one screen, or attached to multiple\n  screens.\n- **Screen membership** is separate from artifact identity: attaching/detaching\n  controls which screens show an artifact; deleting removes the artifact\n  globally. The CLI create commands require `--screen` so in-progress artifacts\n  are visible immediately.\n- An **internal artifact** is a Television-managed bundle. You create a pending\n  bundle, edit files in that bundle, then commit it.\n- An **external artifact** is a pointer to an existing absolute file on disk.\n  Television displays that file but does not own or delete it.\n- **Pending** means a create or edit is staged but not yet committed.\n- **Trash** means metadata and committed internal bundles moved out of the live\n  tree. There is no restore workflow in the current scope.\n\nThe core workflow is:\n\n1. Decide whether the result should be internal or external.\n2. Decide whether the user should be taken to the new screen or artifact now, or whether the work should happen in the background.\n3. Create or stage the artifact with the CLI.\n4. For internal artifacts, edit files in the pending bundle.\n5. Commit when the validation rules are satisfied.\n\n## Focus model\n\nTelevision separates state changes from focus.\n\nThere are two kinds of focus:\n\n- **Screen focus** is persistent. It decides which screen the TV is currently showing.\n- **Artifact focus** is transient. It may switch screens first, then scroll the artifact into view and briefly highlight it.\n\nImportant consequence:\n\n- there is a persisted focused screen\n- there is **not** a persisted focused artifact\n\nState-change commands can optionally trigger focus, but they do not imply it.\n\nAgent-facing create and attach commands require an explicit focus decision:\n\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`\n- `tv create-internal-artifact`, `tv create-external-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n\nUse this decision rule:\n\n- use `--focus-screen` when the user likely wants to go to the new screen immediately\n- use `--focus-artifact` when the user likely wants to inspect the new artifact immediately\n- use `--no-focus` when the work should happen in the background while keeping the current screen and artifact context unchanged\n\nHeuristic examples:\n\n- use a focus flag for requests like "show me", "open it", "put it on screen", "take me there", or "let me review it"\n- treat user language like **active**, **current**, **showing**, **visible**, **switch to**, **change to**, **go to**, or **show me that** as focus intent for the relevant screen or artifact\n- requests like "switch to the other screen", "show me that artifact", or "change to that screen" should usually translate to `tv focus-screen` or `tv focus-artifact`\n- use `--no-focus` for requests like "set this up", "make it in the background", "prepare it", or "wire this in"\n- also use `--no-focus` when the user says things like "in the background", "while I do something else", "while I work on X", or otherwise signals that your work should proceed on a parallel thread decoupled from their main task\n\nDirect focus commands:\n\n- `tv focus-screen --id <screen-id>` sets persistent screen focus\n- `tv focus-artifact --id <artifact-id> [--screen <screen-id>]` sends a transient artifact-focus nudge\n- `tv focus-status` reports the current persistent screen focus and connected client count\n\nImportant communication rule:\n\n- when you use `--no-focus`, explicitly say what you did in chat so the user knows the work happened even though Television did not visibly change\n\nIf you forget these rules or the CLI rejects a command for missing focus intent, run `tv help` and reread this section before retrying.\n\n## User communication during multi-step workflows\n\nWhen you are doing a multi-step artifact workflow, keep the user informed as you\nprogress.\n\nRequired communication style:\n\n- verbalize key actions and decisions as they happen\n- keep the language concise\n- prefer short updates over long explanations\n- frame updates in the user\'s world and goals, not in the internal mechanics of the skill or CLI workflow\n- avoid technical workflow jargon unless the user explicitly asks for it\n- do not write reports, long paragraphs, or chatty summaries while the work is in progress\n- do not use lists unless the user explicitly asks for one\n- optimize for speed and token efficiency\n\nGood examples:\n\n- "Starting the artifact now."\n- "Reviewing the draft and source material."\n- "Updating the HTML and efficiently navigating the artifact creation flow."\n- "The artifact did not pass validation yet; fixing the draft notes and retrying."\n- "Finalizing the artifact now."\n- "Done."\n\nBad examples:\n\n- multi-paragraph progress reports\n- long retrospective narration during execution\n- verbose bullet lists for routine workflow steps\n\n## Internal versus external\n\nUse an **internal artifact** when:\n\n- the artifact is purpose-built for Television\n- Television should own the bundle structure\n- future agents should be able to maintain the result by reading bundle files\n- you need a staged create or staged edit workflow\n\nUse an **external artifact** when:\n\n- a real file already exists on disk\n- the user wants Television to display that existing file\n- you do not need a Television-managed bundle\n\nDecision rule:\n\n- If the result should be maintained as a Television-owned long-lived artifact,\n  choose internal.\n- If the result is already a real file outside Television and should stay that\n  way, choose external.\n\nSupported artifact types:\n\n- `text/markdown`\n- `text/html`\n\n## Internal bundle files\n\nEvery internal artifact bundle contains:\n\n- `artifact.md`\n- `data.json`\n- `memory.md`\n- `public/index.md` or `public/index.html`\n\nFresh pending bundles are intentionally minimal:\n\n- `artifact.md` is blank\n- `memory.md` is blank\n- `public/index.md` or `public/index.html` is blank\n- `data.json` is exactly `{}`\n\nThe scaffold is not commit-valid by itself. Learn the required structure from\nthis skill, not from placeholder content in the scaffold.\n\n### `artifact.md`\n\n`artifact.md` is the contract for the artifact. It explains what the artifact\nis for, what conceptual material it is based on, how it should render, and how\nlater agents should maintain it.\n\nBefore commit, `artifact.md` must be non-empty and contain all of these exact\nheadings:\n\n```md\n## User intent\n## Purpose\n## Data shape\n## Data sources\n## Rendering\n## Update workflow\n## Non-goals\n```\n\nWhat each section should capture:\n\n- `## User intent`: faithful restatement or quotation of what the user actually said they wanted; this is critical and should preserve the user\'s language as closely as practical, including requests, feedback, complaints, constraints, and guidance\n- `## Purpose`: what the artifact is trying to achieve\n- `## Data shape`: the conceptual shape you reasoned about while authoring; for markdown artifacts this will often just be `{}`\n- `## Data sources`: where the underlying facts, notes, or source material came from and how they were obtained\n- `## Rendering`: how `public/index.md` or `public/index.html` should present it\n- `## Update workflow`: how future agents should refresh or modify it\n- `## Non-goals`: what is intentionally excluded, especially application-like runtime behavior\n\n### `data.json`\n\n`data.json` is a **thinking artifact**, not a runtime payload.\n\nIts purpose is to help the model separate:\n\n- reasoning / planning / authoring structure\n- from final presentation in `public/index.md` or `public/index.html`\n\nUse it to capture the pure conceptual shape of what you are about to render.\nThis is an authoring aid for agents, not an application data layer.\n\nHard rules:\n\n- **Do not treat `data.json` as live runtime state.**\n- **Do not write HTML/JS that loads, depends on, or synchronizes against `data.json`.**\n- **Do not build application-like data-driven artifacts.**\n- **We do not support runtime data-backed artifacts at this time.**\n- Artifacts are static markdown or static HTML documents.\n- HTML artifacts may include JavaScript and extra assets under `public/`, but\n  that JavaScript must stay presentation-oriented and self-contained, not\n  driven by `data.json` as an application state container.\n\nFor `text/markdown` artifacts, leave `data.json` as exactly:\n\n```json\n{}\n```\n\nThere is usually little value in separating content from presentation for\nmarkdown artifacts, so prefer `{}` unless there is a very strong authoring\nreason not to.\n\nFor `text/html` artifacts, use `data.json` only when it helps you think clearly\nabout the material before rendering. It may describe the conceptual structure\nof the artifact, but it must not become a runtime contract.\n\nValidation rule:\n\n- `data.json` must exist and contain valid JSON\n\nThe current validator does not require the JSON value to be an object, but an\nobject is the normal choice.\n\n### `memory.md`\n\n`memory.md` is the working scratchpad for later agents. Record decisions,\nlimitations, data-retrieval notes, problems encountered, what changed, and what\nshould be watched during future edits.\n\nRequired validation anchors:\n\n- `memory.md` must contain `## Activity Log`\n- `memory.md` must contain at least one UTC timestamp in exact\n  `YYYY-MM-DDTHH:MM:SSZ` format\n- at least one timestamp must be from the last 30 minutes when you commit\n\nThe minimum required heading is:\n\n```md\n## Activity Log\n```\n\nWhat to record beyond that is up to the artifact and the work performed.\n\n### `public/index.md` and `public/index.html`\n\nThis is the rendered entry file that Television serves.\n\n- Markdown artifacts use `public/index.md`\n- HTML artifacts use `public/index.html`\n- the entry file must match the artifact `type`\n- the entry file must be non-empty before commit\n\nFor HTML artifacts:\n\n- `public/index.html` is a full HTML document, not a body fragment\n- additional public assets may live under `public/`\n- keep paths relative to `public/`\n\n## Quality bar\n\nBuild artifacts that are durable, truthful, and maintainable by later agents.\n\nRequired quality standards:\n\n- be faithful to source data\n- do not invent or hallucinate missing facts\n- do not silently truncate a dataset and pretend it is complete\n- prefer truth over completeness when those goals conflict\n- make limitations, sampling, missing data, and freshness visible\n- keep rendering aligned with the reasoning captured in `artifact.md`, `data.json`, and `memory.md`\n- keep `data.json` as an authoring/thinking artifact rather than a runtime dependency\n- keep the artifact maintainable by a future agent reading only the bundle files\n\nAnti-patterns:\n\n- cursory or low-effort data collection\n- fake data added to make the artifact look complete\n- brittle one-off hacks that a later agent cannot reproduce\n- hidden dependencies that are not documented in `artifact.md` or `memory.md`\n- layout churn during simple data refreshes when the data model did not change\n\n## HTML house style\n\nHTML artifacts should feel intentional and readable inside Television tiles.\n\nTelevision provides a full base stylesheet for HTML artifacts. Only add custom\nCSS when you need something not covered by the built-in styles. Prefer the base\nstyles and theme tokens so artifacts stay visually coherent with the rest of\nTelevision.\n\nHouse-style guidance:\n\n- use semantic HTML first\n- keep the most important information near the top\n- design for small, medium, and large tile sizes\n- avoid horizontal overflow unless there is no reasonable alternative\n- make empty states and error states explicit\n- prefer the built-in HTML styling before inventing custom component chrome\n\n### Elements\n\nStandard elements already have sensible defaults, so you usually do not need to\nstyle from scratch:\n\n- headings (`h1`\u2013`h6`) \u2014 sized and weighted\n- `p`, `ul`, `ol` \u2014 readable defaults\n- `code` and `pre` \u2014 monospace, muted background\n- `blockquote` \u2014 left border, muted text\n- `table`, `th`, `td` \u2014 bordered, striped headers\n- `button` \u2014 styled with border and hover state; use `size="sm"` or `size="md"` when appropriate\n- `hr` \u2014 subtle border\n- `a` \u2014 inherits color by default\n\n### `.prose` class\n\nUse a `.prose` wrapper for document-style HTML where readable vertical rhythm is\nappropriate. Do not rely on `.prose` for dashboards, tables, control surfaces,\nor dense custom layouts.\n\n```html\n<div class="prose">\n  <h1>Title</h1>\n  <p>Some content with proper spacing between elements.</p>\n  <ul>\n    <li>Item one</li>\n    <li>Item two</li>\n  </ul>\n</div>\n```\n\n### CSS variables\n\nUse the existing Television tokens when they are available in the runtime.\nThese are the preferred way to stay aligned with the app theme.\n\nColors:\n- `--color-bg` \u2014 page background\n- `--color-bg-muted` \u2014 subtle background\n- `--color-surface` \u2014 card or panel background\n- `--color-text` \u2014 primary text\n- `--color-text-muted` \u2014 secondary or label text\n- `--color-border` \u2014 border color\n\nSpacing:\n- `--space-4`\n- `--space-8`\n- `--space-12`\n- `--space-16`\n- `--space-24`\n- `--space-32`\n\nFonts:\n- `--font-sans`\n- `--font-mono`\n\nText sizes:\n- `--text-sm`\n- `--text-base`\n- `--text-lg`\n- `--text-xl`\n\nRadius:\n- `--radius-4`\n- `--radius-8`\n\n## Workflows\n\n### Create new internal artifact\n\n1. Decide that the result should be an internal artifact.\n2. Start the pending bundle:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --no-focus\n```\n\n`--screen` is required for internal artifact creation so the artifact has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\n3. Read the returned pending path and edit files there.\n4. Write `artifact.md`.\n5. In `artifact.md`, capture the user\'s language faithfully in `## User intent` before doing the rest of the authoring work. Use direct quotes when helpful, or a close paraphrase when that is clearer, but keep it representative of what the user actually said they wanted.\n6. Think through the artifact in a pure way and write `data.json` only as an authoring aid.\n7. For markdown artifacts, leave `data.json` as `{}` unless there is a compelling authoring reason not to.\n8. Render `public/index.md` or `public/index.html`.\n9. Append a current timestamped activity entry in `memory.md`.\n10. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Update internal artifact with fresh data\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md` before changing anything.\n3. Refresh the underlying facts or source material.\n4. Update `data.json` only if it helps clarify the authoring plan.\n5. For markdown artifacts, prefer to keep `data.json` as `{}`.\n6. Make the minimum rendering changes needed to keep the artifact correct.\n7. Record what changed in `memory.md`.\n8. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\nAvoid unnecessary layout or styling churn during data-only refreshes.\n\n### Modify internal artifact from user feedback\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md`.\n3. Update `artifact.md` if the user intent or non-goals changed.\n4. When the user has added feedback, complaints, corrections, or new guidance, update `## User intent` so it remains a faithful record of what the user actually wants now. Preserve the user\'s language as closely as practical, using direct quotes or close paraphrases.\n5. Update `data.json` only if it improves the authoring model of the artifact.\n6. For markdown artifacts, prefer to keep `data.json` as `{}`.\n7. Adjust `public/index.md` or `public/index.html` as narrowly as possible.\n8. Record the request, decision, and resulting change in `memory.md`.\n9. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Abandon pending work\n\nIf the staged work should be discarded instead of committed:\n\n```bash\ntv abandon-pending-artifact --id "<artifact-id>"\n```\n\n### Create external artifact\n\nUse this when the file already exists on disk and Television should display it\nwithout owning a bundle:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --path /absolute/path/to/file.md --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --path /absolute/path/to/file.html --no-focus\n```\n\n`--screen` is required for CLI creation so the file has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--path` must be absolute\n- the file must already exist and be readable\n- the extension must match `type`\n- external artifacts do not use pending create, pending edit, commit, or abandon\n\n## CLI reference\n\nArtifact commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" (--focus-artifact|--no-focus)\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path (--focus-artifact|--no-focus)\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv list-artifacts [--screen "<screen-id>"] [--unplaced]\ntv get-artifact --id "<artifact-id>"\ntv delete-artifact --id "<artifact-id>"\n```\n\nScreen commands:\n\n```bash\ntv create-screen --name "Screen name" (--focus-screen|--no-focus)\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nScreen membership commands:\n\n```bash\ntv attach-artifact --id "<artifact-id>" --screen "<screen-id>" (--focus-artifact|--no-focus)\ntv detach-artifact --id "<artifact-id>" --screen "<screen-id>"\n```\n\nFocus commands:\n\n```bash\ntv focus-status\ntv focus-screen --id "<screen-id>"\ntv focus-artifact --id "<artifact-id>" [--screen "<screen-id>"]\n```\n\nServer commands:\n\n```bash\ntv status\ntv storage-path\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- `--screen` is required on CLI create commands so new artifacts get immediate screen membership; use `tv attach-artifact` and `tv detach-artifact` for later screen membership changes\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`; `tv create-internal-artifact`, `tv create-external-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv attach-artifact` appends a default-sized card to the right end of the strip; idempotent if the artifact is already on that screen\n- `tv detach-artifact` removes the card from a screen\'s layout; the artifact metadata is never touched, even on the last reference\n- `tv delete-artifact` is the way to globally remove an artifact (detaches from every screen, then trashes the bundle / forgets the external pointer / discards pending-create)\n- `tv list-artifacts` accepts `--screen <id>` to filter by screen membership and `--unplaced` to surface artifacts attached to no screen\n- `tv update-artifact` changes title metadata only\n- `tv focus-screen` sets which screen the GUI is focused on; the change is persisted and broadcast to connected clients\n- `tv focus-artifact` is a transient nudge: clients switch screens if needed, scroll the artifact\'s card into view, and play a brief highlight animation; pass `--screen <id>` to pin which screen, otherwise the server picks one (preferring the active screen when the artifact is there)\n- `tv focus-status` prints the active screen ID and the count of connected GUI clients\n- when the CLI reports an error, follow the directive to run `tv help`\n\n## Deferred or out of scope\n\nThese are not part of the current implementation:\n\n- `tv help <topic>`\n- restore-from-trash\n- pending-listing commands\n- attestation or nonce commands\n- stale pending cleanup or stale trash cleanup\n- markdown editor UI recovery\n- client-side pending presentation work\n- multi-section help output';
+  if ('# Television\n\nTelevision is a persistent artifact screen for agents. Use it when the user\nshould be able to inspect, revisit, and refine a file-backed result instead of\nonly reading a chat reply.\n\nIf you lose context, run:\n\n```bash\ntv help\n```\n\nThat command prints this full skill as one blob. There is no topic-scoped help\nin the current implementation.\n\n## Mental model\n\n- A **screen** is a named viewer surface with a layout.\n- An **artifact** is a file-backed result that can exist independently of any\n  screen. It can be unplaced, attached to one screen, or attached to multiple\n  screens.\n- **Screen membership** is separate from artifact identity: attaching/detaching\n  controls which screens show an artifact; deleting removes the artifact\n  globally. The CLI create commands require `--screen` so in-progress artifacts\n  are visible immediately.\n- An **internal artifact** is a Television-managed bundle. You create a pending\n  bundle, edit files in that bundle, then commit it.\n- An **external artifact** is a pointer to an existing absolute file on disk.\n  Television displays that file but does not own or delete it.\n- **Pending** means a create or edit is staged but not yet committed.\n- **Trash** means metadata and committed internal bundles moved out of the live\n  tree. There is no restore workflow in the current scope.\n\nThe core workflow is:\n\n1. Decide whether the result should be internal or external.\n2. Decide whether the user should be taken to the new screen or artifact now, or whether the work should happen in the background.\n3. Create or stage the artifact with the CLI.\n4. For internal artifacts, edit files in the pending bundle.\n5. Commit when the validation rules are satisfied.\n\n## Focus model\n\nTelevision separates state changes from focus.\n\nThere are two kinds of focus:\n\n- **Screen focus** is persistent. It decides which screen the TV is currently showing.\n- **Artifact focus** is transient. It may switch screens first, then scroll the artifact into view and briefly highlight it.\n\nImportant consequence:\n\n- there is a persisted focused screen\n- there is **not** a persisted focused artifact\n\nState-change commands can optionally trigger focus, but they do not imply it.\n\nAgent-facing create and attach commands require an explicit focus decision:\n\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`\n- `tv create-internal-artifact`, `tv create-external-artifact`, `tv create-url-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n\nUse this decision rule:\n\n- use `--focus-screen` when the user likely wants to go to the new screen immediately\n- use `--focus-artifact` when the user likely wants to inspect the new artifact immediately\n- use `--no-focus` when the work should happen in the background while keeping the current screen and artifact context unchanged\n\nHeuristic examples:\n\n- use a focus flag for requests like "show me", "open it", "put it on screen", "take me there", or "let me review it"\n- treat user language like **active**, **current**, **showing**, **visible**, **switch to**, **change to**, **go to**, or **show me that** as focus intent for the relevant screen or artifact\n- requests like "switch to the other screen", "show me that artifact", or "change to that screen" should usually translate to `tv focus-screen` or `tv focus-artifact`\n- use `--no-focus` for requests like "set this up", "make it in the background", "prepare it", or "wire this in"\n- also use `--no-focus` when the user says things like "in the background", "while I do something else", "while I work on X", or otherwise signals that your work should proceed on a parallel thread decoupled from their main task\n\nDirect focus commands:\n\n- `tv focus-screen --id <screen-id>` sets persistent screen focus\n- `tv focus-artifact --id <artifact-id> [--screen <screen-id>]` sends a transient artifact-focus nudge\n- `tv focus-status` reports the current persistent screen focus and connected client count\n\nImportant communication rule:\n\n- when you use `--no-focus`, explicitly say what you did in chat so the user knows the work happened even though Television did not visibly change\n\nIf you forget these rules or the CLI rejects a command for missing focus intent, run `tv help` and reread this section before retrying.\n\n## User communication during multi-step workflows\n\nWhen you are doing a multi-step artifact workflow, keep the user informed as you\nprogress.\n\nRequired communication style:\n\n- verbalize key actions and decisions as they happen\n- keep the language concise\n- prefer short updates over long explanations\n- frame updates in the user\'s world and goals, not in the internal mechanics of the skill or CLI workflow\n- avoid technical workflow jargon unless the user explicitly asks for it\n- do not write reports, long paragraphs, or chatty summaries while the work is in progress\n- do not use lists unless the user explicitly asks for one\n- optimize for speed and token efficiency\n\nGood examples:\n\n- "Starting the artifact now."\n- "Reviewing the draft and source material."\n- "Updating the HTML and efficiently navigating the artifact creation flow."\n- "The artifact did not pass validation yet; fixing the draft notes and retrying."\n- "Finalizing the artifact now."\n- "Done."\n\nBad examples:\n\n- multi-paragraph progress reports\n- long retrospective narration during execution\n- verbose bullet lists for routine workflow steps\n\n## Internal versus external\n\nUse an **internal artifact** when:\n\n- the artifact is purpose-built for Television\n- Television should own the bundle structure\n- future agents should be able to maintain the result by reading bundle files\n- you need a staged create or staged edit workflow\n\nUse an **external artifact** when:\n\n- a real file already exists on disk\n- the user wants Television to display that existing file\n- you do not need a Television-managed bundle\n\nDecision rule:\n\n- If the result should be maintained as a Television-owned long-lived artifact,\n  choose internal.\n- If the result is already a real file outside Television and should stay that\n  way, choose external.\n\nSupported artifact types:\n\n- `text/markdown`\n- `text/html`\n\n## Internal bundle files\n\nEvery internal artifact bundle contains:\n\n- `artifact.md`\n- `data.json`\n- `memory.md`\n- `public/index.md` or `public/index.html`\n\nFresh pending bundles are intentionally minimal:\n\n- `artifact.md` is blank\n- `memory.md` is blank\n- `public/index.md` or `public/index.html` is blank\n- `data.json` is exactly `{}`\n\nThe scaffold is not commit-valid by itself. Learn the required structure from\nthis skill, not from placeholder content in the scaffold.\n\n### `artifact.md`\n\n`artifact.md` is the contract for the artifact. It explains what the artifact\nis for, what conceptual material it is based on, how it should render, and how\nlater agents should maintain it.\n\nBefore commit, `artifact.md` must be non-empty and contain all of these exact\nheadings:\n\n```md\n## User intent\n## Purpose\n## Data shape\n## Data sources\n## Rendering\n## Update workflow\n## Non-goals\n```\n\nWhat each section should capture:\n\n- `## User intent`: faithful restatement or quotation of what the user actually said they wanted; this is critical and should preserve the user\'s language as closely as practical, including requests, feedback, complaints, constraints, and guidance\n- `## Purpose`: what the artifact is trying to achieve\n- `## Data shape`: the conceptual shape you reasoned about while authoring; for markdown artifacts this will often just be `{}`\n- `## Data sources`: where the underlying facts, notes, or source material came from and how they were obtained\n- `## Rendering`: how `public/index.md` or `public/index.html` should present it\n- `## Update workflow`: how future agents should refresh or modify it\n- `## Non-goals`: what is intentionally excluded, especially application-like runtime behavior\n\n### `data.json`\n\n`data.json` is a **thinking artifact**, not a runtime payload.\n\nIts purpose is to help the model separate:\n\n- reasoning / planning / authoring structure\n- from final presentation in `public/index.md` or `public/index.html`\n\nUse it to capture the pure conceptual shape of what you are about to render.\nThis is an authoring aid for agents, not an application data layer.\n\nHard rules:\n\n- **Do not treat `data.json` as live runtime state.**\n- **Do not write HTML/JS that loads, depends on, or synchronizes against `data.json`.**\n- **Do not build application-like data-driven artifacts.**\n- **We do not support runtime data-backed artifacts at this time.**\n- Artifacts are static markdown or static HTML documents.\n- HTML artifacts may include JavaScript and extra assets under `public/`, but\n  that JavaScript must stay presentation-oriented and self-contained, not\n  driven by `data.json` as an application state container.\n\nFor `text/markdown` artifacts, leave `data.json` as exactly:\n\n```json\n{}\n```\n\nThere is usually little value in separating content from presentation for\nmarkdown artifacts, so prefer `{}` unless there is a very strong authoring\nreason not to.\n\nFor `text/html` artifacts, use `data.json` only when it helps you think clearly\nabout the material before rendering. It may describe the conceptual structure\nof the artifact, but it must not become a runtime contract.\n\nValidation rule:\n\n- `data.json` must exist and contain valid JSON\n\nThe current validator does not require the JSON value to be an object, but an\nobject is the normal choice.\n\n### `memory.md`\n\n`memory.md` is the working scratchpad for later agents. Record decisions,\nlimitations, data-retrieval notes, problems encountered, what changed, and what\nshould be watched during future edits.\n\nRequired validation anchors:\n\n- `memory.md` must contain `## Activity Log`\n- `memory.md` must contain at least one UTC timestamp in exact\n  `YYYY-MM-DDTHH:MM:SSZ` format\n- at least one timestamp must be from the last 30 minutes when you commit\n\nThe minimum required heading is:\n\n```md\n## Activity Log\n```\n\nWhat to record beyond that is up to the artifact and the work performed.\n\n### `public/index.md` and `public/index.html`\n\nThis is the rendered entry file that Television serves.\n\n- Markdown artifacts use `public/index.md`\n- HTML artifacts use `public/index.html`\n- the entry file must match the artifact `type`\n- the entry file must be non-empty before commit\n\nFor HTML artifacts:\n\n- `public/index.html` is a full HTML document, not a body fragment\n- additional public assets may live under `public/`\n- keep paths relative to `public/`\n\n## Quality bar\n\nBuild artifacts that are durable, truthful, and maintainable by later agents.\n\nRequired quality standards:\n\n- be faithful to source data\n- do not invent or hallucinate missing facts\n- do not silently truncate a dataset and pretend it is complete\n- prefer truth over completeness when those goals conflict\n- make limitations, sampling, missing data, and freshness visible\n- keep rendering aligned with the reasoning captured in `artifact.md`, `data.json`, and `memory.md`\n- keep `data.json` as an authoring/thinking artifact rather than a runtime dependency\n- keep the artifact maintainable by a future agent reading only the bundle files\n\nAnti-patterns:\n\n- cursory or low-effort data collection\n- fake data added to make the artifact look complete\n- brittle one-off hacks that a later agent cannot reproduce\n- hidden dependencies that are not documented in `artifact.md` or `memory.md`\n- layout churn during simple data refreshes when the data model did not change\n\n## HTML house style\n\nHTML artifacts should feel intentional and readable inside Television tiles.\n\nTelevision provides a full base stylesheet for HTML artifacts. Only add custom\nCSS when you need something not covered by the built-in styles. Prefer the base\nstyles and theme tokens so artifacts stay visually coherent with the rest of\nTelevision.\n\nHouse-style guidance:\n\n- use semantic HTML first\n- keep the most important information near the top\n- design for small, medium, and large tile sizes\n- avoid horizontal overflow unless there is no reasonable alternative\n- make empty states and error states explicit\n- prefer the built-in HTML styling before inventing custom component chrome\n\n### Elements\n\nStandard elements already have sensible defaults, so you usually do not need to\nstyle from scratch:\n\n- headings (`h1`\u2013`h6`) \u2014 sized and weighted\n- `p`, `ul`, `ol` \u2014 readable defaults\n- `code` and `pre` \u2014 monospace, muted background\n- `blockquote` \u2014 left border, muted text\n- `table`, `th`, `td` \u2014 bordered, striped headers\n- `button` \u2014 styled with border and hover state; use `size="sm"` or `size="md"` when appropriate\n- `hr` \u2014 subtle border\n- `a` \u2014 inherits color by default\n\n### `.prose` class\n\nUse a `.prose` wrapper for document-style HTML where readable vertical rhythm is\nappropriate. Do not rely on `.prose` for dashboards, tables, control surfaces,\nor dense custom layouts.\n\n```html\n<div class="prose">\n  <h1>Title</h1>\n  <p>Some content with proper spacing between elements.</p>\n  <ul>\n    <li>Item one</li>\n    <li>Item two</li>\n  </ul>\n</div>\n```\n\n### CSS variables\n\nUse the existing Television tokens when they are available in the runtime.\nThese are the preferred way to stay aligned with the app theme.\n\nColors:\n- `--color-bg` \u2014 page background\n- `--color-bg-muted` \u2014 subtle background\n- `--color-surface` \u2014 card or panel background\n- `--color-text` \u2014 primary text\n- `--color-text-muted` \u2014 secondary or label text\n- `--color-border` \u2014 border color\n\nSpacing:\n- `--space-4`\n- `--space-8`\n- `--space-12`\n- `--space-16`\n- `--space-24`\n- `--space-32`\n\nFonts:\n- `--font-sans`\n- `--font-mono`\n\nText sizes:\n- `--text-sm`\n- `--text-base`\n- `--text-lg`\n- `--text-xl`\n\nRadius:\n- `--radius-4`\n- `--radius-8`\n\n## Workflows\n\n### Create new internal artifact\n\n1. Decide that the result should be an internal artifact.\n2. Start the pending bundle:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --no-focus\n```\n\n`--screen` is required for internal artifact creation so the artifact has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\n3. Read the returned pending path and edit files there.\n4. Write `artifact.md`.\n5. In `artifact.md`, capture the user\'s language faithfully in `## User intent` before doing the rest of the authoring work. Use direct quotes when helpful, or a close paraphrase when that is clearer, but keep it representative of what the user actually said they wanted.\n6. Think through the artifact in a pure way and write `data.json` only as an authoring aid.\n7. For markdown artifacts, leave `data.json` as `{}` unless there is a compelling authoring reason not to.\n8. Render `public/index.md` or `public/index.html`.\n9. Append a current timestamped activity entry in `memory.md`.\n10. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Update internal artifact with fresh data\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md` before changing anything.\n3. Refresh the underlying facts or source material.\n4. Update `data.json` only if it helps clarify the authoring plan.\n5. For markdown artifacts, prefer to keep `data.json` as `{}`.\n6. Make the minimum rendering changes needed to keep the artifact correct.\n7. Record what changed in `memory.md`.\n8. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\nAvoid unnecessary layout or styling churn during data-only refreshes.\n\n### Modify internal artifact from user feedback\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md`.\n3. Update `artifact.md` if the user intent or non-goals changed.\n4. When the user has added feedback, complaints, corrections, or new guidance, update `## User intent` so it remains a faithful record of what the user actually wants now. Preserve the user\'s language as closely as practical, using direct quotes or close paraphrases.\n5. Update `data.json` only if it improves the authoring model of the artifact.\n6. For markdown artifacts, prefer to keep `data.json` as `{}`.\n7. Adjust `public/index.md` or `public/index.html` as narrowly as possible.\n8. Record the request, decision, and resulting change in `memory.md`.\n9. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Abandon pending work\n\nIf the staged work should be discarded instead of committed:\n\n```bash\ntv abandon-pending-artifact --id "<artifact-id>"\n```\n\n### Create external artifact\n\nUse this when the file already exists on disk and Television should display it\nwithout owning a bundle:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --path /absolute/path/to/file.md --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --path /absolute/path/to/file.html --no-focus\n```\n\n`--screen` is required for CLI creation so the file has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--path` must be absolute\n- the file must already exist and be readable\n- the extension must match `type`\n- external artifacts do not use pending create, pending edit, commit, or abandon\n\n### Create URL artifact\n\nUse this when the artifact should display a live web page (an internal docs\npage, a dashboard, a third-party site) rather than content Television owns or a\nfile on disk:\n\n```bash\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --no-focus\n```\n\n`--screen` is required for CLI creation so the page has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--url` must be `http://` or `https://`\n- the type is always `text/html` \u2014 do not pass `--type`\n- URL artifacts are committed immediately on creation; they have no pending create, pending edit, commit, or abandon lifecycle\n- in the desktop app the page renders in a sandboxed `<webview>`; in the browser it renders in an `<iframe>`\n\n## CLI reference\n\nArtifact commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" (--focus-artifact|--no-focus)\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path (--focus-artifact|--no-focus)\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com (--focus-artifact|--no-focus)\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv list-artifacts [--screen "<screen-id>"] [--unplaced]\ntv get-artifact --id "<artifact-id>"\ntv delete-artifact --id "<artifact-id>"\n```\n\nScreen commands:\n\n```bash\ntv create-screen --name "Screen name" (--focus-screen|--no-focus)\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nScreen membership commands:\n\n```bash\ntv attach-artifact --id "<artifact-id>" --screen "<screen-id>" (--focus-artifact|--no-focus)\ntv detach-artifact --id "<artifact-id>" --screen "<screen-id>"\n```\n\nFocus commands:\n\n```bash\ntv focus-status\ntv focus-screen --id "<screen-id>"\ntv focus-artifact --id "<artifact-id>" [--screen "<screen-id>"]\n```\n\nServer commands:\n\n```bash\ntv status\ntv storage-path\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- `--screen` is required on CLI create commands so new artifacts get immediate screen membership; use `tv attach-artifact` and `tv detach-artifact` for later screen membership changes\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`; `tv create-internal-artifact`, `tv create-external-artifact`, `tv create-url-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv attach-artifact` appends a default-sized card to the right end of the strip; idempotent if the artifact is already on that screen\n- `tv detach-artifact` removes the card from a screen\'s layout; the artifact metadata is never touched, even on the last reference\n- `tv delete-artifact` is the way to globally remove an artifact (detaches from every screen, then trashes the bundle / forgets the external pointer / discards pending-create)\n- `tv list-artifacts` accepts `--screen <id>` to filter by screen membership and `--unplaced` to surface artifacts attached to no screen\n- `tv update-artifact` changes title metadata only\n- `tv focus-screen` sets which screen the GUI is focused on; the change is persisted and broadcast to connected clients\n- `tv focus-artifact` is a transient nudge: clients switch screens if needed, scroll the artifact\'s card into view, and play a brief highlight animation; pass `--screen <id>` to pin which screen, otherwise the server picks one (preferring the active screen when the artifact is there)\n- `tv focus-status` prints the active screen ID and the count of connected GUI clients\n- when the CLI reports an error, follow the directive to run `tv help`\n\n## Deferred or out of scope\n\nThese are not part of the current implementation:\n\n- `tv help <topic>`\n- restore-from-trash\n- pending-listing commands\n- attestation or nonce commands\n- stale pending cleanup or stale trash cleanup\n- markdown editor UI recovery\n- client-side pending presentation work\n- multi-section help output'.length > 0) {
+    return '# Television\n\nTelevision is a persistent artifact screen for agents. Use it when the user\nshould be able to inspect, revisit, and refine a file-backed result instead of\nonly reading a chat reply.\n\nIf you lose context, run:\n\n```bash\ntv help\n```\n\nThat command prints this full skill as one blob. There is no topic-scoped help\nin the current implementation.\n\n## Mental model\n\n- A **screen** is a named viewer surface with a layout.\n- An **artifact** is a file-backed result that can exist independently of any\n  screen. It can be unplaced, attached to one screen, or attached to multiple\n  screens.\n- **Screen membership** is separate from artifact identity: attaching/detaching\n  controls which screens show an artifact; deleting removes the artifact\n  globally. The CLI create commands require `--screen` so in-progress artifacts\n  are visible immediately.\n- An **internal artifact** is a Television-managed bundle. You create a pending\n  bundle, edit files in that bundle, then commit it.\n- An **external artifact** is a pointer to an existing absolute file on disk.\n  Television displays that file but does not own or delete it.\n- **Pending** means a create or edit is staged but not yet committed.\n- **Trash** means metadata and committed internal bundles moved out of the live\n  tree. There is no restore workflow in the current scope.\n\nThe core workflow is:\n\n1. Decide whether the result should be internal or external.\n2. Decide whether the user should be taken to the new screen or artifact now, or whether the work should happen in the background.\n3. Create or stage the artifact with the CLI.\n4. For internal artifacts, edit files in the pending bundle.\n5. Commit when the validation rules are satisfied.\n\n## Focus model\n\nTelevision separates state changes from focus.\n\nThere are two kinds of focus:\n\n- **Screen focus** is persistent. It decides which screen the TV is currently showing.\n- **Artifact focus** is transient. It may switch screens first, then scroll the artifact into view and briefly highlight it.\n\nImportant consequence:\n\n- there is a persisted focused screen\n- there is **not** a persisted focused artifact\n\nState-change commands can optionally trigger focus, but they do not imply it.\n\nAgent-facing create and attach commands require an explicit focus decision:\n\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`\n- `tv create-internal-artifact`, `tv create-external-artifact`, `tv create-url-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n\nUse this decision rule:\n\n- use `--focus-screen` when the user likely wants to go to the new screen immediately\n- use `--focus-artifact` when the user likely wants to inspect the new artifact immediately\n- use `--no-focus` when the work should happen in the background while keeping the current screen and artifact context unchanged\n\nHeuristic examples:\n\n- use a focus flag for requests like "show me", "open it", "put it on screen", "take me there", or "let me review it"\n- treat user language like **active**, **current**, **showing**, **visible**, **switch to**, **change to**, **go to**, or **show me that** as focus intent for the relevant screen or artifact\n- requests like "switch to the other screen", "show me that artifact", or "change to that screen" should usually translate to `tv focus-screen` or `tv focus-artifact`\n- use `--no-focus` for requests like "set this up", "make it in the background", "prepare it", or "wire this in"\n- also use `--no-focus` when the user says things like "in the background", "while I do something else", "while I work on X", or otherwise signals that your work should proceed on a parallel thread decoupled from their main task\n\nDirect focus commands:\n\n- `tv focus-screen --id <screen-id>` sets persistent screen focus\n- `tv focus-artifact --id <artifact-id> [--screen <screen-id>]` sends a transient artifact-focus nudge\n- `tv focus-status` reports the current persistent screen focus and connected client count\n\nImportant communication rule:\n\n- when you use `--no-focus`, explicitly say what you did in chat so the user knows the work happened even though Television did not visibly change\n\nIf you forget these rules or the CLI rejects a command for missing focus intent, run `tv help` and reread this section before retrying.\n\n## User communication during multi-step workflows\n\nWhen you are doing a multi-step artifact workflow, keep the user informed as you\nprogress.\n\nRequired communication style:\n\n- verbalize key actions and decisions as they happen\n- keep the language concise\n- prefer short updates over long explanations\n- frame updates in the user\'s world and goals, not in the internal mechanics of the skill or CLI workflow\n- avoid technical workflow jargon unless the user explicitly asks for it\n- do not write reports, long paragraphs, or chatty summaries while the work is in progress\n- do not use lists unless the user explicitly asks for one\n- optimize for speed and token efficiency\n\nGood examples:\n\n- "Starting the artifact now."\n- "Reviewing the draft and source material."\n- "Updating the HTML and efficiently navigating the artifact creation flow."\n- "The artifact did not pass validation yet; fixing the draft notes and retrying."\n- "Finalizing the artifact now."\n- "Done."\n\nBad examples:\n\n- multi-paragraph progress reports\n- long retrospective narration during execution\n- verbose bullet lists for routine workflow steps\n\n## Internal versus external\n\nUse an **internal artifact** when:\n\n- the artifact is purpose-built for Television\n- Television should own the bundle structure\n- future agents should be able to maintain the result by reading bundle files\n- you need a staged create or staged edit workflow\n\nUse an **external artifact** when:\n\n- a real file already exists on disk\n- the user wants Television to display that existing file\n- you do not need a Television-managed bundle\n\nDecision rule:\n\n- If the result should be maintained as a Television-owned long-lived artifact,\n  choose internal.\n- If the result is already a real file outside Television and should stay that\n  way, choose external.\n\nSupported artifact types:\n\n- `text/markdown`\n- `text/html`\n\n## Internal bundle files\n\nEvery internal artifact bundle contains:\n\n- `artifact.md`\n- `data.json`\n- `memory.md`\n- `public/index.md` or `public/index.html`\n\nFresh pending bundles are intentionally minimal:\n\n- `artifact.md` is blank\n- `memory.md` is blank\n- `public/index.md` or `public/index.html` is blank\n- `data.json` is exactly `{}`\n\nThe scaffold is not commit-valid by itself. Learn the required structure from\nthis skill, not from placeholder content in the scaffold.\n\n### `artifact.md`\n\n`artifact.md` is the contract for the artifact. It explains what the artifact\nis for, what conceptual material it is based on, how it should render, and how\nlater agents should maintain it.\n\nBefore commit, `artifact.md` must be non-empty and contain all of these exact\nheadings:\n\n```md\n## User intent\n## Purpose\n## Data shape\n## Data sources\n## Rendering\n## Update workflow\n## Non-goals\n```\n\nWhat each section should capture:\n\n- `## User intent`: faithful restatement or quotation of what the user actually said they wanted; this is critical and should preserve the user\'s language as closely as practical, including requests, feedback, complaints, constraints, and guidance\n- `## Purpose`: what the artifact is trying to achieve\n- `## Data shape`: the conceptual shape you reasoned about while authoring; for markdown artifacts this will often just be `{}`\n- `## Data sources`: where the underlying facts, notes, or source material came from and how they were obtained\n- `## Rendering`: how `public/index.md` or `public/index.html` should present it\n- `## Update workflow`: how future agents should refresh or modify it\n- `## Non-goals`: what is intentionally excluded, especially application-like runtime behavior\n\n### `data.json`\n\n`data.json` is a **thinking artifact**, not a runtime payload.\n\nIts purpose is to help the model separate:\n\n- reasoning / planning / authoring structure\n- from final presentation in `public/index.md` or `public/index.html`\n\nUse it to capture the pure conceptual shape of what you are about to render.\nThis is an authoring aid for agents, not an application data layer.\n\nHard rules:\n\n- **Do not treat `data.json` as live runtime state.**\n- **Do not write HTML/JS that loads, depends on, or synchronizes against `data.json`.**\n- **Do not build application-like data-driven artifacts.**\n- **We do not support runtime data-backed artifacts at this time.**\n- Artifacts are static markdown or static HTML documents.\n- HTML artifacts may include JavaScript and extra assets under `public/`, but\n  that JavaScript must stay presentation-oriented and self-contained, not\n  driven by `data.json` as an application state container.\n\nFor `text/markdown` artifacts, leave `data.json` as exactly:\n\n```json\n{}\n```\n\nThere is usually little value in separating content from presentation for\nmarkdown artifacts, so prefer `{}` unless there is a very strong authoring\nreason not to.\n\nFor `text/html` artifacts, use `data.json` only when it helps you think clearly\nabout the material before rendering. It may describe the conceptual structure\nof the artifact, but it must not become a runtime contract.\n\nValidation rule:\n\n- `data.json` must exist and contain valid JSON\n\nThe current validator does not require the JSON value to be an object, but an\nobject is the normal choice.\n\n### `memory.md`\n\n`memory.md` is the working scratchpad for later agents. Record decisions,\nlimitations, data-retrieval notes, problems encountered, what changed, and what\nshould be watched during future edits.\n\nRequired validation anchors:\n\n- `memory.md` must contain `## Activity Log`\n- `memory.md` must contain at least one UTC timestamp in exact\n  `YYYY-MM-DDTHH:MM:SSZ` format\n- at least one timestamp must be from the last 30 minutes when you commit\n\nThe minimum required heading is:\n\n```md\n## Activity Log\n```\n\nWhat to record beyond that is up to the artifact and the work performed.\n\n### `public/index.md` and `public/index.html`\n\nThis is the rendered entry file that Television serves.\n\n- Markdown artifacts use `public/index.md`\n- HTML artifacts use `public/index.html`\n- the entry file must match the artifact `type`\n- the entry file must be non-empty before commit\n\nFor HTML artifacts:\n\n- `public/index.html` is a full HTML document, not a body fragment\n- additional public assets may live under `public/`\n- keep paths relative to `public/`\n\n## Quality bar\n\nBuild artifacts that are durable, truthful, and maintainable by later agents.\n\nRequired quality standards:\n\n- be faithful to source data\n- do not invent or hallucinate missing facts\n- do not silently truncate a dataset and pretend it is complete\n- prefer truth over completeness when those goals conflict\n- make limitations, sampling, missing data, and freshness visible\n- keep rendering aligned with the reasoning captured in `artifact.md`, `data.json`, and `memory.md`\n- keep `data.json` as an authoring/thinking artifact rather than a runtime dependency\n- keep the artifact maintainable by a future agent reading only the bundle files\n\nAnti-patterns:\n\n- cursory or low-effort data collection\n- fake data added to make the artifact look complete\n- brittle one-off hacks that a later agent cannot reproduce\n- hidden dependencies that are not documented in `artifact.md` or `memory.md`\n- layout churn during simple data refreshes when the data model did not change\n\n## HTML house style\n\nHTML artifacts should feel intentional and readable inside Television tiles.\n\nTelevision provides a full base stylesheet for HTML artifacts. Only add custom\nCSS when you need something not covered by the built-in styles. Prefer the base\nstyles and theme tokens so artifacts stay visually coherent with the rest of\nTelevision.\n\nHouse-style guidance:\n\n- use semantic HTML first\n- keep the most important information near the top\n- design for small, medium, and large tile sizes\n- avoid horizontal overflow unless there is no reasonable alternative\n- make empty states and error states explicit\n- prefer the built-in HTML styling before inventing custom component chrome\n\n### Elements\n\nStandard elements already have sensible defaults, so you usually do not need to\nstyle from scratch:\n\n- headings (`h1`\u2013`h6`) \u2014 sized and weighted\n- `p`, `ul`, `ol` \u2014 readable defaults\n- `code` and `pre` \u2014 monospace, muted background\n- `blockquote` \u2014 left border, muted text\n- `table`, `th`, `td` \u2014 bordered, striped headers\n- `button` \u2014 styled with border and hover state; use `size="sm"` or `size="md"` when appropriate\n- `hr` \u2014 subtle border\n- `a` \u2014 inherits color by default\n\n### `.prose` class\n\nUse a `.prose` wrapper for document-style HTML where readable vertical rhythm is\nappropriate. Do not rely on `.prose` for dashboards, tables, control surfaces,\nor dense custom layouts.\n\n```html\n<div class="prose">\n  <h1>Title</h1>\n  <p>Some content with proper spacing between elements.</p>\n  <ul>\n    <li>Item one</li>\n    <li>Item two</li>\n  </ul>\n</div>\n```\n\n### CSS variables\n\nUse the existing Television tokens when they are available in the runtime.\nThese are the preferred way to stay aligned with the app theme.\n\nColors:\n- `--color-bg` \u2014 page background\n- `--color-bg-muted` \u2014 subtle background\n- `--color-surface` \u2014 card or panel background\n- `--color-text` \u2014 primary text\n- `--color-text-muted` \u2014 secondary or label text\n- `--color-border` \u2014 border color\n\nSpacing:\n- `--space-4`\n- `--space-8`\n- `--space-12`\n- `--space-16`\n- `--space-24`\n- `--space-32`\n\nFonts:\n- `--font-sans`\n- `--font-mono`\n\nText sizes:\n- `--text-sm`\n- `--text-base`\n- `--text-lg`\n- `--text-xl`\n\nRadius:\n- `--radius-4`\n- `--radius-8`\n\n## Workflows\n\n### Create new internal artifact\n\n1. Decide that the result should be an internal artifact.\n2. Start the pending bundle:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --no-focus\n```\n\n`--screen` is required for internal artifact creation so the artifact has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\n3. Read the returned pending path and edit files there.\n4. Write `artifact.md`.\n5. In `artifact.md`, capture the user\'s language faithfully in `## User intent` before doing the rest of the authoring work. Use direct quotes when helpful, or a close paraphrase when that is clearer, but keep it representative of what the user actually said they wanted.\n6. Think through the artifact in a pure way and write `data.json` only as an authoring aid.\n7. For markdown artifacts, leave `data.json` as `{}` unless there is a compelling authoring reason not to.\n8. Render `public/index.md` or `public/index.html`.\n9. Append a current timestamped activity entry in `memory.md`.\n10. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Update internal artifact with fresh data\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md` before changing anything.\n3. Refresh the underlying facts or source material.\n4. Update `data.json` only if it helps clarify the authoring plan.\n5. For markdown artifacts, prefer to keep `data.json` as `{}`.\n6. Make the minimum rendering changes needed to keep the artifact correct.\n7. Record what changed in `memory.md`.\n8. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\nAvoid unnecessary layout or styling churn during data-only refreshes.\n\n### Modify internal artifact from user feedback\n\n1. Stage the edit:\n\n```bash\ntv edit-internal-artifact --id "<artifact-id>"\n```\n\n2. Read `artifact.md`, `data.json`, and `memory.md`.\n3. Update `artifact.md` if the user intent or non-goals changed.\n4. When the user has added feedback, complaints, corrections, or new guidance, update `## User intent` so it remains a faithful record of what the user actually wants now. Preserve the user\'s language as closely as practical, using direct quotes or close paraphrases.\n5. Update `data.json` only if it improves the authoring model of the artifact.\n6. For markdown artifacts, prefer to keep `data.json` as `{}`.\n7. Adjust `public/index.md` or `public/index.html` as narrowly as possible.\n8. Record the request, decision, and resulting change in `memory.md`.\n9. Commit:\n\n```bash\ntv commit-pending-artifact --id "<artifact-id>"\n```\n\n### Abandon pending work\n\nIf the staged work should be discarded instead of committed:\n\n```bash\ntv abandon-pending-artifact --id "<artifact-id>"\n```\n\n### Create external artifact\n\nUse this when the file already exists on disk and Television should display it\nwithout owning a bundle:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --path /absolute/path/to/file.md --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-external-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --path /absolute/path/to/file.html --no-focus\n```\n\n`--screen` is required for CLI creation so the file has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--path` must be absolute\n- the file must already exist and be readable\n- the extension must match `type`\n- external artifacts do not use pending create, pending edit, commit, or abandon\n\n### Create URL artifact\n\nUse this when the artifact should display a live web page (an internal docs\npage, a dashboard, a third-party site) rather than content Television owns or a\nfile on disk:\n\n```bash\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --focus-artifact\n```\n\nOr:\n\n```bash\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --no-focus\n```\n\n`--screen` is required for CLI creation so the page has immediate screen membership. `--focus-artifact` or `--no-focus` is also required so you explicitly decide whether the user should be taken to it now.\n\nRules:\n\n- `--url` must be `http://` or `https://`\n- the type is always `text/html` \u2014 do not pass `--type`\n- URL artifacts are committed immediately on creation; they have no pending create, pending edit, commit, or abandon lifecycle\n- in the desktop app the page renders in a sandboxed `<webview>`; in the browser it renders in an `<iframe>`\n\n## CLI reference\n\nArtifact commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" (--focus-artifact|--no-focus)\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path (--focus-artifact|--no-focus)\ntv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com (--focus-artifact|--no-focus)\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv list-artifacts [--screen "<screen-id>"] [--unplaced]\ntv get-artifact --id "<artifact-id>"\ntv delete-artifact --id "<artifact-id>"\n```\n\nScreen commands:\n\n```bash\ntv create-screen --name "Screen name" (--focus-screen|--no-focus)\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nScreen membership commands:\n\n```bash\ntv attach-artifact --id "<artifact-id>" --screen "<screen-id>" (--focus-artifact|--no-focus)\ntv detach-artifact --id "<artifact-id>" --screen "<screen-id>"\n```\n\nFocus commands:\n\n```bash\ntv focus-status\ntv focus-screen --id "<screen-id>"\ntv focus-artifact --id "<artifact-id>" [--screen "<screen-id>"]\n```\n\nServer commands:\n\n```bash\ntv status\ntv storage-path\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- `--screen` is required on CLI create commands so new artifacts get immediate screen membership; use `tv attach-artifact` and `tv detach-artifact` for later screen membership changes\n- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`; `tv create-internal-artifact`, `tv create-external-artifact`, `tv create-url-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv attach-artifact` appends a default-sized card to the right end of the strip; idempotent if the artifact is already on that screen\n- `tv detach-artifact` removes the card from a screen\'s layout; the artifact metadata is never touched, even on the last reference\n- `tv delete-artifact` is the way to globally remove an artifact (detaches from every screen, then trashes the bundle / forgets the external pointer / discards pending-create)\n- `tv list-artifacts` accepts `--screen <id>` to filter by screen membership and `--unplaced` to surface artifacts attached to no screen\n- `tv update-artifact` changes title metadata only\n- `tv focus-screen` sets which screen the GUI is focused on; the change is persisted and broadcast to connected clients\n- `tv focus-artifact` is a transient nudge: clients switch screens if needed, scroll the artifact\'s card into view, and play a brief highlight animation; pass `--screen <id>` to pin which screen, otherwise the server picks one (preferring the active screen when the artifact is there)\n- `tv focus-status` prints the active screen ID and the count of connected GUI clients\n- when the CLI reports an error, follow the directive to run `tv help`\n\n## Deferred or out of scope\n\nThese are not part of the current implementation:\n\n- `tv help <topic>`\n- restore-from-trash\n- pending-listing commands\n- attestation or nonce commands\n- stale pending cleanup or stale trash cleanup\n- markdown editor UI recovery\n- client-side pending presentation work\n- multi-section help output';
   }
   const devSkillPath = import_node_path7.default.join(getDevPackageDir(), "skill/SKILL.md");
   if (!(0, import_node_fs4.existsSync)(devSkillPath)) {
@@ -50493,7 +50493,8 @@ If you wish to display temporary content to the user, use an internal artifact i
     writeLine(env.stdout, `External artifact ${artifact.id} created.`);
     writeLine(env.stdout, `Television will display content from ${externalPath} and watch it for changes.`);
   });
-  program2.command("create-url-artifact").description("Create a URL-backed artifact that embeds an external page").requiredOption("--screen <id>", "Target screen ID").requiredOption("--title <title>", "Artifact title").requiredOption("--url <url>", "http(s) URL of the page to embed").option("--server <url>", "Server URL", DEFAULT_SERVER_URL).action(async (opts) => {
+  program2.command("create-url-artifact").description("Create a URL-backed artifact that embeds an external page").requiredOption("--screen <id>", "Target screen ID").requiredOption("--title <title>", "Artifact title").requiredOption("--url <url>", "http(s) URL of the page to embed").option("--focus-artifact", "Focus the new artifact after creation").option("--no-focus", "Create the artifact in the background without changing focus").option("--server <url>", "Server URL", DEFAULT_SERVER_URL).action(async (opts) => {
+    const shouldFocus = resolveFocusDirective(argv, "create-url-artifact", "--focus-artifact");
     const client = createAuthenticatedClient(opts.server);
     const { artifact } = await client.artifacts.create({
       externalURL: opts.url,
@@ -50501,6 +50502,9 @@ If you wish to display temporary content to the user, use an internal artifact i
       type: "text/html",
       screenID: opts.screen
     });
+    if (shouldFocus) {
+      await client.viewer.focus({ artifactID: artifact.id, screenID: opts.screen });
+    }
     writeLine(env.stdout, `URL artifact ${artifact.id} created.`);
     writeLine(env.stdout, `Television will display ${opts.url} in an embedded frame.`);
   });