claude-marketplace

デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。

iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。

Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。

Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.

Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.

Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.

Use this skill for UI/UX, frontend visual design, product flow, landing page, dashboard, component, or design-system-aware work where design reasoning should be traceable, isolable, and retractable. It orchestrates context reading, relation mapping, hypothesis generation, artifact design, critique, and trace archival. This is about the reasoning process, not visual output methodology — for HIG/Material Design/Atomic Design-driven UI or design-system construction without a trace/retraction workflow, use design-plugin's web-app-designer, mobile-app-designer, or design-system-builder instead.

Codex CLI (OpenAI gpt-5.4) に直接相談するスキル。設計判断・実装方針・コードレビュー・デバッグ方針など、別モデルの視点が欲しい時に使用する。「codexに相談」「codexに聞いて」「別の視点が欲しい」「セカンドオピニオン」「codexでレビュー」「codexとペアプロ」「codexとTDD」「codexでペアプログラミング」「ペアプロモード」「adversarial review」と言った時にトリガーする。

生成AIが人間に対して行う作業開始時オンボーディング。AIが"説明係"ではなく"進行役"として、探索→仮説→検証→要約→未確定の明示を回し、人間が最小スキーマ（因果・境界・不変条件・壊れ方・観測）を短時間で再構築できる状態に導く。トリガー条件: 新しいタスクやコード変更に着手する前（「この機能を修正して」「このバグを直して」）、未知のコードベースを理解する必要がある時、「オンボーディングして」「作業開始の準備をして」「コードを理解したい」、複雑なタスクを始める前の文脈理解が必要な時、「作戦ブリーフを作成して」「安全に始められるようにして」、AIエージェント自身の着手前チェック（preflight、要件・境界・検証・観測のボトルネック解消、ready/partial/blocked判定）が必要な時。

コードのAI可読性を分析し、生成AIがバグ修正や変更を行う際に苦戦する原因となる問題を特定するスキル。以下の場合に使用する：(1)「AIが修正しやすいコードか分析して」「AI可読性を診断して」と依頼された時 (2) バグ修正や変更作業が難航している原因を調査したい時 (3) コードベースのAIフレンドリー度を評価したい時 (4) リファクタリング優先度を決めたい時。分析観点：コンテキストウィンドウ問題、命名・表現問題、構造・設計問題、テスト・検証問題、ドキュメント問題、LLM特有の苦手パターン

境界条件・エッジケースの観測。null/空/0/最大値/最小値/オーバーフロー/タイムゾーン等を網羅的にテスト。Use when: テスト設計、バリデーション実装、パーサー実装、日付/金額処理、例は通るが端で壊れる疑い、バグ修正後の再発防止。

コード変更に対して永続的なコメント（Why・制約・境界条件）を自動付与する。差分の依存グラフを解析し、2パス処理（意図マップ構築→役割別コメント生成）でレビュアーと将来の開発者の理解を助ける。「コメントを付けて」「アノテーションして」「レビューしやすくして」「comment annotation」と言われた時に使用する。

依存関係の取り違えを検出する観測。lockfile固定、クリーンビルド、統合スモークで再現性を担保。Use when: 依存追加/更新、CI設定、ローカルでは動く問題、新環境セットアップ、バージョン差異の疑い。

GitHub Projectの管理スキル。ghコマンドを使用してプロジェクトの確認、アイテム追加・状態変更、フィールド更新を行う。トリガー条件: 「Projectを確認して」「プロジェクトのアイテム一覧」「Project #N を見せて」、「IssueをProjectに追加」「PRをProjectに紐付け」、「ステータスをDoneに変更」「フィールドを更新」、「カンバンを操作」「タスクの進捗を更新」。

コード変更の影響範囲分析スキル。変更が引き起こし得る影響を影響面（code/interface/data/external/config/runtime/security/observability）ごとに整理し、「どこをレビューし、何をテストし、何を観測すべきか」を根拠つきで提示する。トリガー条件: 「影響範囲を分析して」「この変更の影響は？」「どこまで波及する？」、PRレビュー依頼時、リファクタ/仕様変更時、障害対応で「原因箇所の周辺影響」を確認したい時。注意: 変更の是非の最終判断は行わない。実行時にしか分からない挙動は推定と不確実性を提示する。

