review-results

Review existing git-slop report and health artifacts, explain detector and overlay evidence, and optionally turn one explicitly selected finding into a bounded maintenance proposal. Use when a user asks what results mean, which findings are actionable, or wants a plan from a reviewed finding; do not use merely to generate a fresh report.

Jump to install

Repository: coreycoto/git-slop
Last source activity: August 26, 2026 at 19:41
Detected SKILL.md language: English
Stars: 5
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/coreycoto/git-slop --skill review-results

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer

5 files

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

Review Git Slop Results

Start from an existing .slop/latest/report.json, report.yaml, summary.md, or health.md artifact.

Interpret The Evidence

Treat git-slop as a detector and evidence surface, not a correctness oracle.

Keep hotspot costs separate from overlay evidence. Use slop_score, slop_band, and context_band for the stable hotspot queue.

Use health file/folder bands, distributions, watchlists, and concentration metrics as human-facing rollups of existing facts, not as a second score.

Treat health output as advisory: findings do not change the command's success status or the stable check gate.

Use overlays only as supporting evidence about organization, verification, navigation, blast radius, stewardship, and concept dispersion.

Follow a finding's deterministic next_command, or run a targeted git-slop explain, before recommending work.

Treat budget_exceeded as a threshold label and review candidate, not an automatic mandate to change code.

Give each reviewed finding one explicit disposition: implement, consolidate, defer, accept, or won't fix. Do not optimize for closing every finding.

Stop after explaining and prioritizing the evidence unless the user explicitly asks for a maintenance proposal.

Plan One Reviewed Finding

When the user explicitly selects a finding for planning, read the maintenance-planning reference and follow it for that finding only.

If the proposal would add or promote a command, option, configuration key, schema, output, Action contract, Agent Plugin surface, workflow, integration, or compatibility promise, also read the contract-admission reference. Apply its state model, admission test, and surface-area ledger before recommending implementation.

Preserve Generated-State Boundaries

Treat .slop/latest/, .slop/runs/, .slop/cache/, SARIF, prompt packs, plan JSON, and compare JSON as generated evidence. Reference or upload a bounded artifact when useful; do not commit routine generated output.