CARBON — Engineering ConfidenceUser Guide
CHAPTER 30 / 60 Pro

/carbon-api

Run focused CARBON API testing and generate a branded api report.

Arjun · Data integritySecurity & resilience

When to use it

A contract boundary needs focused input/output validation.

Before you start

Supply endpoint contracts and safe credentials. Exercise missing, malformed and boundary inputs; inspect status, schema, side effects and authorization. Keep test data isolated and distinguish contract assumptions from documented rules.

Try this in your coding agent.

/carbon-api Test the local cart API for invalid quantities and missing required fields.

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

Cart API input validation

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 cart api input validation. 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: Synthetic request: quantity = -1; expected validation error, illustrated response accepts it.

Report

A negative quantity reaches the update branch. Authentication and rate limiting require separate checks.

CARBON

Example report

Illustration
Trace the data boundary
Trace the data boundary — TestBucks teaching screen

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

  1. Synthetic input
  2. Processing boundary
  3. Allowed destination

Illustrated outcome

A negative quantity reaches the update branch.

Evidence to inspect

Synthetic request: quantity = -1; expected validation error, illustrated response accepts it.

Still untested / not established

Authentication and rate limiting require separate checks.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For cart api input validation, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Synthetic request: quantity = -1; expected validation error, illustrated response accepts it. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Authentication and rate limiting require separate checks.

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 cart api input validation 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-api result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-security →/carbon-data →

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