원클릭으로
frontend-only-lint
Apply frontend code quality rules for React and TypeScript components. Auto-activates when editing component files.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Apply frontend code quality rules for React and TypeScript components. Auto-activates when editing component files.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| title | frontend-only-lint |
| name | frontend-only-lint |
| description | Apply frontend code quality rules for React and TypeScript components. Auto-activates when editing component files. |
| paths | ["src/components/**","src/pages/**","src/hooks/**"] |
| allowed-tools | Bash(npx eslint *) Bash(npx prettier *) Read |
These rules apply whenever you write or modify code in src/components/, src/pages/, or src/hooks/.
Components must be functional. Do not write class components. If you encounter an existing class component during a task, note it but do not refactor it unless the task specifically asks for that.
Hooks must follow the use prefix convention. A function that calls other hooks must start with use. A function that does not call hooks must not start with use.
The props interface must be defined directly above the component function, not inside it and not in a separate file. Name it <ComponentName>Props:
interface ButtonProps {
label: string;
onClick: () => void;
disabled?: boolean;
}
export function Button({ label, onClick, disabled = false }: ButtonProps) {
No inline styles except for values that are computed at runtime and cannot be expressed as a static class. Use CSS modules, Tailwind, or the project's existing styling system for static styles.
Export components as named exports, not default exports:
// Correct
export function Button() { ... }
// Avoid
export default function Button() { ... }
After making changes to any component file, apply formatting and linting:
Run prettier on the edited file:
npx prettier --write <edited-file>
Run eslint on the edited file:
npx eslint <edited-file>
If eslint reports errors that --fix can safely resolve, run:
npx eslint --fix <edited-file>
Report any remaining eslint errors that require manual attention. Do not hide them or continue without noting them.
If npx, eslint, or prettier is not installed or not configured in this project, skip the tool and note its absence. Do not fail the task because of a missing linter.
Explains code in plain language for someone unfamiliar with the programming language. Use when asked to explain code, walk through logic, describe what a function does, or when the user says "explain this" or "walk me through this".
Summarizes uncommitted git changes in a concise machine-readable format. Use in CI pipelines, scripts, or headless invocations where the output will be piped or captured.
Explains what a skill is and demonstrates that skills are working. Use when testing skills, when asked about skills, or when asked to demonstrate how skills work.
Demonstrates the personal scope for Claude Code skills. Use when testing personal-scoped skills or when the user wants to understand the difference between personal and project skill scopes.
Lists the conventions for this project and demonstrates the project scope for Claude Code skills. Use when asked about project conventions, code style, or as a demonstration of project-scoped skills.
Draft a CHANGELOG.md entry for the current changes in Keep a Changelog format. Use when releasing, tagging a version, or updating CHANGELOG.md.