To use Amp CLI with a signed-in browser, run Amp locally on the same machine as Tabbit Browser, confirm the tabbit Skill is discoverable, and verify that Tabbit CLI can open the signed-in document in a separate task tab. Then ask Amp to turn the document changes into a local regression checklist and stop at a named draft for human review. An Amp Orb or a Runner is a different execution location, so it will not inherit the browser session on your current desktop by default.
Amp’s current docs list Skills with amp skills list and describe automatic loading based on the request. The 2026 CLI rebuild announcement says user-invoked Skills were removed, so a slash command such as /tabbit is not the current documented route (Amp Skills, Amp, Rebuilt).
Key takeaways
Use local Amp CLI when the signed-in Tabbit Browser is on the same machine.
Check the current thread’s Skill list; do not assume that
/tabbitworks in Amp.Amp Skill discovery, Tabbit CLI availability, and browser login are separate checks.
An Orb or Runner runs in another execution environment unless it is explicitly the machine holding the target browser session.
Have Amp save a named checklist draft and review each source before sharing it.
First decide where the Amp thread runs
Amp CLI can run an agent locally, in an Orb, or on a connected Runner. The plain amp command opens a local interactive thread by default. An Orb is a remote Amp-managed machine; a Runner is a machine where someone started an Amp runner process. This choice decides which files, commands, and browser instance the thread can reach (Amp CLI guide, Orbs and Runners).
| Amp location | Where the agent runs | Use it for this task when… |
|---|---|---|
| Local CLI | Your current computer | Tabbit Browser is signed in to the source document on this machine. |
| Orb | A separate Amp-managed remote machine | The task uses public or remote resources, not the current desktop’s Tabbit login. |
| Runner | The host running the Amp runner process | That host has Tabbit installed, the intended browser profile signed in, and the supported desktop or browser handoff configured. |
An Orb can use Orb Network Routing for network requests, but network reachability does not copy a local browser profile or its cookies. Amp’s runner docs also describe a desktop hosted by the Runner machine; that is not the desktop where you happened to start a remote CLI command. If you need to know the trade-offs between local and remote browser environments, see local vs. cloud browser agents.
Check the Skill before asking Amp to read a private page
The Tabbit CLI quick start says Tabbit installs a Skill for agents it detects and asks you to verify it by entering /tabbit. That exact slash syntax is supported by some clients, including Qoder CLI, but current Amp CLI docs do not document it. Amp’s Skills page says it scans local and shared Skill locations, including ~/.agents/skills/, and provides amp skills list or Ctrl+O → skills: list to inspect what the current thread can use (Tabbit CLI quick start, Amp Skills).
Check from the same Amp CLI installation and machine that will run the task. An amp skills list call in another shell can show discovered Skill sources, but the docs warn that it does not reload an already running thread. In the current thread, ask Amp to list the Skills available there, use the palette’s skills: list, or ask it to reload Skills. The new Amp CLI automatically selects Skills based on names and descriptions. Its rebuild notes explicitly say user-invoked Skills were removed, so do not type /tabbit or depend on the older skill: invoke palette action (Amp rebuild notes).
| Gate | What to verify | Stop if… |
|---|---|---|
| Skill discovery | tabbit appears in the local Amp thread’s Skill list and points to the intended SKILL.md. | The name is missing or a different local Skill masks it. |
| Tabbit CLI | The local environment can find and run Tabbit CLI, and Amp’s tool policy allows the needed command. | The command is missing, blocked, or starts in another host environment. |
| Browser session | Tabbit Browser is signed in to the right document and a read-only Tabbit task can open it. | Tabbit asks you to sign in again, the wrong profile is selected, or the task opens a separate empty browser. |
Tabbit’s official setup page documents session reuse and shows that the task can continue while the user works elsewhere. A local fixture check in this environment confirmed that a second Tabbit CLI task could read a test page after a separate task established a test login. That check confirms the Tabbit CLI session behavior only; it did not test Amp CLI as an integration.
Make a regression checklist from document changes
Use this pattern when a signed-in release document has changed and QA needs a compact list of pages to recheck. First open the document in Tabbit yourself. In local Amp CLI, ask for a bounded, read-only task and name the output file so it stays a draft.
If the tabbit Skill is available in this local Amp thread, use its instructions for the browser step. Read the signed-in release document that I opened in Tabbit and compare the latest changes with the previous version.
Do not edit the source document, submit a form, or publish anything. For each change, capture the section heading, old wording if visible, new wording, the URL, and the user flow that may need a regression check. Mark missing old wording as unknown.
Save a local file named "release-doc-regression-checklist-draft.md". Include one checklist item per change and a final section called "Needs human review". Stop before sharing or attaching the checklist anywhere.This prompt illustrates a proposed workflow. It is not a reported Amp + Tabbit CLI test. It is also not a request to let the agent write back to the knowledge base. If your Amp thread does not list the Tabbit Skill, do not proceed as though the browser connection succeeded.
A useful checklist row names the document section, the visible change, the relevant page, the expected behavior, and the result a reviewer should record. Keep the source URL beside every row. The browser agent prompt template helps set those boundaries; the first-task checklist gives a repeatable read-only smoke test.
Review the draft before it becomes release work
Open each source URL in Tabbit and verify that the document changed as the draft says. A regression candidate is only a suggestion until someone confirms that the changed wording affects a user flow. Remove duplicate checks, add an owner or test environment if your team needs them, then move the reviewed items into your normal QA process.
| Checklist field | Human check | Keep it when… |
|---|---|---|
| Section and URL | Reopen the source in Tabbit | The link lands on the exact changed document. |
| Old and new wording | Compare the visible document versions | The draft preserves the actual change without rewriting its meaning. |
| Affected user flow | Follow the relevant page or UI yourself | There is a concrete path worth retesting. |
| Expected result | Write a visible pass condition | A reviewer can decide pass or fail without guessing. |
| Uncertainty | Inspect each unknown or inferred item | The draft marks gaps instead of presenting them as facts. |
If the goal is browser connection setup, start with the Tabbit CLI guide, connecting an agent to an existing browser, and the Codex session check. The browser task itself may use a CLI or an MCP server; the same-task comparison explains that choice. For a concrete local test site, use the browser validation example or an agent browser CLI tutorial.
FAQ
Can Amp CLI use the browser where I am already signed in?
The local Amp CLI can run on the same machine as Tabbit Browser, but that alone does not connect the two. Verify the Tabbit Skill is visible in the local Amp thread and that Tabbit CLI can reach the signed-in browser. Amp Orbs run remotely, and a Runner uses the machine where its process runs.
Does Amp CLI support a `/tabbit` command?
Current Amp documentation does not describe a `/tabbit` Skill command. Amp lists discovered Skills with `amp skills list` or the CLI palette, then loads Skills automatically when the request matches. Amp's 2026 rebuild announcement says user-invoked Skills were removed.
How do I make Amp use the Tabbit Skill?
Confirm `tabbit` appears in the local thread's Skill list, then describe the browser task clearly and name the Skill in your request. If it is not listed, reload or inspect the local Skill source before asking Amp to use a private page.
Should I run this task in an Amp Orb or Runner?
Use the local Amp CLI when the signed-in Tabbit Browser is on your current machine. An Orb is a separate remote machine. A Runner executes on its own host, so use it only if that host has the correct Tabbit installation, browser profile, login, and an explicitly supported handoff.
How should I review the regression checklist?
Ask Amp to save a named local draft with a source URL and before/after wording for every item. Reopen each cited document in Tabbit, verify the change and expected behavior, and edit the checklist before sharing it with a release process.