القائمة
Use when checking code style, running linters, formatters, or static analysis, fixing lint errors, or scaffolding a linter stack for a project
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when asked to implement an epic, a backlog of issues, or "/epic-implement N" — autonomous multi-agent execution of a GitHub epic's sub-issues, safe under a permission-bypassed session. Pass the epic number as the argument; if omitted, asks which open epic to run. A single issue goes to issue-implement.
Use when asked to implement a single GitHub issue end to end — "implement #171", "fix issue N", "pick up that bug" — where the deliverable is a reviewed PR. Epics and multi-issue backlogs go to epic-implement.
Use when capturing a feature, remediation, port/resurrection of old functionality, or any multi-issue program of work as a GitHub epic with sub-issues for later execution by separate agents — including when asked to "create an epic", "file this as issues", or "plan this so a lesser model can execute it". Single-issue-scale work (one bug/feature/chore) goes to issue-plan.
Use when capturing a single unit of work as a GitHub issue for later execution by a separate session — a bug found while debugging, a feature request, a chore, or a discovery out of scope for the current task. Triggers include "file an issue", "create an issue", "write this up as a bug". Multi-issue programs of work go to epic-plan.
Use when starting work in an unfamiliar module, when a module's `.context.md` is missing or stale, or when asked to document or understand a module's role
Use when restructuring existing code without changing behavior — extracting functions, splitting modules, or addressing tech debt and code smells
| name | lint |
| description | Use when checking code style, running linters, formatters, or static analysis, fixing lint errors, or scaffolding a linter stack for a project |
| allowed-tools | Bash(make lint:*), Bash(make format:*), Bash(make typecheck:*) |
Linter configs are the canonical coding standards — not prose docs. Anything not in the linter config is a suggestion, not a standard.
| Invocation | Action |
|---|---|
/lint | make lint (whole project) |
/lint [file|dir] | linter directly on a path |
/lint fix or /lint --fix | make format then make lint |
/lint setup | scaffold a linter stack (see below) |
See linter-stacks.md for per-language config (Python/Ruff, TS/ESLint, Rust/Clippy, etc.).
Group by file, severity within file, most critical first:
[severity] [file:line] [rule-id] — message
Summary:
Errors: N (must fix) Warnings: N (should fix) Info: N (optional)
For /lint fix, separately list what got auto-fixed vs what still needs manual attention.
/lint setuppyproject.toml / package.json / Cargo.toml / etc.linter-stacks.md for the recommended config.lint, format, typecheck Makefile targets if missing.