Prhythm Skills

提案のリズムを生み出す Agent Skills 集。各スキルは rank（コア / ユーティリティ / メタ）と categories（ビジネス / デザイン / テック / 実行計画）で分類され、ページは skills/<name>/README.md からビルド時に生成される。

分類

• ランク — コア は他スキルの入力になる成果物を出す / ユーティリティ は端末成果物や横断ツール / メタ はスキル自体の整備
• カテゴリ — 誰が使うかではなく、注入する視点（ビジネス / デザイン / テック / 実行計画）。2つ持つスキルは職能横断の対話誘発装置

コア

スキル	カテゴリ	概要
hearing	ビジネス	顧客ヒアリングの会議に向けて、営業メモや既知情報から「この場で聞くこと」と進行の台本を作り、会議後には発言をもとにボトルネック仮説と次回の確認事項を残す。会議前は mode:prep、会議後は mode:analysis を使う。
market-landscape	ビジネス	解きたい課題（またはカテゴリ名）、対象ユーザー、望ましさの仮説を渡すと、参考サービスを集め、軸を決めたうえで 4 象限の地図に並べる。軸の右と上を望ましい方向に取ったとき、まだどのサービスも立っていない領域を、本 README では「空白の右上」と呼ぶ。成果物はその地図と、その領域を一文にしたもの。
product-vision-and-concept	ビジネス	プロダクト名（あれば）、概要、使う言語を渡すと、対話で素材を引き出し、複数案を見比べて磨き込んだ一行ステートメントと Why / Who / What / How it's different の最終稿を返す。既存のビジョン文を貼れば、弱点と改善方向の診断から入る。
uncertainty-map	ビジネス	プロトや機能の話を渡すと（ビジョンや機能一覧、DESIGN.md があればそれを物差しにする）、各機能の暗黙の仮説を抽出し、コア / 周辺と検証度（検証済 / 部分検証 / 未検証）の 2x2 に置く。成果物は docs/uncertainty-map.md（Mermaid の quadrantChart、4 象限の表、次の検証アクション）。本スキルの「コア」はビジョンを成立させる仮説（Why の核）である。
create-journey-map	デザイン	ペルソナのヒアリングメモやインタビュー記録を渡すと、ユーザー体験を時系列の台本として描くジャーニーマップ（JM）を返す。現状（As-Is）では課題からインサイトと HMW（How Might We。構造的な問い）まで出し、チームが優先度を決めたあと理想（To-Be）では対比サマリーとプロトタイプ検証用のコアシーン候補まで導く。感情は数値ではなく言葉で描く。
defining-personas-and-segments	デザイン	インタビューメモ、ディスカバリーノート、プロダクトブリーフなどを渡すと、ターゲットユーザーの候補と比較表、チームが決める論点を返す。チームが Primary（主要ターゲット）を選んだあと、その人物像、JTBD、検証計画まで深掘りする。スキルは Primary を確定させず、人間が決める材料を揃える。
function-usecase-map	デザイン	Persona、ビジョン、要件メモ、議事録などを渡すと、Actor（誰が）、Function（ユーザーに見える機能）、Use case（その機能を通じて達成する行為）の関係を整理し、全体俯瞰と機能別の Mermaid 図を docs/usecase-map.md に書く。コードは不要。別入力の全文例は example.md。
proto-storyboard	デザイン	選定済みのコアシーンと To-Be ジャーニー、一行コンセプトを渡すと、提案当日およそ 5 分のデモプレイ絵コンテに落とす。基本は導入 / 山場 / 着地の 3 カットで、それぞれに画面、操作、台本を付け、docs/proto-storyboard.md に残す。顧客が社内で同じデモを再現するときの台本にもなる。見た目のトーンは DESIGN.md へ回す。
ooui-graphql-modeling	テック ビジネス	チャットで伝えたアプリ概要、ユーザータスク、参考プロダクトから、ビジネスドメイン中心の GraphQL SDL を段階的に設計し、src/model/schema.graphql に残す。このファイルが構造の正。画面実装や DB / resolver の詳細は扱わない。
delivery-phase-plan	実行計画 ビジネス	主指標の現状と目標、パイロットの規模を渡すと、役割を横レーン、時期と判定を縦のフェーズに載せた図にする。本 README ではこの図を「矢羽」と呼ぶ。各ゲートに Go/No-Go の判定を書き、最終ゲートには未達のときの一手を付ける。成果物は docs/delivery-phase-plan.md で、図そのものが共有物。仮説の優先順位そのものは uncertainty-map で扱う。
delivery-team-plan	実行計画	パイロットのスコープと、顧客側の決裁者・実行者を渡すと、受注後だれが決裁しだれが手を動かすかを体制（Owner / 実行レーン / Support）と RACI に落とし、docs/delivery-team-plan.md に書く。時期、KPI、矢羽は delivery-phase-plan で扱う。

