Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

subagent-review

Étoiles28

Forks1

Mis à jour12 juillet 2026 à 00:16

Keep reviews light by running quick spec and quality checks after each task before claiming completion.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

jesscss

jesscss/jess

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	subagent-review
description	Keep reviews light by running quick spec and quality checks after each task before claiming completion.

Subagent Review Checklist

Use this skill when you’re wrapping up a discrete task (bug fix, feature, doc cleanup). It does not spawn subagents, but it reminds you to run the minimal spec and quality verifications that an independent reviewer would otherwise do.

When to apply

You’ve just finished coding/testing a change and are about to say “this task is done” or “tests/build pass.”
You want to mimic the two-stage review (spec + quality) described by superpowers/subagent-driven-development without spinning up parallel agents.

Mini two-stage review

Spec sanity check – Re-read the requirements/plan for this task. Ask: “Does the behavior still match the plan?” Run or re-run the focused test, reproduce the edge case, or verify the command that proves the spec.
Quality check – Run git status, lint, or formatting checks relevant to the touched files. Scan the diff for clarity, remove boilerplate comments, and double-check there are no stray console.log calls or .only.
Document review outcome – Record the commands run and their pass/fail status (e.g., pnpm test -- --run ... (0 failures), git status -sb (clean)). Mention both the spec check and quality scan before claiming completion.

Anti-patterns

Skipping git status / diff review because “I remember it was clean.”
Claiming success without explicitly noting both a spec-focused check and a quick quality check.
Relying on mental review alone—write down the commands you ran so you can cite them later.

Project context

Use the skill in tandem with systematic-debugging (if applicable) and verification-before-completion.
The “spec check” command is often the focused Vitest suite for extend/core tasks; quality check is usually git status -sb + lint (per .cursor/rules/30-tests.mdc).

Plus depuis ce dépôt

même dépôt

perf-architecture

jesscss/jess

Load BEFORE writing or changing code on Jess hot paths (core tree/eval/render, grammar/parser, extend/selector algorithms). Packages the 9 V8-architecture invariants as pre-write checks and points at the canonical checklist.

2026-07-2328

fixture-driven-dev

jesscss/jess

Use when working with fixture-based or expected-output tests (especially Less test-data). Helps isolate one fixture, reproduce deterministically, update expectations safely, and avoid cross-package build pitfalls.

2026-07-2228

api-surface-safety

jesscss/jess

Use when changing exports, entrypoints, or shared types across packages. Ensures public API stability, correct ESM/CJS surface, and cross-package build/test validation.

2026-07-1228

perf-sanity

jesscss/jess

Use when changing perf-sensitive codepaths (parsing, selector/extend algorithms). Provides a lightweight sanity protocol and avoids ungrounded perf claims.

2026-07-1228

systematic-debugging

jesscss/jess

Use a strict observe-hypothesize-trace-verify-fix loop when debugging; avoid random changes and context loss. Use when the user is debugging, investigating a failure, or fixing a bug.

2026-07-1228

verification-before-completion

jesscss/jess

Run and read the verification command every time before claiming success. Use when you are about to report a fix, tests/builds passing, or task completion.

2026-07-1228

name	subagent-review
description	Keep reviews light by running quick spec and quality checks after each task before claiming completion.

Subagent Review Checklist

When to apply

You’ve just finished coding/testing a change and are about to say “this task is done” or “tests/build pass.”
You want to mimic the two-stage review (spec + quality) described by superpowers/subagent-driven-development without spinning up parallel agents.

Mini two-stage review

Spec sanity check – Re-read the requirements/plan for this task. Ask: “Does the behavior still match the plan?” Run or re-run the focused test, reproduce the edge case, or verify the command that proves the spec.
Quality check – Run git status, lint, or formatting checks relevant to the touched files. Scan the diff for clarity, remove boilerplate comments, and double-check there are no stray console.log calls or .only.
Document review outcome – Record the commands run and their pass/fail status (e.g., pnpm test -- --run ... (0 failures), git status -sb (clean)). Mention both the spec check and quality scan before claiming completion.

Anti-patterns

Skipping git status / diff review because “I remember it was clean.”
Claiming success without explicitly noting both a spec-focused check and a quick quality check.
Relying on mental review alone—write down the commands you ran so you can cite them later.

Project context

Use the skill in tandem with systematic-debugging (if applicable) and verification-before-completion.
The “spec check” command is often the focused Vitest suite for extend/core tasks; quality check is usually git status -sb + lint (per .cursor/rules/30-tests.mdc).