メニュー
Use when implementing React frontend changes — components, hooks, pages, or UI. Follows the frontend repo's own stack and conventions, and keeps the formatter and linter clean.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/marvs/kantan-dev --skill kantan-frontendコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use when a feature is complete or wrapping up implementation in a Rails + React app. Records how the feature was built as a docs file and captures new reusable patterns into each repo's conventions file.
Use when planning a feature or before writing implementation code in a Rails + React app. Produces an approved implementation plan, asking clarifying questions and grounding the plan in repo conventions and prior feature docs. Never starts implementation.
Use when implementation is complete, before reporting or marking any feature as done, and before finishing a feature in a Rails + React app. Mandatory review step of the Kantan workflow — never skip it. Performs an expert Rails + React code review of the changes against the plan, the repo conventions, and universal best practices.
SOC 職業分類に基づく
SKILL.md を表示中
| name | kantan-frontend |
| description | Use when implementing React frontend changes — components, hooks, pages, or UI. Follows the frontend repo's own stack and conventions, and keeps the formatter and linter clean. |
For React frontend work. Detect the frontend by a package.json that depends on React. If more than one React frontend exists in the workspace and the target is ambiguous, confirm which one before editing — do not guess.
Before writing code, read the frontend repo's conventions file — AGENTS.md if present, else CLAUDE.md. Frontends differ a lot (e.g. SWR vs Redux, sx vs makeStyles, quote/print-width rules, Node version, data-fetching helpers). Follow that repo's stack and conventions exactly. Do not impose conventions from memory.
Apply these unless the repo's conventions say otherwise — repo conventions always win.
fetch in components.key={item.id ?? idx}, never the bare index for backend-persisted lists.Content-Type manually — let the browser set the multipart boundary.useState initializers for expensive/derived initial state to avoid stale closures.key to reset local state when the entity changes.kantan-review-feature as an open item. Never record it as decided — the review re-opens it, and only the user closes it.Do NOT run git add or git commit. Leave changes for the user to review.
A clean formatter and linter complete the implementation, not the feature. Do not report the feature as done: the feature is only done after kantan-review-feature has run with no Critical/Major findings and kantan-finish-feature is complete. Keep those as pending todos until they are.
"Formatter and linter are clean" is not a reason to skip review — that is exactly the state review is for. Linters cannot catch design issues, missed plan items, or convention drift.