| name | feedback-loops |
| description | Run the project's verification commands before claiming work complete. Use ALWAYS when finishing a task, claiming work done, committing, or creating a PR. Blocks completion until all checks pass. |
This project has specific verification commands that MUST pass before work is considered complete. These are the project's feedback loops — automated checks that catch regressions, style violations, type errors, and broken tests.
The Rule
Do not claim work is done, commit code, or create a PR unless you have run the project's feedback loops and every command passed.
If any command fails, the task is not complete. Fix the failures first, re-run the full checklist, and only then claim completion.
When This Skill Fires
- You are about to say "done", "complete", "finished", "ready for review", or "ready to merge"
- You are about to run
git commit or create a commit via any tool
- You are about to run
gh pr create or open a PR
- You are reporting a task status as DONE in any workflow or plan
In all of these moments: stop, run the checklist below, report pass/fail for each, fix any failures, then continue.
The Checklist
{{ $feedback_loops_checklist }}
How to Run
- Run each command in order, from the project root
- Capture the exit code for each
- If a command fails, read the output, fix the issue, then re-run from the start
- Do NOT skip commands or claim "probably passes" — run them
- Do NOT edit test assertions to make failing tests pass — fix the underlying code
Reporting Results
When you report on your work (in a PR body, completion message, or task update), include the feedback loop status. Example:
Feedback loops:
✓ composer test
✓ composer analyse
✓ composer format --test
If a command is intentionally skipped (e.g., no changes to frontend → skipping npm run types), note that explicitly.
Common Mistakes
- Claiming done without running the loops. Even if "the change is small" — run them.
- Fixing only the failing test instead of the underlying code. A failing test usually indicates a real problem.
- Ignoring warnings. Warnings from static analysis tools (PHPStan, Pint) are loops output and count as failures.
- Running only some of the commands. Run all of them. Each one catches different problems.