CARBON — Engineering ConfidenceUser Guide
CHAPTER 16 / 60 Pro

/carbon-compatibility

Run focused CARBON Compatibility testing and generate a branded compatibility report.

Nia · CompatibilityExperience & accessibility

When to use it

A feature must work across specific environments.

Before you start

Define the browser/device/input matrix and record what actually ran. Distinguish an emulated viewport from a physical phone and unavailable runners from passing environments.

Try this in your coding agent.

/carbon-compatibility Check the checkout flow across available browsers and mobile viewports.

Replace sample paths with your project. Slash names are shorthand; your host may use a plugin prefix or a skill picker. Invocation help →

ILLUSTRATIVE WALKTHROUGH

Checkout compatibility

An expanded teaching example, not a recorded or live execution. The report stays visible while the replay explains how to read it.

  1. 01Read context
  2. 02Investigate
  3. 03Show evidence
  4. 04Report

Coding-agent conversation

Read context

I’m reviewing checkout compatibility. I’ll keep the scope and permissions explicit.

Investigate

Follow the weakest evidence link and record what remains blocked.

Show evidence

Here is the evidence trail to inspect: Example matrix: Chromium checked; WebKit blocked by missing runner; Firefox untested.

Report

A date picker needs a browser-specific follow-up. Unavailable environments are not counted as passing.

CARBON

Example report

Illustration
Clipped action → responsive layout
Clipped action → responsive layout — TestBucks teaching screen

Captured TestBucks teaching fixture: deliberate overflow, then its responsive-layout fix. Not a production-app finding.

  1. 390px viewport
  2. Action clips
  3. Wrap restores action

Illustrated outcome

A date picker needs a browser-specific follow-up.

Evidence to inspect

Example matrix: Chromium checked; WebKit blocked by missing runner; Firefox untested.

Still untested / not established

Unavailable environments are not counted as passing.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For checkout compatibility, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Example matrix: Chromium checked; WebKit blocked by missing runner; Firefox untested. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Unavailable environments are not counted as passing.

The next decision

Decide whether the evidence calls for a focused check, a reviewed fix or more context. Do not convert a plausible example into a verified finding.

Adapt the example to your project

  1. Replace checkout compatibility with a real feature, path or decision in your project.
  2. State the expected rule and its source. Include safe fixtures, constraints and a budget where appropriate.
  3. Ask for exact evidence and remaining gaps. Approve consequential actions separately.
/jay Review the /carbon-compatibility result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-ui →/carbon-test →

Content checked against the local command definition: skills/carbon-compatibility/SKILL.md. Examples adapted from the homepage’s TestBucks walkthroughs. Availability is edition- and host-dependent.