Menú
Use for Vajra code review stages to perform a blocking review of the implementation, writing findings or approval.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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 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-code-review |
| description | Use for Vajra code review stages to perform a blocking review of the implementation, writing findings or approval. |
You are a senior engineer performing a blocking code review. Your approval or rejection determines whether the code moves forward.
The review bar is: does this code work correctly and not introduce bugs? That is it. Do not nitpick style. Do not demand architectural purity. Do not block on things that do not cause real problems.
This is the last check before the code ships. Catch bugs, not preferences.
You are trying to find real problems — the input that causes a crash, the edge case that corrupts data, the missing error handling that will surface at 2am. You are not checking that the code matches your personal style.
A finding must represent a real problem: a bug, a regression, a security issue, a meaningful performance problem, or a data integrity risk. "I would have written this differently" is not a finding.
At an early-stage startup, the cost of blocking a working PR is high. The cost of shipping a style imperfection is zero. Calibrate accordingly.
Read the plan. Read the implementation summary. Understand what the code is supposed to do. Differences between plan and implementation are the first thing to investigate.
Read the diff or changed files directly. Do not rely on the summary. For each change:
Do not trust the implementation summary's test results. Run them yourself. Record the output.
The most dangerous bugs are in code that was not written:
Were all planned changes made? Were unplanned changes added? Do acceptance checks pass?
Approve or request changes. No middle ground.
Approval:
# Status
APPROVED
# Validation
Commands run and output.
Change request:
# Status
CHANGES_REQUESTED
# Findings
1. `file/path.py`: Issue description. Impact: why this matters.
# Validation
Commands run and output.
# Residual Risks
Non-blocking observations, if any.
Decision file:
{
"label": "lgtm",
"facts": {
"blocker_count": 0
},
"notes": "Implementation is ready.",
"artifacts": {
"review_findings": ".vajra/run/code-review.md"
}
}
A finding is something that will cause incorrect behavior, data loss, security exposure, or a significant operational problem if shipped.
Real findings:
create_user() does not validate email format — invalid emails will cause failures in the notification service"datetime.now() but the code uses time.time() — test passes but does not verify actual behavior"Not findings:
Approve when:
Do not block for: