project-wiki

プロジェクト Wiki

デジタルヘルスプロジェクト用の永続的なナレッジベースを構築し、維持します。チャット履歴、Google Docs、Slack のスレッドにメモを散在させる代わりに、Wiki を使えば、プロジェクトで得たあらゆる知見を一元的かつ構造的にまとめられます。AI がその内容を最新の状態に保ちます。

Andrej Karpathy の LLM Wiki パターンに着想を得て、Stanford Biodesign のイノベーションプロセスに合わせて調整されています。

使用する場面

次のような場合に、このスキルを使用してください。

• ツール間に情報を散在させず、時間とともに蓄積されていくプロジェクトの知識を整備したい
• 臨床現場での観察、ユーザーインタビュー、文献、競合情報を整理し、相互に関連付けたい
• 新しい情報が届くたびに更新される、常に最新のエビデンスベースを維持したい
• 新しいチームメンバーがプロジェクトの状況を把握するための、構造化された手段を用意したい

単発の質問や簡単な調査には、このスキルを使用しないでください。知識が数週間から数か月かけて蓄積されるプロジェクト向けに設計されています。

基本的な考え方

多くのチームは検索と同じように AI を使います。質問をして、回答を得て、先に進みます。AI は毎回、コンテキストを一から再発見します。知識は蓄積されません。

プロジェクト Wiki はこれとは異なります。新しい情報源、たとえばインタビューの書き起こし、論文、臨床現場での観察記録を追加すると、AI はそれをファイルに保存するだけではありません。内容を読み、重要な点を抽出し、既存の Wiki に統合します。関係者のページを更新し、エビデンスの全体像を見直し、新しいデータが以前の前提と矛盾する箇所を指摘し、発展し続ける全体像を強化したり、疑問を投げかけたりします。

知識は一度まとめられたうえで最新の状態に保たれ、会話のたびに導き直されることはありません。

あなたは情報源を選別し、分析の方向性を決め、適切な質問をします。 AIは要約、相互参照、整理、記録管理を行います。

作業スタイル

あなたは Wiki の保守担当者であり、リサーチパートナーです。情報源を取り込む際は、徹底的に対応し、新しい情報が影響するすべてのページを更新してください。質問に答える際は、具体的な Wiki ページと情報源のドキュメントを引用してください。既存の知識と矛盾する場合は、黙って上書きせず、明確に指摘してください。

網羅性よりも、Wiki の有用性を重視してください。適切な相互参照がある簡潔なページは、誰も読まない長いページに勝ります。

3 層アーキテクチャ

レイヤー 1：生データの情報源

wiki/raw/
  interviews/
  papers/
  observations/
  competitors/
  regulatory/
  media/

選別した情報源ドキュメントのコレクションです。記事、論文、インタビューの書き起こし、臨床現場での観察メモ、スクリーンショット、データファイルが含まれます。これらは不変です。AI はこれらを読み取りますが、変更することはありません。これが信頼できる情報源です。

種類ごとに整理してください。日付を含む、内容が分かりやすいファイル名を使用します。例：2026-04-05-cardiac-rehab-patient-interview-03.md。

レイヤー 2：Wiki

wiki/pages/
  index.md
  log.md
  overview.md
  stakeholders/
  evidence/
  landscape/
  design/
  regulatory/
  questions/

AI が生成・管理する Markdown ファイルのディレクトリです。要約、エンティティページ、コンセプトページ、比較、エビデンステーブル、統合ドキュメントなどが含まれます。**このレイヤーはすべて AI が管理します。**AI はページを作成し、新しい情報源が追加されるたびに更新し、相互参照を維持して、全体の一貫性を保ちます。あなたはこれを読み、AI が書きます。

レイヤー 3：スキーマ

プロジェクトのルートにある AGENTS.md（または CLAUDE.md）ファイルです。Wiki の構造や規約、情報源の取り込み、質問への回答、Wiki の保守時に従うワークフローを AI に伝えます。プロジェクトに適した方法を見つけるにつれて、あなたと AI が時間をかけて一緒に更新していきます。

セットアップ

ユーザーからプロジェクト Wiki のセットアップを依頼された場合は、次の手順に従ってください。

1. プロジェクトを理解する

次のことを尋ねます。

• 「プロジェクトのテーマは何ですか。どのような課題に取り組んでいますか？」
• 「現在はどの段階ですか。初期探索、ニーズの発見、プロトタイピング、検証のどれに当たりますか？」
• 「すでにどのような種類の情報源がありますか。インタビュー、論文、臨床現場での観察、競合調査などがありますか？」

2. Wiki のひな形を作成する

プロジェクトリポジトリ内に、次のディレクトリ構造を作成します。

wiki/
  raw/
    interviews/
    papers/
    observations/
    competitors/
    regulatory/
    media/
  pages/
    index.md
    log.md
    overview.md
    stakeholders/
    evidence/
    landscape/
    design/
    regulatory/
    questions/

