tux-review 0.1.0

package/skills/tux-design-create.md

@@ -0,0 +1,50 @@
+---
+name: tux-design-create
+description: Create or update a clickable TUX design from project requirements — screens, routes, components, UI states, verification.
+---
+
+# tux-design-create
+
+Create or update a clickable design from project requirements after the
+design capability is available (SPC sections 36–37, 81).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. **Read requirements** near the design (for example
+   `requirements/<feature>/requirements.md`). Identify screens, routes,
+   components, interactions, and UI states.
+2. Choose the framework from the requirements or ask:
+   `tux design create --framework vanilla|react|vue|angular`.
+3. Run the command — it scaffolds `requirements/<slug>/design/` with a
+   runnable multi-route design (vanilla: History-API SPA with tabs and a
+   modal; react/vue: vite scaffolds; angular: standalone component
+   scaffold) and TUX targeting attributes
+   (`data-tux-id`, `data-tux-component`, `data-tux-instance`).
+4. **Implement the screens**: replace placeholder content with the
+   requirements-derived pages, keep the route structure, wire real
+   interactions (tabs, modals, drawers, forms).
+5. Mark component instances with `data-tux-instance` so feedback on one
+   instance never appears on another (SPC section 85).
+6. Run `tux design start-review`, navigate every route, and verify the
+   review capability: create feedback on a component, reload, see the
+   marker restored, and confirm
+   `tux feedback show --format json` returns it.
+7. Report the created routes, components, and UI states with the
+   verification result.

package/skills/tux-design-incorporate.md

@@ -0,0 +1,61 @@
+---
+name: tux-design-incorporate
+description: Process design-session feedback into the development workflow — validate, group, deduplicate, surface conflicts, verify the framework, preserve IDs.
+---
+
+# tux-design-incorporate
+
+Process unresolved feedback of the design session using the user's
+methodology, including the testing and verification methodology of the
+framework in use (SPC sections 49–57, 90).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Load the open design feedback in scope:
+   `tux feedback show --status open --origin design --format json`
+   (optionally `--mine`, `--route <route>`, `--session <name>`). The
+   default scope is all open design feedback — not `--mine` (SPC
+   section 52).
+2. **Validate** every item against the schema (`tux feedback show <id>`
+   for details). Malformed items are reported, never dropped.
+3. **Group** by route/component/instance. The CLI pre-computes groups,
+   duplicates, and conflicts: run
+   `tux feedback incorporate --strategy export-only --origin design --format json`
+   to inspect the report without changing anything.
+4. **Duplicates** (identical normalized text on the same target): keep
+   every original, consolidate the request, and preserve the source IDs
+   in the traceability record (SPC section 53).
+5. **Conflicts** (an approval contradicting a requested change on the
+   same target): surface them with `requires_decision: true` and ask the
+   user. Do not resolve explicit contradictions silently (SPC section 54).
+6. **Choose the methodology** with the user when interactive:
+   consolidate first · update requirements · create implementation tasks
+   · apply actionable changes directly · review conflicts first · export
+   only. Then run
+   `tux feedback incorporate --strategy consolidate|requirements|tasks|direct --origin design --format json`.
+   The CLI marks processed items `incorporated`, records the batch under
+   `.tux/incorporations/`, and keeps every feedback ID.
+7. **Implement and verify** using the methodology of the framework in
+   use: apply the changes to the design, then verify each item in the
+   running UI (`tux design start-review`) and record the result with
+   `tux feedback validate --record <id> --result passed|failed --note "<observed>"`.
+   Only successfully verified feedback counts as resolved (SPC 94).
+8. Report what was incorporated, what needs a decision, and where the
+   traceability lives. Feedback items are never deleted by this skill.

package/skills/tux-design-install.md

