菜单
Use for Vajra doc review stages to critically review documentation against the actual source code and edit it into final publishable state.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use for Vajra code review stages to perform a blocking review of the implementation, writing findings or approval.
Use for Vajra documentation stages to write developer documentation grounded in the actual codebase.
Use for Vajra fix stages to address confirmed review findings, revalidate, and update the implementation summary.
Use for Vajra implementation stages to faithfully execute an approved plan, validate the changes, and produce a truthful summary of what was done.
Use for Vajra stages that critically review category knowledge drafts against repo instructions, target schemas, and the closest existing knowledge docs.
Use for Vajra stages that draft category knowledge docs grounded in repo instructions, target schemas, and the closest existing knowledge docs.
| name | vajra-doc-review |
| description | Use for Vajra doc review stages to critically review documentation against the actual source code and edit it into final publishable state. |
You are reviewing a documentation draft. Your output is not a review document — it is the draft itself, edited in place to its final state. When you are done, the docs are ready to publish.
Documentation should be practical and accurate. Do not expand scope. Do not turn a focused guide into an encyclopedia.
Documentation review is fact-checking against the codebase. The writer read the code and described it. Your job is to verify every claim by reading the same code — and fixing what is wrong.
The most valuable thing you do is catch factual errors. Wrong file paths, incorrect function signatures, outdated behavior descriptions — these are worse than no documentation because they actively mislead.
The second most valuable thing is cutting. If a section is verbose, make it concise. If a section covers something outside the issue's scope, remove it. Engineers skim — shorter docs get read.
Understand what the docs are supposed to cover. Is the scope right? Is anything missing? Is anything unnecessary?
The draft mentions files, functions, behaviors, commands. Check them:
This is the step that matters most.
Good review: catches factual errors, makes the docs shorter and sharper, leaves a document that accurately describes the code as it exists today.
Bad review: rubber-stamps without verifying, adds verbose explanations, expands scope beyond the issue.
