---
name: carbon
description: Route product, web, API, AI-feature, regression, exploratory, persona, and release testing through the CARBON plugin runtime. Use for test this, QA, validate, inspect, find bugs, learn, generate tests, run regressions, compare builds, or CARBON Quick, Medium, Large, Plan, Test, Review, Focused, and Learn modes. Prefer black-box and integration behavior; write unit tests only when explicitly requested.
---

# CARBON

CARBON is the first AI Agentic Verification Harness for coding agents.

Before any inspection or tool call, read and follow [the CARBON command start preview](../../runtime/carbon/references/command-start-preview.md). Show the tailored high-level approach in chat before beginning the workflow.

This skill is the host-facing router. Framework logic and report generation
live under `../../runtime/carbon/`; do not recreate or fully load them in chat.

Apply the runtime's anonymous opinionated testing doctrine from
`../../runtime/carbon/references/testing-doctrine.md`. Do not name, imitate,
quote, or claim to speak for an individual author. When recommending a testing
practice, include its useful case, failure mode, and CARBON counterweight from
the doctrine's machine-readable `spices`. Treat rapid or session-based
exploration as bounded discovery whose consequential findings must become
evidence-bearing repeatable candidates; never present a session alone as
regression or release proof.

## Start with the workspace

Before project-scoped work, follow
`../../runtime/carbon/references/workspace-onboarding.md` and narrate its
inspection. Inspect first; on first use present grounded focus choices, then
initialize the chosen focus under `<project>/.carbon/` with guided defaults.
Use a stated unambiguous focus without asking the user to repeat it.

For established workspaces, respect saved focus and guidance. Offer two to four
untried, project-specific actions that close evidence gaps; suggestions never
execute themselves and always preserve approval boundaries.

For bare `/carbon` or “test this,” use **First Look** by default: run
`carbon_intelligence action=all`, show its report, generate the broad durable
candidate pool, and select at most 20 high-value tests within a 25-minute
planning budget. Do not block the first run with an effort question. State the
default and let an explicit user preference switch to a lighter, deeper, or
full pass. Focused work starts with `action=doctor` and retains freshness gates.

At the start, call `carbon_set_preferences` with no arguments and apply the
returned local execution preferences.

Apply the returned `executionContext` to every local run: honor its custom prompt, read each configured context document before planning, and use its username when authentication is needed. Never request or reveal the stored password. For an approved executable runner, wrap the runner with `carbon-runtime context exec -- <runner command>` so credentials exist only in that child process. For direct browser control, use an already authenticated session or ask the user to sign in.

## Route the request

Resolve `../../bin/carbon-runtime` relative to this `SKILL.md` and use it as
the stable entry point. Run `carbon-runtime help` when a subcommand is unclear.

- Broad requests such as `test this` use `framework prepare`, expose the live
  execution plan, then `run init`.
- Every broad initial pass explicitly tests business value: the primary
  customer outcome, time to first value, output usefulness, value-preserving
  recovery, and agreement among claims, limits, access, and delivered value.
  A technically working control is not enough when the intended user outcome
  is absent, misleading, or not worth the work required.
- A reachable site, app, API, or feature defaults to Test mode.
- Source, screenshots, specs, or descriptions without a runnable target use
  Review mode. Planned checks are not passes.
- A named behavior uses Focused mode.
- A request such as “just test sign in” or “test checkout accessibility” stays
  in Focused mode. Treat the named behavior as the cut line and call
  `carbon_get_testing_domains` with only the explicitly requested or
  materially required domains. The dedicated `/carbon-test` route exposes the
  same behavior without changing CARBON's evidence or safety rules.
- A named top-level quality concern routes through its dedicated domain command:
  functionality, UI, UX, usability, accessibility, privacy, security,
  performance, networking, reliability, compatibility, content, data, API, or
  localization. Domain commands load their opinionated runtime pack and stable
  named specialists rather than inventing a generic checklist.
- An unfamiliar surface uses Learn mode and keeps hypotheses separate from
  supported behavior.
- A request to inject faults, force errors, corrupt artifacts, or test recovery
  routes to `$failure`. It creates isolated baseline and sandbox copies, never
  modifies the original artifact, and verifies original hashes before closing.
- Test-generation requests use the runtime selectors and leave generated cases
  planned until execution evidence supports their oracles.

After planning, refresh the graph and use `carbon_intelligence action=why-test`
for selected P0/P1 cases. Show risk, provenance, results, freshness, and the
decision rule. Before fixing failures, run `action=failures` and work from its
clusters, classification hypotheses, and portable repros.

```bash
<plugin-root>/bin/carbon-runtime framework prepare --root <project> --request "test this" --target <target> --size quick --strategy auto --coverage-profile broad
call carbon_open_execution_plan with root=<project> and planPath=<project>/.carbon/framework/orchestration-plan.json
<plugin-root>/bin/carbon-runtime run init --root <project> --plan <project>/.carbon/framework/orchestration-plan.json --mode quick --target <target>
```

The broad profile generates at least five candidates for every top-level
CARBON domain plus five business-value candidates, merges context-derived
cases from source and APIs, and saves the complete pool under
`.carbon/framework/candidate-pool.json`. The initial plan contains no more
than 20 selected tests and preserves every deferred candidate for
`/carbon-more`.

