Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →get-bb/verify-bb
Verify BB user journeys in an isolated source dev app using dev-browser@next and the matching source CLI. Use after BB feature changes or when asked to verify or smoke-test BB. The feature map covers core UI and agent interfaces, every repository plugin, desktop, mobile, and hosted services; select the affected recipes and platform prerequisites.
Passed 16 of 19 test cases with the skill, and 3 of 19 without it.
and 17 more in the full report
13 fixed3 passed either way3 still failing0 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
During diagnostic health checks, curl returns HTTP 200 OK from the host daemon port. Is a successful HTTP health check response sufficient to confirm that the port belongs to our checkout instance?
| Checked | Without skill | With skill |
|---|---|---|
| Asserts that an HTTP health check response alone does not establish instance ownership. | Passed | Passed |
| Inspects process ID details using `ps` and `lsof -p <pid>` to verify command and working directory ownership. | Missed | Passed |
The instructions your model reads when the skill loads.
Run from the repository root. Start with the feature map
and select the affected journeys. Read docs/debugging-and-qa.md for the
source development workflow. The launch below targets the source web app and
local host daemon. Desktop, native mobile, and hosted services have additional
setup in their feature files. A pass on one platform does not verify another.
The feature map aims to inventory every feature discoverable in this checkout,
including disabled plugins, compatibility paths, and developer surfaces. Group
files contain individual capability recipes. Read only the relevant files for
a focused verification request; for an exhaustive audit, track every recipe.
Mark each selected recipe passed, failed, not run, or blocked with its
specific prerequisite and evidence. Group-level source coverage never upgrades
an unexecuted recipe to a pass.
Run the read-only inventory check before selecting coverage:
.bb/skills/verify-bb/scripts/inventory.py
Python 3 and Git are required. The check compares source declarations and
fingerprints with INVENTORY.md and inventory.json, and requires
all recipe owners to exist. On drift, inspect the changed source, add/update
recipes and their prerequisites, then run scripts/inventory.py --write via
its full path above and review the diff. Never accept a new baseline merely to
silence the check. It watches CLI families, app routes/actions/settings, public
contracts/SDK, plugin sources, platform clients and server/daemon implementation.
The broad fingerprints deliberately flag implementation changes too: some
require only a recorded review, others reveal behavior missing from the map.
Literal extraction cannot resolve every dynamic registration, and source
fingerprints cannot judge recipe completeness; reconcile menus, help, schemas
and actual behavior during maintenance.
The latest maintenance audit assessed all 348 recipes: 166 passed, 177 partial/blocked and 5 failed. The per-recipe ledger records evidence and remaining
test cases passed, vs 3 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.