mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-01 19:25:10 +02:00
656df0e37e
* feat(v1.5.2.0): Opus 4.7 migration — model overlay, voice, routing
Adapts GStack skill text for Claude Opus 4.7's behavioral changes per
Anthropic's migration guide and community findings.
Key changes:
model-overlays/claude.md:
- Fan out explicitly (4.7 spawns fewer subagents by default)
- Effort-match the step (avoid overthinking simple tasks at max)
- Batch questions in one AskUserQuestion turn
- Literal interpretation awareness (deliver full scope)
hosts/claude.ts:
- coAuthorTrailer updated to Claude Opus 4.7
SKILL.md.tmpl:
- Expanded routing triggers with colloquial variants ("wtf",
"this doesn't work", "send it", "where was I") — 4.7 won't
generalize from sparse trigger patterns like 4.6 did
- Added missing routes: /context-save, /context-restore, /cso, /make-pdf
- Changed routing fallback from strict "do NOT answer directly" to
"when in doubt, invoke the skill" — false positives are cheaper
than false negatives on 4.7's literal interpreter
generate-voice-directive.ts:
- Added concrete good/bad voice example — 4.7 needs shown examples,
not just described tone. "auth.ts:47 returns undefined..." vs
"I've identified a potential issue..."
Regenerated all 38 SKILL.md files. All tests pass.
* refactor(opus-4.7): split overlay, align routing, fix trailer fallback
Follow-up to wintermute's initial Opus 4.7 migration commit (addresses
ship-quality review findings before v1.6.1.0 release).
Overlay split (model-overlays/):
- Move 4 Opus-4.7-specific nudges (Fan out, Effort-match, Batch your
questions, Literal interpretation) from claude.md into new
opus-4-7.md with {{INHERIT:claude}}
- claude.md now holds only model-agnostic nudges (Todo discipline,
Think before heavy, Dedicated tools over Bash)
- Prevents Opus-4.7-specific guidance leaking onto Sonnet/Haiku
- Uses existing {{INHERIT:claude}} mechanism at
scripts/resolvers/model-overlay.ts:28-43
scripts/models.ts:
- Add opus-4-7 to ALL_MODEL_NAMES
- resolveModel: claude-opus-4-7-* variants route to opus-4-7,
all other claude-* variants continue to route to claude
scripts/resolvers/utility.ts:
- Update coAuthor trailer fallback: Opus 4.6 -> Opus 4.7
(fallback was missed in the initial migration commit)
scripts/resolvers/preamble/generate-routing-injection.ts:
- Align policy with new SKILL.md.tmpl: soft "when in doubt, invoke"
instead of hard "ALWAYS invoke... Do NOT answer directly"
- Replace stale /checkpoint reference with /context-save +
/context-restore (skills were renamed in v1.0.1.0)
- Expand route coverage to match full skill inventory:
/plan-devex-review, /qa-only, /devex-review, /land-and-deploy,
/setup-deploy, /canary, /open-gstack-browser,
/setup-browser-cookies, /benchmark, /learn, /plan-tune, /health
scripts/resolvers/preamble/generate-voice-directive.ts:
- Voice example closing: "Want me to ship it?" -> "Want me to fix it?"
- Preserves directness while routing through review gates
SKILL.md.tmpl:
- Add routing triggers for skills that were missing from the list:
/plan-devex-review, /qa-only, /devex-review, /land-and-deploy,
/setup-deploy, /canary, /open-gstack-browser,
/setup-browser-cookies, /benchmark, /learn, /plan-tune, /health
- Within Opus 4.7 overlay, added scope boundary to
"Literal interpretation" nudge ("fix tests that this branch
introduced or is responsible for")
- Added pacing exception to "Batch your questions" nudge so skills
that require one-question-at-a-time pacing still win
Follow-up commit will regenerate SKILL.md files + update goldens.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(opus-4.7): regenerate SKILL.md files + update golden fixtures
Mechanical consequence of the preceding source changes (overlay split,
routing alignment, voice example, routing expansion). No behavior change
beyond what that commit introduced.
- 36 SKILL.md files regenerated via bun run gen:skill-docs
- 3 golden fixtures updated (claude, codex, factory ship skill)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(routing): assert slash-prefixed skills + new policy + current names
Align gen-skill-docs.test.ts routing assertions with the remediated
routing-injection output:
- Expect '/office-hours' slash-prefixed form (matches SKILL.md.tmpl style)
- Add test asserting /context-save + /context-restore references
(guards against stale '/checkpoint' name regression)
- Add test asserting "When in doubt, invoke the skill" soft policy
(guards against "Do NOT answer directly" hard policy regression)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(binary-guard): replace xargs-per-file loops with fs.statSync + mode filter
The "no compiled binaries in git" describe block had two flaky tests:
- "git tracks no files larger than 2MB" timed out at 5s regularly because
it spawned one `sh -c` per tracked file via `xargs -I{}` (~571 shells
on every run, ~11s locally).
- "git tracks no Mach-O or ELF binaries" ran `file --mime-type` over every
tracked file (~3-10s, flaky near the timeout).
Both were pre-existing — not caused by any recent change — but showed up
as red in every local `bun test` run and masked legit failures in the
same suite.
Rewrites:
- 2MB test: `fs.statSync(f).size` in a filter. Millisecond-fast.
- Mach-O test: pre-filter to mode 100755 files via `git ls-files -s`,
then batch-invoke `file --mime-type` once across all executables.
With zero executables tracked, the `file` invocation is skipped.
Test suite: 320 pass, 0 fail, 907ms (was ~12.7s with 2 fails).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(team-mode): give setup -q / setup --local tests a 3-minute budget
./setup runs a full install, Bun binary build, and skill regeneration.
On a cold cache it takes 60-90s, comfortably above bun test's 5s default.
Both "setup -q produces no stdout" and "setup --local prints deprecation
warning" have been flaky-to-failing for a while with [5001.78ms] timeouts.
The test logic was fine, the budget wasn't. Bumped both to 180s via the
third-arg timeout.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(opus-4.7): E2E eval for fanout rate + routing precision
Closes the measurement gap flagged by the ship-quality review: "zero
tests exercise Opus 4.7 behavior; every skill-e2e hardcodes 4.6."
Two cases, both pinned to claude-opus-4-7:
1. Fanout rate (A/B)
- Arm A: regen SKILL.md with --model opus-4-7 (overlay ON, includes
"Fan out explicitly" nudge).
- Arm B: regen SKILL.md with --model claude (overlay OFF, only
model-agnostic nudges).
- Prompt: "Read alpha.txt, beta.txt, gamma.txt. These are independent."
- Measure: parallel tool calls in first assistant turn.
- Assert: arm A >= arm B.
2. Routing precision (6-case mini-benchmark)
- 3 positive prompts that should route (wtf bug, send it, does it work)
- 3 negative prompts that match keywords but should NOT route
(syntax question, algorithm question, slack message)
- Assert: TP rate >= 66%, FP rate <= 33%.
Cost estimate: ~$3-5 per full run. Classified as periodic tier per
CLAUDE.md convention (Opus model, non-deterministic). Runs only with
EVALS=1 env var, touchfile-gated so unrelated diffs don't trigger it.
Test plan artifact at
~/.gstack/projects/garrytan-gstack/garrytan-feat-opus-4.7-migration-eng-review-test-plan-20260421-230611.md
tracks the full specification.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(opus-4.7): rewrite fanout nudge to show parallel tool_use pattern
The original fanout nudge told 4.7 to "spawn subagents in the same turn"
and "run independent checks concurrently" in prose. An E2E eval on
claude-opus-4-7 reading 3 independent files showed zero effect: both
overlay-ON and overlay-OFF arms emitted serial Reads across 3-4 turns.
Rewrite follows the same "show not tell" principle the PR introduced for
voice examples. The nudge now includes a concrete wrong/right contrast
showing the exact tool_use structure:
Wrong (3 turns):
Turn 1: Read(foo.ts), then wait
Turn 2: Read(bar.ts), then wait
Turn 3: Read(baz.ts)
Right (1 turn, 3 parallel tool_use blocks in one assistant message):
Turn 1: [Read(foo.ts), Read(bar.ts), Read(baz.ts)]
Applies to Read, Bash, Grep, Glob, WebFetch, Agent, and any tool where
sub-calls don't depend on each other's output.
Effect on test/skill-e2e-opus-47.test.ts fanout eval: unchanged (both
arms still 0 parallel in first turn via `claude -p`). May land better in
Claude Code's interactive harness, where the system prompt + tool
handlers differ. Tracked as P0 TODO for follow-up verification in the
correct harness.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(opus-4.7): tighten ambiguous /qa routing prompt
"does this feature work on mobile? can you check the deploy?" was too
vague — a reasonable agent asks "which feature?" via AskUserQuestion
instead of routing to /qa. That's not a routing miss, it's an under-
specified prompt.
Replaced with "I just pushed the login flow changes. Test the deployed
site and find any bugs." — concrete subject + clear QA verb.
Result: pos-does-it-work went from MISS to OK, routing TP rate 2/3 -> 3/3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(opus-4.7): rewrite scratch-root helper + add afterAll cleanup
First run of the Opus 4.7 eval exposed two test-setup gaps that made
results misleading:
- Only the root gstack SKILL.md was installed. Claude Code does
auto-discovery per-directory under .claude/skills/{name}/SKILL.md, so
without individual skill dirs the Skill tool had nothing to route to.
Positive routing cases all failed.
- `claude -p` does not load SKILL.md content as system context the way
the Claude Code harness does. The overlay nudges in SKILL.md were
invisible to the model, so the fanout A/B could not actually differ.
New `mkEvalRoot(suffix, includeOverlay)` helper, modelled on the pattern
in skill-routing-e2e.test.ts:
- Installs per-skill SKILL.md under .claude/skills/ for ~14 key skills
so the Skill tool has discoverable targets.
- Writes an explicit routing block into project CLAUDE.md.
- When includeOverlay is true, inlines the content of
model-overlays/opus-4-7.md into CLAUDE.md too. This is what makes the
fanout A/B observable in `claude -p`: arm ON gets the overlay in
context, arm OFF does not.
Plus an afterAll that re-runs gen-skill-docs at the default model so
the working tree is not left with opus-4-7-generated SKILL.md files
after the eval finishes (would break golden-file tests in the next
`bun test` run otherwise).
With this setup in place: routing went from 3/3 FAIL to 3/3 PASS
(correct skill or clarification in every positive case, zero false
positives on negatives). Fanout A/B is now a fair comparison; still
shows 0 parallel in both arms under `claude -p` (tracked as a P0 TODO
for re-measurement inside Claude Code's harness, where fanout may land
differently).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(todos): verify Opus 4.7 fanout nudge in Claude Code harness (P0)
v1.6.1.0 shipped a rewritten "Fan out explicitly" nudge with a concrete
tool_use example. Under `claude -p` on claude-opus-4-7, the A/B eval
showed zero parallel tool calls in the first turn for both arms
(overlay ON and OFF). Routing verified 3/3 in the same harness, so the
gap is specific to fanout and likely to `claude -p`'s system prompt +
tool wiring.
This TODO closes the measurement loop the ship-quality review flagged:
re-run the fanout A/B inside Claude Code's real harness (or a faithful
replica) before landing another Opus migration claim.
P0 because it is a ship-quality commitment from the v1.6.1.0 release
notes, not a nice-to-have.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(release): v1.6.1.0 — Opus 4.7 migration, reviewed
Bump VERSION + package.json from 1.6.0.0 to 1.6.1.0. New CHANGELOG
entry describing the ship-quality remediation of PR #1117:
- Overlay split (model-agnostic claude.md + opus-4-7.md with INHERIT)
- Routing-injection aligned with SKILL.md.tmpl ("when in doubt" policy,
current skill names, full skill inventory)
- utility.ts trailer fallback updated
- Voice example closes through review gate instead of ship-bypass
- Literal-interpretation nudge bounded to branch scope
- Batch-questions nudge has explicit pacing exception
- First Opus 4.7 eval: routing verified 3/3, fanout A/B unverified
under `claude -p` (tracked as P0 TODO for next rev)
- Pre-existing test failures fixed: fs.statSync binary guard, 180s
setup timeout, golden-file updates
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(opus-4.7): key touchfile entries by testName, not describe text
TOUCHFILES completeness scan in test/touchfiles.test.ts expects every
`testName:` literal passed to runSkillTest to appear as a key in
E2E_TOUCHFILES. The previous entries were keyed by the outer describe
test names ("fanout: overlay ON emits...") rather than the inner
testName values ('fanout-arm-overlay-on', 'fanout-arm-overlay-off'),
which failed the completeness check.
Switched both E2E_TOUCHFILES and E2E_TIERS to use the two fanout arm
testNames as keys. The routing sub-tests use a template literal
(`routing-${c.name}`) which the scanner skips, so they inherit selection
from file-level changes to the opus-4-7.md / routing-injection.ts paths
already covered by the fanout entries.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: gstack <ship@gstack.dev>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
309 lines
11 KiB
Cheetah
309 lines
11 KiB
Cheetah
---
|
|
name: gstack
|
|
preamble-tier: 1
|
|
version: 1.1.0
|
|
description: |
|
|
Fast headless browser for QA testing and site dogfooding. Navigate pages, interact with
|
|
elements, verify state, diff before/after, take annotated screenshots, test responsive
|
|
layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or
|
|
test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
|
|
allowed-tools:
|
|
- Bash
|
|
- Read
|
|
- AskUserQuestion
|
|
triggers:
|
|
- browse this page
|
|
- take a screenshot
|
|
- navigate to url
|
|
- inspect the page
|
|
|
|
---
|
|
|
|
{{PREAMBLE}}
|
|
|
|
If `PROACTIVE` is `false`: do NOT proactively invoke or suggest other gstack skills during
|
|
this session. Only run skills the user explicitly invokes. This preference persists across
|
|
sessions via `gstack-config`.
|
|
|
|
If `PROACTIVE` is `true` (default): **invoke the Skill tool** when the user's request
|
|
matches a skill's purpose. Do NOT answer directly when a skill exists for the task.
|
|
Use the Skill tool to invoke it. The skill has specialized workflows, checklists, and
|
|
quality gates that produce better results than answering inline.
|
|
|
|
**Routing rules — when you see these patterns, INVOKE the skill via the Skill tool:**
|
|
- User describes a new idea, asks "is this worth building", brainstorms, pitches a concept → invoke `/office-hours`
|
|
- User asks about strategy, scope, ambition, "think bigger", "what should we build" → invoke `/plan-ceo-review`
|
|
- User asks to review architecture, lock in the plan, "does this design make sense" → invoke `/plan-eng-review`
|
|
- User asks about design system, brand, visual identity, "how should this look" → invoke `/design-consultation`
|
|
- User asks to review design of a plan → invoke `/plan-design-review`
|
|
- User asks about developer experience of a plan, API/CLI/SDK design → invoke `/plan-devex-review`
|
|
- User wants all reviews done automatically, "review everything" → invoke `/autoplan`
|
|
- User reports a bug, error, broken behavior, "why is this broken", "this doesn't work", "wtf", "something's wrong" → invoke `/investigate`
|
|
- User asks to test the site, find bugs, QA, "does this work", "check the deploy" → invoke `/qa`
|
|
- User asks to just report bugs without fixing → invoke `/qa-only`
|
|
- User asks to review code, check the diff, pre-landing review, "look at my changes" → invoke `/review`
|
|
- User asks about visual polish, design audit of a live site, "this looks off" → invoke `/design-review`
|
|
- User asks to audit the live developer experience, time-to-hello-world → invoke `/devex-review`
|
|
- User asks to ship, deploy, push, create a PR, "let's land this", "send it" → invoke `/ship`
|
|
- User asks to merge + deploy + verify as one flow → invoke `/land-and-deploy`
|
|
- User asks to configure deployment for the project → invoke `/setup-deploy`
|
|
- User asks to monitor prod after shipping, post-deploy checks → invoke `/canary`
|
|
- User asks to update docs after shipping → invoke `/document-release`
|
|
- User asks for a weekly retro, what did we ship, "how'd we do" → invoke `/retro`
|
|
- User asks for a second opinion, codex review → invoke `/codex`
|
|
- User asks for safety mode, careful mode → invoke `/careful` or `/guard`
|
|
- User asks to restrict edits to a directory → invoke `/freeze` or `/unfreeze`
|
|
- User asks to upgrade gstack → invoke `/gstack-upgrade`
|
|
- User asks to save progress, checkpoint, "save my work" → invoke `/context-save`
|
|
- User asks to resume, restore, "where was I" → invoke `/context-restore`
|
|
- User asks about security, OWASP, vulnerabilities, "is this secure" → invoke `/cso`
|
|
- User asks to make a PDF, document, publication → invoke `/make-pdf`
|
|
- User asks to launch a real browser for QA, "open the browser" → invoke `/open-gstack-browser`
|
|
- User asks to import cookies for authenticated testing → invoke `/setup-browser-cookies`
|
|
- User asks about page speed, performance regression, benchmarks → invoke `/benchmark`
|
|
- User asks what gstack has learned, "show learnings" → invoke `/learn`
|
|
- User asks to tune question sensitivity, "stop asking me that" → invoke `/plan-tune`
|
|
- User asks for code quality dashboard, "health check" → invoke `/health`
|
|
|
|
**When in doubt, invoke the skill.** A false positive (invoking a skill that wasn't
|
|
needed) is cheaper than a false negative (answering ad-hoc when a structured workflow
|
|
exists). The skill provides multi-step workflows, checklists, and quality gates that
|
|
always produce better results than an ad-hoc answer. If no skill matches, answer
|
|
directly as usual.
|
|
|
|
If the user opts out of suggestions, run `gstack-config set proactive false`.
|
|
If they opt back in, run `gstack-config set proactive true`.
|
|
|
|
# gstack browse: QA Testing & Dogfooding
|
|
|
|
Persistent headless Chromium. First call auto-starts (~3s), then ~100-200ms per command.
|
|
Auto-shuts down after 30 min idle. State persists between calls (cookies, tabs, sessions).
|
|
|
|
{{BROWSE_SETUP}}
|
|
|
|
## IMPORTANT
|
|
|
|
- Use the compiled binary via Bash: `$B <command>`
|
|
- NEVER use `mcp__claude-in-chrome__*` tools. They are slow and unreliable.
|
|
- Browser persists between calls — cookies, login sessions, and tabs carry over.
|
|
- Dialogs (alert/confirm/prompt) are auto-accepted by default — no browser lockup.
|
|
- **Show screenshots:** After `$B screenshot`, `$B snapshot -a -o`, or `$B responsive`, always use the Read tool on the output PNG(s) so the user can see them. Without this, screenshots are invisible.
|
|
|
|
## QA Workflows
|
|
|
|
> **Credential safety:** Use environment variables for test credentials.
|
|
> Set them before running: `export TEST_EMAIL="..." TEST_PASSWORD="..."`
|
|
|
|
### Test a user flow (login, signup, checkout, etc.)
|
|
|
|
```bash
|
|
# 1. Go to the page
|
|
$B goto https://app.example.com/login
|
|
|
|
# 2. See what's interactive
|
|
$B snapshot -i
|
|
|
|
# 3. Fill the form using refs
|
|
$B fill @e3 "$TEST_EMAIL"
|
|
$B fill @e4 "$TEST_PASSWORD"
|
|
$B click @e5
|
|
|
|
# 4. Verify it worked
|
|
$B snapshot -D # diff shows what changed after clicking
|
|
$B is visible ".dashboard" # assert the dashboard appeared
|
|
$B screenshot /tmp/after-login.png
|
|
```
|
|
|
|
### Verify a deployment / check prod
|
|
|
|
```bash
|
|
$B goto https://yourapp.com
|
|
$B text # read the page — does it load?
|
|
$B console # any JS errors?
|
|
$B network # any failed requests?
|
|
$B js "document.title" # correct title?
|
|
$B is visible ".hero-section" # key elements present?
|
|
$B screenshot /tmp/prod-check.png
|
|
```
|
|
|
|
### Dogfood a feature end-to-end
|
|
|
|
```bash
|
|
# Navigate to the feature
|
|
$B goto https://app.example.com/new-feature
|
|
|
|
# Take annotated screenshot — shows every interactive element with labels
|
|
$B snapshot -i -a -o /tmp/feature-annotated.png
|
|
|
|
# Find ALL clickable things (including divs with cursor:pointer)
|
|
$B snapshot -C
|
|
|
|
# Walk through the flow
|
|
$B snapshot -i # baseline
|
|
$B click @e3 # interact
|
|
$B snapshot -D # what changed? (unified diff)
|
|
|
|
# Check element states
|
|
$B is visible ".success-toast"
|
|
$B is enabled "#next-step-btn"
|
|
$B is checked "#agree-checkbox"
|
|
|
|
# Check console for errors after interactions
|
|
$B console
|
|
```
|
|
|
|
### Test responsive layouts
|
|
|
|
```bash
|
|
# Quick: 3 screenshots at mobile/tablet/desktop
|
|
$B goto https://yourapp.com
|
|
$B responsive /tmp/layout
|
|
|
|
# Manual: specific viewport
|
|
$B viewport 375x812 # iPhone
|
|
$B screenshot /tmp/mobile.png
|
|
$B viewport 1440x900 # Desktop
|
|
$B screenshot /tmp/desktop.png
|
|
|
|
# Element screenshot (crop to specific element)
|
|
$B screenshot "#hero-banner" /tmp/hero.png
|
|
$B snapshot -i
|
|
$B screenshot @e3 /tmp/button.png
|
|
|
|
# Region crop
|
|
$B screenshot --clip 0,0,800,600 /tmp/above-fold.png
|
|
|
|
# Viewport only (no scroll)
|
|
$B screenshot --viewport /tmp/viewport.png
|
|
```
|
|
|
|
### Test file upload
|
|
|
|
```bash
|
|
$B goto https://app.example.com/upload
|
|
$B snapshot -i
|
|
$B upload @e3 /path/to/test-file.pdf
|
|
$B is visible ".upload-success"
|
|
$B screenshot /tmp/upload-result.png
|
|
```
|
|
|
|
### Test forms with validation
|
|
|
|
```bash
|
|
$B goto https://app.example.com/form
|
|
$B snapshot -i
|
|
|
|
# Submit empty — check validation errors appear
|
|
$B click @e10 # submit button
|
|
$B snapshot -D # diff shows error messages appeared
|
|
$B is visible ".error-message"
|
|
|
|
# Fill and resubmit
|
|
$B fill @e3 "valid input"
|
|
$B click @e10
|
|
$B snapshot -D # diff shows errors gone, success state
|
|
```
|
|
|
|
### Test dialogs (delete confirmations, prompts)
|
|
|
|
```bash
|
|
# Set up dialog handling BEFORE triggering
|
|
$B dialog-accept # will auto-accept next alert/confirm
|
|
$B click "#delete-button" # triggers confirmation dialog
|
|
$B dialog # see what dialog appeared
|
|
$B snapshot -D # verify the item was deleted
|
|
|
|
# For prompts that need input
|
|
$B dialog-accept "my answer" # accept with text
|
|
$B click "#rename-button" # triggers prompt
|
|
```
|
|
|
|
### Test authenticated pages (import real browser cookies)
|
|
|
|
```bash
|
|
# Import cookies from your real browser (opens interactive picker)
|
|
$B cookie-import-browser
|
|
|
|
# Or import a specific domain directly
|
|
$B cookie-import-browser comet --domain .github.com
|
|
|
|
# Now test authenticated pages
|
|
$B goto https://github.com/settings/profile
|
|
$B snapshot -i
|
|
$B screenshot /tmp/github-profile.png
|
|
```
|
|
|
|
> **Cookie safety:** `cookie-import-browser` transfers real session data.
|
|
> Only import cookies from browsers you control.
|
|
|
|
### Compare two pages / environments
|
|
|
|
```bash
|
|
$B diff https://staging.app.com https://prod.app.com
|
|
```
|
|
|
|
### Multi-step chain (efficient for long flows)
|
|
|
|
```bash
|
|
echo '[
|
|
["goto","https://app.example.com"],
|
|
["snapshot","-i"],
|
|
["fill","@e3","$TEST_EMAIL"],
|
|
["fill","@e4","$TEST_PASSWORD"],
|
|
["click","@e5"],
|
|
["snapshot","-D"],
|
|
["screenshot","/tmp/result.png"]
|
|
]' | $B chain
|
|
```
|
|
|
|
## Quick Assertion Patterns
|
|
|
|
```bash
|
|
# Element exists and is visible
|
|
$B is visible ".modal"
|
|
|
|
# Button is enabled/disabled
|
|
$B is enabled "#submit-btn"
|
|
$B is disabled "#submit-btn"
|
|
|
|
# Checkbox state
|
|
$B is checked "#agree"
|
|
|
|
# Input is editable
|
|
$B is editable "#name-field"
|
|
|
|
# Element has focus
|
|
$B is focused "#search-input"
|
|
|
|
# Page contains text
|
|
$B js "document.body.textContent.includes('Success')"
|
|
|
|
# Element count
|
|
$B js "document.querySelectorAll('.list-item').length"
|
|
|
|
# Specific attribute value
|
|
$B attrs "#logo" # returns all attributes as JSON
|
|
|
|
# CSS property
|
|
$B css ".button" "background-color"
|
|
```
|
|
|
|
## Snapshot System
|
|
|
|
{{SNAPSHOT_FLAGS}}
|
|
|
|
## Command Reference
|
|
|
|
{{COMMAND_REFERENCE}}
|
|
|
|
## Tips
|
|
|
|
1. **Navigate once, query many times.** `goto` loads the page; then `text`, `js`, `screenshot` all hit the loaded page instantly.
|
|
2. **Use `snapshot -i` first.** See all interactive elements, then click/fill by ref. No CSS selector guessing.
|
|
3. **Use `snapshot -D` to verify.** Baseline → action → diff. See exactly what changed.
|
|
4. **Use `is` for assertions.** `is visible .modal` is faster and more reliable than parsing page text.
|
|
5. **Use `snapshot -a` for evidence.** Annotated screenshots are great for bug reports.
|
|
6. **Use `snapshot -C` for tricky UIs.** Finds clickable divs that the accessibility tree misses.
|
|
7. **Check `console` after actions.** Catch JS errors that don't surface visually.
|
|
8. **Use `chain` for long flows.** Single command, no per-step CLI overhead.
|