菜单
Compressed code review comments. Cuts noise from feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. When the context is already using caveman mode, and user requests a review, ask user whether this skill should be used.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Token-efficient man page reading. Load when looking up CLI tool docs, flags, options, usage examples, config formats. Do NOT use bash to run `man` directly without loading this skill first.
Load when user asks to create, update, edit, or refactor any OpenCode (OC) artefact: skills, agents, commands, tools, plugins, or snippets — including modifying an existing one. Triggers examples: "create skill to …", "draft a command to …", "add Y to OC cmd Z", "edit the W agent", "write a plugin to …", "create a tool for …", "update crafter skill". Guides user through discovery, drafting, and iterative refinement.
Methodology for drafting technical design specs. Load when asked to write, draft, or refine a spec, design doc, architecture note, RFC, or similar document for a system, API, protocol, or subsystem.
Load ONLY when user explicitly invokes /reflect-friction or directly asks to review session friction (e.g. "review friction", "what went wrong", "where did you push back"). Do NOT auto-load speculatively.
General script writing guidelines: structure, naming, error handling, and organization. Language-agnostic. Auto-load when writing or reviewing any script. Language-specific skills (write-script-bash, write-script-bats) build on top of this.
Load whenever new files or directories are created in a git repo — via write, bash, or any other tool. Ensures `git_track_new_file` is called so new files are git-tracked for the user.
| name | caveman-review |
| description | Compressed code review comments. Cuts noise from feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. When the context is already using caveman mode, and user requests a review, ask user whether this skill should be used. |
Write code review comments terse & actionable. One line per finding: Location, problem, fix. No throat-clearing.
Format: L<line>: <problem>. <fix>. — or <file>:L<line>: ... when reviewing multi-file diffs.
Severity prefix (optional, when mixed):
BUG: — broken behavior, will cause incidentRISK: — works but fragile (race, missing null check, swallowed error)nit: — style, naming, micro-optim. Author can ignoreQ: — genuine question, not a suggestionDrop:
nit: insteadQ:Keep:
Bad: "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."
Good: L42: ❌ bug: user can be null after .find(). Add guard before .email.
Bad: "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
Good: L88-140: nit: 50-line fn does 4 things. Extract validate/normalize/persist.
Bad: "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
Good: L23: 🤔 risk: no retry on HTTP 429 (TooManyRequest). Wrap in withBackoff?
Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". 👉 In those cases write a normal paragraph, then resume terse for the rest.
Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. "stop caveman-review" or "normal mode": revert to verbose review style.