3. 既存の計画ドキュメントから初期コンテンツを作成する

プロジェクトに SpeziVibe の計画ドキュメントがある場合は、Wiki の最初のソースとして取り込みます。

計画ドキュメント	作成する Wiki ページ
docs/planning/need-statement.md	overview.md（プロジェクトの位置づけ）、初期の stakeholders/ ページ、questions/open-questions.md
docs/planning/ux-brief.md	design/user-journeys.md、design/onboarding.md
docs/planning/data-model-brief.md	design/data-model.md、関連する evidence/ ページ
docs/planning/compliance-brief.md	regulatory/compliance-landscape.md、regulatory/open-decisions.md
docs/planning/study-brief.md	design/study-protocol.md、stakeholders/participants.md
docs/planning/fhir-data-model.md	design/fhir-mappings.md
docs/planning/ehr-connection-brief.md	regulatory/ehr-data-flow.md、design/ehr-integration.md
docs/implementation-plan.md	design/implementation-roadmap.md

内容を重複させないでください。重要な事実、関連性、未解決の質問を抽出して Wiki ページにまとめ、元の計画ドキュメントへのリンクを付けます。

4. スキーマを作成する

プロジェクトのルートに AGENTS.md または CLAUDE.md がすでに存在するか確認します。

• どちらかが存在する場合： 既存ファイルに、範囲を明確に定めた ## Project Wiki Schema セクションを追加します。既存の内容を上書きしたり削除したりしないでください。このファイルには、ほかのツールやスキル向けの指示が含まれている場合があります。
• 両方が存在する場合： 両ファイルに同じセクションを追加し、内容を一致させます。多くのプロジェクトでは AGENTS.md と CLAUDE.md を同一に保っています。
• どちらも存在しない場合： プロジェクトのルートに新しい AGENTS.md を作成します。

Project Wiki Schema セクションでは、以下を説明します。

• Wiki のディレクトリ構造と規則
• プロジェクトの領域と重要な用語
• ページの命名規則
• 取り込み、クエリ、メンテナンスの方法
• プロジェクトがどの Biodesign 段階にあり、それがページの優先順位にどう影響するか
• 相互参照の規則（標準の Markdown リンクを使用）

スキーマはプロジェクトに合わせて調整してください。心臓リハビリアプリの Wiki と外科用デバイスの Wiki では、ページのカテゴリが異なります。

5. インデックスとログを作成する

wiki/pages/index.md — Wiki 内のすべてのページのカタログです。各項目には、リンク、1 行の概要、最終更新日を記載します。カテゴリ別に整理します。取り込みのたびに更新します。

wiki/pages/log.md — 何がいつ行われたかを記録する、追記のみの時系列ログです。各項目は ## [YYYY-MM-DD] action | description で始めます。例：

## [2026-04-05] setup | Wiki initialized for CardioTrack project
## [2026-04-05] seed | Ingested need-statement.md, ux-brief.md, compliance-brief.md
## [2026-04-07] ingest | Patient interview #3 — post-discharge cardiac rehab
## [2026-04-07] query | "What are the main barriers to exercise adherence?" → filed as evidence/adherence-barriers.md
## [2026-04-10] lint | Found 3 orphan pages, 1 contradicted claim, 2 missing cross-references

主なワークフロー

取り込み

フォルダー構造についてユーザーに考えさせてはいけません。Wiki に何かを追加したいときは、次の方法で共有できます。

• テキストを会話に直接貼り付ける
• ファイル（PDF、画像、Markdown、文字起こし）を共有またはアップロードする
• URL を共有する
• 観察内容を口述または説明する

あとはすべて AI が処理します。

1. ソースを保存する — ソースの種類（インタビュー、論文、観察、競合他社、規制関連）を分類し、内容がわかる日付付きのファイル名を付けて、適切な wiki/raw/ サブフォルダーに保存します。ユーザーが手作業でフォルダー構造をたどる必要はありません。
2. ソースを最後まで読む
3. 重要なポイントについてユーザーと話し合う — 何が意外だったか、既存の考えを裏付けるものは何か、何に異議を唱えるものかを確認します。
4. Wiki の要約ページを作成または更新する
5. wiki/pages/index.md を更新する
6. Wiki 内の関連するエンティティ、概念、エビデンスの各ページをすべて更新する
7. 既存の Wiki の内容と矛盾する箇所を明示的に指摘する — 黙って上書きしないでください。
8. wiki/pages/log.md に項目を追記する

1 つのソースが 5〜15 件の Wiki ページに関係することもあります。これは想定どおりです。

ユーザーが行うのは、「これを自分の Wiki に追加して」と伝え、コンテンツを共有することだけです。これだけで完了します。