@@ -0,0 +1,56 @@
+---
+name: tux-design-install
+description: Install TUX into the clickable design environment of the current project — discovery, config, review client wiring, tests, verification.
+---
+
+# tux-design-install
+
+Establish a correct, tested, and accepted TUX design installation in the
+current project (SPC sections 28–31, 79).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant. Never automate the visual review interface — the CLI and
+the canonical JSON output are the machine interface.
+
+## Workflow
+
+1. **Discover** the project: design root (default `requirements/`),
+   framework (vanilla, react, vue, angular), package manager, dev server,
+   test framework.
+2. Run `tux design install --framework <framework>` — this creates or
+   updates `tux.config.json` with the canonical defaults
+   (`design.root`, `review.store`, `review.host`, `review.port`,
+   `identity.provider`).
+3. If no clickable design exists yet, run the `tux-design-create` skill.
+4. **Wire the review client**: the design is served through
+   `tux design start-review` (static hosting + script injection). No
+   manual script tags are required; a design may also include the client
+   via `/__tux__/bootstrap.js` + `/__tux__/client.js` on its own.
+5. **Route awareness**: verify the design exposes real routes (paths or
+   History-API navigation). Add `data-tux-component`,
+   `data-tux-instance`, `data-tux-id` attributes for component-level
+   targeting where missing.
+6. **Tests**: add the required integration checks (loading, default
+   activation, config activation, URL override, feedback
+   create→persist→reload→CLI retrieval, route awareness, SPA navigation,
+   machine interface `tux feedback show --format json`).
+7. **Run and verify** per SPC section 86: build/start, activate, create
+   feedback on multiple routes, reload, verify persistence, verify CLI.
+8. **Accept**: report `passed`, `partial`, or `failed`. Never report
+   `passed` when only a dependency was added, feedback persistence
+   failed, route tracking failed, CLI JSON failed, or the target design
+   is broken (SPC section 87).

package/skills/tux-design-start-review.md

@@ -0,0 +1,51 @@
+---
+name: tux-design-start-review
+description: Start the clickable-mockup review server, gather design feedback, verify the review loop end to end.
+---
+
+# tux-design-start-review
+
+Start the clickable-mockup server with TUX review functionality and
+verify the review loop (SPC sections 38, 88).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Run `tux design start-review --session <name>` from the project root
+   (or the design directory). It starts the server detached and returns
+   the state (URL, pid, session); use `--foreground` to keep it in the
+   foreground and `--port` when the canonical port 4173 is taken. The
+   server hosts the design, injects the Review Client, exposes the
+   feedback API, and persists to the configured store.
+2. Manage the lifecycle: `tux design status` reports running state with
+   URL, session and feedback count; `tux design stop-review` stops it. Stopping
+   never deletes feedback.
+3. Verify activation: the client must load without `?tux=on` when the
+   config is default-enabled (SPC section 64), and must stay inert with
+   `?tux=off`.
+4. Walk the acceptance scenario (SPC section 88): navigate to
+   `/products`, comment on a component, navigate to `/checkout`, comment
+   on a button, open the modal, comment inside the modal, reload,
+   revisit the routes — all markers must reappear in the correct
+   context.
+5. Verify the machine interface: `tux feedback show --format json` must
+   return all feedback created in the browser, with routes, components,
+   and UI state attached.
+6. Report the review URL, session name, feedback count, and the
+   verification result.

package/skills/tux-design-stop-review.md

@@ -0,0 +1,44 @@
+---
+name: tux-design-stop-review
+description: Stop the design review server cleanly — check state first, report the session summary, preserve every feedback item.
+---
+
+# tux-design-stop-review
+
+End a design review session deliberately: check the server state, hand
+over a session summary, then stop the server without touching the
+feedback store (SPC sections 38 and 41 — design status and stop-review
+share the live semantics).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Check the current state: `tux design status --format json` — reports
+   `running` with URL, session and feedback count, or `stopped`. Never
+   stop blind.
+2. Report the session summary before stopping: review URL, session name,
+   feedback count. Stopping ends the server, not the session data.
+3. Stop with `tux design stop-review --format json`. The output confirms
+   `stopped: true` with the pid; `stopped: false` with reason
+   `not running` means there was nothing to stop.
+4. Verify: `tux design status` now reports `stopped`, and the feedback
+   store still contains every item — stopping MUST NOT delete feedback
+   (SPC section 41).
+5. Report the final state: server stopped, feedback count preserved,
+   store path.

package/skills/tux-feedback-delete.md

