home / skills / athola / claude-night-market / review-core

review-core skill

/plugins/imbue/skills/review-core

This skill initiates detailed reviews with a consistent structure for context, evidence, and deliverables, enabling comparable findings across architectures

npx playbooks add skill athola/claude-night-market --skill review-core

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.6 KB
---
name: review-core
description: 'Use this skill at the BEGINNING of any detailed review for consistent
  structure. Use when starting any detailed review workflow, needing consistent structure
  for capturing context and findings, ensuring comparable review outputs. Do not use
  when quick catchup without formal review - use catchup. DO NOT use when: diff-focused
  analysis - use diff-analysis.'
category: review-patterns
tags:
- workflow
- scaffolding
- evidence
- reporting
- analysis
dependencies: []
tools: []
usage_patterns:
- review-preflight
- workflow-scaffolding
- evidence-capture
complexity: intermediate
estimated_tokens: 1500
---

# Core Review Workflow

## Table of Contents

1. [When to Use](#when-to-use)
2. [Activation Patterns](#activation-patterns)
3. [Required TodoWrite Items](#required-todowrite-items)
4. [Step 1 – Establish Context](#step-1--establish-context-review-corecontext-established)
5. [Step 2 – Inventory Scope](#step-2--inventory-scope-review-corescope-inventoried)
6. [Step 3 – Capture Evidence](#step-3--capture-evidence-review-coreevidence-captured)
7. [Step 4 – Structure Deliverables](#step-4--structure-deliverables-review-coredeliverables-structured)
8. [Step 5 – Contingency Plan](#step-5--contingency-plan-review-corecontingencies-documented)
9. [Troubleshooting](#troubleshooting)

## When To Use
- Use this skill at the beginning of any detailed review workflow (e.g., for architecture, math, or an API).
- It provides a consistent structure for capturing context, logging evidence, and formatting the final report, which makes the findings of different reviews comparable.

## When NOT To Use

- Diff-focused analysis - use diff-analysis

## Activation Patterns
**Trigger Keywords**: review, audit, analysis, assessment, evaluation, inspection
**Contextual Cues**:
- "review this code/design/architecture"
- "conduct an audit of"
- "analyze this for issues"
- "evaluate the quality of"
- "perform an assessment"

**Auto-Load When**: Any review-specific workflow is detected or when analysis methodologies are requested.

## Required TodoWrite Items
1. `review-core:context-established`
2. `review-core:scope-inventoried`
3. `review-core:evidence-captured`
4. `review-core:deliverables-structured`
5. `review-core:contingencies-documented`

## Step 1 – Establish Context (`review-core:context-established`)
- Confirm `pwd`, repo, branch, and upstream base (e.g., `git status -sb`, `git rev-parse --abbrev-ref HEAD`).
- Note comparison target (merge base, release tag) so later diffs reference a concrete range.
- Summarize the feature/bug/initiative under review plus stakeholders and deadlines.

## Step 2 – Inventory Scope (`review-core:scope-inventoried`)
- List relevant artifacts for this review: source files, configs, docs, specs, generated assets (OpenAPI, Makefiles, ADRs, notebooks, etc.).
- Record how you enumerated them (commands like `rg --files -g '*.mk'`, `ls docs`, `cargo metadata`).
- Capture assumptions or constraints inherited from the plan/issue so the domain-specific analysis can cite them.

## Step 3 – Capture Evidence (`review-core:evidence-captured`)
- Log every command/output that informs the review (e.g., `git diff --stat`, `make -pn`, `cargo doc`, `web.run` citations). Keep snippets or line numbers for later reference.
- Track open questions or variances found during preflight; if they block progress, record owners/timelines now.

## Step 4 – Structure Deliverables (`review-core:deliverables-structured`)
- Prepare the reporting skeleton shared by all reviews:
  - Summary (baseline, scope, recommendation)
  - Ordered findings (severity, file:line, principle violated, remediation)
  - Follow-up tasks (owner + due date)
  - Evidence appendix (commands, URLs, notebooks)
- validate the domain-specific checklist will populate each section before concluding.

## Step 5 – Contingency Plan (`review-core:contingencies-documented`)
- If a required tool or skill is unavailable (e.g., `web.run`), document the alternative steps that will be taken and any limitations this introduces. This helps reviewers understand any gaps in coverage.
- Note any outstanding approvals or data needed to complete the review.

## Exit Criteria
- All TodoWrite items complete with concrete notes (commands run, files listed, evidence paths).
- Domain-specific review can now assume consistent context/evidence/deliverable scaffolding and focus on specialized analysis.
## Troubleshooting

### Common Issues

**Command not found**
Ensure all dependencies are installed and in PATH

**Permission errors**
Check file permissions and run with appropriate privileges

**Unexpected behavior**
Enable verbose logging with `--verbose` flag

Overview

This skill establishes a consistent starting point for any detailed review workflow. It standardizes how context, scope, evidence, deliverables, and contingencies are captured so different reviews are comparable and actionable. Use it at the start of architecture, API, or code reviews to make downstream analysis more focused and reproducible.

How this skill works

The skill guides a five-step intake: confirm repo and branch context, enumerate relevant artifacts, capture command outputs and evidence, assemble a structured deliverable skeleton, and record contingency plans. It requires writing five TodoWrite flags as checkpoints to ensure each stage is completed. The output is a reproducible review scaffold that domain-specific analysis can consume.

When to use it

  • Starting any detailed review (architecture, API, code, design)
  • When you need consistent context and evidence across reviews
  • When producing an auditable report with findings and follow-ups
  • When reviews must be comparable over time or across teams
  • When handing off a review to another analyst or stakeholder

Best practices

  • Run repository commands (git status, git rev-parse) and record outputs verbatim for traceability
  • Enumerate artifacts with explicit commands and include file lists or globs used
  • Log all investigative commands and save snippets or line references for evidence
  • Populate the deliverable skeleton early: summary, ordered findings, follow-ups, evidence appendix
  • Document fallback steps when tools or data are unavailable and list outstanding approvals

Example use cases

  • Begin an API security audit by establishing branch, target tag, and listing OpenAPI artifacts
  • Start an architecture review with clear stakeholder, deadline, and the set of diagrams and ADRs to examine
  • Prepare a code quality assessment by recording file lists, lint outputs, and test runs for evidence
  • Create a reproducible bug investigation by capturing commands, failing test cases, and environment details
  • Hand off a review to a teammate with a ready-made deliverable skeleton and evidence appendix

FAQ

When should I not use this skill?

Do not use this skill for quick catchups or diff-focused analysis; use a lightweight catchup flow or a diff-analysis workflow instead.

What are the required checkpoints?

Complete these TodoWrite items: context-established, scope-inventoried, evidence-captured, deliverables-structured, contingencies-documented.