Science

カスタマイズ

実行する前に、次の場所にユーザーによるカスタマイズがないか確認してください： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Science/

このディレクトリが存在する場合は、そこにある PREFERENCES.md、設定、リソースを読み込み、適用してください。これらはデフォルトの動作より優先されます。ディレクトリが存在しない場合は、スキルのデフォルト設定で進めてください。

🚨 必須：音声通知（アクションを起こす前に必ず実行）

このスキルが呼び出されたら、ほかのことをする前に必ずこの通知を送信してください。

1. 音声通知を送信：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the Science skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力：

   Running the **WorkflowName** workflow in the **Science** skill to ACTION...
   

これは任意ではありません。このスキルが呼び出されたら、直ちにこの curl コマンドを実行してください。

Science - 万能アルゴリズム

概要

科学的手法を汎用的な問題解決アルゴリズムとして適用します。まず目標を定義し、複数の仮説を立て、失敗する可能性のある実験を設計し、誠実に測定し、目標に照らして分析し、反復します。7つのコアワークフローに加え、2つの診断用ショートカット（15分で行う迅速なデバッグと、複数要因を扱う体系的な調査）があります。ミクロ（TDD）からメソ（機能の検証）、マクロ（MVP のリリース）まで拡張できます。

課題

ほとんどの問題解決は、仕事をしているように見せかけた当てずっぽうです。最初に思いついたアイデアを選び、何かを変更し、「よくなったように見える」時点で完了とします。しかし、それは進歩ではなく確証バイアスです。成功の定義が明確でなければ、変更が役に立ったかどうか判断できないため、いつまでも調整を続けたり、早々にやめたりします。仮説を1つだけ立てる考え方では、すでに信じているアイデアしか検証できません。このスキルは、明示された目標、少なくとも3つの競合する仮説、反証可能なテスト、そして期待ではなく目標と比較する測定によって、こうした問題を解決するための規律を徹底します。

仕組み

全体は1つの反復サイクルです。そして、その軸となるのが目標です。成功基準が明確でなければ、結果を判断できません。

GOAL -----> What does success look like?
   |
OBSERVE --> What is the current state?
   |
HYPOTHESIZE -> What might work? (Generate MULTIPLE)
   |
EXPERIMENT -> Design and run the test
   |
MEASURE --> What happened? (Data collection)
   |
ANALYZE --> How does it compare to the goal?
   |
ITERATE --> Adjust hypothesis and repeat
   |
   +------> Back to HYPOTHESIZE

答えは、当てずっぽうではなく、このサイクルから導き出されます。

---

ワークフローの振り分け

実行時に出力： Running the **WorkflowName** workflow in the **Science** skill to ACTION...

コアワークフロー

ワークフロー	トリガー	ファイル
DefineGoal	「目標を定義する」「何を達成しようとしているのか」	Workflows/DefineGoal.md
GenerateHypotheses	「何がうまくいくか」「アイデア」「仮説」	Workflows/GenerateHypotheses.md
DesignExperiment	「どうやってテストするか」「実験の設計」	Workflows/DesignExperiment.md
MeasureResults	「何が起きたか」「測定」「結果」	Workflows/MeasureResults.md
AnalyzeResults	「分析」「目標と比較」	Workflows/AnalyzeResults.md
Iterate	「反復する」「もう一度試す」「次のサイクル」	Workflows/Iterate.md
FullCycle	体系的なサイクル全体	Workflows/FullCycle.md

診断ワークフロー

ワークフロー	トリガー	ファイル
QuickDiagnosis	迅速なデバッグ（15分ルール）	Workflows/QuickDiagnosis.md
StructuredInvestigation	複雑な調査	Workflows/StructuredInvestigation.md

---

リソース一覧

リソース	説明
Methodology.md	各フェーズの詳細
Protocol.md	スキルにおける Science の実装方法
Templates.md	目標、仮説、実験、結果のテンプレート
Examples.md	さまざまな規模での実例

---

分野別の適用例

分野	適用例	関連スキル
コーディング	TDD（レッド・グリーン・リファクタリング）	Development
製品	MVP -> 測定 -> 反復	Development
研究	問い -> 調査 -> 分析	Research
プロンプト	プロンプト -> 評価 -> 反復	Evals
意思決定	選択肢 -> 協議会 -> 選択	Council

---

適用規模

レベル	サイクル時間	例
マイクロ	数分	TDD：テスト、コード作成、リファクタリング
メゾ	数時間〜数日	機能：仕様策定、実装、検証
マクロ	数週間〜数か月	製品：MVP、ローンチ、PMF の測定

---

統合ポイント

フェーズ	呼び出すスキル
目標	検証には Council
観察	コンテキストの調査には Research
仮説	アイデア出しには Council、ストレステストには RedTeam
実験	並列テストには Development（Worktrees）
測定	構造化された測定には Evals
分析	多角的な分析には Council

---

アンチパターン

悪い例	良い例
「もっと良くして」	「読み込み時間を 3 秒から 1 秒に短縮する」
「X がうまくいくと思う」	「X、Y、Z の 3 つのアプローチがあります」
「自分が正しいと証明して」	「反証できるテストを設計する」
「失敗しなかったことにする」	「何を学びましたか？」
「いつまでも実験を続ける」	「リリースして、本番環境から学ぶ」

---

注意点

• テストの前に、最低 3 つの仮説を立ててください。 仮説を 1 つだけ検証するのは確証バイアスです。いきなり 1 つのテストに進むのは科学ではなく、試行錯誤です。
• 測定は具体的かつ再現可能でなければなりません。 「良くなった気がする」は測定ではありません。
• 完全なサイクルは体系的な調査のためのものです。 素早いデバッグには、クイック診断モードを使用してください。

例

例 1：クイック診断

User: "figure out why Surface time filters show stale items"
→ Quick diagnosis mode
→ Hypothesis: timestamp format mismatch in D1
→ Test: query D1 for actual stored format
→ Analyze: compare stored vs expected format
→ Result: ISO string vs Unix timestamp mismatch

例 2：体系的な完全調査

User: "experiment with different prompt structures for better output"
→ Full cycle mode
→ 3+ hypotheses generated
→ Controlled experiments with measurements
→ Analysis identifies winning approach
→ Iterates until convergence

実行ログ

ワークフローの完了後、JSONL エントリを 1 つ追記してください：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Science","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED は実行したワークフローに、8_WORD_SUMMARY は入力の簡単な説明に、SECONDS はおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。