القائمة
Secret 管理 4 方式（Vault dynamic / Vault static via ESO / Vault Transit / SealedSecret）の健全性を一括チェック — Vault seal 状態、ESO 同期、SealedSecret 復号、関連 cert をまとめて診断
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Longhorn の健全性チェック — volume robustness（degraded 検出）、node 容量、R2 バックアップの鮮度、recurring job の動作状況を一括診断
Scaffold a new infrastructure component, choosing the right layout (Helm multi-source / raw YAML / ApplicationSet) for its category
Create a new Sealed Secret — generates raw secret, seals it with kubeseal, and places it in the correct resources/ directory
Troubleshoot a specific infrastructure component — resolve namespace, check pods, events, logs, and Argo CD sync status
全 Helm Application の chart バージョン鮮度を一括チェック — 各 app.yaml の targetRevision を upstream 最新と突き合わせ、更新候補を優先度付きでレポート（/helm-upgrade の前段）
OpenAI Codex に作業を委譲する。コードレビュー、セカンドオピニオン、別解の生成、調査・分析を Codex にやらせたいとき（「Codex にレビューさせて」「Codex に聞いて」「Codex の意見も欲しい」等）に使う。
| name | secret-health |
| description | Secret 管理 4 方式（Vault dynamic / Vault static via ESO / Vault Transit / SealedSecret）の健全性を一括チェック — Vault seal 状態、ESO 同期、SealedSecret 復号、関連 cert をまとめて診断 |
| argument-hint | null |
4 方式が併用されているため（SoT: docs/secret-management/index.md）、障害時の切り分けに必要な状態を 1 回で横断確認する。
Vault 本体:
kubectl get pods -n vault -o wide
kubectl exec -n vault vault-0 -- vault status
Sealed: false を確認。sealed なら以降の ESO / dynamic creds は全滅するので最優先で報告vault status の HA Mode: active の pod が現リーダーvault-aws-kms-credentials（SealedSecret、vault ns）— これが壊れると再起動時に unseal できないClusterSecretStore（ESO ↔ Vault の接続）:
kubectl get clustersecretstore -o wide
vault-backend が Valid / Ready であること。ここが死んでいると全 ExternalSecret が巻き添えExternalSecret 同期状態（Vault static 方式）:
kubectl get externalsecret -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,STORE:.spec.secretStoreRef.name,REFRESH:.spec.refreshInterval,STATUS:.status.conditions[0].reason,READY:.status.conditions[0].status'
SecretSynced / True 以外を列挙。SecretSyncedError は Vault path の存在・token 権限を疑うSTORE が <none> の行は異常ではなく generator 参照（dataFrom.sourceRef.generatorRef、下記 step 4）の ExternalSecretconditions[0] は配列順序依存。判定が怪しい場合は素の kubectl get externalsecret -A（READY/STATUS 列）と突き合わせるDynamic creds（ESO generator 方式、DB credential 系）:
# このクラスタは VSO ではなく ESO generator (generators.external-secrets.io) を採用
kubectl get vaultdynamicsecret.generators.external-secrets.io -A
kubectl get externalsecret -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,GEN:.spec.dataFrom[0].sourceRef.generatorRef.name' | grep -v '<none>'
must be owner of table 42501）。これは secret 配布ではなく Vault DB role 定義側の問題として切り分けるSealedSecret 復号状態:
kubectl get sealedsecret -A
# controller は kube-system に居る（sealed-secrets ns ではない）
kubectl logs -n kube-system -l app.kubernetes.io/name=sealed-secrets --tail=50 | grep -iE "error|unable" || echo "no decryption errors"
|| echo が誤って正常表示する。先に kubectl get pods -A -l app.kubernetes.io/name=sealed-secrets でヒットを確認すること/sealed-secret で再封緘を提案Secret 消費側の整合:
kubectl get pods -A --field-selector=status.phase=Pending -o wide 2>/dev/null
kubectl get events -A --field-selector reason=FailedMount,type=Warning 2>/dev/null | head -20
CreateContainerConfigError / FailedMount を検出spec.target.name は ES 名と異なることがある（例: ES postgres-polaris → Secret postgres-polaris-cred）。Secret 不在の判定は target 名で行うReloader の生存確認（rotation の最終工程）:
kubectl get pods -n reloader
Summary:
/troubleshoot <component> への導線を示す/cert-check を案内（本 skill では深追いしない）