requesting-code-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited requesting-code-review (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Dispatch aegis:code-reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
This skill is the canonical review-request workflow for method-pack implementation work. Use it to request review only after you have enough evidence, enough context, and a clear authority boundary for what the reviewer is being asked to assess.
Core principle: Review early, review often.
Findings First: Reviews lead with concrete findings before summary. Use bugs first, risk first, tests first. Strengths and general assessment are still useful, but they must not bury correctness, evidence, architecture, or retirement problems.
Review readiness is not merge approval. A review can reduce uncertainty and recommend readiness, but it does not replace verification-before-completion and does not grant completion authority.
Mandatory:
Optional but valuable:
Before you leave this workflow, you must be able to state:
Review in this method pack is advisory and evidence-oriented. It is not authoritative completion by itself.
1. Gather minimum review inputs:
requirements/product alignment and architecture/current-authority alignment
Auto Backfill or baseline sync findings
recording-architecture-decisions was used, or should be used, whenan ADR action or baseline sync closure is in scope
If you cannot answer these, stop and gather them before dispatching review.
2. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)3. Dispatch code-reviewer subagent:
Use Task tool with aegis:code-reviewer type, fill template at code-reviewer.md
Placeholders:
{WHAT_WAS_IMPLEMENTED} - What you just built{PLAN_OR_REQUIREMENTS} - What it should do{EVIDENCE} - Fresh tests, commands, logs, or verification already available{COMPATIBILITY_BOUNDARY} - What existing behavior or interfaces must not break{RETIREMENT_NOTES} - Old owner / fallback / patch / duplicate branch and expected disposition{BASE_SHA} - Starting commit{HEAD_SHA} - Ending commit{DESCRIPTION} - Brief summary4. Act on feedback:
legacy alias such as architecture drift, decide explicitly whether to repair now, correct the baseline, or record retirement conditions
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch aegis:code-reviewer subagent]
WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
PLAN_OR_REQUIREMENTS: Task 2 from docs/aegis/plans/deployment-plan.md
EVIDENCE: pytest tests/index/test_verify.py -v -> 12 passed
COMPATIBILITY_BOUNDARY: Existing index format and CLI flags must remain stable
RETIREMENT_NOTES: Legacy repair fallback still exists in old helper; remove once new path covers all four issue types
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]Subagent-Driven Development:
Executing Plans:
Ad-Hoc Development:
The review request must prompt the reviewer to inspect at least:
non-goals
source-of-truth, compatibility, and retirement boundaries
scope: requirements | architecture | both
drift must map back to Design Defect / Implementation Drift rather than becoming parallel result vocabularies
decisions
recording-architecture-decisions handoff when ADR action orbaseline sync closure is in scope
If the review only asks “is this code good?”, it is underspecified.
Never:
If reviewer wrong:
See template at: requesting-code-review/code-reviewer.md
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.