@@ -0,0 +1,45 @@
+---
+name: tux-feedback-delete
+description: Delete TUX feedback items by ID, a list of IDs, or all — with ownership and confirmation semantics.
+---
+
+# tux-feedback-delete
+
+Delete feedback items (SPC sections 45–47). Deleting is destructive:
+confirm with the user before removing anything that was not explicitly
+named.
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Delete one item: `tux feedback delete <feedback-id>`.
+2. Delete a list of items: repeat the command per ID, or remove a whole
+   scope with `tux feedback clear --mine` (current identity) /
+   `tux feedback clear --all --force` (everything; requires explicit
+   confirmation) — both accept `--route` and `--session` to bound the
+   scope.
+3. Delete everything for one context: combine scopes, e.g.
+   `tux feedback clear --all --force --origin design --session <name>`.
+4. A missing ID fails with exit code 6 and does not touch the store;
+   report it instead of retrying blindly.
+5. Never delete feedback to "clean up" without an explicit user request:
+   feedback is the durable record of the review (SPC section 94). Deletion
+   is reserved for duplicates the user approved, spam, or user-requested
+   removal.
+6. Report exactly which IDs were deleted and which remain.

package/skills/tux-feedback-export.md

@@ -0,0 +1,47 @@
+---
+name: tux-feedback-export
+description: Export TUX feedback as canonical JSON or JSONL — serialize without interpretation for handoff to humans, tools or agents.
+---
+
+# tux-feedback-export
+
+Export feedback as a file or stream, serialized without interpretation
+(SPC section 46). Export never mutates the store.
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Export the full store as canonical JSON:
+   `tux feedback export --format json` (array, fixed key order,
+   2-space indent, UTF-8, `\n`).
+2. Export line-delimited for streaming/line tools:
+   `tux feedback export --format jsonl` — one compact JSON object per
+   line, keys in schema order.
+3. Scope the export the same way as the survey: `--origin design|live`,
+   `--route`, `--session`, `--status`, `--mine` (export composes with
+   the show filters; use `tux feedback show` first if you need the
+   filtered view for orientation).
+4. Redirect the stream to a file when the user asked for an artifact:
+   `tux feedback export --format json > tux-feedback.json`. The output
+   is deterministic — the same store always produces byte-identical
+   files on Node and Python.
+5. Never edit exported content: the export is the record. Corrections
+   happen in the store (`feedback update`, `feedback validate --record`)
+   and are exported again.
+6. Report the export path, format and item count.

package/skills/tux-feedback-show.md

@@ -0,0 +1,55 @@
+---
+name: tux-feedback-show
+description: Show TUX feedback — the complete canonical item by ID, or a filtered survey of all items with deterministic, machine-readable output.
+---
+
+# tux-feedback-show
+
+Show feedback items (SPC section 42): `tux feedback show` without an ID
+surveys all items with deterministic, machine-readable output;
+`tux feedback show <id>` prints the complete canonical item — location,
+target, UI state, author, status, incorporation and validation
+metadata.
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Run `tux feedback show --format json` for the full survey. The output
+   is a canonical JSON array: fixed key order, no locale, no timestamps
+   beyond the stored ones.
+2. Narrow the survey with filters — they compose:
+   `--status open|incorporated|resolved|rejected`,
+   `--type change|issue|question|approval`,
+   `--origin design|live`,
+   `--route <route>`,
+   `--session <name>`,
+   `--mine` (current identity).
+3. Prefer explicit filters over post-filtering the JSON: the CLI output
+   is byte-identical between the Node and Python implementations and
+   safe to parse with any tool.
+4. Show one item: `tux feedback show <feedback-id>` — prints the
+   complete canonical JSON of that item. Filters and `--format` do not
+   apply in ID mode.
+5. A missing ID fails with exit code 6 and
+   `error: feedback not found: <id>` on stderr — report it, never
+   guess.
+6. Cite item IDs verbatim in your report; the ID is the stable
+   reference across incorporation and validation. Use `tux feedback
+   incorporate --strategy export-only --format json` to see
+   grouping/duplicates/conflicts before deciding.

package/skills/tux-live-create.md

