本文へ移動
cccskills
無料GitHub で公開

pattern-abstraction

要件・問い合わせ・事例の集まりを、「対応が変わる分かれ目」で階層に分けて抽象化する(パターン分け・ケース分け・分類)。上の階層ほど根本の問い、下の階層は「なぜそうなるか」の理由で分け、名前は見た目ではなく「相手の側で何が起きているか」で付ける。

「パターン分けして」「抽象化して」「ケースを整理して」「分類して」「網羅的に洗い出して」「テストケースを設計して」「どういう場合がある?」と言われたとき、事例の一覧から応対・仕様・テストの方針を作るとき、ユーザーが同じ整理を何度も求めているとき(伝わっていない合図)は、明示されていなくても必ず使う。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md7.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

階層のある抽象化(パターン分け)

事例の集まり(問い合わせ、要件、不具合、テストの会話など)を、対応が変わる分かれ目で階層に分ける。 目的は、事例を似たもの同士で束ねることではない。「この場合はこう対応する」が漏れなく決められる地図を作ることにある。

よくある失敗(これを避けるためのスキル)

  • 平たい表に並べる: 例を下から寄せ集めて一列に並べると、高さの違うもの(根本の分かれ目と、その下の理由)が同じ列に混ざる。読み手には何で分かれているのかが見えない
  • 見た目で名前を付ける: 「無いボタンの名前を言う」のように例の表面をなぞると、同じ構造の別の例(出ないはずのエラー、無い機能が動いた)を拾えない
  • 案件の固有名詞に縛られる: 「〇〇サービスの話か」と書くと、別の案件で使えない。「担当するもの以外の話かもしれない」のように一般の言葉にする
  • 書き残さない: 会話の中で表を出して終わると、次の判断の土台にならない。ユーザーに同じ整理を繰り返し頼まれたら、伝わっていない合図

手順

1. ゴール(何ができたら終わりか)と、分ける目的を決める

何のために分けるのかを先に 1 文にする。たとえば「お客様の発言ごとに、ボットの応対を決めるため」。 分ける目的が決まると、分かれ目の基準が決まる。「対応が変わるところでだけ分ける」。対応が同じなら、見た目が違っても同じパターン。

2. いちばん上の分かれ目を決める

事例を並べる前に、「対応を決めるうえで、まず何が分かっていればよいか」を考える。それが最上位の問いになる。

  • 例(問い合わせ対応): 「ゴールと対象が分かるか」→ 分かる/分からない/そもそも答えない/途中の反応
  • 例(不具合の報告): 「再現できるか」→ できる/できない/仕様どおり/担当外

最上位は 3〜5 個に収める。多すぎるなら、高さの違うものが混ざっている。

3. 下の階層は「なぜそうなるか」で分ける

上の階層の各枝について、「なぜそうなるのか」「相手の側で何が起きているのか」で分ける。

  • 「分からない」の下: 相手が言っていない/言葉があいまい/相手自身が分かっていない/担当外の話かもしれない/担当するものでは起きない事象を伝えてくる
  • 1 つの階層の兄弟は、同じ問いへの答えになっていること(同じ軸で分かれていること)を確かめる

4. 名前は「相手の側で何が起きているか」で付ける

例をなぞった名前を付けたら、「つまり何が起きている?」と 1〜2 回上に上げる。 上げすぎて対応が決まらなくなったら 1 つ戻す。

  • 「無いボタンの名前を言う」→「実際には無いものがあると思っている」→「担当するものでは起きない事象を伝えてくる」
  • 確かめ方: その名前で、元の例以外の例を 2 つ挙げられるか。挙げられなければ、まだ見た目の名前

固有名詞(製品名・社名)は、名前に入れない。例の欄に入れる。

5. 葉ごとに「こうなっていれば合格」を書く

いちばん下の各パターンに、対応(合格の姿)を 1 文で書く。対応が隣と同じなら、パターンを統合する。 似た 2 つは、境目を 1 行で書く(例: 「〜できますか」と聞いている vs 「〜が起きた」と言っている)。

