القائمة
観測の最小セットを適用。6つの失敗モード（仕様誤解/境界条件/依存/セキュリティ/並行性/運用）を継続可能なコストで網羅。Use when: プロジェクト開始、リリース前チェック、品質改善振り返り、観測が足りているか確認したい。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）から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.
| name | observation-minimum-set |
| context | fork |
| description | 観測の最小セットを適用。6つの失敗モード（仕様誤解/境界条件/依存/セキュリティ/並行性/運用）を継続可能なコストで網羅。Use when: プロジェクト開始、リリース前チェック、品質改善振り返り、観測が足りているか確認したい。 |
観測は"バグを見つける手段"というより、失敗モードごとに、間違いが露出する場所を作る技術。 このスキルは、6つの失敗モードを継続可能なコストで薄くカバーする。
| # | 失敗モード | 典型的な症状 | 関連スキル |
|---|---|---|---|
| 1 | 仕様誤解 | 型もテストも通るのに"違うもの" | spec-observation |
| 2 | 境界条件漏れ | 例は通るが端で壊れる | boundary-observation |
| 3 | 依存取り違え | ローカルでは動くのに本番で死ぬ | dependency-observation |
| 4 | セキュリティ | 認可漏れ、機密漏えい | security-observation |
| 5 | 並行性 | 通常テストが通るのに本番で死ぬ | concurrency-observation |
| 6 | 運用不能 | 原因不明、ログがない、復旧できない | operability-observation |
継続可能な"最小セット"として、以下の5つを必須とする：
[ ] 仕様の例（少数）＋否定例をテスト化
[ ] 仮定ログを成果物として残し、差分レビュー対象にする
[ ] lockfile固定＋CIで固定破り即fail
[ ] クリーン環境でのビルドがCIで回る
[ ] 型チェック/コンパイルが通る
[ ] lint（静的解析）がエラー0
[ ] 外部境界ごとに最小・最大・空・異常のテスト
[ ] 重要箇所に性質テスト1本
[ ] lockfile固定
[ ] 依存脆弱性スキャン（npm audit / pip-audit等）
[ ] Secret scan（gitleaks等）
[ ] 起動時設定検証（fail fast）
[ ] ヘルスチェック（liveness/readiness）
[ ] 構造化ログ＋相関ID＋エラー分類
[ ] 最低限メトリクス（エラー率・レイテンシの2つでも）
[ ] レース検出/サニタイザをCIで回す
[ ] ストレステスト1本
[ ] タイムアウト＋飽和メトリクス
各最小セットがどの失敗モードに効くか：
| 失敗モード | 1.仕様 | 2.ビルド | 3.境界 | 4.供給網 | 5.運用 | 6.並行 |
|---|---|---|---|---|---|---|
| 仕様誤解 | ◎ | △ | ○ | △ | ○ | - |
| 境界条件 | ○ | ○ | ◎ | △ | ○ | △ |
| 依存取違 | △ | ○ | △ | ◎ | ○ | - |
| セキュリティ | △ | ○ | ○ | ◎ | ○ | △ |
| 並行性 | - | △ | △ | - | ○ | ◎ |
| 運用不能 | ○ | △ | △ | ○ | ◎ | ○ |
凡例：◎強い ○中程度 △限定的 -効果なし
assets/observation-checklist.md を使って、現在の観測状況を診断する。
最小セットと現状の差分を特定し、優先順位を付ける。
優先順位の基準：
テストのオラクル（期待値）の独立性を守る
observation-checklist.md: 現状診断チェックリストobservation-gap-report.md: ギャップレポート## 観測現状診断 (2024-01-15)
### 1. 実行可能仕様 ＋ 仮定ログ
- [x] 受入テストあり（ただし否定例が不足）
- [ ] 仮定ログなし
### 2. ビルド ＋ 型 ＋ lint
- [x] lockfile固定
- [x] 型チェック
- [x] lint
### 3. 境界値 ＋ 性質テスト
- [ ] 境界値テスト（API入力のみ、DB境界なし）
- [ ] 性質テストなし
### 4. 供給網
- [x] lockfile固定
- [ ] 脆弱性スキャンなし
- [ ] secret scanなし
### 5. 運用観測性
- [x] ヘルスチェックあり
- [ ] 設定検証なし（起動後にクラッシュする可能性）
- [ ] 構造化ログなし
- [ ] メトリクスなし
### 優先対応
1. secret scan導入（即日）
2. 仮定ログの運用開始（今週）
3. 設定検証の実装（来週）