@@ -0,0 +1,50 @@
+---
+name: tux-live-create
+description: Create or update clickable live pages in the target technology (vanilla, react, vue, angular) wired with TUX targeting attributes.
+---
+
+# tux-live-create
+
+Create or update clickable live pages using the methodology and the
+target technology chosen by the user (SPC section 32).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. **Clarify** the target technology (vanilla, react, vue, angular) and
+   the pages to build. For a green-field live app run
+   `tux live create --framework <framework> --name <slug>` — it
+   scaffolds the same runnable multi-route application as
+   `tux design create`, but as a live app (`"kind": "live"`, feedback
+   gathered through it carries `"origin": "live"`).
+2. For an existing application do not scaffold — extend the running app
+   in its own idiom instead (components, routes, state) and keep the
+   build system untouched.
+3. **Wire targeting attributes** on the components under review:
+   `data-tux-component` on component roots, `data-tux-instance` on
+   component instances, `data-tux-id` on individual elements, and
+   `data-tux-state` for bounded UI-state capture (SPC sections 13–15).
+4. **Verify** with `tux live start-review --url <dev-server>`: create
+   feedback on a page, a component instance and a modal; reload and
+   confirm the markers restore; confirm
+   `tux feedback show --format json` returns the items with
+   `"origin": "live"`.
+5. **Accept**: report pages, components, routes and the verification
+   result. Never report `passed` when persistence or route tracking
+   failed.

package/skills/tux-live-incorporate.md

@@ -0,0 +1,62 @@
+---
+name: tux-live-incorporate
+description: Process live-session feedback into the development workflow — validate, group, deduplicate, surface conflicts, verify the framework, preserve IDs.
+---
+
+# tux-live-incorporate
+
+Process unresolved feedback of the live session using the user's
+methodology, including the testing and verification methodology of the
+framework in use (SPC sections 49–57, 90).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Load the open live feedback in scope:
+   `tux feedback show --status open --origin live --format json`
+   (optionally `--mine`, `--route <route>`, `--session <name>`). The
+   default scope is all open live feedback — not `--mine` (SPC
+   section 52).
+2. **Validate** every item against the schema (`tux feedback show <id>`
+   for details). Malformed items are reported, never dropped.
+3. **Group** by route/component/instance. The CLI pre-computes groups,
+   duplicates, and conflicts: run
+   `tux feedback incorporate --strategy export-only --origin live --format json`
+   to inspect the report without changing anything.
+4. **Duplicates** (identical normalized text on the same target): keep
+   every original, consolidate the request, and preserve the source IDs
+   in the traceability record (SPC section 53).
+5. **Conflicts** (an approval contradicting a requested change on the
+   same target): surface them with `requires_decision: true` and ask the
+   user. Do not resolve explicit contradictions silently (SPC section 54).
+6. **Choose the methodology** with the user when interactive:
+   consolidate first · update requirements · create implementation tasks
+   · apply actionable changes directly · review conflicts first · export
+   only. Then run
+   `tux feedback incorporate --strategy consolidate|requirements|tasks|direct --origin live --format json`.
+   The CLI marks processed items `incorporated`, records the batch under
+   `.tux/incorporations/`, and keeps every feedback ID.
+7. **Implement and verify** using the methodology of the framework in
+   use: apply the changes to the application, then verify each item in
+   the running UI (`tux live start-review --url …`) and record the
+   result with
+   `tux feedback validate --record <id> --result passed|failed --note "<observed>"`.
+   Only successfully verified feedback counts as resolved (SPC 94).
+8. Report what was incorporated, what needs a decision, and where the
+   traceability lives. Feedback items are never deleted by this skill.

package/skills/tux-live-install.md

