MCP HubMCP Hub
SKILL·CE90AE

what-if-oracle

K-Dense-AI
업데이트됨 5 days ago
8 조회
48,722
4,378
48,722
GitHub에서 보기
테스팅aitesting

정보

what-if-oracle 스킬은 유리한 상황, 불리한 상황, 불확실한 변수 등 구조화된 시나리오를 생성하여 개발자들이 연구 및 프로젝트 계획을 스트레스 테스트할 수 있도록 돕습니다. 이 스킬은 명시적인 가정, 근거, 그리고 대응 계획 수립을 위한 결정 계기를 제공합니다. 불확실성 하에서 잠재적인 미래를 탐색하는 데 사용할 수 있으며, 이는 보정된 예측이 아닌 서술형 시나리오를 제공한다는 점에 유의하세요.

빠른 설치

Claude Code

추천
기본
npx skills add K-Dense-AI/claude-scientific-skills -a claude-code
플러그인 명령대체
/plugin add https://github.com/K-Dense-AI/claude-scientific-skills
Git 클론대체
git clone https://github.com/K-Dense-AI/claude-scientific-skills.git ~/.claude/skills/what-if-oracle

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

What-If Oracle — Research Scenario Planning

Explore a bounded set of possible futures before committing research resources. The output is a scenario comparison, an evidence ledger, and a contingency plan. It does not cover the full possibility space or establish that a narrated mechanism will occur.

The six branch prompts and 0·IF·1 mnemonic come from the upstream What-If framework. Treat the mnemonic as a framing aid: a potential change (0), a stated condition (IF), and a resulting scenario (1). It is not a scientific law or a computational model.

The author's What-If Paradigm and Unified Theory of Digital Consciousness are catalogued by Zenodo as preprints. Their deposit and DOI establish provenance, not forecasting accuracy or empirical validation of this workflow.

When to use

Use for questions such as:

  • What if sample attrition is higher than planned?
  • What if a method fails to transfer to a new instrument, cohort, or site?
  • What if a key reagent, dataset, or measurement becomes unavailable?
  • Which research option remains feasible under competing hypotheses or resource constraints?

Keep the analysis attached to a scientific decision. This is not a general business, personal advice, or software architecture skill. If the question requires an intervention effect, a power calculation, or a numerical simulation, identify the required design/model and evidence; do not manufacture those results with scenario prose.

No package, API endpoint, credential, or network connection is required for the qualitative workflow. Verify current external facts when they matter, or label the analysis as based only on supplied material. For research-specific prompts and a worked example, see references/scenario-templates.md.

Phase 1 — Frame the question and evidence

Write one operational question containing:

  • Decision and comparator: what can be changed, and what happens under the current plan?
  • Perturbation: the main variable, magnitude, units, and any coupled changes. Do not assume other variables remain fixed when the mechanism links them.
  • Horizon and system: population, site, protocol, and time window to which the answer applies.
  • Outcome and constraints: measurable success/failure criteria, budget, capacity, and irreversible consequences.
  • Baseline: observations and their dates, separated from assumptions and desired targets.

For example: "If the usable-sample fraction is 60% rather than the planned 80%, can a batch of 100 samples deliver 80 usable samples this month, and which contingency should we prepare?" Both fractions may be planning assumptions until supported by data.

Use the user's supplied framing when sufficient. State reasonable working assumptions and proceed; ask for a missing fact only when it materially changes the analysis.

Maintain a short evidence ledger: claim, source or data version/date, relevant population/protocol, uncertainty, and status (observed, model-derived, or assumed). Record conflicting evidence. An LLM-generated rationale is not an additional observation or an independent expert assessment.

Phase 2 — Explore scenario branches

Select distinct scenarios suited to the question, usually four to six. A short screening can use favorable, reference, and adverse scenarios. The labels below are exploration lenses, not mutually exclusive outcomes or a probability distribution.

LensWhat to examineScientific boundary
Ω Favorable (best case)Favorable conditions within justified boundsNot a proven upper limit; specify whose outcome improves
α Reference caseA stated baseline or central set of assumptionsCall it "likely" only if comparative evidence supports that ranking
Δ Adverse (worst case)Plausible failures, including dependent failuresNot a proven lower limit or the worst imaginable outcome
Ψ Wild cardA concrete disruption outside the main assumptionsDo not claim to enumerate unknowable events or assign a rarity from the label
Φ ContrarianAn alternative to a dominant hypothesisEvaluate supporting and disconfirming evidence; disagreement alone is not support
∞ Second orderDownstream effects, delays, feedback, or changed behaviorCan occur within any other scenario; mark untested mechanisms as hypotheses

