Menu
セキュリティ観測。認可漏れ、インジェクション、機密漏えい、暗号誤用、依存脆弱性を検出。Use when: 認証/認可実装、外部入力処理、依存更新、コミット前チェック、セキュリティレビューして、脅威分析が必要な時。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | security-observation |
| context | fork |
| description | セキュリティ観測。認可漏れ、インジェクション、機密漏えい、暗号誤用、依存脆弱性を検出。Use when: 認証/認可実装、外部入力処理、依存更新、コミット前チェック、セキュリティレビューして、脅威分析が必要な時。 |
セキュリティバグは生成コードで最も"損失が大きい"失敗モードで、レビューで見落としやすい。 このスキルは、破局（情報漏えい・不正操作）の確率を下げる。
以下の3点を明確化する（これがないとテストも静的解析も焦点が合わない）：
| 観点 | 質問 |
|---|---|
| 境界 | どこからが外部入力か？ |
| 資産 | 守るべきデータは何か？ |
| 権限 | 誰が何をできるべきか？ |
鍵・トークン・パスワードの混入をスキャン：
# gitleaks
gitleaks detect --source . --verbose
# truffleHog
trufflehog filesystem .
# git-secrets
git secrets --scan
lockfile前提で脆弱性をスキャン：
# Node.js
npm audit
# Python
pip-audit
# Go
govulncheck ./...
# Rust
cargo audit
権限がない主体で必ず失敗することを検証：
def test_admin_endpoint_requires_admin_role():
# 一般ユーザーでログイン
token = login_as("user@example.com")
# 管理者エンドポイントへアクセス → 403
response = client.get("/admin/users", headers={"Authorization": f"Bearer {token}"})
assert response.status_code == 403
チェックすべき境界：
攻撃っぽい入力を当てる：
MALICIOUS_INPUTS = [
"'; DROP TABLE users; --", # SQLi
"<script>alert('xss')</script>", # XSS
"../../../etc/passwd", # Path traversal
"{{7*7}}", # SSTI
]
@pytest.mark.parametrize("payload", MALICIOUS_INPUTS)
def test_input_is_sanitized(payload):
response = client.post("/api/search", json={"query": payload})
# 実行されずエスケープされていること、または拒否されること
assert response.status_code in [200, 400]
assert payload not in response.text # 反射されていない
詳細は references/threat-catalog.md を参照。
┌─────────────────────────────────────┐
│ 信頼境界内 │
│ ┌─────────┐ ┌─────────────┐ │
─────────────────►│ │ API │───►│ Database │ │
外部入力 │ │ Gateway │ │ (資産: PII) │ │
(信頼境界外) │ └─────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Auth Service│ │
│ │ (資産: 認証情報) │
│ └─────────────┘ │
└─────────────────────────────────────┘
| エンドポイント | anonymous | user | admin | owner_only |
|---|---|---|---|---|
| GET /public | ✅ | ✅ | ✅ | - |
| GET /profile | ❌ | ✅ | ✅ | self |
| PUT /profile | ❌ | ✅ | ✅ | self |
| GET /admin | ❌ | ❌ | ✅ | - |
| DELETE /users | ❌ | ❌ | ✅ | - |
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）から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.