6. 抜けを確かめる

  • 各階層で「どれにも当てはまらない例は無いか」を考え、あれば枝を足す
  • 回数や程度で対応が変わるもの(3 回やっても進まない、など)は、閾値を決めて独立した葉にする。閾値はユーザーに決めてもらう
  • 元にした事例の出どころを書き、「これで全部とは言えない」場合はそう書く。根拠の無い網羅を言わない

7. 書き残す

最初に頼まれたときから、ユーザーが指定する場所(issue、ファイル)に書く。指定が無ければ、どこに残すかを 1 行で聞く。 以後の判断(設計、テスト)は、この地図を元にし、地図を直したら書き残したものも直す。

出力の形

  1. 分ける目的(1 文)
  2. 階層(入れ子の箇条書き。番号は「1」「1-2」のように階層が分かる形)。各葉は「パターン → 対応」
  3. 境目の注記(似たもの同士の分かれ目)
  4. 出どころと、まだ無いもの(テストや例が無い葉)
目的: お客様の発言ごとに、ボットの応対を決める

- 1. ゴールと対象が分かる
  - 1-1. 資料で案内できる → ゴールに向けて案内する
  - 1-2. 資料に答えが無い(「〜できますか」)→ 分かることを伝え、言い切らず、担当者へつなぐかを聞く
- 2. ゴールか対象が分からない → 決まるまで聞く
  - 2-1. 相手が言っていない(症状だけ)→ 足りないことを 1 つ聞く
  - 2-2. 言葉があいまい → どれのことかを確かめる
  - 2-3. 相手自身が分かっていない → 確かめ方を教える
  - 2-4. 担当するもの以外の話かもしれない → 意図を確かめる
  - 2-5. 担当するものでは起きない事象を伝えてくる → 似たものに当てはめず、何を見たか、何をしたいかを聞く
  - 2-6. 3 回やりとりしても決まらない → 担当者へつなぐかを聞く
- 3. 答えない(関係ない、料金、悪意、読み取れない)
- 4. 途中の反応(進んだ、進まない、話が変わった)

境目: 1-2 は「できるか」を聞いている。2-5 は「起きた」と言っている
出どころ: 指摘から作った 17 本の会話。2-6 と 3 の悪意はまだテストが無い

出す前の確かめ

  • 同じ階層の兄弟は、同じ問いへの答えになっているか(高さの違うものが混ざっていないか)
  • 名前は、元の例以外にも当てはまるか(固有名詞が入っていないか)
  • 葉ごとに対応が書いてあり、隣と対応が違うか
  • ユーザーが使った言葉(ゴール、担当範囲など)を軸に使っているか
  • 書き残す場所に書いたか

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

animated-arch-diagram

無料概要あり

構成図・アーキテクチャ図・エージェント構成・処理の流れを「動く画像」にして、X(Twitter)などに貼れる MP4 と GIF で書き出すスキル。ノードが順に現れ、線が引かれ、光の粒がエッジを流れ、いま動いている部分だけが光り、下に字幕がタイプされ、最後に全体が同時に動いてループする。箇条書きのツリー(「> main が…」「> worker が…」のような投稿文)やシステムの説明文を渡すだけで作れる。「構成図を動画にして」「アーキテクチャ図をアニメーションで」「エージェントのツリーを動く図に」「データの流れが見える図」「Xに貼る図解GIF」「この投稿みたいな動く図」「フロー図をMP4で」と言われたら、動画やGIFと明言されていなくても必ずこのスキルを使うこと。マルチエージェント構成、マイクロサービス、データパイプライン、RAG、CI/CD、業務フローなど、箱と矢印で描けるもの全般に使う。「お客様(専門外の人)に仕組みを説明する動画」「質問が処理されて返事になるまでを見せたい」「AI とプログラムの役割分担を見せたい」「データが手順を通ってどう変わるか」「ループの流れを動画で」のように、1つの具体例が手順を通って変わっていく様子を見せたいときも使う(運搬型)。静止画の図だけが欲しい場合(Mermaid で十分な場合)には使わない。

