vrchat-albums

コードを変更する実装作業（機能追加、バグ修正、リファクタリング、テスト追加）を始めるときに使うスキル。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼のほか、 方針合意後に「進めて」「お任せ」「どんどんやって」と任された場合にも使う。 調査・質問回答・レビューだけで完結するタスクや、方針が未決で相談段階のものには使わない。

ユーザーの発言内容だけを忠実にドキュメント化するスキル。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行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。