Review code
Stack-agnostic agentic-programming workflow skills + documentation scaffold
npx -y skills add gtrabanco/agentic-workflow --skill review-codeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Internal correctness + simplification review pass of the agentic-workflow review pack — composed in-turn by review-change and product-audit; not a menu entry. Checks correctness, error handling, duplication, dead code, and simplification opportunities against the project's own conventions. Findings only; never edits code.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.6 KB, as published. Nobody here has run it
Review Code (internal)
Composed by review-change / product-audit within their conversation — on any
agent, follow this file inline as the routed step. Findings only; never edits,
never refactors.
Scope
The diff or path/glob the caller passes; default the current change vs the default branch. State the scope at the top of the returned table.
Checklist (evaluate EVERY item — none is optional; n/a must be stated)
✓ No logic errors on the changed paths (trace each modified function's inputs → outputs, including boundary values) ✓ Every error path is handled — no swallowed exceptions, no empty catch, no silently-ignored return codes ✓ No duplicated logic (a changed block does not re-implement an existing helper — cite the existing one if it does) ✓ No dead code introduced (unused functions, params, imports, unreachable branches) ✓ No leftover TODO/FIXME/HACK markers in the diff ✓ Naming and file conventions match the project's docs (read them first; cite the convention violated) ✓ No new abstraction beyond what the SPEC requires (an interface/base class with one implementation is a finding) ✓ No new dependency not justified in the SPEC ✓ Simplification: any changed block that can lose lines without losing behavior (cite before/after) ✓ Edge cases the SPEC's dev scenarios name are actually handled in code, not just in tests
Return exactly
REVIEW CODE — scope: <scope>
| # | Finding | Sev | Evidence | Suggested fix |
|---|---------|-----|----------|---------------|
| 1 | <what> | critical|major|minor | <file:line> | <smallest action> |
Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAIL
FAIL if any critical or major finding is open; PASS otherwise. Minor findings never block — they route to the caller's triage step.
Done when
- Every checklist item was evaluated with evidence (file:line or command output) or explicitly marked n/a with the reason.
- The fixed-format block above is returned — nothing more, nothing less — and no code was changed.