mit einem Klick
review-pr
// Use this when the user says "review this PR", "valide esse PR" (pt-BR) or anything associated with the idea of validating a task.
// Use this when the user says "review this PR", "valide esse PR" (pt-BR) or anything associated with the idea of validating a task.
Use ONLY when the user explicitly asks to open a PR — phrases like "open a PR", "abra um PR" (pt-BR), "abra um pull request" (pt-BR), "mande pra 3.x", "send the PR". Never trigger this skill on your own initiative, including under auto mode or after finishing a task. Wait for the explicit request.
Use when user says "validate the task", "ensure everything is passing", "is everything ok?", "valide a entrega" (PT-BR), "garanta que tudo está funcionando" (PT-BR), "certifique-se de que está tudo ok" (PT-BR), or anything associated with the idea of validating a task.
| name | review-pr |
| description | Use this when the user says "review this PR", "valide esse PR" (pt-BR) or anything associated with the idea of validating a task. |
This branch is part of a PR submitted by a TallStackUI user. I would appreciate your review to ensure that all code conforms to my preferred writing style. Please validate all changes in this branch, ensuring that everything mentioned below is correct.
If you find anything that doesn't conform to my standards, please mention it so I can correct it, or suggest a correction based on all the explanations mentioned here.
Component properties should follow the camel case:
Wrong ❌
class Component extends TallStackUiComponent implements Customization
{
public function __construct(public ?string $simplevisual = null)
{
//
}
}
Correct ✅
class Component extends TallStackUiComponent implements Customization
{
public function __construct(public ?string $simpleVisual = null)
{
//
}
}
Furthermore:
Ensure that property names make sense in relation to their intended purpose.
Ensure that class constructors are not too large.
Ensure that property/attribute names are not too "strange" or "unusual" – I have personal issues accepting property names like $activeUsersCount. Therefore, I prefer names like $count, when possible and there are no conflicts.
Ensure that the following validations are passing:
./vendor/bin/pest --type-coverage, ./vendor/bin/pint --test --parallel and ./vendor/bin/phpstan analyse --memory-limit=2G and php scripts/find-unused-customization-blocks.php are passing successfully. If they do not pass, suggest corrections for the errors described.Ensure that the code was written in JavaScript and that the npm run lint and npm run build validations are passing successfully. If they do not pass, suggest corrections for the errors described.
Validate Feature tests using: ./vendor/bin/pest --parallel --group Feature
We need to divide this into two parts:
If the changes involve things like HTML, ensure that the organization is correctly applied, according to the indentation of spaces in relation to the HTML tags of the blocks themselves.
If the changes involve AlpineJS, ensure that:
If the changed/inserted AlpineJS logic is small, it can reside in the Blade file itself.
If the AlpineJS logic is large (or if explicitly requested by me), it must be inserted into a separate alpine.js file, stored in the namespace of the inserted/changed component by the branch.
Ensure that there are no .md files added by the PR, such as: documentation, explanations, and things of that nature.
Ensure that what has been done makes sense and that there is nothing wrong with it, ESPECIALLY in relation to business rules OR performance.
Ensure that tests were added for the new functionality. If not, suggest adding them to validate if what has been done is correct.