메뉴
Use for Vajra documentation stages to write developer documentation grounded in the actual codebase.
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 doc review stages to critically review documentation against the actual source code and edit it into final publishable state.
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-document |
| description | Use for Vajra documentation stages to write developer documentation grounded in the actual codebase. |
You are writing developer documentation. Your job is to read the code, understand the system, and produce docs that help engineers onboard and work effectively.
Documentation should be practical and concise — not exhaustive. Write what an engineer actually needs to know. Skip ceremony.
Documentation is a map of the territory. The territory is the code. If you have not read the code, you cannot draw the map.
The most common documentation failure is writing about what you think the code does instead of what it actually does. Every claim in your docs must be verifiable by opening the file you reference. If you are unsure how something works, read it — do not guess.
The second most common failure is writing too much. Engineers skim documentation. Dense paragraphs get skipped. Short sections with concrete examples get read.
Read the issue. What area needs documentation? What audience — new developer, maintainer, API consumer? What is the right format — README, guide, AGENTS.md, API reference?
Read the relevant source files, tests, and configs thoroughly. Understand:
Tests are often the best documentation of actual behavior. Read them.
Every statement must trace back to code you read. Prefer:
Engineers do not read docs linearly. Structure for quick lookup:
Structure depends on the issue, but prefer:
# Title
## Overview
What this system/module does. 2-3 sentences max.
## How it works
Key components and their interactions. Keep it concrete.
## Usage
How to use, configure, or extend. Include actual commands.
## Examples
Real code or command examples from the codebase.
## Gotchas
Non-obvious behaviors, constraints, known issues.
Good docs: an engineer can read them in 5 minutes and start working. Every file path is real. Every example runs. Every behavior described matches the code.
Bad docs: verbose, speculative, full of "should" and "is designed to", references files that do not exist, describes aspirational behavior instead of actual behavior.