smithery/workingdanny911

review-backlog

Review completed Task or Feature deliverables. Uses type-specific checklists (coding/docs/ideation/general) for quality review. Two modes: default (creates improvement Tasks) and immediate-fix (fixes issues directly). Triggers: 'review task', 'review feature', 'review backlog

Installation

$ npx skills add smithery/workingdanny911 --skill review-backlog

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 10,805 B
  • docs SUMMARY.md 306 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Sprint Review Backlog Skill

Systematically review completed Task or Feature deliverables, identify areas for improvement, and connect to next actions.

When to Use

  • Immediately after a Task or Feature is completed
  • When quality review of code/docs/design is needed
  • Before moving to the next Task for checkpoint

Prerequisites

This skill operates in a sprint folder containing:

  • BACKLOG.md - Backlog items
  • HANDOFF.md - Current progress status
  • INSTRUCTION.md - Agent guidelines
  • refs/ - Reference documents

Execution Modes

This skill supports two modes:

Aspect Default Mode Immediate-Fix Mode
When Manual review, post-completion Called from /sprint:work-on-feature R&R step
Trigger User runs /sprint:review-backlog R&R Agent selects "immediate-fix" when prompted
Output New improvement Tasks in BACKLOG.md Issues fixed directly in code
Post-review Tasks for next session R&R Agent reports fixes to Lead
Sprint files Updates BACKLOG.md with Tasks Does NOT touch sprint files (Lead handles)

Mode selection: After Step 4 (Report Results), ask:

How would you like to handle the findings?
1. Create improvement Tasks (default) — adds Tasks to BACKLOG.md for next session
2. Fix issues directly (immediate-fix) — fix all issues now in this session

If the agent is running as part of /sprint:work-on-feature, it should select option 2.


Workflow

Step 1: Understand Sprint Context

Required files to read:

  1. BACKLOG.md - Check completed items
  2. HANDOFF.md - Check progress status

After identifying target, read related files:

Target Files to Read
Feature refs/designs/F-{slug}.md, active/F-{slug}.md (contains decisions), refs/archive/F-{slug}.md (if prior Feature)
Task refs/plans/F-{feature-slug}-T-*.md, related Feature files

Sprint-wide (if needed):

  • refs/decisions/_sprint.md
  • refs/lessons/_sprint.md

Report to user:

Recently completed items:
- T-login-api: Login API (done)
- T-signup-api: Signup API (done)
- F-dashboard: Dashboard (done)

What would you like to review?
1. Specific Task
2. Entire Feature

Step 2: Identify Review Target

Collect information about the user's selected item:

  1. Check type - coding | docs | ideation | general from BACKLOG.md
  2. Check completion criteria - Originally defined success criteria
  3. Collect related deliverables - Code, documents, designs, etc.

Step 3: Apply Type-Specific Checklist

Note: Checklists are minimum standards. Apply additional criteria based on project characteristics.

Load checklist based on type:

Type Checklist
coding assets/coding/checklist.md
docs assets/docs/checklist.md
ideation assets/ideation/checklist.md
general assets/general/checklist.md

Perform review:

  • Check each checklist item one by one
  • Record pass/fail for each item
  • Provide detailed explanation for failed items

Agent Teams for Review

Consider using agent teams when:

  • Large scope — Entire Feature or multiple Tasks to review
  • Critical deliverable — High-risk work where thorough review matters (security, data integrity, core business logic)
  • Other cases — When deeper or multi-perspective review would add value

Always propose to the user and get approval before spawning agent teams.

Parallelization strategies:

Strategy Description Example
By aspect Each agent reviews a different quality dimension functionality, security, performance, code quality
By target Each agent reviews a different Task or component Agent A: T-login-api & T-signup-api, Agent B: T-token-refresh & T-logout-api
Cross-verification A separate agent validates the primary reviewer's findings Reduces false positives and missed issues

After parallel review, merge results into a single report in Step 4.


Step 4: Organize Review Results

Categorize findings:

Classification Criteria

Category Description Examples
🔴 Critical Immediate fix required, functional/security issues. Failure to meet goals or acceptance criteria is always Critical. Goal not met, acceptance criteria failed, bugs, security vulnerabilities, data loss risk
🟡 Improvement Would be better if improved, quality enhancement Refactoring candidates, performance improvements, readability
🟢 Minor Minor improvements Naming, comments, formatting
💡 Suggestion Future considerations New feature ideas, technical debt

Report results to user:

## Review Results: [Item name]

### 🔴 Critical (N items)
1. [Issue]: [Description]
   - Location: [File/location]
   - Impact: [Scope of impact]

### 🟡 Improvement (N items)
1. [Improvement]: [Description]
   - Current: [Current state]
   - Suggested: [Improvement direction]

### 🟢 Minor (N items)
- [Items...]

### 💡 Suggestion (N items)
- [Items...]

---
Would you like to create an improvement plan for Critical/Improvement items?

Step 5: Handle Findings

Mode A: Default — Create Improvement Tasks