Issueの初期トリアージスキル。Issueを受け取り、標準化された分析結果（分類・深刻度・影響スコープ・不確実性・次アクション参照）を生成する。GitHub/Jira/Linear等のトラッカーからissue_payload形式で受け取る。トリガー条件: 「Issue #N を分析して」「このIssueの深刻度は？」「このバグはCritical？」、「Issue本文を初期トリアージして」「Issueを取り込んで」、新しいIssueを受け取り、最初の分類・判断が必要な時。注意: 根本原因の断定、修正案の確定、優先度の最終決定は行わない（材料提供まで）。

Issueワークフロー統括スキル。Issue受領から実装・検証・PRレビュー完了までを、分類に応じたテンプレートで統括し、フェーズ成果物を構造化して引き継ぎながら進行する。トリガー条件: 「Issue #N を修正して」「#N を直してPRまで」「/fix-issue 123」「/orchestrate-issue 123」Issue修正の全体統括が必要な時。注意: 実装そのもの、コード生成、レビュー判断の最終決裁は行わない（該当スキルへ委譲し、統括は状態と根拠の整合性を担保する）

LLM生成システムの検証設計スキル。assay-kitフレームワークを活用し、LLM特有の失敗モード（幻覚、例への過学習、部分的処理）を考慮した総合的なテストケース設計を支援する。使用タイミング: LLMベースのワークフロー/エージェントの評価設計時、ゴールデンデータセット（golden-dataset.yaml）の設計・拡張時、既存テストが特定パターンに過学習していないか検証時、LLM出力の品質スコアラー設計時、「なぜこのテストケースが必要か」の根拠を示す時。

観測の最小セットを適用。6つの失敗モード（仕様誤解/境界条件/依存/セキュリティ/並行性/運用）を継続可能なコストで網羅。Use when: プロジェクト開始、リリース前チェック、品質改善振り返り、観測が足りているか確認したい。

.envファイルのシークレットを1Password CLIで管理する（平文.envの保存・Git流出対策。AIからの秘匿は対象外）。migrate/run/sync/addをサポート。

運用観測性の確保。ログ、メトリクス、ヘルスチェック、設定検証でバグを扱う能力を担保。Use when: デプロイ前チェック、障害調査が困難、原因不明、ログ設計、メトリクス設計、設定管理実装。

PRのCI失敗を自動診断・修正し、成功するまでリトライするスキル。GitHub Actionsの実際のログを取得し、エラーを構造化分類して優先順位順に修正する。トリガー条件: 「CIを修正して」「CI直して」、「PR #N のCIが落ちている」、PRのCI失敗を自動修正したい時、「CIが通るまで直して」、「/pr-ci-responder」。

PR作成時に生成AIがPR本文にオンボーディングを記述するスキル。変更の契約を、レビューア・将来の自分・障害対応者に渡す。理解の再現性・反証可能性・運用可能性を同時に成立させる。トリガー条件: PRを作成する時（「PRを作成して」「プルリクを書いて」）、PR本文を充実させたい時（「PR説明を書いて」「PRオンボーディングして」）、変更の影響を整理したい時（「この変更の影響範囲を整理して」）、レビューの準備をする時（「レビュー用に変更をまとめて」）。

セキュリティ観測。認可漏れ、インジェクション、機密漏えい、暗号誤用、依存脆弱性を検出。Use when: 認証/認可実装、外部入力処理、依存更新、コミット前チェック、セキュリティレビューして、脅威分析が必要な時。

ユニットテストとPBT（Property-Based Testing）を組み合わせた体系的テスト設計スキル。「脳を使う場所」を原因推理から「プロパティとジェネレータの設計」へ移動させる。4つの成果物（ユニットテスト、プロパティカタログ、ジェネレータ群、反例コーパス）を固定し、意地悪レベル（L0-L8）を段階的に上げながら、反例を資産化して回帰テストに回収する。トリガー条件: 「体系的にテスト設計して」「テストを設計して」、「PBTでテスト設計して」「プロパティベーステストを書いて」、「ユニットテストを設計して」「テストケースを作成して」、「テストをもっと意地悪にして」「境界値を網羅して」、「ジェネレータを設計して」「反例を資産化して」、「テストの穴を探して」「プロパティカタログを作成して」、ELDのGroundフェーズでL1-L3テスト設計時。

要求トレーサビリティ（REQ→TCND→TEST）とカバレッジモデルによりテスト設計の抜け漏れを防止する監査スキル。モデル化・複数視点監査で体系的に検証する。Use when: テスト設計、テスト計画作成、QA開始前、「テスト漏れがないか不安」と感じた時

不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証済み仮説をLaw（LDE）に昇格させる。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき、または検証結果のLaw化を求められたとき。

