pekral

Use when reviewing HTTP API design in a PR or change set — endpoints, routes, HTTP methods, status codes, idempotency, and input validation. Treats the API as a consumer-facing contract and flags resource-orientation, method-semantics, status-code, and trust-boundary violations. Read-only.

Use when checking that the pull request implementation actually fulfills the business requirements stated in the linked issue or task. Returns a plain-language markdown block that is the Functional review half of the two-part CR output (`@rules/code-review/general.mdc` Two-part CR output — Technical & Functional review): a full checklist of every extracted acceptance criterion with its status (Met / Not met / Partial / Divergent) and an explicit Goal met: Yes/No verdict, rendered on every run that has a linked tracker — including the fully affirmative report when every requirement is satisfied. No local file is created and the block is not embedded in the GitHub PR comment.

Use when run code review for a Bugsnag error and publish results to the linked GitHub PR and the Bugsnag error

Use when perform code review for GitHub pull requests and post findings as PR comments plus a non-technical summary to every linked issue

Use when run code review for JIRA issues and publish results to GitHub PR and JIRA

Use when senior PHP code review focused on architecture, business logic, and risk detection. Read-only.

Use when summarizing current PR changes for the development and product team. Analyzes all commits in the current branch, explains the purpose of changes, and produces a clear human-readable report that can be posted either as a GitHub PR comment (Markdown) or as a JIRA comment (Wiki Markup).

Use when a single objective is too large for one pull request and must span multiple sessions or PRs. Turns the objective into a sequenced construction plan of 3-12 one-PR steps, each with a cold-start context brief, dependency edges, and exit criteria, then reviews it adversarially and registers it as Markdown.

Use when you need an evidence-first, read-only inventory of every automation in this repo (GitHub Actions, Claude Code hooks/settings, MCP servers, composer scripts, the bundled CLI installer, the skills catalog, scheduler/cron) before changing any of them, classifying each as live, broken, or redundant and recommending keep/merge/cut/fix.

Use when choosing how to run Claude Code autonomously on this project — from a single sequential pipeline to multi-agent DAG orchestration. A reference catalog of loop patterns anchored to this repo's real tooling (resolve-issue, autoresolve-oldest-github-issue, code-review-github, process-code-review, merge-github-pr, /loop), with composer build / composer skill-check as the quality gate between iterations.

Use when a goal is vague speed ("make it faster", "reduce p95", "cut query time") and you need a bounded, measured loop that promotes only verified, correctness-preserving wins instead of guessed micro-tweaks.

Use when measuring performance baselines or detecting regressions before and after a change in a Laravel app — page Core Web Vitals, API latency percentiles, build/test velocity, and DB query timing, stored as git-tracked baselines for team comparison.

Use when a single objective is too large for one pull request and must span multiple sessions or PRs. Turns the objective into a sequenced construction plan of 3-12 one-PR steps, each with a cold-start context brief, dependency edges, and exit criteria, then reviews it adversarially and registers it as Markdown.

Use when refactor PHP classes to improve structure, readability, and maintainability while preserving behavior

Use when run code review for a Bugsnag error and publish results to the linked GitHub PR and the Bugsnag error

Use when perform code review for GitHub pull requests and post findings as PR comments plus a non-technical summary to every linked issue

Use when analyzing problems from issue trackers. Downloads and reviews attachments, provides technical analysis and solutions, and creates human-readable explanations for both technical and non-technical audiences.

Use when refactoring PHP classes following Laravel best practices and SOLID principles. Ensures code quality, maintains functionality, improves testability, and achieves 100% code coverage. Focuses on single responsibility, DRY principle, and clean code structure.

Use when performing code review for GitHub pull requests. Analyzes code changes, identifies critical and moderate issues, runs tests, and posts review comments. Reviews code quality, security, and adherence to project standards.

Use when performing code review for JIRA issues. Analyzes pull requests, identifies critical and moderate issues, runs tests, and posts review comments to GitHub PRs. Reviews code quality, security, and adherence to project standards.

Senior PHP code reviewer. Use when reviewing pull requests, examining code changes vs master branch, or when the user asks for a code review. Read-only review — never modifies code.

Use when the user ran composer update and wants to check for package conflicts and get a summary of changelogs from updated packages.

Create an issue in a generic issue tracker from the provided task description. Use when the user asks to open an issue. Preserve the original task content exactly and only improve formatting for readability.

Reads your pull request code review, verifies that all recommended test coverage is implemented in the codebase, and adds missing tests using the create-test skill. Use when a PR review already exists and missing tests must be completed with 100% coverage for current changes.

Use when structured problem analysis for debugging, root cause identification, and breaking down complex issues before proposing solutions

Analyze issue and pull request discussions, find unanswered current questions, and prepare concise unified answers for project managers or clients in plain language. Use when stakeholders need non-technical answers from GitHub issue/PR threads.

Use when preparing a JIRA issue draft from GitHub pull request context while preserving the original assignment text and making the output understandable for both AI agents and non-technical stakeholders.

Use when reviewing composer.json packages. Validates structure, checks required fields, verifies links, and ensures proper configuration of autoloading, dependencies, and metadata.

Use when AI creates or modifies API endpoints and you need to generate or update Postman collections, keep request examples aligned with routes, and verify the collection is importable and runnable.

Use when reviewing code for race conditions, concurrency issues, and shared-state consistency problems. Analyzes read-modify-write patterns, concurrent access to shared resources, and missing atomicity guards. Provides structured findings with severity levels and concrete fixes.

Use when resolving Bugsnag issues. Fixes bugs, refactors code, performs code and security reviews, ensures 100% test coverage, runs CI checks, and creates pull requests. Updates GitHub issues with review results.

Use when resolving Github issues. Fixes bugs, refactors code, performs code and security reviews, ensures 100% test coverage, runs CI checks, and creates pull requests. Updates GitHub issues with review results.