Use Tada from your coding agent

Connecting Tada gives your agent its tools. The Tada skill tells it when to call them. With it, the agent checks each feature it builds, reads the report, and keeps a task open while Tada says Failed.

Connect Tada first: see MCP server.

What it teaches

• Check after building. The agent sends the feature in words: what should work, with the result in it. Tada writes the test and checks it in a real browser.
• Read the report. Each failed report says why: the app broke, the test is out of date, Tada could not get in, or Tada did not finish. Each has its own next step.
• Done means passed. A task stays open while its check has failed, and the agent hands you the report’s link.
• Secrets stay out. Steps sign in with placeholders, and Tada types the real values on its side.

Where it goes

Your tool	The file it reads
Claude Code	.claude/skills/tada/SKILL.md in your repository
Codex, Cursor, Devin	AGENTS.md at the root of your repository
Claude desktop	Added to Claude as a skill named tada

Commit the file, so everyone who works in the repository gets the same agent. In the app, Settings, AI tools has a Copy the Tada skill action under each tool’s steps.

The skill

Save this as .claude/skills/tada/SKILL.md.

---
name: tada
description: Check a feature in a real browser with Tada before calling it done. Use after building or changing anything a person sees in the app, when asked to test, verify or prove that something works, and when a Tada answer comes back Failed or Inconclusive.
---

# Tada

Tada is the QA for this app. It opens the app in a real browser on its own machines, follows a test, and answers with a verdict, Passed, Failed or Inconclusive, then what to do, with the link to the report.

You reach it through the Tada MCP tools:

- `about_app` reads what Tada knows about the app: a test account that cannot sign in (first, with its fix), its features and tests, its test accounts and its screens. Free, and it changes nothing.
- `create_test` creates a test of a feature and checks it. An older setup lists it as `check_feature` or `verify_feature`, with the same input.
- `check_test` checks a saved test again, by its name.
- `read_report` reads a check by its id.
- `create_test_account` makes a test account in a role, when `about_app` lists none for it.

When none of these tools is listed, Tada is not connected here. Tell the developer to connect it (https://taada.dev/docs/mcp-server) and stop.

## After you build a feature

1. Call `about_app` with the app's `repo`. Reuse the feature names, roles and screens it lists. When it says a test account cannot sign in, tell the developer the fix it names before anything else.
2. Tell the developer in two lines what the check will prove and what it leaves out. Get a yes.
3. Call `create_test` with a `goal` (see Writing the goal) and the app in `repo`. Add `role` when it matters who is signed in.
4. Read the first line: it is the verdict. Then do what the answer says (see Reading the verdict).
5. After a fix, send the same goal again, word for word. Tada keeps to the test it wrote for that goal.
6. When it passes, tell the developer the result, what the check proves, what it did not cover, and the report's link.

A task is done when its check passed. While Tada says Failed, the task stays open: report it as failed, with the report's link.

## Writing the goal

The goal is what should work, in one or two sentences, with the result in it. The result is what the test will expect, so name what the person sees at the end.

- Good: "A signed-in admin can invite a teammate by email, and the invite shows under Pending."
- Weak: "Test the invite feature." It names no result, so the test has nothing to hold.

One goal is one feature. Two things that should work are two goals. Use the app's own words for screens and buttons, read from the code you wrote.

A goal needs an app Tada knows. For an app it has not seen, such as one on localhost, send the test's `steps` yourself.

## Reading the verdict

Every answer leads with one of three verdicts.

**Passed.** The test did what it claims, at that address. Give the developer the report's link.

**Failed.** The answer names the step that failed, what was expected and what the app showed, and the report's one-press fix when it has one. It also says why, as one of four types:

| Why | What it means | What you do |
| --- | --- | --- |
| The app broke | The app did the wrong thing: an error, a click that changed nothing, a result that is missing. | Fix the code. Keep the test exactly as it is. Send the same goal again. |
| The test is out of date | The app changed on purpose, such as a renamed button, and the test still names the old one. | When you wrote the steps, rewrite that step with the words the screen shows now. When Tada keeps the test, give the developer the report's link: its Fix the test writes the new steps for them to confirm. |
| Could not get in | Tada never got past the sign-in, or the address did not answer. | Check the app is up and the role has a test account in `about_app`. Ask the developer when it needs them. |
| Tada error | Tada stopped before a result. | Tell the developer. |

"Tada's reading" means Tada inferred the type from the evidence, and a person may know better. Until a test has passed it has no type: decide from the step, what it expected and what the app showed. An expect that was true to the feature and failed is the check doing its job. Keep it, and fix the app.

**Inconclusive.** Never a pass, and never your code's fault: Tada could not reach a verdict. The answer names the cause and its fix, such as "Add the test account’s password". Stop, tell the developer the cause and the fix, and do not send the check again.

## Waiting

A check can take minutes. When a tool stops waiting, it gives the check's id: read it later with `read_report`. The first check is still going, so a second send is a second, counted check.

## Secrets

Sign in with the placeholders `{{secret.TADA_TEST_EMAIL}}` and `{{secret.TADA_TEST_PASSWORD}}`, or with `role` on a step. Tada types the real values on its side. Keep real passwords, keys and tokens out of goals, steps and this conversation. When a check needs one, ask the developer to add it in Tada.

## Where the report is

Every answer gives the report's link in the Tada app. The report holds the verdict, each step, the failing frame, and a film when the check passed. Give the developer the link with your summary, so they can see what Tada saw.

The AGENTS.md section

Paste this into AGENTS.md, beside your own instructions.

## Tada (QA)

This repository uses Tada to check features in a real browser before they are called done.

1. After you build or change a feature a person sees, call `about_app`, then `create_test` with a `goal`: one or two sentences saying what should work, with the result in it. Older setups list `create_test` as `check_feature` or `verify_feature`.
2. Every answer leads with the verdict. Passed: give the developer the report's link. Failed: fix the one thing the answer names, usually the code, and send the same goal again; never loosen an expect. Inconclusive: never a pass and never the code's fault; stop, tell the developer the cause and its fix, and do not send the check again.
3. A task is done when its check passed. A failed check keeps the task open: report it with its link.
4. When a tool gives an id instead of a verdict, read it with `read_report`. A second send is a second, counted check. `check_test` checks a saved test again.

Sign in with `{{secret.TADA_TEST_EMAIL}}` and `{{secret.TADA_TEST_PASSWORD}}`, or with `role`. Real passwords, keys and tokens stay out of every goal and step.

The full skill: https://taada.dev/docs/coding-agent-skill