review-core

Provides review-workflow scaffolding for context, evidence, and output. Use at the start of any detailed review to ensure consistent, comparable findings.

Ir a la instalación

Repositorio: athola/claude-night-market
Última actividad en el origen: 5 de junio de 2026 a las 21:45
Idioma detectado de SKILL.md: inglés
Estrellas: 327
Forks: 35

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

npx skills add https://github.com/athola/claude-night-market --skill review-core

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

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

review-core:context-established
review-core:scope-inventoried
review-core:evidence-captured
review-core:deliverables-structured
review-core:findings-verified
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.

Record Lessons Learned (decision journal)

If this work involved rework, a failed approach, or a blocker, record it to docs/lessons-learned.md so the insight survives past the session (draft and confirm):

If leyline is installed, invoke Skill(leyline:decision-journal) and append a lesson entry (what_happened, what_didnt_work, root_cause, action; set phase to review). Show the draft; append on confirmation.
Fallback (leyline absent): append to docs/lessons-learned.md using the in-file ENTRY TEMPLATE; assign the next LL-NNN id.

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 – Verify Findings Are Grounded (`review-core:findings-verified`)

Every finding must be falsifiable: a citation a second pass can mechanically re-read and confirm. Findings that fail verification do not ship.

Use the grounded-finding schema from Skill(imbue:structured-output): each finding carries a Location (file:line) and a verbatim Anchor snippet copied from that line.
Write the findings to .review/findings.json (one object per finding: id, file, line, anchor, severity, category, recommendation, evidence_refs).
Run the verifier:
```
python plugins/imbue/scripts/citation_verifier.py \
  --findings .review/findings.json --repo-root .
```
Exit 0 means every citation resolved; exit 1 lists each finding whose path, line, or anchor did not match the source.
Drop or label UNVERIFIED any finding the verifier failed; only verified findings enter the report. Attach the verifier output to the evidence appendix.
If the script is unavailable, fall back to re-reading each cited file:line by hand and confirming the anchor text is present; note the manual fallback in the contingency section.

Step 6 – 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).
Every reported finding carries a Location + verbatim Anchor and was confirmed by citation_verifier.py (or a documented manual re-read); no unverified findings ship.
.review/findings.json exists and the verifier exited 0, or every failed finding was dropped or labeled UNVERIFIED.
Domain-specific review can now assume consistent context/evidence/deliverable scaffolding and focus on specialized analysis.
Any rework, failed approach, or blocker uncovered during evidence capture is recorded to docs/lessons-learned.md (or the in-file template).

name	review-core
description	Provides review-workflow scaffolding for context, evidence, and output. Use at the start of any detailed review to ensure consistent, comparable findings.
alwaysApply	false
category	review-patterns
tags	["workflow","scaffolding","evidence","reporting","analysis"]
dependencies	[]
tools	[]
usage_patterns	["review-preflight","workflow-scaffolding","evidence-capture"]

name	review-core
description	Provides review-workflow scaffolding for context, evidence, and output. Use at the start of any detailed review to ensure consistent, comparable findings.
alwaysApply	false
category	review-patterns
tags	["workflow","scaffolding","evidence","reporting","analysis"]
dependencies	[]
tools	[]
usage_patterns	["review-preflight","workflow-scaffolding","evidence-capture"]

review-core

Datos de origen

Opciones de instalación

Revisa los archivos de origen

Más de este repositorio

Más de este repositorio

Core Review Workflow

Table of Contents

When To Use

When NOT To Use

Activation Patterns

Required TodoWrite Items

Step 1 – Establish Context (review-core:context-established)

Step 2 – Inventory Scope (review-core:scope-inventoried)

Step 3 – Capture Evidence (review-core:evidence-captured)