Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

check-and-fix

Run project checks from repo-root `CHECKLIST.md` and fix task-related failures, including skipped tests. Use when the user asks to run checks, lint and fix, or verify code quality.

Executar no Manus

Estrelas0

Forks0

Atualizado8 de junho de 2026 às 09:01

Fonte

MuhammedAlkhudiry

MuhammedAlkhudiry/my-setup

Abrir repositório GitHub Ver repositórios do creator

Comando de instalação

Download

Executar no Manus

Explorador de arquivos

3 arquivos

SKILL.md

readonly

name	check-and-fix
description	Run project checks from repo-root `CHECKLIST.md` and fix task-related failures, including skipped tests. Use when the user asks to run checks, lint and fix, or verify code quality.

Check and Fix

Checklist First

Repo-root CHECKLIST.md is the source of truth for verification commands.

If CHECKLIST.md exists, read it first and use its commands.
If it is missing, create it from real repo config such as Makefile, package.json, composer.json, pyproject.toml, or tool configs.
Follow CHECKLIST.md for the file shape.
Update it only when a stable project-wide command is missing, wrong, or stale.
Run task-specific checks separately without adding them to CHECKLIST.md.

Command Selection

To discover stable candidates quickly, run:

bun "$HOME/.agents/skills/check-and-fix/scripts/discover-checks.ts" /path/to/repo

Prefer repo-level commands such as mise run check or make check when they cover the needed categories.
Use exact runnable commands, not guesses or alternatives.
Prefer built-in parallel forms such as php artisan test --parallel.
Keep CHECKLIST.md as plain commands, one per line, with # comments only when useful.
Include real verification tools beyond lint/tests when the repo uses them.
Do not include build commands unless the repo explicitly treats build as verification.
If verification depends on git hooks, inspect existing setup first: .githooks, .husky, .pre-commit-config.yaml, lefthook.yml, package scripts, or install docs.
Prefer the documented setup command; if only .githooks exists, use git config core.hooksPath .githooks.
Do not create new hooks unless the user explicitly asks.

Fix Loop

Run the relevant checklist command.
Read the exact failure.
Fix only issues related to the current task or directly blocking clean output, including unexpected skipped tests.
Re-run the same command.
Continue until all relevant checks pass or a real blocker remains.

Rules

Use safe auto-fix commands from repo scripts when available.
Do not skip a checklist item without saying why.
Report pre-existing unrelated failures instead of widening scope.
Final report lists each checklist item as PASS, FAIL, or BLOCKED.

Mais deste repositório

mesmo repositório

bug-learning

MuhammedAlkhudiry/my-setup

Use after fixing or investigating a hard-earned bug that took significant debugging, crossed multiple files or systems, had misleading symptoms, or revealed durable system behavior worth preserving in docs/knowledge/learnings.

2026-06-080

dependency-upgrade

MuhammedAlkhudiry/my-setup

Systematically upgrade project dependencies. Use for Composer, npm, bun, pnpm, yarn, lockfile updates, security updates, Laravel/PHP upgrades, React/JavaScript upgrades, framework bumps, package modernization, or dependency cleanup.

2026-06-080

project-knowledge

MuhammedAlkhudiry/my-setup

Use when answering questions about a project feature, documenting existing functionality, investigating product behavior, or maintaining docs/knowledge feature packs, glossary terms, aliases, key files, and feature history.

2026-06-080

workshop

MuhammedAlkhudiry/my-setup

Stress-test and challenge ideas before building. Use when the user wants to think through code architecture, UX/UI, or product direction before implementation.

2026-06-080

product-strategy

MuhammedAlkhudiry/my-setup

Find high-leverage product opportunities. Use when the user wants product strategy, asks what would make something 10x better, or wants to decide what to build next.

2026-06-080

planning

MuhammedAlkhudiry/my-setup

Create, review, refine, or execute conversational plans before implementation. Use when the user asks for a plan, implementation plan, roadmap, task breakdown, sequence, scope, phases, or multi-step work. For uncertain architecture, product, UX, or pre-implementation direction, apply the workshop skill first.

2026-06-080

Check and Fix

Checklist First

Repo-root CHECKLIST.md is the source of truth for verification commands.

If CHECKLIST.md exists, read it first and use its commands.

If it is missing, create it from real repo config such as Makefile, package.json, composer.json, pyproject.toml, or tool configs.

Follow CHECKLIST.md for the file shape.

Update it only when a stable project-wide command is missing, wrong, or stale.

Run task-specific checks separately without adding them to CHECKLIST.md.

Command Selection

To discover stable candidates quickly, run:

bun "$HOME/.agents/skills/check-and-fix/scripts/discover-checks.ts" /path/to/repo

Prefer repo-level commands such as mise run check or make check when they cover the needed categories.

Use exact runnable commands, not guesses or alternatives.

Prefer built-in parallel forms such as php artisan test --parallel.

Keep CHECKLIST.md as plain commands, one per line, with # comments only when useful.

Include real verification tools beyond lint/tests when the repo uses them.

Do not include build commands unless the repo explicitly treats build as verification.

If verification depends on git hooks, inspect existing setup first: .githooks, .husky, .pre-commit-config.yaml, lefthook.yml, package scripts, or install docs.

Prefer the documented setup command; if only .githooks exists, use git config core.hooksPath .githooks.

Do not create new hooks unless the user explicitly asks.

Fix Loop

Run the relevant checklist command.

Read the exact failure.

Fix only issues related to the current task or directly blocking clean output, including unexpected skipped tests.

Re-run the same command.

Continue until all relevant checks pass or a real blocker remains.

Rules

Use safe auto-fix commands from repo scripts when available.

Do not skip a checklist item without saying why.

Report pre-existing unrelated failures instead of widening scope.

Final report lists each checklist item as PASS, FAIL, or BLOCKED.