Retain important shared drivers and correlations across branches. Avoid implausible combinations created by independently toggling quantities that share a cause. Use descriptive scenario names in the final output so favorable/adverse labels do not substitute for evaluation.

Phase 3 — Analyze and challenge each branch

Use a compact record:

Scenario: [name and lens]
Condition and horizon: [operational definition]
Assumptions: [including dependencies and boundary conditions]
Evidence: [source/data version, supporting and conflicting observations]
Mechanism: [conditional narrative; identify untested causal links]
Consequences: [outcomes, units, range, and relevant time points]
Likelihood: [not estimated, or justified estimate with method and uncertainty]
Evidence confidence: [reasoned assessment, separate from event likelihood]
Discriminating observation: [what would weaken this scenario or favor another]
Trigger and response: [observable measure, threshold, review time, owner, action]
Residual risk: [what this response does not resolve]

For quantitative claims, show inputs, units, method, assumptions, and whether the calculation was executed. Distinguish variation in future outcomes from uncertainty in the inputs or model. Sensitivity checks should vary decision-critical assumptions, including plausible joint changes, and identify where the preferred action changes.

For causal claims, specify the intervention, comparator, population, outcome, and horizon. An observational association or a changed prediction is not by itself an intervention effect. State the identification assumptions and supporting design; for observational adjustment these include consistency, exchangeability, and positivity. A scenario can motivate a controlled pilot or measurement, but cannot replace that evidence. See the author's maintained Causal Inference: What If, especially Chapters 1–3, for this distinction.

Phase 4 — Compare responses and define the next check

Compare candidate actions against the scenarios using a table of outcome, cost, feasibility, reversibility, and unresolved assumptions. Include the current plan. State which objective or trade-off determines the recommendation.

  • Robust actions: identify actions that remain acceptable across the tested scenarios, with their costs and exceptions. Robustness within the tested set is not a guarantee across all futures.
  • Contingencies: specify conditional actions and lead times; account for the cost of preparing a backup even when it is never used.
  • Decision triggers: record the measurement, threshold, review date, and responsible role. A trigger can be a practical operating rule without being a statistical test or proof of a mechanism.
  • Next evidence: identify the smallest feasible pilot, control, or observation that could change the choice. If none of the current evidence distinguishes scenarios, say so.

Do not turn a recommendation into an executed experiment, purchase, or protocol change. The deliverable is the analysis and proposed response unless the user separately requested execution.

Probability and confidence

Use "not estimated" when evidence cannot support a numerical probability. If a probability is useful, define the event and horizon, identify a relevant base rate or fitted model, and record estimation uncertainty and transfer limitations. Qualitative plausibility is not a hidden numeric score. Confidence concerns the strength and consistency of evidence; it is not the probability that an event happens. This distinction is also used in the IPCC uncertainty guidance.

Normalize only a mutually exclusive, collectively exhaustive outcome partition under the same conditioning assumptions and horizon. For example, the final number of usable samples from one fixed batch of 100 can be partitioned as 0–59, 60–79, and 80–100. That defines valid outcome bins, but supplies no probabilities for them. The six scenario lenses do not form such a partition.

Keep resource allocation separate from event likelihood. A 61.8/38.2 golden-ratio allocation is not justified by this workflow. Choose allocations from evidence, consequences, costs, capacity, reversibility, and the stated objective.

Modes

  • Quick screening: three distinct scenarios, critical assumptions, and the next observation. Brevity does not establish evidence quality.
  • Detailed analysis: more scenarios and explicit sensitivity/decision comparisons; allocate time to evidence gathering as needed, without promising a high-stakes analysis in minutes.
  • Scenario chain: expand a decision-relevant branch, including adverse or ambiguous ones. Keep each child conditional on its parent. For probabilities, use P(A and B) = P(A) × P(B given A), not a product of marginal probabilities without justified independence. Stop when added detail cannot change the action or lacks evidence.
  • Reverse planning: work backward from a target to candidate prerequisites and test their feasibility. A plausible path is not proof of necessity, sufficiency, or likelihood.
  • Stakeholder comparison: evaluate the same scientific scenarios from researcher, participant, facility, or funder perspectives. Different preferences are not independent corroborating evidence.

