.github

Markdown ドキュメント (README, 設計書, .claude/rules/, docs/) や、コード内の 公開関数 JSDoc / docstring / 非自明ロジックへのコメントを書く・編集するときに 使うスキル。「半年後の読者が誤解しない文章」を成立させるためのチェックリスト。 以下の場面で必ず発動する: "ドキュメントを書いて", "README を更新して", "設計書を書いて", "コメントを足して", "JSDoc を書いて", "docstring を書いて", "ルールを追加して", "プランを書いて", "仕様をまとめて", ".claude/rules に追加", "docs/ に追加", "PR description を書いて" Markdown 文書 (.md / .mdx) や code comment の Edit/Write を行う前後に チェックリストを通す。

修正・バグ修正・リファクタリングの依頼を受けたとき、末端パッチではなく上流での根本解決を 「どう直すか」決めるまでを担うスキル（実装フェーズには踏み込まず、方針決定までを担う）。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」「ゼロから設計し直すなら」といった依頼で使う。 コード修正の依頼で発動し、症状の奥に設計上の根本原因が無いかを一度診断する。 smell が無ければ局所修正で止め、smell があれば上流まで遡って直す方針を立てる。

PR・ブランチ差分を「ユーザー価値とプロダクト品質」の観点で、PdMとしてレビューするスキル。「PRをレビューして」「この変更でユーザーに何が起きる？」「ユーザーへの価値はどう変わる？」「イシューの意図に沿ってる？」「これマージして大丈夫？」「PdM目線で見て」「合否を判断して」といったリクエストで使う。codex review や code-review が行レベルのコード品質を見るのに対し、本スキルは「このPRをユーザーに出して良いか」を、価値の増減（プラス/マイナス）・イシューの意図との整合・想定外の変化の3点で評価し、PdMがパッと見で合否判断できる粒度にまとめる。