CtrlK
BlogDocsLog inGet started
Tessl Logo

tessleng/sdlc-assurance

Assurance guidance for verification, technical review, review fixes, and safe delivery handoff.

69

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

SKILL.mdskills/requesting-code-review/

name:
requesting-code-review
description:
Dispatch a code-reviewer subagent with precisely scoped context (git SHAs, task description, requirements) to review a diff and return Critical, Important, and Minor findings. Use after delivery-flow finishes implementing and verifying a task, before merging to main. This is the internal code-review stage of the delivery-flow workflow. It is not a standalone entry point, so do not activate it directly for a one-off "review this PR" or "review my code" request; use delivery-flow for those instead.

Requesting Code Review

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.

Core principle: Review early, review often.

When to Request Review

Mandatory:

  • After each task in subagent-driven development
  • After completing major feature
  • Before merge to main

Optional but valuable:

  • When stuck (fresh perspective)
  • Before refactoring (baseline check)
  • After fixing complex bug

How to Request

1. Get git SHAs:

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch code reviewer subagent:

Dispatch a general-purpose subagent, filling the template at code-reviewer.md

Placeholders:

  • {DESCRIPTION} - Brief summary of what you built
  • {PLAN_OR_REQUIREMENTS} - What it should do
  • {BASE_SHA} - Starting commit
  • {HEAD_SHA} - Ending commit

3. Act on feedback, in order:

  1. Fix all Critical issues immediately
  2. Fix all Important issues before proceeding
  3. Record Minor issues for later
  4. Push back with technical reasoning if the reviewer is wrong

Example

[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 code reviewer subagent]
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[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]

Common Rationalizations

ExcuseReality
"I'll just review the diff myself"Reviewing inline burns the context you need to keep driving the work. Dispatch a subagent instead — only the findings come back.
"The reviewer needs my session history"Hand it precisely crafted context, never your session's history.

Red Flags

Never: skip review because "it's simple", ignore Critical issues, proceed with unfixed Important issues, or argue with valid feedback.

If the reviewer is wrong: push back with technical reasoning, show code/tests that prove it works, or request clarification.

See template at: code-reviewer.md

skills

requesting-code-review

tile.json