musoukun/skills82026年10月19日 更新

ddd-requirements-modeling

無料概要あり

要件・仕様・業務の説明・受注依頼書から、業務の分類、中心となるデータと守る決まり、業務同士のつながりを整理し、設計の土台を作る。まず業務領域ごとに作り方を3段階で判定する(1: Next.js+Prisma+SQLite+Tailwind で素直に作る、2: 厳選した11種のデザインパターンで疎結合にする、3: 集約・リポジトリ・値オブジェクト・ユースケースなど DDD の部品を持ち込む)。全体図・判定表・機能一覧を先に示し、用語、主体、保存の当たりを仮置きする。「要件をDDDで整理して」「集約を切って」「文脈を分けて」「ユビキタス言語を作って」「ドメインモデルにして」「設計に落として」「モデリングして」「構造を整理して」「どう作ればいい?」「DDDいる?」「どのパターンが合う?」など、要件から設計を考える依頼に使う。UIモックや画面設計のみ、設計済みコードの実装のみ、パターンの一般解説のみの依頼には使わない。

musoukun/skills82026年10月19日 更新

issue-comment-style

無料概要あり

GitHub の issue / PR に投稿するコメントの書き方ルール。お客さん・非エンジニアも読む前提で、平易・短く・結論だけ・専門用語なしで書くためのもの。`gh issue comment` / `gh pr comment` でコメントを書く・投稿する・直すとき、特に検証結果(修正できた証拠)や差し戻しへの返信を書くときは必ずこのルールに従う。「issue にコメントして」「PR にコメント残して」「検証結果を載せて」と言われたら、明示されていなくてもこのスキルを参照する。

musoukun/skills82026年10月19日 更新

issue-dev-rules

無料概要あり

GitHub の issue を 1 件こなすときの開発ルール集。issue の読み方、作業フォルダ(git worktree)の選び方、ブランチの切り方と名前、Before/After の証拠の撮り方、コミット・push・PR の決まり、issue / PR へのコメントの書き方をまとめたもの。複数の issue を自動で回すループは含まない。「issue に着手して」「#123 やって」「この issue 対応して」「ブランチ切って」「PR 出して」「issue にコメントして」など、issue を起点に開発するときは、スキル名が出ていなくても参照する。

musoukun/skills82026年10月19日 更新

issue-loop

無料概要あり

GitHub の Kanban から1〜3件の issue を取って、1件ずつ順番に「理解 → A/B 判定 → (必要なら設計)→ ブランチ → Before → 実装 → After → PR → レビュー対応」まで自走で処理する skill。feedback / enhancement / bug すべて対象。明示トリガーは `/issue-loop`、「kanban から issue 回して」「3件まとめて対応して」「ループで issue 処理」「feedback 回して」など。各 issue で A/B 判定する:A(やることが明確)なら設計を省いてすぐ実装に進めるか確認、B(曖昧)なら設計 HTML を見せて Accept を取ってから実装。「実装しなくていいから A パターン(すぐ迷わず実装できる issue)だけ洗い出して」「簡単なやつリストして」のように着手せず候補だけ見たいときは**スキャンモード**(`--scan`)で、A の issue だけを表にして止まる。

musoukun/skills82026年10月19日 更新

issue-status

無料概要あり

自分が担当している GitHub issue の「今どうなっているか」と、作業フォルダ(git worktree)の空き状況をまとめて確認する skill。「担当 issue の状況」「自分のチケット確認」「今抱えてる issue 一覧」「何が止まってる?」「ボールどっち?」「自分の issue の進捗まとめて」「空いてる worktree ある?」などと言われたら使う。issue 番号を指定されなくても、自分の担当 issue を棚卸ししたい意図が見えたら起動する。最重要: ブランチや PR の有無だけで「未着手」などと判断してはいけない。各 issue のコメントを 1 件ずつ実際に読んで現状を出す。

musoukun/skills82026年10月19日 更新

musoukun のスキルをすべて見る

このスキルの問題を報告する