Review
Skill initxy/initxy-skills/skills/ai-native-engineering/review
Make any repo AI native — fewer skills, conventions over steps, so any agent can cold-start, implement, self-verify, and write its decisions back.
npx -y skills add initxy/initxy-skills --skill reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 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
Accept an implementation — gates first, then human judgment — deciding mergeability against the spec's acceptance criteria, and wrapping up with distillation and archiving. Use for review, checking a diff/PR, acceptance, or judging mergeability.
SKILL.md
2.6 KB, as published. Nobody here has run it
Review
Acceptance, not a line-by-line recheck. What a machine can check goes to the gates; this skill only makes the judgments the gates can't cover.
Prerequisites
- Run the automated gates defined in
AGENTS.mdfirst. Gates not green → reject immediately, no human review. - When the repo has no
AGENTS.mdor no defined gates, substitute its existing test / lint / build commands; if there's no runnable verification at all, say so honestly and write "verification missing" into the findings itself. - Find the corresponding spec (default: search
docs/specs/). With no requirement source, review by code quality and risk, and state clearly that requirement conformance can't be judged.
Review
- Against the acceptance criteria: check off each of the spec's Acceptance criteria, with evidence (test, output, code location); "should be fine" is not accepted.
- Check scope: any creep into Non-goals, any unrelated refactor mixed in.
- Check risks the gates can't cover: boundary conditions, data migration, compatibility, security, concurrency, error handling.
- Check tests: whether the critical path and failure path of new behavior are covered.
Findings
Sorted by severity, only actionable issues:
- [P1] Title
File/location:
Problem / Impact / Suggestion:
P0 data loss, serious security, core flow unusable; P1 must fix before merge; P2 boundary issue, test gap; P3 minor, non-blocking.
Verdict
One of three: mergeable / revise and re-review / needs re-shape. When there are no issues, say explicitly that no blocking issues were found.
Wrap-up distillation (when the verdict is mergeable)
- Flip the spec's status to
done, move it intodocs/specs/archive/. - Stable terms and system boundaries that emerged during implementation go into
CONTEXT.md; long-term decisions go into an ADR, with any overturned old ADR markedsuperseded. - If this was a large feature, suggest a scoped
gcover the changed area.
Completion criteria
- Gate results confirmed; each acceptance criterion has evidence.
- Every finding has a clear impact and suggestion; no style preference disguised as a defect.
- The verdict directly supports the next action.
- When mergeable, distillation and archiving are done or explicitly listed as pending.