review

Solid

adversarial read-only code review grading documented claims against reality (saves scorecard to .construct/)

Code & Development 3 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 82/100

Stars 20%
20
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

**documented claims measured against reality:** a scorecard that never flatters you - strictly read-only, and it never flatters the user - punishes hand-wavy conventions and unearned "green ci" claims - produces a graded scorecard saved to file, not a chat reply # Instructions ## Telemetry ```! "${CLAUDE_PLUGIN_ROOT}"/skills/review/review.sh $ARGUMENTS echo "sidecar exit: $?" ``` - `help: requested` → the run was refused before it started; `## Help` below is the whole turn - it already ran, so there is no command to issue - fail (`sidecar exit` > 0) → abort and report: "<raw terminal error>" - success (`sidecar exit` = 0) → continue 1. read the core foundational documents to learn the "claims": - read `README.md`, which always exists and always carries claims worth grading - read `AGENTS.md` IF it exists, for project rules and automation descriptions - host projects ship one, so there it is a required read and its rules are fair game - this repo does not, since `AGENTS.md` is generated and project agnostic here - absent → say so in the scorecard rather than grading claims it never made 2. evaluate the shell telemetry against the documented claims using these dimensions: - **effort vs output:** does the sheer volume of commits/days justify the actual features shipped? does infrastructure/config LOC rival the actual application LOC? - **claim vs reality:** do the docs lie? if `AGENTS.md` claims strict commit types, does the git log reflect that? - **t...

Details

Author
MaisonDeVolonte
Repository
MaisonDeVolonte/construct
Created
1 months ago
Last Updated
today
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

code-review

Review the changes since a fixed point (commit, branch, tag, PR, or merge-base) on two axes — Standards (does it follow this repo's documented rules?) and Spec (does it do what the originating issue asked?). Each axis returns a verdict per enumerated item rather than an open-ended list of findings, so a round terminates. Use when the user wants to review a branch, a PR, working-tree changes, or asks to "review since X"; and again after fixes, to review the fix.

20 Updated today
ConnorGriffin
Code & Development Featured

review

Use after writing code to get a thorough code review. Runs two passes — structural correctness then adversarial edge-case hunting. Scales depth by diff size. Supports --quick, --standard, --thorough modes. Triggers on /review.

206 Updated yesterday
garagon
Code & Development Listed

code-review

Use when the user wants a code review of a branch, PR, MR, or working diff against its acceptance criteria and declared scope, in whatever form they take in this repo. Triggers on "review my branch", "review this PR", "check this diff before I raise it", "is this ready to merge". Works with any language, delivery process, or issue tracker. Produces a structured verdict with blocking, warning, and suggestion findings; writes no source changes. Do NOT use to address or fix review findings (code-review-fix), to implement work (implement), to publish a review to a provider as its reviewer (merge-request-review), to sign off completion of a larger body of work (validate), or to review rendered UI (ux-design-review).

2 Updated 3 weeks ago
carinyaparc