agentsclimarketplace
Sign in

Assist review

Skill drafthq/draft/skills/assist-review

Reviewing someone else's PR for handoff/sign-off. Isolates structural changes from trivial edits, flags HLD/LLD drift and guardrail violations, points the reviewer at what to scrutinize. Use when prepping to review another engineer's work — NOT for first-pass self-review (use review / quick-review).From its SKILL.md

Install
npx -y skills add drafthq/draft --skill assist-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.4 KB, as published. Nobody here has run it

Draft Assist Review: Human-in-the-Loop Gateway

Help human reviewers effectively review an executed track without shifting the entire cognitive burden onto them.

Red Flags - STOP if you're

  • Conducting standard unit tests; use /draft:review for that.
  • Fixing code rather than explaining logic and risk profiles to the human.
  • Reviewing output without first summarizing the source spec.md intent.

Workflow Constraints

  1. Context Extraction:

    • Load the track's spec.md and plan.md.
    • Load the track's hld.md and lld.md if present — extract Key Design Decisions, Alternatives Considered, and (LLD) class invariants and error policies.
    • Re-summarize the Intent of what this track was supposed to achieve in exactly two sentences.

  2. Blast Radius Isolation:

    • Scan the git diff generated by the target track.
    • Separate trivial edits (naming, routing adjustments, formatting) from Structural Edits (schema updates, concurrency alterations, middleware auth changes, API surface changes).
    • Present structural edits first — these are where review time should be spent.

  3. Generate the Human Helper Guide:

    • Instead of a traditional bug hunt, generate an executive summary containing a Risk Assessment.
    • For each structural edit, cite the originating decision: "I chose [Pattern] for [File/Function] because hld.md §Key Design Decisions / Alternatives Considered selected it over [rejected alternative]. You should specifically scrutinize lines X–Y because they touch [global state / auth boundary / shared schema]." Fall back to architecture.md only when no HLD exists.
    • Highlight any code that violates an LLD §Classes and Interfaces invariant (thread safety, idempotency, ordering) or contradicts an HLD §Checklist claim (e.g., "code introduces a new shared mutex but HLD declared single-writer").
    • Highlight any code that touches shared state, auth boundaries, data persistence, or concurrency.

  4. Knowledge Base Verification:

    • Verify if any pattern implemented violates the draft/guardrails.md learned anti-patterns.
    • Verify the diff is consistent with hld.md/lld.md commitments. If the diff makes structural changes not reflected in HLD §Detailed Design or LLD §Classes/Interfaces: flag for the reviewer that HLD/LLD must be amended (/draft:change) before merge.
    • If so, specifically direct the human reviewer to veto the change unless an ADR is created via /draft:adr.

  5. Output Format:

    • Track Intent (2 sentences)
    • HLD/LLD Decision Trace (per structural edit: which §Key Design Decision or §Alternatives Considered row drove this code; or "no HLD justification — reviewer must request one")
    • Structural Edits (table: file, change type, risk level, review guidance)
    • Trivial Edits (collapsed list — skim only)
    • HLD/LLD Drift (diff makes claims that HLD/LLD does not document — recommend /draft:change)
    • Guardrail Violations (if any — with ADR recommendation)
    • Suggested Review Order (which files to review first, based on blast radius)

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.