Content
88%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a high-quality operational skill: fully executable commands, strong validation around a genuinely destructive operation, and sensible externalization of the heavy setup script. The main weakness is mild verbosity in the rationale and OpenCode-specific sections.
Suggestions
Tighten the "为什么不能直接 --yes" paragraph into a one-line note; the exit-code table and NEEDS_CONSENT FAQ row already convey the safety contract.
Move the OpenCode timeout wrappers and known-limitations table into a references/opencode-notes.md file, keeping only a pointer in SKILL.md so the main body stays lean.
Consider splitting the startup flow's detect/branch/consent steps into a short numbered checklist with bold validation checkpoints to make the feedback loop visually explicit.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Dense operational commands and tables with little padding, but the "为什么不能直接 --yes" prose and the OpenCode timeout/known-limitations sections include rationale that could be trimmed. It sits above the 3-anchor (mostly efficient, some unnecessary explanation) but below the 5-anchor's every-token-earns-its-place standard. | 4 / 5 |
Actionability | Copy-paste-ready commands throughout (agent-browser invocations, setup-cdp-chrome.js flags, base64/heredoc eval patterns, PowerShell Job and timeout wrappers) covering the common cases, matching the fully-executable anchor. | 5 / 5 |
Workflow Clarity | The destructive Chrome-kill workflow has explicit validation: a --detect-only probe, branching on CDP_STATUS, AskUserQuestion consent, documented exit codes 0/1/2/3, and a NEEDS_CONSENT→ask→--yes→retry feedback loop. The destructive-operations cap does not apply because validation is present and emphasized. | 5 / 5 |
Progressive Disclosure | Well-sectioned body with a clear one-level-deep reference to scripts/setup-cdp-chrome.js (the 40KB asset is correctly externalized), but the ~170-line body inlines the OpenCode timeout wrappers and known-limitations table that could live in a separate reference. Good structure with minor organization gaps rather than the clear-overview ideal of the 5-anchor. | 4 / 5 |
Total | 18 / 20 Passed |