Upgrade skill docs with missing commands and engine semantics#4
Upgrade skill docs with missing commands and engine semantics#4
Conversation
Both skills were missing documentation for session status/close, node pick, profiler export, and advanced session open options (--browser, --channel, --device, --storage-state, --user-data-dir, --headless). Also adds engine selection semantics (auto/custom/devtools) to runtime-semantics.md and improves skill descriptions for better triggering accuracy. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Documentation-only change — no source code, tests, or build artifacts are modified. All changes are scoped to |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbfa9c8677
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | Engine | Behavior | | ||
| |---|---| | ||
| | `auto` | Tries the custom engine first, falls back to DevTools-aligned if unavailable | |
There was a problem hiding this comment.
--engine auto resolution order
This table inverts the default engine selection. In detectDevtoolsCapabilities() the runtime sets recommendedEngine to devtools when the hook is usable and then resolves auto to that recommendation (src/runtime-script.js:206-209), so --engine auto prefers DevTools and falls back to custom, not the reverse. As written, the default workflow in this skill will make agents assume custom-engine semantics when the session is actually on the DevTools-backed path.
Useful? React with 👍 / 👎.
| | `selectedEngine` | The engine actually in use after resolution | | ||
| | `availableEngines` | Engines that the runtime supports for this page | | ||
| | `recommendedEngine` | The engine the runtime considers optimal | | ||
| | `engineFallback` | `true` if the selected engine differs from the preference (auto resolved to a specific engine, or a forced engine was unavailable) | |
There was a problem hiding this comment.
engineFallback as a forced-devtools fallback only
The new definition says this flag becomes true whenever selectedEngine differs from enginePreference, including normal auto resolution, but both detectDevtoolsCapabilities() and buildResolvedEngineMetadata() only set engineFallback when an explicit devtools request had to fall back to custom (src/runtime-script.js:227,255). That mislabels ordinary --engine auto sessions and will cause agents to misread session doctor / session status output.
Useful? React with 👍 / 👎.
| ## Prefer Built-in Interact Commands | ||
|
|
||
| - Use `interact click`, `interact type`, `interact press`, and `interact wait` before ad hoc helper scripts. | ||
| - All interact commands accept optional `--timeout-ms <ms>` for element location timeout. |
There was a problem hiding this comment.
--timeout-ms guidance for interact wait
This says every interact command accepts --timeout-ms, but rdt --help only advertises that flag on interact click, interact type, and interact press; interact wait is rdt interact wait --session <name> --ms <n>, and handleInteractCommand() ignores options.timeoutMs in the wait branch (src/cli.js:371-375). Agents following this skill will think they shortened a wait when the flag is actually a no-op.
Useful? React with 👍 / 👎.
1 participant
Summary
session status,session close,node pick,profiler export--browser,--channel,--device,--storage-state,--user-data-dir,--headless--profile-idfor profiler start,--compress/--outputfor profiler exportauto/custom/devtools) to runtime-semantics.mdTest plan
rdt --helpoutputsession doctoroutput🤖 Generated with Claude Code