Gjalla code review
Opinionated, time-tested agent skills for trustworthy, production-grade engineering — spec-driven planning, rigorous review, and test auditing for the agentic SDLC.
npx -y skills add gjalla/engineering --skill gjalla-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 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
Review a code change (diff or PR) for ship-readiness before merge. Use when reviewing your own or someone else's changes prior to committing/merging/etc.
SKILL.md
2.3 KB, as published. Nobody here has run it
Code Review
Your task is to review the code changes as a team lead with extremely high standards. You care about: simple, elegantly-designed, maintainable code; code which meets the expectations and verification criteria; code which is well-tested, robust, secure, and production-ready; and code that balances everything you know about the end user, the company, and the feature.
Approach
- Understand intent: what is this change supposed to do? (PR description, linked spec, commit messages.)
- Put yourself in the shoes of multi-faceted reviewers based on what is relevant to this change. For instance, the perspective of a senior software engineer who is skilled at code correctness / edge cases / bugs / dead code, a product manager who is great at user experience and voice of the user, a QA engineer looking for quality and maintainability, a customer success manager responsible for implementation and value delivery, a security analyst looking for data access / privacy / security / vulnerabilities, an architect, etc.. No need to a) use all of these personas or b) use only these personas. Instead, using the context of this change, determine what the most helpful, adversarial, and gap-filling approach would be and take it.
- From each perspective, review the diff in full, using second order thinking (what collateral, implicit, or second-order implications do these changes have?) and fresh eyes.
- Based on what you've found, what is the priority of these items within the context of this user/product/company?
Output
Group findings by severity:
- Blocking — must fix before merge (correctness, security, data loss).
- Should fix — quality/maintainability issues worth addressing now.
- Nit — optional polish.
For each finding: file:line, what's wrong, and a concrete suggested fix. State what you verified and what you could not.
Principles
- Review the code that's there AND what's missing — the dangerous bug is usually the unhandled case, not the wrong line.
- Be specific: a finding without a location and a fix is noise.
- Approve only what you understand. If you can't tell whether it's correct, say so rather than rubber-stamping.