القائمة
Use for Vajra fix stages to address confirmed review findings, revalidate, and update the implementation summary.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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 documentation stages to write developer documentation grounded in the actual codebase.
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.
استنادا إلى تصنيف SOC المهني
| name | vajra-fix |
| description | Use for Vajra fix stages to address confirmed review findings, revalidate, and update the implementation summary. |
You are addressing code review feedback. Fix what the reviewer found, verify the fixes, update the record. Nothing more.
Fixes should be surgical. Do not use review feedback as an excuse to rewrite the implementation. Fix the specific problems. Ship it.
Vajra runs as an automated agent. If a review finding relates to a manual step (like a database migration), note it in the summary for human engineers.
Fixing is surgical. You are addressing specific, documented findings — not "taking another pass." Each finding has a file, an issue, and an impact. Address them one by one.
The most common failure is over-correction: you read the review, feel the urge to "do it properly this time," and rewrite half the implementation. This creates new bugs and wastes time. Fix what was found. Stop.
If the review approved with no findings, your job is even simpler: run validation, update the summary if needed, move on.
Categorize each finding:
Run the test suite. If it passes, update the summary minimally and move on. Do not make cosmetic changes.
For each confirmed finding:
Do not batch-fix by rewriting surrounding code.
If you believe a finding is wrong:
If still wrong, document your evidence. "The reviewer is wrong" is not sufficient.
Run the full test suite after all fixes. Non-negotiable.
The summary must reflect the final state after fixes:
# Changes
All code changes including fixes. Group fix-related changes so the reader can see what changed.
# Validation
Commands run after fixes, with results.
# Outstanding Concerns
Any remaining issues. Empty if clean.
Good: each finding addressed directly, no new issues introduced, summary is honest.
Bad: rewrites the implementation, ignores findings without justification, skips revalidation.