スキルを探す

直近N日（デフォルト1日）にマージされた `cc-ui-design` ラベル付きPR（UIデザインPR）から確定したビジュアルアイデンティティ（カラー・タイポグラフィ・スペーシング・コンポーネント）をリポジトリルートの `DESIGN.md`（google-labs-code/design.md フォーマット）へ集約・更新し、`design.md` CLI の lint を通してから commit-push + create-pr でPRを作成する（`cc-triage-scope` ラベル + 自分自身をAssignee）。`DESIGN.md` は pencil-design-updater がデザイン時の前提として読み込む。

直近N日（デフォルト1日）のPRレビューで繰り返し指摘されている観点のうち「実際に修正すべき」と判断できるものを集約し、リポジトリルートのCODING_GUIDELINES.mdを生成・更新したうえで、commit-push + create-prでPRを作成する。サイズが膨らみすぎないよう既存ルールとの統合・圧縮も行う。

Sentry の Issue 一覧 URL（例 `https://<org>.sentry.io/issues/?project=<id>&environment=<env>`）を受け取り、未解決（unresolved）の Issue を列挙して1件ずつサブエージェントで並列調査する。コード上で既に解消済みと確認できたものは Sentry 側を resolved にし、未解消のものは `create-issue` スキルで GitHub Issue を作成する。「Sentryのissueをトリアージして」「Sentryの未解決エラーをチケット化して」といった依頼で使用する。

GitHub Actions ワークフロー実行（run）のIDまたはURLを受け取り、その実行が失敗している場合に原因を調査・特定して修正し、PRを作成します。成功している場合は何もしません。

指定されたGitHub PRがターゲットブランチとコンフリクトしていないかを確認し、コンフリクトしている場合はrebaseで解消してforce-pushします。PRをマージ可能な状態に整えたいときに使用してください。

gitコンフリクト状態になった.penファイル（Pencilで作成されたデザインファイル）を、Pencil CLI（`pencil`コマンド）とgitだけで解消するスキル。.penは暗号化バイナリでテキストマージが不可能なため、コンフリクトマーカーの手編集や`git mergetool`は絶対に使わず、「片側採用 → もう一方の変更をPencilで再適用」のフローで解消する。ユーザーが.penファイルのコンフリクト解消、rebase/merge中に`UU`/`AA`状態になった.penの解消、テキストマージで破損した.penの復旧などを依頼した場合に必ずこのスキルを使用する。通常の.penの編集・新規作成は`edit-pencil-design`スキル、PR全体のコンフリクト解消フロー（rebase起点・force-push）は`resolve-pr-conflict`スキルの担当。

GitHub Issueの内容を取得し、並列実行可能な単位に分解します。

pen.dev CLI（`pencil` / `pen`コマンド）だけを使って、.penファイル（pen.devで作成されたデザインファイル）の中のNodeのデザインデータ（属性・構造）とスクリーンショット画像を読み取り専用で取得するスキル。Node ID指定に加え、名前の正規表現（例: 「ヘッダー」「.*Button」）、Nodeタイプ（frame / text / image など）、再利用可能コンポーネント、特定Node配下、ドキュメント全体のトップレベルなど、**ID以外の指定方法**にも対応する。ユーザーが「.penのこのNodeの中身を見せて」「特定コンポーネントのデザインデータを取り出して」「Nodeのスクリーンショットだけ欲しい」「ヘッダーの構造を確認したい」「ボタンのスタイルをコピーしたい」「再利用可能コンポーネント一覧を見せて」「ドキュメント全体の構造を覗きたい」「全てのテキストNodeを取得して」のように.pen内の要素の調査・参照・確認・抜き出しを依頼した場合に必ずこのスキルを使う。インタラクティブモード（`pencil interactive`）で `execute` の `Get` / `Print`（読み取り専用関数のみ）を使ってNode属性を取得し、同じ `execute` の `Export` / `TakeScreenshot` で画像を`.pen`と同階層の`snapshots/`にPNG出力する。編集はしない（`save()` も変更系関数も呼ばない）ため、対象ファイルは絶対に書き換わらない。pen.dev MCPには依存せず`pencil`コマンドのみで完結。