Analyze a disposable prototype across 10 quality axes using static analysis, test results, and Codex MCP triangulation. Produces structured autopsy report with scored findings and recommendations. Part of H-DGM cycle. Use after disposable-spike completes.

Orchestrate the full H-DGM (Hybrid Disposable Generation Method) disposable prototyping cycle. Manages spike-autopsy-distill iterations with Mode A (auto) or Mode B (manual) control. Tracks cycle history and graduation readiness. Use to start or continue a disposable prototyping session.

Generate a disposable prototype (spike) from requirements. Creates isolated branch, generates code, runs lint/test/coverage, and produces unified metrics. Part of H-DGM (Hybrid Disposable Generation Method) cycle. Use when starting a new disposable prototype, rapid exploration, or throwaway implementation.

高リスク変更時にgit worktreeで隔離環境を作成するスキル。eld-predict-lightでMedium以上と判定された変更に安全な実験環境を提供する。「worktreeで隔離して」「安全な環境で試して」「実験的に変更して」「失敗しても大丈夫なように」等で使用。大規模リファクタリングやアーキテクチャ変更時にも使う。

実行時Law違反監視スキル。本番環境でのLaw違反を検知し、分析結果を記録して継続的改善を促す。使用タイミング: 本番ログからLaw違反を分析する時、「Law違反を確認して」、運用中のLaw健全性をチェックする時、違反パターンから新Lawを発見する時。

ELD v2.3 接地検証+PRレビュー統合スキル。2軸評価（Grounding Level G0-G4 × Evaluator Quality E0-E3）+TDD統制。verify: Law/Term接地チェック+完成度確認。review: PRレビュー（Artifact-Based + 行レビュー必須領域）。full: verify+review一括実行。使用タイミング: PR作成前の接地確認、PRレビュー、「Groundingチェックして」「PRレビューして」、Law/Term追加後の接地完了確認。

ELD v2.3 Predict-Lightゲート。変更の影響度をP0/P1/P2で自動判定し、適切な検証深度を決定する。フルPredictの代わりに軽量ゲートとして機能。使用タイミング: Change前の自動判定、「影響度を判定して」「P0/P1/P2を判定して」、実装前のリスク評価、段階化計画の策定。

Context Delta の収集・検証・構造化・知識移転を一貫実行する。開発知識をtasks/lessons.mdやADRとして永続化する。「記録して」「知識を整理して」「引き継ぎ資料を作って」等で使用。

タスクを親→子→孫に分解し、コンテキスト継承を設計し、並列実行を最適化する計画スキル。大きなタスクの実装計画・分解・並列化が必要な時に使う。

要件の曖昧さを能動的に発見する対話的ブレインストーミングスキル。Issue Contract作成前に、Law/Term観点、境界条件、失敗モードから多角的質問を生成する。「要件を明確にして」「要件をブレストして」「要件の曖昧さをチェックして」「何が不明確か教えて」等、新機能開発の最初期（Issue Contract作成前）に使用。ELD Phase 1: Issueの前段階として自動実行される。

Evidence-Loop Development (ELD) v3 - 証拠で回す統合開発手法。5+1フェーズ（Sense→Spec→Change→Ground→Record+Predict-Lightゲート）でコード観測・Spec規範・安全な変更・知識管理を統一ループで実行する。「ELDで進めて」「証拠ループで実装して」「コードベースを理解して」「影響範囲を分析して」「Specを定義して」「Termをカード化して」「安全に変更して」「証拠パックを作成して」「コンテキスト駆動で実装して」「ELDでデバッグして」「法則視点でバグ調査して」等で使用。新機能開発、バグ修正、リファクタリング、障害調査に対応。

ELD SpecのLaw Card・Term Card作成統合スキル。ビジネス上の「守るべき条件」（Law）およびドメインの語彙（Vocabulary/Term）を標準フォーマットで文書化する。使用タイミング: 新しいLaw/Termを追加する時、既存Law/Termを更新する時、Law Catalog/Vocabulary Catalogに新規エントリを追加する時、Grounding Mapを更新する時、Discovery後にCard化する時。

コードベースや要件からVocabulary（語彙）とLaw（守るべき条件）を自動発見するスキル。名辞抽象（Term/Type）と関係抽象（Law/制約）の両方を抽出し、/eld-spec-card term および /eld-spec-card law への入力を生成する。使用タイミング: 新規プロジェクトでVocabulary/Lawを洗い出す時、既存コードからLaw/Termを抽出する時、「Lawを発見して」「語彙を抽出して」、ELD Specをレトロフィットする時、初期Catalogを作る時。