メニュー
Use when a decision sounds reasonable but still needs pressure-testing before agreement, especially for scope, architecture, sequencing, or irreversible product trade-offs.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when asked to assess OpenShift cluster health, explain degraded status, troubleshoot control-plane issues, or produce a health report — including degraded operators, node issues, etcd problems, auth failures, ingress errors, certificate expiry, upgrade readiness, post-maintenance validation, pending pods, CrashLoopBackOff, scheduling failures, quota exhaustion, or OOMKilled pods.
Use when discovering, planning, installing, validating, hardening, upgrading, migrating, backing up, restoring, maintaining, uninstalling, or troubleshooting Longhorn on OpenShift/OKD — including Single Node OpenShift, dedicated disk preparation, V1 filesystem data disks, V2 block/SPDK data engine, oauth-proxy handling, SCC/MachineConfig workflows, StorageClass defaulting, and lifecycle safety.
Use when planning, installing, configuring, validating, upgrading, expanding, shrinking, backing up, restoring, maintaining, or troubleshooting LVM Storage (LVMS) on OpenShift/OKD — including Single Node OpenShift, multi-node clusters, volume group provisioning, thin pool configuration, TopoLVM CSI filesystem and raw block volumes, volume group expansion, disk management, StorageClass defaulting, and lifecycle safety.
Use when planning, installing, configuring, validating, upgrading, expanding, shrinking, backing up, restoring, maintaining, or troubleshooting Red Hat OpenShift Data Foundation (ODF) on OpenShift/OKD — including Single Node OpenShift, multi-node clusters, internal mode with Local Storage Operator disks, StorageCluster sizing, ceph-rbd block, cephfs shared filesystem, Multicloud Object Gateway (MCG/NooBaa) and RGW object storage, OLM operator lifecycle, and default StorageClass safety.
Use when planning, installing, configuring, validating, upgrading, expanding, shrinking, backing up, restoring, maintaining, or troubleshooting Rook Ceph on OpenShift/OKD — including Single Node OpenShift, multi-node clusters, dedicated block disks for OSDs, CephBlockPool RBD, CephFS filesystem, CephObjectStore RGW/S3, host networking, device discovery, stretch clusters, PG/PGP tuning, and operator lifecycle safety.
Use when the user asks to simplify, clean up, refactor, tidy, reduce complexity, improve readability, or review code quality in any programming language — including direct rewrites, refactor reviews, readability passes, and targeted cleanup before a PR.
| name | challenging-decisions |
| description | Use when a decision sounds reasonable but still needs pressure-testing before agreement, especially for scope, architecture, sequencing, or irreversible product trade-offs. |
Normal assistants often challenge weak decisions through only one practical lens, and they can still agree first on decisions that are probably right. This skill forces a better default: pressure-test first, then endorse only if the choice still holds up.
Challenge before agreement. Use named lenses instead of theatrical personas. Do not lead with agree-first language or early reassurance. If the decision still looks good after pressure-testing, say so after the pushback, not before it.
What concrete evidence makes this worth doing now instead of merely plausible?
What is the smallest version that still preserves learning or customer value?
Why now, and what trigger would justify doing it later instead?
What systems, dependencies, coordination cost, or operational burden does this add?
If this is wrong, how expensive is it to unwind, migrate, or explain away?
What better learning, revenue, or reliability work gets delayed if this wins the slot?
Use the fewest lenses that still surface the strongest counterarguments. Do not hide the sharpest objection just because the decision is probably correct.
Do not open with lines like “Yes, that makes sense” or “I’d keep the monolith for now.” Pressure-test first, then endorse if the choice survives.
Re-evaluate with the new evidence, state the remaining risk, and either endorse with conditions or propose the smaller move instead. If uncertainty remains, ask the next forcing question instead of drifting into vague agreement.
