CARBON — Engineering ConfidenceUser Guide
CHAPTER 46 / 60 Pro

/chatbot

Generate, extend, review, and optionally execute large risk-based chatbot test suites from the current conversation, supplied product context, repository artifacts, requirements, existing chatbot suites, websites, and APIs.

Diego · AI chatbotAI evaluations

When to use it

You need a broad conversational test matrix or multi-turn suite.

Before you start

Provide product policy, intents, existing cases and authorized endpoints. Include ambiguity, unsupported requests, state, escalation and safety. Generated conversations are candidates until execution is explicitly in scope.

Try this in your coding agent.

/chatbot Design tests for the support bot covering refunds, ambiguity and unsupported requests.

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

Support-bot test design

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 support-bot test design. I’ll keep the scope and permissions explicit.

Analyze

Analyze: Design tests for the support bot covering refunds, ambiguity and unsupported requests.

Show evidence

Here is the evidence trail to inspect: Build a matrix of intents, conversation state, safety boundaries and expected escalation.

Report

Refund, ambiguity and unsupported-request cases become explicit test candidates. Generated cases are not executed unless the real run has authorized access.

CARBON

Example report

Illustration
Answer vs supporting source
Answer vs supporting source — TestBucks teaching screen

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

  1. Question / intent
  2. Reference evidence
  3. Scoring & uncertainty

Illustrated outcome

Refund, ambiguity and unsupported-request cases become explicit test candidates.

Evidence to inspect

Build a matrix of intents, conversation state, safety boundaries and expected escalation.

Still untested / not established

Generated cases are not executed unless the real run has authorized access.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For support-bot test design, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Build a matrix of intents, conversation state, safety boundaries and expected escalation. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Generated cases are not executed unless the real run has authorized access.

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 support-bot test design 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 /chatbot result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-eval →/carbon-security-review →

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