メニュー
修正・バグ修正・リファクタリングの依頼時に、末端パッチではなく上流での根本解決を優先するスキル。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」といった依頼で使う。 コード修正の依頼全般で使うこと。単純な typo 修正や1行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。
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実装が絡むなら使うべき。
| name | upstream-fix |
| description | 修正・バグ修正・リファクタリングの依頼時に、末端パッチではなく上流での根本解決を優先するスキル。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」といった依頼で使う。 コード修正の依頼全般で使うこと。単純な typo 修正や1行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。 |
修正依頼を受けたとき、その場しのぎのパッチではなく、設計レベルで根本原因を解決するためのワークフロー。
末端でのパッチは「今この瞬間」は最速に見える。しかし同じ種類の問題が別の場所で再発し、パッチが積み重なってコードベースが複雑化する。上流（データの流れの源流、抽象化のより高いレイヤー、設計の根本）で直せば、下流の問題が一括で消える。修正コストは一度だけ、効果は永続的。
修正に手をつける前に、現状を正確に理解する。
現状把握の結果を整理し、ユーザーに共有する。
## 診断結果
### 症状（ユーザーが報告した問題）
- [何が起きているか]
### 直接原因（症状を引き起こしているコード）
- [どのコードが問題か、なぜそうなっているか]
### 根本原因（なぜそのコードがそうなっているか）
- [設計上の問題、データフローの問題、責務の曖昧さなど]
### 影響範囲
- [同じ根本原因から生じている、または生じうる他の問題]
「今あるコードをどう直すか」ではなく、「この領域を今からゼロで作るならどう設計するか」を考える。
観点:
「ここまでやれば綺麗になる」が見えたら、その全体像をユーザーに提案する。一見関係なさそうに見える領域でも、根を辿れば同じ設計上の問題に繋がっていることがある。そういう繋がりが見えたなら、それも含めて提案する。見えている改善を黙っているのは機会損失。
修正方針を選択肢として示す。
## 修正方針
### A: フル改善（ここまでやれば綺麗になる）
- 何をするか: [根本原因の解消 + 周辺の設計改善]
- 影響範囲: [変更が及ぶファイル・機能]
- メリット: [この領域全体がスッキリする、今後の変更も楽になる]
### B: 上流修正（報告された問題の根本解決）
- 何をするか: [根本原因の解消に絞った変更]
- メリット: [根本解決、再発防止]
### C: 局所修正（最小パッチ）
- 何をするか: [症状を直接修正]
- メリット: [変更が小さい、リスクが低い]
- リスク: [再発の可能性、技術的負債の蓄積]
判断ガイド:
A が見えているなら必ず提案に含める。
選択された方針に沿って実装する。
| シグナル | 上流修正すべきか |
|---|---|
| 同じ種類の修正が複数箇所にある | はい - 共通の原因がある |
if や特殊ケース分岐が増えている | はい - データの正規化不足 |
| 「ワークアラウンド」「暫定」コメントがある | はい - 本来の解決が別にある |
| 修正箇所がデータの流れの下流にある | はい - 上流で正しいデータを作るべき |
| 問題が1箇所だけで設計に問題がない | いいえ - 局所修正で十分 |
| 緊急の本番障害 | まず局所修正、後日上流修正 |