CARBON — Engineering ConfidenceUser Guide
CHAPTER 52 / 60 Pro

/carbon-stats

Show an evidence-qualified, privacy-safe CARBON activity dashboard with commands executed and frequency, tests created and executed, issues found and explicitly verified fixed, biggest issues saved, exact host-supplied tokens and model levels per activity, observed unit costs, evidence leverage, and optional user-baselined time and dollar savings.

Jay · Your AI test managerTesting operations

When to use it

You need an evidence-qualified view of testing activity and trends.

Before you start

Keep executed tests, created tests, findings and verified fixes separate. Tokens and costs require attributable host data; do not invent savings, ROI or missing values.

Try this in your coding agent.

/carbon-stats Show saved testing activity and evidence trends for this project.

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

Testing activity and trends

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. 02Analyze
  3. 03Show evidence
  4. 04Report

Coding-agent conversation

Read context

I’m reviewing testing activity and trends. I’ll keep the scope and permissions explicit.

Analyze

Analyze: Show saved testing activity and evidence trends for this project.

Show evidence

Here is the evidence trail to inspect: Group by run, revision and date; distinguish findings, executed tests and blocked work.

Report

The dashboard separates new evidence from repeated and stale runs. Activity counts do not establish product quality by themselves.

CARBON

Example report

Illustration
Project → decisions → retained evidence
Project → decisions → retained evidence — TestBucks teaching screen

TestBucks course screen with illustrative analysis. The screenshot supplies context; the demo does not establish a newly observed bug.

  1. TestBucks project
  2. Command action
  3. Reviewable output

Illustrated outcome

The dashboard separates new evidence from repeated and stale runs.

Evidence to inspect

Group by run, revision and date; distinguish findings, executed tests and blocked work.

Still untested / not established

Activity counts do not establish product quality by themselves.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For testing activity and trends, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Group by run, revision and date; distinguish findings, executed tests and blocked work. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Activity counts do not establish product quality by themselves.

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 testing activity and trends 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-stats result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-full-report →/carbon-tests →

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