Immediately after the required chat preview, start the command-level live
checklist with the exact project root and open it inside the host. Before
`run init` or `run start`, call `carbon_open_execution_plan`. In Codex,
open `codexBrowserUrl` beside chat and show `codexChatLink`; `codexFileLink` is
the file fallback. In Claude, attach the HTML artifact and use
`claudeChatLink`. Show count and duration. OS-browser opening is opt-in. Never
start execution before that link exists. The protected viewer polls durable run
state every second. Plan-only requests stop after showing it; execution keeps
all destructive, paid, public, and other safety gates.

The runtime selects risk-based `breadth`, `depth`, or `balanced` exploration,
maps UI/API impact, and writes durable `.carbon/` plans and reports. Quick uses
two perspectives, Medium four, and Large six unless scope says otherwise.
Before execution, follow the required [persona journey contract](../../runtime/carbon/references/persona-journeys.md).

## Execute and preserve evidence

Use installed local adapters and route browser work through
`carbon-browser/v1`. Negotiate required operations and evidence first, select
the best available safe adapter, keep missing capability explicit, and persist
each observed result through the runtime:

```bash
<plugin-root>/bin/carbon-runtime run start --run-dir <run-dir>
<plugin-root>/bin/carbon-runtime run update --run-dir <run-dir> --test-id <id> --status <running|passed|failed|blocked|skipped> --actual <observed-result> --evidence <handle>
<plugin-root>/bin/carbon-runtime run observe --run-dir <run-dir> --test-id <id> --status <passed|failed|blocked|skipped> --title <specific-behavior> --actual <observed-result> --evidence <handle> --dimension <quality-dimension>
<plugin-root>/bin/carbon-runtime evidence page --run-dir <run-dir> --url <url> --test-id <id> <available-artifacts> --account-missing --missing-reason <why-other-channels-could-not-be-captured>
<plugin-root>/bin/carbon-runtime evidence analyze --run-dir <run-dir>
<plugin-root>/bin/carbon-runtime run complete --run-dir <run-dir>
```

For each tested page or material state, capture the richest safe evidence.
Inspect safe screenshots, mark unavailable or privacy-withheld channels, keep
generated-user opinion separate from deterministic verdicts, and record mixed
child behaviors without erasing the parent result.

Completion fails closed when browser checks lack page evidence, or any run
lacks completed planned persona journeys, persona-attributed exploration, or
charter coverage. Keep `persona-journeys.html` and `persona-journeys.md` linked;
an explicit cut line may close a bounded run only with the gaps still visible.

## Optional human decision context

Near the final confidence interpretation, after risk ranking and observed
execution evidence, call `carbon_human_context action=generate` with the
project root, the relevant request or release scope, and `size=quick`. This
must inspect current code, plans, results, findings, and evidence to produce
only the smallest set of questions a person can answer better than the agent.
Persist unanswered questions under `.carbon/human/decision-context.json` and
surface their IDs, why they matter, and exact answer syntax in the command
report and closing chat.

This step is optional and non-blocking: continue to calculate and publish
evidence-qualified confidence when no answer is yet recorded. State that the
result covers observed technical evidence only and is qualified by unresolved
intent, risk appetite, domain judgment, experience/taste, consequence, and
accountability. Never infer a human answer from silence. When answers are
provided, call `carbon_human_context action=answer` immediately and use the
durable context to steer current and future risk, readiness, confidence,
persona, and test-selection work. Human context does not convert unobserved
behavior into a pass; human release authority remains explicit.
See [the human decision context contract](../../runtime/carbon/references/human-decision-context.md).

## Evidence and authority

- E3: observed live behavior with reproducible steps and captured actual result.
- E2: source/request/log evidence corroborated by rendered state.
- E1: inspected source, screenshot, or specification.
- E0: unknown; keep the check planned or blocked.

Never turn inspection, a generated case, persona opinion, or a visual guess
into a pass. A human retains mutation, destructive-action, paid/public-run,
regression-promotion, and release authority.

Do not execute destructive, high-volume, privacy-invasive, privilege,
payment, notification, or hostile security tests on shared or production-like
targets without explicit scope, safe identities/data, limits, reversibility,
and recovery. Never request secrets in chat; use named environment variables
or an ignored credentials file.

After failures, reproduce first, create a portable repro, then use
`framework adapt` for the smallest adjacent regression set. Finish with
`framework analyze` and `framework report`, state residual uncertainty, and
state both generated and executed counts. When deferred candidates remain,
recommend `/carbon-more` with useful scope text and explain that it continues
the saved pool without repeating the initial pass. Offer Quick, Medium, or
Large only when it is more useful than that continuation.

Every result report must surface evidence-qualified confidence in quality,
remaining risk, coverage achieved and missing, and the evidence that would
change the decision. Never present this judgment as a probability that the
product is correct or defect-free.

Surface all eight `carbon.quality-confidence/v1` dimensions independently;
leave one `not-assessed` without dimension-specific evidence. See
[CARBON intelligence layer](../../runtime/carbon/references/intelligence-layer.md).

For domain reports, pass `carbon_get_testing_domains` IDs and specialists to
`carbon_publish_command_report`, then show its grayscale profiles in supported
host chat. Accessibility requires criterion-level `wcagResults`, linked WCAG
2.2 and VPAT 2.5Rev-aligned ACR artifacts, and explicit unresolved criteria;
automation alone never proves conformance and CARBON never certifies an ACR.

## Required HTML result

Before the final chat response, follow [command result reporting](../../runtime/carbon/references/command-result-reporting.md). Generate the branded single-file command page, open it beside chat, and end with the current host's **Open the CARBON report** link.
