Run any Skill in Manus with one click

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.

Run Skill in Manus

Stars0

Forks0

UpdatedJune 8, 2026 at 09:01

Source

MuhammedAlkhudiry

MuhammedAlkhudiry/my-setup

View GitHub Repository View Creator Repositories

Install command

Download

Run Skill in Manus

File Explorer

3 files

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.

More from this repository

same repository

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.