菜单
コードを変更する実装作業（機能追加、バグ修正、リファクタリング、テスト追加）を始めるときに使うスキル。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼のほか、 方針合意後に「進めて」「お任せ」「どんどんやって」と任された場合にも使う。 調査・質問回答・レビューだけで完結するタスクや、方針が未決で相談段階のものには使わない。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。
npm (pnpm) / Cargo の依存パッケージをバージョンアップするスキル。 サプライチェーン攻撃 (Shai-Hulud 系 worm) のリスクを抑えつつ、脆弱性のある パッケージを優先的に潰し、override (pnpm.overrides / [patch.crates-io]) という 負債をなるべく増やさない / 既存の override を外せないか検討する、までを 1 セットで回す。 以下の依頼で使う: 「依存を上げて」「パッケージを更新して」「バージョンアップして」「audit を潰して」 「脆弱性のあるパッケージを直して」「dependabot の PR を見て」「override を整理して」 「outdated を解消して」。 個別 1 パッケージの bump でも、まずこのワークフローを通して安全性と override 負債を確認する。
PR が「その文脈を知らない初見のレビュアー（別チーム／入社直後）」に通じるかを点検したいときに使う。初見が詰まる原因は2つ。①意味が取れない（issue/PR にしか登場しない呼び名「Phase-2」「軸B」、PR に含まれない参照、未定義の略語、暗黙の前提「前回の議論どおり」等）と、②頭に入ってこない（一文が長い・主述が遠い・名詞化・回りくどい述語・結論が後ろ＝可読性）。語は分かるのに文がまどろっこしいときも対象。社内で定着しコードに実体がある用語（grep で定義に辿れる社内サービス名等）は対象外。トリガー例:「初見でレビューできる？」「PRのジャーゴンを消して」「文がまどろっこしい」「スッと頭に入らない」「onboarding した人が分かる？」。
Research-driven UI design decision-making. Use when facing UI/UX design choices, information layout challenges, or needing to decide how to display complex data. Triggers: (1) UI design decisions with multiple valid approaches, (2) information overload or layout consolidation needs, (3) "how should we display X?" or "how do other products handle Y?" questions, (4) progress indicators, steppers, navigation, form design decisions, (5) when the user says the design feels "broken", "too much", or "messy", (6) when uncertain about the best way to organize or present information in UI
UIコンポーネントやページを実装する際に、AI特有の「ジェネリック感」を排除し、プロのUIデザイナーが設計したような品質を実現するスキル。 UIの実装、コンポーネント作成、画面構築、フロントエンド開発、ページデザインを依頼されたとき、 または「UIを作って」「画面を実装して」「コンポーネントを作って」「フォームを作って」「ダッシュボードを作って」 といったリクエストで必ず使うこと。既存の frontend-design スキルと併用可能だが、 こちらは「参照ベースの実装」と「AI感の排除」に特化している。 ボタン1つでも画面全体でも、UI実装が絡むなら使うべき。
修正・バグ修正・リファクタリングの依頼時に、末端パッチではなく上流での根本解決を優先するスキル。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」といった依頼で使う。 コード修正の依頼全般で使うこと。単純な typo 修正や1行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。
| name | autonomous-dev |
| description | コードを変更する実装作業（機能追加、バグ修正、リファクタリング、テスト追加）を始めるときに使うスキル。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼のほか、 方針合意後に「進めて」「お任せ」「どんどんやって」と任された場合にも使う。 調査・質問回答・レビューだけで完結するタスクや、方針が未決で相談段階のものには使わない。 |
方針が固まったら、確認を挟まず一気に完成まで持っていく。品質は、セルフレビューの反復と「実際に動かして確かめる」ことで担保する。
ユーザーが方針に合意した後の逐次確認は、作業を中断させるだけで価値を生まない。代わりに、自分自身で何度もレビューと改善を回すことで、ユーザーの時間を奪わずに高い品質を実現する。
このスキルは特定の言語・ツールを前提にしない。着手時に作業対象プロジェクトの作法を特定し、以降のフェーズではそれを使う。
.github/workflows/ 等）→ package.json / pyproject.toml / Makefile の順に確認する。lint・テストに加えて、型チェック・ビルド・フォーマットチェックがあればそれも含める.claude/rules/ から、変更対象ファイルに適用されるルールを確認する。実在を確認したルールだけに従う（例: robustness.md、code-intent-documentation.md）以降、本文の lint & test はここで特定したコマンド群を指す。例: pnpm のプロジェクトなら pnpm lint:fix && pnpm lint && pnpm test、Python なら flake8 + pytest など。
実装の方向性が不明確な場合のみ、ユーザーに確認する。
方針が明確なら（ユーザーが「進めて」と言っている、要件が自明、など）、この Phase はスキップして即座に Phase 2 に入る。
Phase 1 を抜けたら、以降はユーザーに確認を求めない。 完成するまで自律的に進める。
例外として、次に該当したときだけは手を止めて確認する。
これ以外の迷いは自分で判断して進める。
設計やUXの判断は、局所的なコードだけ見ていると的外れになる。実装に入る前に、変更が影響する範囲の全体像を掴む。
原因や変更箇所が特定済みのタスクでも、このフェーズを丸ごと飛ばさない。最低限、変更箇所の呼び出し元と既存テストのカバー範囲は確認する。「分かっているつもり」の小さな修正が、呼び出し元の暗黙の前提を壊す事故はここで防ぐ。
devtools（Chrome DevTools MCP 等）で画面を確認できる環境なら、関係する画面を渡り歩いて現状のUIを把握する。
コードだけ読んでも、実際の見た目やユーザーの操作感は分からない。画面を見ることで「ここに追加すると狭くなる」「この色は周囲と合わない」といった判断ができる。ここで撮った変更前のスクリーンショットは、Phase 5 の最終確認で変更後と見比べる材料にもなる。
画面を確認する手段がない環境では、コードとスタイル定義から把握した上で、実画面を確認できていないことを報告に明記する。
主要ユースケースを洗い出し、データの流れや呼び出し関係を把握する。
実装コードより先にテストを書く。テストが実装の仕様書になる。
テスト設計 - 何をテストするか洗い出す
テスト実装 - 丁寧に書く
"test" ではなく具体的な値）テスト実行 - 新しく書いたテストが「未実装」を理由に失敗することを確認する
テストを通すための最小限の実装を書く。
実装が動いたら、ここから品質を磨き上げる。改善点が見つからなくなるまでレビューと修正を繰り返す。
各ラウンドで以下の観点をチェックし、問題を見つけたら即座に修正してから次のラウンドに進む。
ラウンド N:
1. 変更した全ファイルを読み直す（差分ではなくファイル全体）
ラウンド1では、呼び出し元・関連テスト・設定・ドキュメントも開いて波及を確認する
2. 上記7つの観点でチェック
3. 問題を発見 → 修正 → lint & test 実行
4. 修正があった → ラウンド N+1 へ
5. 修正がなかった → 最終確認へ
最低2ラウンド。修正が発生しなくなるまで回す。目安は3ラウンド程度。1ラウンド目で粗い問題、2ラウンド目で細かい問題、3ラウンド目で確認、という流れになることが多い。「修正ゼロ」のラウンドも、7つの観点を全て当てた上でのゼロであること。流し読みして「修正なし」と数えるのは収束ではない。
レビューが収束したら、完了と言う前に次の3つを確認する。
git status と git diff を見て、意図しない変更・デバッグ用コードの残骸・無関係ファイルが紛れていないか確認するcommit・push・PR 作成まで依頼されている場合は、プロジェクトの PR フロールールに接続する。Phase 5 のセルフレビューは内省であり、PR 前に求められる外部レビューの代替にはならない。
ci-workflow.md）pr-self-review.md。hook＝ツール実行を自動ブロックする仕組みで強制されるプロジェクトもある）pr-ci-watch.md）これらのルールがないプロジェクトでも、push 前に CI 相当のチェックをローカルで通すことだけは省略しない。
依頼に push・PR まで含まれるか不明な場合は、push せずに Phase 7 で報告し、push・PR の要否を添える。push は外部に出る不可逆寄りの操作なので、Phase 1 の例外（破壊的・不可逆な操作）と同じ扱いにする。
完了したら、ユーザーに簡潔に報告する。
報告に含めるもの:
報告に含めないもの:
「急ぎで」「デモまでに」と言われても、ワークフローを黙って崩さない。縮めてよいものと縮めてはならないものを区別する。
| 縮めてよい | 縮めてはならない |
|---|---|
| Phase 2 の調査範囲（呼び出し元と既存テストの確認は残す） | テストを先に書くこと（回帰テスト1本まで減らすのは可） |
| テストケース数（バグ修正なら回帰1本まで） | Phase 3 のテスト実行確認（失敗確認、挙動保存ならパス確認） |
| レビューラウンド数（最低の2回まで） | lint & test 全パス |
| 動作確認の範囲（変更箇所そのものの確認は残す） | 動作確認を実施すること自体 |
| 報告の詳しさ | git status / git diff での混入チェック |
時間圧力はアンチパターン表と Phase 6 の外部レビュー・CI 監視を無効化しない。縮めた場合（レビューを2ラウンドで打ち切った・動作確認の範囲を絞った等）は、何をどこまで縮めたかを報告に含める。縮めてはならない側が時間内に収まらないなら、品質を黙って落とすのではなく、間に合わないことと残作業をその時点でユーザーに報告する。
| やりがち | なぜダメか | 代わりに |
|---|---|---|
| 実装の途中で「この方針でいいですか？」 | ユーザーの時間を奪う | 方針は Phase 1 で合意済み。迷ったら自分で判断 |
| 「原因は分かっている」と Phase 2 を飛ばす | 小さな修正ほど呼び出し元の前提を壊したことに気づけない | 呼び出し元と既存テストだけは必ず確認 |
| 「3行の修正だからテスト不要」 | 回帰したとき誰も検知できない | 回帰テスト1本を先に書く |
| テストを後から書く | 実装に引きずられて甘いテストになる | テストを先に書く |
| セルフレビュー1回で完了 | 最初のレビューでは構造的な問題を見落としやすい | 最低2ラウンド、収束するまで回す |
| diff だけ見てレビュー | 文脈を見失い、周辺との不整合を見逃す | ファイル全体を読み直す |
| テストが通ったので動かさずに完了報告 | 結合部の不具合や見た目の崩れはテストの外で起きる | 最終確認で実際に動かす |
| スキル記載の例のコマンドをそのまま実行 | pnpm ... は一例。プロジェクトごとにコマンドは違う | 「前提」で特定したコマンドを使う |
| 「完了しました」だけ報告 | ユーザーが変更内容を把握できない | 何を変えたかと、レビューで直した点を簡潔に |