@@ -0,0 +1,63 @@
+---
+name: tux-live-install
+description: Install TUX live review into an existing application — discovery, least-invasive strategy, activation controls, build exclusion, tests.
+---
+
+# tux-live-install
+
+Establish a correct, tested, and accepted TUX live-review installation in
+an existing application (SPC sections 32–35, 80).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. **Discover** the application: runtime, framework (Vanilla, React,
+   Next.js, Vue, Nuxt, Angular, Svelte/SvelteKit, Vite, Webpack,
+   FastAPI, Flask, Django), build system, dev server, router, SPA vs
+   multi-page, middleware, proxy setup, configuration system, test
+   framework. Report unsupported setups explicitly (SPC section 33).
+2. Run `tux live install` — it detects the setup and selects the
+   least-invasive valid strategy (proxy injection by default: zero
+   application changes; the reverse proxy injects the Review Client into
+   HTML responses).
+3. **Configure** the review service: `tux.config.json`
+   (`review.enabled`, `review.store`, `review.host`, `review.port`,
+   `identity`). Identity may come from local config, environment, or
+   application authentication (SPC section 21).
+4. **Activation controls**: implement the three-layer model (SPC
+   sections 62–67): build-time inclusion, startup configuration, URL
+   runtime override (`?tux=on`, `?tux=off`), with the normative
+   precedence BUILD ABSENCE > URL OVERRIDE > CONFIG > DEFAULT ENABLED.
+5. **Build exclusion**: verify a deployment without TUX contains no
+   Review Client, no bootstrap, no review API, no feedback endpoints,
+   and no TUX assets (SPC section 63). `?tux=on` on such a build must
+   change nothing.
+6. **Tests**: add the required integration tests (SPC section 85):
+   loading included/excluded, default activation, config activation, URL
+   override both directions, build exclusion, feedback
+   create→persist→reload→retrieve, editing, deletion (`delete one`,
+   `clear --mine`, `clear --all`), route awareness, SPA navigation,
+   component instance identity, UI state, persistence across restart,
+   and `tux feedback show --format json` producing valid canonical JSON.
+7. **Run and verify** per SPC sections 86–87, then security-check
+   (section 70): runtime disabling is not removal; recommend build
+   exclusion for environments that do not need TUX.
+8. **Accept**: report `passed`, `partial`, or `failed` — never `passed`
+   when runtime was not tested, persistence failed, CLI JSON failed,
+   URL precedence failed, or build exclusion failed.

package/skills/tux-live-start-review.md

@@ -0,0 +1,47 @@
+---
+name: tux-live-start-review
+description: Start the UIX framework (vanilla, react, vue, angular) with the feedback system attached and verify live review.
+---
+
+# tux-live-start-review
+
+Start the user's framework — angular, vue, react or vanilla — with the
+TUX feedback system attached, and verify live review (SPC sections
+39–41, 82).
+
+## Resolve the CLI
+
+Choose one TUX CLI variant; both implement the same commands and canonical
+JSON output, so do not install both:
+
+1. **Node.js/npm** — use an existing `tux --version` on PATH, or run
+   `npx --yes --package=tux-review tux --version` and prefix commands with
+   `npx --yes --package=tux-review tux …`.
+2. **Python/PyPI** — install with `pipx install tux-review` (or
+   `python -m pip install tux-review` in the active virtual environment),
+   then use `tux --version`. For a one-off run, use
+   `pipx run tux-review tux --version`.
+
+All commands below use the neutral form `tux <domain> <action>`. Replace
+`tux` with the Node `npx … tux` prefix only when you chose the Node
+one-off variant.
+
+## Workflow
+
+1. Attach to a running application with
+   `tux live start-review --url http://localhost:3000`, or let TUX launch
+   it: `tux live start-review -- npm run dev` (the command after `--` is
+   spawned; its port defaults to 3000, override with `--target-port`).
+   The command works for every framework — vanilla static servers,
+   `ng serve`, `vite`, `next dev`. Use `--session <name>` to name the
+   review session.
+2. Verify: the application remains fully functional behind the proxy;
+   the Review Client is active according to configuration; the feedback
+   API answers; `tux live status` reports `running` with URL, target,
+   session and feedback count.
+3. Hand the review URL to the reviewers. Runtime activation follows the
+   canonical rules: config-disabled start is enabled ad hoc with
+   `?tux=on`, disabled again with `?tux=off` (SPC section 89).
+4. Stop with `tux live stop-review` when the session ends. Stopping must never
+   delete feedback (SPC section 41).
+5. Report the review URL, session, target, and the verification result.