Enter Plan Mode if Critical or Improvement items exist and user agrees.

There are items that need improvement.
Entering Plan Mode to create an improvement plan.

Content to write in Plan Mode:

# [Item Name] Improvement Plan

> This plan will be executed in the next session via `@INSTRUCTION.md`.
> Do not start improvement work immediately after plan approval.

## Review Summary
- Review target: [Task/Feature name]
- Issues found: Critical N, Improvement N

## Improvement Tasks

### Task 1: [Improvement item]
- Issue: [Current problem]
- Solution: [Specific solution]
- Scope: [Files/areas to modify]
- Completion criteria: [How to know it's done]

### Task 2: [Improvement item]
...

## Priority Order
1. [What to do first]
2. [Next...]

## Risks
- [Things to watch out for during improvement]

## Estimated Effort
- [Expected time/complexity]

Wait for user approval.

CRITICAL: In default mode, this skill only handles review and planning. It does NOT perform actual improvement work.

When the user approves the Plan:
1. Update BACKLOG.md (Step 6A)
2. End the skill

Mode B: Immediate-Fix — Fix Issues Directly

Fix all Critical, Improvement, and Minor issues in this session.

  1. For each issue (Critical first, then Improvement, then Minor):

- Identify the file and location - Apply the fix - Verify the fix is correct

  1. Run tests if applicable (coding type)
  2. Report results:
## Immediate-Fix Results

Fixed:
- 🔴 Critical: N/N items fixed
- 🟡 Improvement: N/N items fixed
- 🟢 Minor: N/N items fixed
- 💡 Suggestion: N items (skipped — future consideration)

Unfixable (if any):
- [Issue]: [Why it cannot be fixed]

Files modified:
- [list of files]

**In immediate-fix mode, do NOT modify sprint files (BACKLOG.md, HANDOFF.md, active/).
The Lead (orchestrator) handles sprint file updates.**


Step 6: Post-Action Updates

Step 6A: Default Mode — Post-Approval Updates

IMPORTANT: After user approval, only update files and end the skill. Do not start improvement work.

6A.1 Update BACKLOG.md

Add improvement Tasks:

- [x] T-login-api: Login API `done`
- [ ] T-fix-login-api-review: Fix review issues (T-login-api) `backlog`  ← newly added
  - [ ] T-fix-login-api-review.critical: [Critical improvement 1]
  - [ ] T-fix-login-api-review.improvement: [Improvement 1]

Reopen Feature (if Feature was in completed state):

- [ ] F-user-auth: Login System  ← changed from [x] to [ ]
6A.2 Update HANDOFF.md

Add to ## Context for Next Session:

**Review results to address:**
- [Item name] review found N improvement items
- Improvement Task: T-{task-slug}
- Work from Plan file - no Plan Mode needed

Step 6B: Immediate-Fix Mode — No Sprint File Updates

In immediate-fix mode, the skill ends after fixing issues and reporting results. Sprint file updates are handled by the Lead (orchestrator from /sprint:work-on-feature).

End the skill.


Step 7: Completion Report

Default Mode:

[Item name] review complete.

Review results:
- 🔴 Critical: N items
- 🟡 Improvement: N items
- 🟢 Minor: N items
- 💡 Suggestion: N items

Updated files:
- BACKLOG.md - Improvement Tasks added
- HANDOFF.md - Status reflected

Call @INSTRUCTION.md in your next session to start improvement work.

Immediate-Fix Mode:

[Item name] review and fix complete.

Review results:
- 🔴 Critical: N found, N fixed
- 🟡 Improvement: N found, N fixed
- 🟢 Minor: N found, N fixed
- 💡 Suggestion: N items (noted)

Files modified:
- [list]

[If unfixable issues exist:]
⚠️ Unfixable issues:
- [issue and reason]

Key Principles

  • Type-specific checklists — Different criteria for coding/docs/ideation/general
  • Classification and prioritization — Categorize findings by severity
  • Two execution modes — Default (create Tasks) for manual workflows, immediate-fix for automated orchestration
  • Default mode: Plan-based — Planned improvements, not ad-hoc fixes; create improvement Tasks
  • Immediate-fix mode: Direct action — Fix all fixable issues in-session; no sprint file modifications
  • Reopen Feature — Reopen if Feature was in completed state (default mode only)

Related Skills

  • /sprint:init - Sprint initialization
  • /sprint:add-backlog - Add backlog items
  • /sprint:plan-backlog - Design items in detail
  • /sprint:review-work - Same-session review, improve, and mark done
  • @INSTRUCTION.md - Execute improvement work

Example Usage

User: "Review T-login-api"

Claude:

  1. Understand sprint context (check T-login-api in BACKLOG.md)
  2. Check T-login-api type (coding)
  3. Load coding checklist
  4. Perform systematic review
  5. Categorize and report results
  6. (If issues found) Get user confirmation, enter Plan Mode
  7. Create improvement plan
  8. Wait for user approval
  9. After approval, add improvement Tasks to BACKLOG.md
  10. Report completion