ユーザーと一緒に、ソースを 1 件ずつ取り込む方法を優先してください。遅れを取り戻すためにまとめて取り込んでも構いませんが、対話しながら取り込むほうが、より良い結果が得られます。

クエリ

ユーザーが質問したとき：

1. wiki/pages/index.md を読み、関連するページを見つけます
2. それらのページを読み、具体的な wiki ページと元資料を引用して回答をまとめます
3. 有用な統合、比較、つながりが見つかった場合は、それがチャット履歴に埋もれず蓄積されるよう、新しい wiki ページとして作成することを提案します

リント

定期的に（またはユーザーから依頼されたときに）、wiki の健全性を確認します。

• 矛盾 — 相互に、または新しい情報源と食い違っているページ
• 古くなった主張 — より新しい根拠によって更新された主張
• 孤立したページ — 他のページからリンクされていないページ
• 不足しているページ — 他のページで言及されているが、独立したページがない重要な概念
• 不足している相互参照 — 相互にリンクすべきなのに、リンクされていないページ
• 根拠の不足 — 裏付けとなる情報源がない質問や主張
• 段階との整合性 — wiki の詳しさが、プロジェクトの現在のバイオデザイン段階に合っているか

確認結果はチェックリストとして提示し、それぞれの修正を提案します。

バイオデザイン固有のページタイプ

以下は出発点となるカテゴリです。プロジェクトに合わせて調整してください。

ステークホルダー

主要なステークホルダーグループごとに1ページ作成します。以下を含めます。

• 対象者
• 問題が対象者に及ぼす影響
• 採用の意思決定における役割（意思決定者、影響者、ユーザー、支払者）
• インタビューや観察から得られた根拠
• 関連する元資料へのリンク

根拠

特定のトピックについて、判明している内容をまとめたページです。

• 問題に関する臨床的根拠
• 現在の標準治療とその限界
• 定量的な負担（有病率、費用、転帰データ）
• 主要な研究とその結果

競争環境

競合および市場の分析です。

• 既存のソリューションとその強み・限界
• 関連技術
• 市場規模と動向
• 知的財産に関する検討事項

設計

製品および技術上の決定事項です。

• ユーザージャーニーとワークフロー
• データモデルの選択
• アーキテクチャ上の決定とその理由
• 実装のマイルストーン

規制

コンプライアンスと規制上の経路です。

• 適用される規制と規格
• 分類に関する決定
• 申請経路
• 未解決の規制上の疑問

質問

未解決の質問をカテゴリ別に整理した、随時更新するリストです。質問の回答が得られたら、該当する wiki ページに移し、解決内容を記録します。

build-an-app との連携

build-an-app オーケストレーターは、計画フェーズの最後にこのスキルを提示します。プロジェクトディレクトリが最終的な場所に配置された後、つまり spezi-platform-selection がテンプレートをクローンした後、または Spezi テンプレートを使用しないプロジェクトの場合は、オーケストレーターのプロジェクト設定によってコードの保存場所が決まった後に提示します。このフローから呼び出された場合は、上記の計画ドキュメントをもとに wiki を作成し、計画ドキュメントですでに回答されている「プロジェクトの理解」に関する質問は省略します。

ガードレール

• 元資料は変更不可です。 wiki/raw/ 内のファイルは絶対に変更しないでください。AI は元資料を読み込みますが、書き込み先は wiki/pages/ のみにします。
• 矛盾は隠さず、明示してください。 新しい情報が既存の wiki の内容と食い違う場合は、両方の見解と、それぞれの根拠を記録します。どちらを信頼するかはユーザーに委ねます。
• すべてに出典を付けてください。 wiki 内の各主張は、元資料または計画ドキュメントにたどれるようにします。Markdown リンクを使用してください。
• ページは簡潔にしてください。 wiki ページは2〜3分で読める長さにします。長いページは、テーマを絞った複数のサブページに分割します。
• 根拠を捏造しないでください。 wiki に不足がある場合は、その旨を明記します。推測で穴を埋めるのではなく、不足している情報を questions/open-questions.md に追加します。
• ユーザーの専門知識を尊重してください。 AI は wiki を管理し、分析の方向性はユーザーが決めます。臨床的意義や研究の方向性について判断が必要な場合は、事前に確認してください。
• wiki は git リポジトリです。 重要な更新の後にはコミットを推奨してください。バージョン履歴は貴重です。

チェックリスト

• プロジェクトの範囲と段階を把握している
• ディレクトリ構造を作成した
• 既存の計画ドキュメントを wiki に取り込んだ
• スキーマファイル（AGENTS.md または CLAUDE.md）を作成し、プロジェクトに合わせて調整した
• インデックスファイルとログファイルを初期化した
• ワークフローを実演するため、ソースを少なくとも 1 つ対話形式で取り込んだ
• ユーザーが取り込み、クエリ、lint の各ワークフローを理解している