---
name: carbon-test
description: Test only a named feature, user flow, API, page, component, behavior, or change using CARBON Focused mode and optional named quality domains. Use for requests such as "just test sign in", "test checkout accessibility", "only test the upload API security", or "test X-Y" where the user wants a strict scope instead of a broad product pass.
---

# CARBON Test

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.

Keep the cut line narrow. Test the named behavior and only the adjacent contracts whose failure could invalidate that behavior.

1. Call `carbon_set_preferences` without arguments and apply its safe execution context.
2. Follow `../../runtime/carbon/references/workspace-onboarding.md` for project-scoped work.
3. Parse the request into:
   - exact feature, flow, API, page, component, behavior, or change;
   - explicitly requested quality domains;
   - directly affected consumers, dependencies, states, and data;
   - exclusions and consequential-action gates.
4. Call `carbon_get_testing_domains` with the selected domains and exact scope. If the user names no domain, select only domains supported by the artifacts, code, change, and feature risk. Do not silently turn focused work into a broad audit.
5. Use the returned domain families, evidence channels, safety contract, named specialists, and WCAG registry. Load relevant control and flow packs through the runtime selectors. Add code-derived cases for regexes, validation, branches, boundaries, feature flags, contracts, error paths, and hard-coded special values.
6. Prepare Focused mode through `../../bin/carbon-runtime framework prepare`. Before executable work, call `carbon_open_execution_plan` and automatically open its live page beside chat. In Codex, navigate to `codexBrowserUrl` and show `codexChatLink`; in Claude, attach the artifact and show `claudeChatLink`. Include count, duration estimate, cut line, and gates.
7. Execute locally through CARBON's negotiated adapters. Prefer live black-box behavior plus source-aware inspection. Keep planned, observed, inferred, blocked, skipped, and not-tested states distinct. Do not write unit tests unless explicitly requested.
8. Record page, API, network, performance, accessibility, visual, data, persona, and exploration evidence only when relevant and available. Reproduce failures before classifying them.
9. When accessibility is selected, evaluate WCAG 2.2 A and AA criterion by criterion, record manual-review gaps, and never infer conformance from automation alone.
10. Publish the result with `carbon_publish_command_report`, passing `testingDomains`, returned `specialistIds`, and criterion-level `wcagResults` when accessibility applies.

Follow [command result reporting](../../runtime/carbon/references/command-result-reporting.md). In the closing chat, show relevant grayscale specialist profile images from returned `chatMarkdown` when the host supports local images, with each first name, role, and short bio. Otherwise show the same text without emoji or substitute avatars. End with the current host's **Open the CARBON report** link and, when returned, its **Open the WCAG 2.2 report** and **Open the Accessibility Conformance Report** links.