ユーティリティ

スキル	カテゴリ	概要
assumption-breaker	ビジネス	RFC、提案書、brief、Slack 投稿などのテキストを渡すと、提案者が当然としている前提を洗い出し、それぞれを外した代替解とトレードオフ付きの推奨を返す。説得術ではなく発想法で、見えていなかった解の空間を可視化する。
feature-backlog-map	ビジネス 実行計画	ビジョン、プロダクトの説明、または docs/usecase-map.md を渡すと、次の 3 ファイルを一度に出す。機能一覧（システムが何をするか）、プロダクトバックログ（ユーザーが何をできるか。並び順が優先度の提案）、受け入れ条件一覧（完了したと言える条件。Given/When/Then）。何も無ければスキルが 1 ターンだけ聞く。読み手は必要なファイルだけ使う。
prototype-design-md	デザイン テック	製品名、用途、空気感を渡すと、v0 や Cursor で UI を生成する前に AI が読む 1 枚の判断ブリーフ DESIGN.md を一緒に作る。hex や padding の値は CSS トークンに任せ、ここでは性格、サーフェス、禁止パターン、コンポーネント選びだけを固定する。
shadcn-explorer	デザイン テック	探したい UI の種類、用途、雰囲気を渡すと、shadcn/ui エコシステム（コミュニティ registry とテーマ）を横断検索し、コンポーネント、ブロック、UI ライブラリ、テーマ候補を名前・説明・homepage 付きで返す。テーマ依頼なら CSS 変数も付ける。プロジェクトへのインストール手順は扱わない。
ooui-architect	テック	フロントエンドの置き場所とコンポーネント構成を、OOUI（Object-Oriented UI。画面を「もの」単位で組み立てるやり方）に揃える。チャットで配置の相談、新オブジェクトの追加、コンポーネントレビューなどを依頼すると、common / model とフレームワークが定めるルーティング dir に、4-file コンポーネントと scaffold を置く。GraphQL SDL の設計そのものは扱わない。
create-html-deck	実行計画 デザイン	チャットで発表の依頼を渡すと、ブラウザでそのまま再生できる HTML スライドデッキを slides/{deck}/ に作る。アウトライン、テーマ、スライド本文、組み立て、プレビューの順で進み、成果物は組み立て後の index.html（必要なら単体 HTML）。PowerPoint や Slidev は扱わない。

メタ

スキル	概要
prhythm-docs	調査・分析スキルのチャット結果、または同等のメモや既存 docs/ 成果物を渡すと、そのスキルの文書テンプレに流し込み、docs/prhythm/{skill}/ にマークダウン文書とスライド形式の HTML を作成して情報をまとめる。
prhythm-skill-pr	Prhythm リポジトリでスキル追加・更新の Pull Request を作る。形式チェックと README カタログ確認のあと、日本語の PR 本文を揃え、gh pr create まで進める。
prhythm-skill-review	Prhythm に追加する Agent Skill の SKILL.md と日本語 README を、同じ型で点検・修正する。対象スキルのディレクトリを渡すと、テンプレに沿った README の作成、品質チェック、指摘の修正のいずれかを行う。判定基準の正本は references/readme-principles.md。