stably 4.12.21 → 4.12.22

package/dist/stably-plugin-cli/skills/bulk-test-handling/SKILL.md

@@ -101,6 +101,12 @@ After all batches complete, provide:
 - List of any failed/skipped tests with reasons
 - Suggestions for resolving issues
 
+## Orchestrator Available
+
+If `create-planner` and `create-worker` subagents are available (check your available subagent types), defer to the orchestrator for parallel execution instead of using this batch approach. The orchestrator groups tests by page and runs workers in parallel, which is faster than sequential batching. This skill applies only when the orchestrator subagents are not available.
+
+Note: the batching guidance in this skill (browser-close between tests, batch sizes of ~6) still applies *within* each orchestrator worker — workers process their page group's tests sequentially with the same browser-reset pattern.
+
 ## Do NOT
 
 - Start creating tests without informing user of scope

package/dist/stably-plugin-cli/skills/stably-browser/SKILL.md

@@ -231,6 +231,40 @@ stably-browser run-test --help
 - Overrides `browser`/`context`/`page` fixtures to connect via CDP (no new browser launched)
 - Preserves browser state after the run (pages remain open for inspection)
 
+## Test Creation Workflow
+
+Use `stably-browser` as a live exploration tool during test creation, not just as a final verifier.
+
+Preferred pattern when feasible:
+
+1. Open the page and explore it live.
+```bash
+stably-browser open https://example.com/target
+stably-browser click e15
+stably-browser fill e22 "query"
+```
+
+2. Read the snapshot returned by each action.
+- Treat the browser snapshot as ground truth for visible DOM structure, roles, labels, text, and control behavior.
+- Use code/source reads for routes, feature flags, auth/setup, and hidden preconditions.
+
+3. Reuse emitted Playwright code.
+- `stably-browser` actions emit concrete Playwright code/locator suggestions.
+- Prefer copying that evidence into the test instead of inventing selectors from scratch.
+
+4. Run `stably-browser run-test` to verify.
+- Use `run-test` after you understand the page, or earlier when it is needed to bootstrap project-aware auth/setup.
+- After `run-test`, prefer inspecting the persisted browser/session before blindly rerunning from the error text alone.
+
+5. If auth/setup requires a project-aware bootstrap:
+- Direct `open` may not reproduce Playwright project auth/setup on its own.
+- In those repos, use `stably-browser run-test --project=<project>` or a seed test to establish the correct state, then inspect the persisted browser/session.
+
+Anti-patterns:
+- Guessing selectors from source code when the live browser already shows the actual DOM
+- Treating `run-test` as the only discovery tool
+- Blindly looping `run-test` → read error → edit without inspecting the browser state in between
+
 ### Running Multiple Tests — Sequential vs Parallel
 
 When verifying that multiple independent tests pass, each test needs its own clean browser state. Two approaches:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "stably",
-  "version": "4.12.21",
+  "version": "4.12.22",
   "packageManager": "pnpm@10.24.0",
   "description": "AI-powered E2E Playwright testing CLI. Stably can understand your codebase, edit/run tests, and handle complex test scenarios for you.",
   "main": "dist/index.mjs",