pen.dev CLI（`pencil` / `pen`コマンド）だけを使って.penファイル（pen.devで作成されたデザインファイル）をAIプロンプトまたは決定論的な編集操作で修正・更新・新規作成するスキル。.penファイルの編集、ボタン追加、レイアウト変更、UIデザインの調整、pen.devデザインの更新、新しい.penデザインの作成などの依頼で必ず使用する。AI任せの編集・新規作成はエージェントモード（`pencil --in --out --prompt`）で行い、既存ファイルは同一パスを指定して上書き、新規作成は`--in`を省略して`--out`に新しいパスを指定する。決定論的な編集はインタラクティブモード（`pencil interactive`）の`execute`（`Insert` / `Update` / `Delete` など）で行い、最後に`save()`する。編集・作成後は「**編集・作成したコンポーネントのNodeだけ**」を`execute`の`Export` / `TakeScreenshot`でPNG出力し、`.pen`と同階層の`snapshots/`ディレクトリに保存する。pen.dev MCPには依存せず`pencil`コマンドのみで完結する。.penファイルのgitコンフリクト解消・破損復旧は本スキルではなく`resolve-pencil-conflict`スキルの担当。

与えられた企画・機能アイデアに対して不明点をユーザーへ質問し、合意した内容を PRD（プロダクト要求仕様）として確定させ、GitHub Issue として作成するスキル。「PRDを作って」「要求仕様をまとめて」「この企画をPRD化して」といったリクエストで使用する。作成した PRD Issue は `/breakdown-issues <番号>` へ渡してタスク分解できる。

コード変更を適切なgitコミット戦略でgit commitし、pushします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。

ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。

指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。

claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。

依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。

Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.

GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。

claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。

GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。

GitHubでPull Request（PR）を作成します。PRのdescriptionには指定されたテンプレートを使用し、必要な情報を記載します。PR作成後、PRのURLを報告します。

スライド作成の“プレゼント”一式。このリポジトリ（リンク/フォルダ）を渡されたら内部を読み、相手の状況に合わせて「壁打ち」または「フォルダテンプレート作成」または「スライド作成」を行う。構成→1スライドずつ生成→批評→改善→自動検証のループで、はみ出しゼロ・1スライド1メッセージのスライド（単一HTML）を作る。「スライド作って」「資料にして」「プレゼン作って」「この台本をスライドに」「このリポジトリでスライド作りたい」で使う。Claude Code 推し（CLAUDE.md / .claude/agents）。Claude Code でも動く。

Facilitate Kimball-style dimensional (data warehouse / BI) modeling sessions through conversation, producing DimML (Dimensional Modeling Language, YAML) as the primary artifact plus a bus-matrix + star-schema HTML. Use whenever the user wants to design fact tables, dimensions, a star schema, or a bus matrix — declaring grain, choosing SCD types, identifying conformed dimensions and measures (additivity) — by grilling one step at a time. Also invoke for refining an existing DimML, or when the user says "ディメンショナル・モデリング", "ディメンションモデリング", "スタースキーマ", "バスマトリクス", "ファクト表を設計したい", "グレインを決めたい", "DimML を育てたい", "Kimball で整理したい".

Facilitate DDD domain modeling sessions via EventStorming conversation and DML (Domain Modeling Language). Use whenever the user wants to model a business domain by discovering domain events, commands, aggregates, policies, read models, and bounded contexts through dialogue. Produces incrementally-built DML as the primary artifact, plus a Markdown session report. Also invoke for refining existing DML, mapping out a new feature's domain model, or when the user says "ドメインモデリングしたい", "イベントストーミング", "DDDで整理したい", "DMLを育てたい".

社員が申請したソフトウェア・SaaS・クラウドサービスの社内利用可否を、企業のIT/セキュリティ統制の観点から調査・評価するスキル。「〇〇のセキュリティ評価をして」「〇〇は社内で使っても大丈夫？」「このSaaSのセキュリティチェックをして」「新しいツールの導入審査をして」「〇〇と△△どちらが安全？」のような依頼で必ず使うこと。「セキュリティ」という言葉がなくても、特定のツール・サービスの社内導入可否・利用申請・リスク判断が話題になったら使う。Web検索で一次情報（プライバシーポリシー、利用規約、セキュリティホワイトペーパー、第三者認証）を収集し、6分野18項目のチェックリストに基づく3段階リスク評価付きの日本語レポート（Markdownファイル）と、ワークフロー（稟議）システムの承認コメント欄に貼れる短文サマリーを生成する。