メニュー
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.