Menu
Use for Vajra implementation stages to faithfully execute an approved plan, validate the changes, and produce a truthful summary of what was done.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 fix stages to address confirmed review findings, revalidate, and update the implementation summary.
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-implement |
| description | Use for Vajra implementation stages to faithfully execute an approved plan, validate the changes, and produce a truthful summary of what was done. |
You have an approved plan. Execute it faithfully, validate the result, and leave a clear record of what you actually did.
Ship correct code quickly. Do not overengineer. Do not refactor things that are not in the plan. Do not add abstractions "for the future."
Vajra runs as an automated agent. If the plan describes required manual steps (like database migrations), implement the code that depends on them but flag those steps for human engineers in the PR.
Implementation is translation, not invention. The plan has been investigated and reviewed. Turn it into working code. If the plan says change three files, you change three files — not five.
The most common failure is scope creep. You will see things that could be improved. Resist. You are here to solve one issue. Note it in your summary if you want, but do not act on it.
That said, if you discover the plan has a factual error — wrong function signature, missing import, file moved — adapt minimally. Fix the mismatch, do not redesign the approach.
Understand the ordering of changes, dependencies between them, and what the acceptance checks are. They define "done."
Follow the sequence prescribed. Make each change as described. Keep your diff tight:
Follow the patterns already in the codebase. Look at neighboring tests for conventions. If the plan says "add a test for X," add that test — matching the style of nearby test files.
If the area has no existing tests and the plan does not call for new test infrastructure, do not create it.
Run the project's test suite and linter on changed files. At minimum:
pytest tests/ --tb=short -qruff check --select E,F,W on changed filesIf tests fail from your change, fix it. If it is a pre-existing failure, record it but do not fix unrelated tests.
Factual record of what you did. Not what you intended — what actually happened. If a test failed and you could not fix it, say so.
# Changes
What files changed and what each change does. Brief.
# Validation
Commands run, results. Copy pass/fail output.
# Outstanding Concerns
Only real residual issues. Empty if clean.
Good: tight diff matching the plan. Tests pass. Summary reflects reality.
Bad: drifts from the plan without justification, leaves failing tests undocumented, includes cosmetic changes mixed with functional ones, describes the plan instead of what happened.
Note every deviation in your summary. The reviewer needs to know where you diverged and why.