Method and source boundaries

The current Government Office for Science Futures Toolkit distinguishes scenarios from predictions and describes stress-testing options across possible futures. This skill adapts those general distinctions to research contingencies; the toolkit does not validate these six particular lenses, their probabilities, or a prescribed number of branches.

This documentation-only skill contains no forecast engine or causal estimator. Its worked example is synthetic and illustrates planning arithmetic, not demonstrated improvement in real research outcomes.

License and adaptation

© 2026 Ashraf Hussein Kahoush / AHK Strategies. Licensed under CC BY-NC-SA 4.0. Commercial use requires a license from the author. This repository adaptation narrows the workflow to research planning and revises evidence, probability, and causal-claim guidance; it preserves attribution to the upstream framework and preprints.

GitHub 저장소

K-Dense-AI/claude-scientific-skills
경로: skills/what-if-oracle
0
agent-skillsai-scientistbioinformaticschemoinformaticsclaudeclaude-skills
FAQ

자주 묻는 질문

what-if-oracle Skill이란 무엇인가요?

what-if-oracle은(는) K-Dense-AI이(가) 만든 Claude Skill입니다. Skill은 Claude가 필요할 때 불러오는 지침과 리소스를 묶어 추가 프롬프트 없이 what-if-oracle 관련 작업을 수행할 수 있게 합니다.

what-if-oracle은(는) 어떻게 설치하나요?

이 페이지의 설치 명령을 사용하세요. what-if-oracle을(를) Claude Code 플러그인으로 추가하거나 저장소를 skills 디렉터리에 복제한 다음 Claude를 다시 시작해 Skill을 불러옵니다.

what-if-oracle은(는) 어떤 카테고리에 속하나요?

what-if-oracle은(는) 테스팅 카테고리에 속합니다.

what-if-oracle은(는) 무료로 사용할 수 있나요?

네. what-if-oracle은(는) AIMCP에 등록되어 있으며 무료로 설치할 수 있습니다.

연관 스킬

evaluating-llms-harness
테스팅

이 Claude Skill은 MMLU, GSM8K를 포함한 60개 이상의 표준화된 학술 과제에서 LLM 성능을 벤치마크하기 위해 lm-evaluation-harness를 실행합니다. 개발자들이 모델 품질을 비교하고, 학습 진행 상황을 추적하거나 학술 결과를 보고할 수 있도록 설계되었습니다. 이 도구는 HuggingFace와 vLLM 모델을 포함한 다양한 백엔드를 지원합니다.

스킬 보기
cloudflare-cron-triggers
테스팅

이 스킬은 cron 표현식을 사용하여 Worker를 스케줄링하기 위한 Cloudflare Cron Triggers 구현에 관한 포괄적인 지식을 제공합니다. 주기적 작업, 유지보수 작업, 자동화된 워크플로우 설정 방법을 다루며, 잘못된 cron 표현식이나 시간대 문제 같은 일반적인 이슈들을 해결하는 방법을 포함합니다. 개발자들은 이를 통해 스케줄된 핸들러 구성, cron 트리거 테스트, Workflows 및 Green Compute와의 연동 작업을 수행할 수 있습니다.

스킬 보기
webapp-testing
테스팅

이 Claude Skill은 Python 스크립트를 통해 로컬 웹 애플리케이션을 테스트하기 위한 Playwright 기반 툴킷을 제공합니다. 프론트엔드 검증, UI 디버깅, 스크린샷 캡처, 로그 확인 기능을 지원하며 서버 라이프사이클을 관리합니다. 브라우저 자동화 작업에 사용하되 컨텍스트 오염을 방지하기 위해 소스 코드를 읽지 않고 스크립트를 직접 실행하세요.

스킬 보기
finishing-a-development-branch
테스팅

이 스킬은 테스트 통과를 확인한 후 체계적인 통합 옵션을 제시하여 개발자가 완성된 작업을 마무리하도록 돕습니다. 구현이 완료된 후 머지, PR 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.

스킬 보기