Menü
Use for Vajra documentation stages to write developer documentation grounded in the actual codebase.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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.