---
name: carbon-demo
description: Create a fresh, disposable CARBON demo project when the user has no code to test yet, choose a bundled website, SPA, API, eval harness, or large codebase, optionally include a representative existing suite, then run CARBON First Look against the copy. Use when a user says carbon demo, show me a demo, try Carbon without code, or asks for a safe sample project.
---

# CARBON Demo

Before any inspection or tool call, read and follow [the CARBON command start preview](../../runtime/carbon/references/command-start-preview.md). Explain that the demo is a new local copy, not the user's project, and that external writes, credentials, and destructive tests are out of scope unless later requested.

`/carbon-demo` is CARBON's first suggested command for someone who has no code,
target, or existing tests ready. It gives a user a concrete, safe first pass
without hiding the difference between testing a product from scratch and
learning from a preexisting suite.

## Create the demo copy

1. Call `carbon_demo action=list` first. Use its returned fixture descriptions,
   start instructions, and test profiles; do not invent fixture contents.
2. Interpret an explicit fixture name or plain-language request using the
   returned list. Supported fixture categories are a simple website, an
   interactive web app, a REST API, an evaluation harness, and a large
   codebase. If the user gives no selection, choose the default simple website
   (`web-static`).
3. Choose the test profile:

   - Default to `without-existing-tests`. It makes the first run demonstrate
     discovery, risk-based candidate generation, and evidence planning from
     the product itself.
   - Use `with-existing-tests` when the user asks to see test inventory,
     import/upgrade behavior, or a comparison with existing manual or automated
     coverage.

4. Call `carbon_demo action=create` with the exact existing workspace root,
   chosen `fixture`, and `testProfile`. Let the runtime select its unique
   `carbon-demo-<fixture>` destination unless the user provides a new child
   destination. Never overwrite an existing folder or modify the bundled
   fixture.
5. State the new copy path and the returned start command. Treat the returned
   fixture description as observed; the copy itself is not a passing test.

## Run First Look in the copy

The user explicitly asked to try CARBON end-to-end when invoking this command,
so continue in the copied destination without asking a second time.

1. Initialize CARBON project state in the **copied destination**, not the
   original workspace, using `carbon_workspace_onboarding action=initialize`
   with `focusAll=true` and guided defaults. Record this as `carbon-demo`.
2. If the fixture returned a local start command, start it in that copied
   directory using a local, disposable process. Use the returned localhost URL
   only; never use a live user browser profile. If a fixture has no URL, keep
   the run in Review mode until its command produces an appropriate local
   artifact or target.
3. Run the main `/carbon` First Look workflow with the copied destination as
   its root. It must create the broad candidate pool, select at most 20
   highest-value checks within the First Look budget, distinguish existing
   tests from generated candidates, and open the protected live plan before
   execution.
4. If browser execution is available, use a separate local test context. If it
   is not, preserve the plan and clearly label browser checks as blocked or
   planned rather than changing browsers or claiming results.
5. Publish the normal CARBON report plus a short demo handoff: selected
   fixture/profile, copy path, start command, generated versus executed count,
   observed findings, and the best next command to run against the user's own
   codebase.

## Fixture intent

| Fixture | Best first demonstration | Existing-test profile demonstrates |
| --- | --- | --- |
| `web-static` | Forms, content, navigation, local storage, and browser evidence | Manual charter plus optional Playwright smoke test |
| `web-app` | SPA routing, state, task lifecycle, and exploratory behavior | Manual lifecycle charter plus optional Playwright flow |
| `api-server` | API contracts, auth, validation, idempotency, and boundary checks | `node:test` unit/integration suite plus manual API charter |
| `eval-runner` | AI-style evaluator, candidate, scorer, and report quality | Python unittest suite plus evaluator/report charter |
| `large-project` | Change impact, test selection, suite scale, and evidence cut lines | Broad unittest inventory plus change-impact charter |

## Boundaries

- The fixture library is packaged with CARBON and is read-only. A demo command
  creates one new copy and writes only the copy's `.carbon-demo.json` marker
  and subsequent project-local CARBON state.
- Do not use a user browser session, request credentials, or
  perform failure injection merely because the fixture is safe. Those need a
  separately scoped request and their normal gates.
- Do not claim that optional Playwright files ran merely because they exist.
  They are inventory evidence until their runner and browser results are
  captured.
- When the user later supplies a real project, recommend `/carbon` directly;
  do not create another demo copy.

Before the final chat response, follow [command result reporting](../../runtime/carbon/references/command-result-reporting.md). Publish a branded single-file CARBON Demo report, end with the current host's **Open the CARBON report** link, and include the copied project path plus either `/carbon <their-project>` or `/carbon-more` as the relevant next action.
