Ask your coding agent to check Brave Android, and get findings you can inspect.
BART helps an agent investigate issues, verify fixes and develop changes using both Brave Core source and the running Android app. It gives the agent Brave-specific guidance for testing, evidence and reporting. You describe the work in ordinary language; the agent chooses the relevant checks and tools.
For QA, the benefit is more coverage with reviewable evidence: phone and tablet layouts, landscape behavior, system-theme changes and configuration-specific controls. For engineers, the same skills support local development and an optional QA pass before submission. Reviewers get the tested build, what actually happened, captures and clear coverage limits.
** androperator is required for Android app execution and evidence capture.** Install its CLI and a compatible Operator on the device/emulator using Androperator setup. If it is missing, BART's agent guidance directs setup and readiness checks before app work. Source-only investigation does not require a connected device. See BART installation guidance.
Once set up, start your usual coding-agent session and ask:
/brave-core-bart QA verify https://github.com/brave/brave-core/pull/40563.
Save a local HTML report, captures and text-only context ZIP under .work/pr-40563/.
Do not publish findings.
Ordinary verification of a merged fix uses current Nightly, rather than requiring the original PR build. The agent inspects the issue, PR and relevant source, exercises the app, and records observations. It prefers suitable existing emulators and can prepare one when needed within the authorized task and host rules. Missing devices, prerequisites or evidence are reported, not counted as passing checks.
Use /brave-core-bart as the main entry point. You do not need to invoke a series of preparation commands or supply a formal test package.
A QA report leads with a familiar summary:
🟢 Verification PASSED using the following:
Automated BART assessment - not an official QA sign-off.
Device, build and conditions
STEPS
ACTUAL RESULTS
SCREENSHOT / SCREENCAST
The headline reflects the findings: passed, failed, blocked, inconclusive or partial. This is an example format, not a recorded pass.
The report includes:
- Tested identity: device make/model, Android version/API, Brave and Chromium versions, Androperator version and available model/execution context.
- Actual results: observed behavior, relevant failures and any additional issues spotted during testing.
- Configuration coverage: phone/tablet, portrait/landscape and system-theme checks, with useful captures and explicit omissions.
- Visible evidence: labeled screenshots and transition recordings, with inspection and timing limits stated.
- Reproduction context: a compact text-only ZIP for published reports or when requested locally, containing useful commands, test inputs, instructions and sanitized receipts. Media and APKs stay separate.
Requested local HTML opens with its capture assets using relative links. Reports exclude device serials and other personally identifying information. Measurements can add precise observations, but are not presented as universal proof that a bug is fixed.
BART assists QA; it does not provide official QA sign-off. A successful command is not automatically successful app behavior, and untested configurations remain untested. See reporting for the output conventions.
Develop a feature locally:
/brave-core-bart Implement <feature description> in this Android checkout.
Build, install and inspect it on my configured device. Keep everything local.
Implement an issue and retain evidence for review:
/brave-core-bart Implement <issue URL> in this Android checkout on its current branch.
Build and commit locally, do not push. Create a QA evidence pack.
The evidence pack includes a local HTML assessment, inspected screenshots and required transition demos, useful build/test/install receipts and a sanitized text-only context ZIP. It assesses the actual changed build; a successful commit or build alone does not establish the fix. “This checkout” selects the session's Core checkout rather than a different configured default. See development evidence packs.
Run an optional pre-submit QA pass:
/brave-core-bart QA my local Android changes before submission.
Build and inspect them on phone and tablet. Save a local HTML report and captures.
Do not edit product code or publish findings.
A local pre-submit pass tests your changed build, not an unrelated installed Nightly. It supplements Core's normal tests and presubmit checks.
You can ask to discuss the approach before editing, contribute feedback during the work, or let the agent continue authorized implementation and testing autonomously. A GitHub URL is optional; a feature description, design reference or app observation can start the task. The agent can move between source research, app inspection and changes as needed. Local development normally ends with a concise summary rather than a formal QA report.
Development guidance is available; end-to-end feature development through BART still needs a dedicated live demonstration. See developing and the validation plan.
/brave-core-bart Perform a technical review of <PR URL>.
Check out and sync the PR in this review checkout, build and run it,
and construct local fixtures where useful. Save a local HTML review and evidence pack.
Do not modify product code, push or publish findings.
A runtime-backed review combines source review with the actual PR build and meaningful app experiments, including small extensions/pages or other test inputs when helpful. Findings lead the report, with tested revision, evidence and unassessed scope explicit. A code-only request does not imply checkout/sync/device operations, and review does not implicitly fix the PR. This workflow is documented but not yet demonstrated end to end; see review guidance.
- Make the BART skills discoverable to your existing agent, following setup.
- Use a Brave Core checkout for source work and install the required Androperator tooling for Android actions and evidence. Local builds use Core's existing tools; Brave Scaffold is optional.
- Optionally set checkout, work-folder, device and posting defaults in ignored
config.toml, using config.example.toml. Missing config is supported when the task supplies the needed context.
For an existing Brave Scaffold installation, opt in with brave-scaffold.enabled = true and brave-scaffold.root = "/path/to/brave-scaffold". The agent uses its maintained bcore-full-build-context skill for local builds/tests and BART/Androperator for runtime inspection. See Scaffold builds; Core's standalone workflow remains available when disabled.
BART runs through the agent already in your session. It does not require a BART CLI, separate agent launcher or model-provider account. Skills and shared docs supply the guidance; the host agent and existing tools perform the work.
Task artifacts can live in ignored .work/ or an external directory. Publication occurs only when requested and permitted by the host. The example configuration sends development reports and PR previews to BART issues; a preview is not an actual Core draft PR. See configuration and delivery scope.
Initial local QA runs have exercised Wallet settings across system-theme changes and Appearance settings on phone/tablet configurations. They produced HTML reports, captures and text context, and identified a tablet-only icon/alignment omission. Coverage and evidence quality are still being refined; these runs are not a reliability benchmark or complete regression suite.
Fresh-session development, actual draft-PR delivery, external publication and independent reuse of exported reproduction instructions need further validation. BART is ready for more scoped QA trials, with findings and limitations reviewed by people. The maintained plan tracks capabilities and gaps.
| Skill | Use |
|---|---|
| brave-core-bart | Main entry point for development, investigation and verification. |
| brave-core-bart-report | Create or update a report from observations and evidence. |
| brave-core-bart-reproduce | Save optional adaptive instructions for another attempt. |
Shared guidance covers verification, builds, evidence, action recipes and Brave QA resources. Contributors should read AGENTS.md and contributing; bart-issue-create helps draft issues about BART itself.