@telepath-computer/television 0.1.32 → 0.1.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/browser/assets/index-B2ud1GTM.css +1 -0
- package/dist/browser/assets/index-CtP6T8MN.js +520 -0
- package/dist/browser/index.html +2 -2
- package/dist/cli.cjs +4 -4
- package/package.json +1 -1
- package/skill/SKILL.md +2 -2
- package/dist/browser/assets/index-BBVNTUwf.js +0 -552
- package/dist/browser/assets/index-C0YgLV2m.css +0 -1
package/dist/browser/index.html
CHANGED
|
@@ -4,8 +4,8 @@
|
|
|
4
4
|
<meta charset="UTF-8" />
|
|
5
5
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
6
6
|
<title>Television</title>
|
|
7
|
-
<script type="module" crossorigin src="./assets/index-
|
|
8
|
-
<link rel="stylesheet" crossorigin href="./assets/index-
|
|
7
|
+
<script type="module" crossorigin src="./assets/index-CtP6T8MN.js"></script>
|
|
8
|
+
<link rel="stylesheet" crossorigin href="./assets/index-B2ud1GTM.css">
|
|
9
9
|
</head>
|
|
10
10
|
<body></body>
|
|
11
11
|
</html>
|
package/dist/cli.cjs
CHANGED
|
@@ -49508,8 +49508,8 @@ function createDirectiveError(message) {
|
|
|
49508
49508
|
return new CLIDirectiveError(ensureHelpPointer(message));
|
|
49509
49509
|
}
|
|
49510
49510
|
function readCLIVersion() {
|
|
49511
|
-
if ("0.1.
|
|
49512
|
-
return "0.1.
|
|
49511
|
+
if ("0.1.34".length > 0) {
|
|
49512
|
+
return "0.1.34";
|
|
49513
49513
|
}
|
|
49514
49514
|
const devPackageJsonPath = import_node_path7.default.resolve(process.cwd(), "package.json");
|
|
49515
49515
|
if (!(0, import_node_fs4.existsSync)(devPackageJsonPath)) {
|
|
@@ -49518,8 +49518,8 @@ function readCLIVersion() {
|
|
|
49518
49518
|
return JSON.parse((0, import_node_fs4.readFileSync)(devPackageJsonPath, "utf8")).version;
|
|
49519
49519
|
}
|
|
49520
49520
|
function readWorkflowHelpText() {
|
|
49521
|
-
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 the screen and layout container.\n- An **artifact** is one displayed result on that screen.\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. Create or stage the artifact with the CLI.\n3. For internal artifacts, edit files in the pending bundle.\n4. Commit when the validation rules are satisfied.\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-sm`\n- `--radius-md`\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"\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title"\n```\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\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\n```\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\nWorkflow commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title"\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv remove-artifact --id "<artifact-id>" --screen "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nRead and server commands:\n\n```bash\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv create-screen --name "Screen name"\ntv storage-path\ntv status\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv remove-artifact` removes the artifact reference from the named screen; if another screen still references it, the artifact is unlinked and kept alive; otherwise it cascades to trash/discard\n- `tv update-artifact` changes title metadata only\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) {
|
|
49522
|
-
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 the screen and layout container.\n- An **artifact** is one displayed result on that screen.\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. Create or stage the artifact with the CLI.\n3. For internal artifacts, edit files in the pending bundle.\n4. Commit when the validation rules are satisfied.\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-sm`\n- `--radius-md`\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"\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title"\n```\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\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\n```\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\nWorkflow commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title"\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv remove-artifact --id "<artifact-id>" --screen "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nRead and server commands:\n\n```bash\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv create-screen --name "Screen name"\ntv storage-path\ntv status\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv remove-artifact` removes the artifact reference from the named screen; if another screen still references it, the artifact is unlinked and kept alive; otherwise it cascades to trash/discard\n- `tv update-artifact` changes title metadata only\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';
|
|
49521
|
+
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 the screen and layout container.\n- An **artifact** is one displayed result on that screen.\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. Create or stage the artifact with the CLI.\n3. For internal artifacts, edit files in the pending bundle.\n4. Commit when the validation rules are satisfied.\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"\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title"\n```\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\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\n```\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\nWorkflow commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title"\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv remove-artifact --id "<artifact-id>" --screen "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nRead and server commands:\n\n```bash\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv create-screen --name "Screen name"\ntv storage-path\ntv status\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv remove-artifact` removes the artifact reference from the named screen; if another screen still references it, the artifact is unlinked and kept alive; otherwise it cascades to trash/discard\n- `tv update-artifact` changes title metadata only\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) {
|
|
49522
|
+
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 the screen and layout container.\n- An **artifact** is one displayed result on that screen.\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. Create or stage the artifact with the CLI.\n3. For internal artifacts, edit files in the pending bundle.\n4. Commit when the validation rules are satisfied.\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"\n```\n\nOr:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title"\n```\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\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\n```\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\nWorkflow commands:\n\n```bash\ntv create-internal-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title"\ntv edit-internal-artifact --id "<artifact-id>"\ntv commit-pending-artifact --id "<artifact-id>"\ntv abandon-pending-artifact --id "<artifact-id>"\ntv create-external-artifact --screen "<screen-id>" --type <text/markdown|text/html> --title "Artifact title" --path /absolute/path\ntv update-artifact --id "<artifact-id>" --title "New title"\ntv remove-artifact --id "<artifact-id>" --screen "<screen-id>"\ntv remove-screen --id "<screen-id>"\n```\n\nRead and server commands:\n\n```bash\ntv list-screens\ntv get-screen --id "<screen-id>"\ntv create-screen --name "Screen name"\ntv storage-path\ntv status\ntv serve\ntv stop\n```\n\nCLI behavior notes:\n\n- workflow and mutation commands print plain text\n- read commands print JSON\n- `tv get-screen` includes artifact `kind` and `status`\n- `tv remove-artifact` removes the artifact reference from the named screen; if another screen still references it, the artifact is unlinked and kept alive; otherwise it cascades to trash/discard\n- `tv update-artifact` changes title metadata only\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';
|
|
49523
49523
|
}
|
|
49524
49524
|
const devSkillPath = import_node_path7.default.resolve(process.cwd(), "skill/SKILL.md");
|
|
49525
49525
|
if (!(0, import_node_fs4.existsSync)(devSkillPath)) {
|
package/package.json
CHANGED