init-workspace

init-workspace

短い確認のやり取りの後、充実した自己完結型のテンプレート、または同じスタイルで作成したカスタムのスキャフォールドを使って、すぐに作業を始められる、ノート中心のナレッジプロジェクトを作成します。作成されるものには、フォルダーツリーと、レイアウトを説明し、作業を適切なスキルに振り分けるAGENTS.mdが含まれます。選択したテンプレートやヒアリング内容に応じて、ワークスペース内のreferences/とObsidianの_dashboard/（Dataview）も追加します。

使用する場面

ユーザーがノート中心のナレッジプロジェクトを始めるにあたり、その構造や規約も整えたい場合に使用します。学習、調査、執筆、大学院などへの出願、試験対策、プレゼンテーション、理論、または主な成果物がノートや文書となるその他の活動について、「…のためのワークスペースやボルトを設定／開始／初期化／スキャフォールド／ブートストラップしたい」といった依頼があれば起動します。この範囲内で、8つのテンプレートに一致しない依頼にはカスタムの方法で対応します。

使用しない場面

• ユーザーが実際の後続作業（このエッセイを添削して、導入部を書いて、この補題を証明して）を求めている場合は、ここではなく該当分野のスキルに振り分けます。
• プロジェクトがすでに存在し、構造化されている場合。このスキルはスキャフォールドを作成しますが、再構成はしません。（マージルールを参照。再実行しても安全ですが、既存のレイアウトは再構成されません。）
• 仮説検証を迅速に行うためのコードベースの構成（ソースコードのレイアウト）には、research-codebaseを使用します。ここのpaperテンプレートは執筆用のボルトであり、コード構成はそのスキルに委ねます。
• ユーザーがソフトウェアリポジトリ、アプリケーション、パッケージ、ウェブサイト、データパイプライン、その他のコーディングプロジェクトを求めている場合。このスキルが作成するのはナレッジワーク用のボルトであり、「プロジェクトを始めたい」と言われた場合でも、ソースコードのスキャフォールドは作成しません。

テンプレート一覧

8つのテンプレートは出発点であり、選択肢はこれだけではありません。以下の確認ヒアリングで、いずれかに明確に当てはまらない依頼にもスキャフォールドを作成する方法を説明します。

種類	用途	AGENTS.mdが最初に案内するスキル
learn-a-topic	不慣れな分野を幅広く学び始める	flow-learn-new-topic
ielts	IELTSライティングの練習サイクル（取り組み → フィードバック → 上達）	ielts-learning-planner
paper	1本の研究論文のアイデアから投稿、成果物まで	flow-paper-lifecycle
phd-application	博士課程／研究職への出願サイクル全体	flow-phd-application
research-notebook	継続的な研究上の問い、アイデア、根拠、判断、統合	whiteboard-peer
study-notes	各回の学習サイクル：記録 → 展開 → 演習、2つのフォルダー	professor-mentor-technical-teaching
talk	講演／プレゼンテーションの構成からスライド作成まで	research-talk-planner
theory	理論／証明プロジェクトの主張から証明、検証まで	flow-idea-to-proof

テンプレートのうち2つは、理由は正反対ですが、AGENTS.mdのみを用意します。ieltsにはフォルダーとダッシュボードを用意しますが、references/はありません。インストール済みのielts-*スキルに、すでにバンド記述とフィードバック集約機能が含まれているためです。study-notesは意図的に最もシンプルなテンプレートとしており、フォルダーは2つだけで、references/、_dashboard/、agents/はありません。記録を素早く行うワークフローにファイルの分類判断を増やすファイルを配置するのではなく、AGENTS.mdに手法全体を記載します。ほかの6つのテンプレートには、ワークスペースを自己完結型にするため、それぞれ独自のreferences/を用意します。

学習がセッション単位（コースや読書シリーズなど）で構成され、各回につきノート1つと演習ファイル1つを作成する場合はstudy-notesを選びます。不慣れな分野の全体像を把握するなど、情報源とサブトピック単位で構成される場合はlearn-a-topicを選びます。どちらも学習に使いますが、判別の基準は整理の軸です。

エージェント共通プロトコル

2つのプロトコルはすべてのテンプレートで共通しているため、テンプレートごとに複製するのではなく、信頼できる唯一の情報源としてtemplates/_shared/agents/に置いています。この2つは成果物のサイズに応じて使い分ける一対のプロトコルです。pipeline.mdは実質的な成果物を対象とし、note-method.mdはその基準に満たないすべての成果物を対象とします。

note-method.md — キャプチャ → 展開 → 保存 → クエリ。 すべてのテンプレートの契約では、小さなメモはパイプラインを省略すると定めています。このファイルは、そうしたメモが代わりに従う手順を示すため、「パイプラインを省略する」が「方法がない」という意味ではなくなります。日常的な一連の流れ（断片的な内容をざっとキャプチャし、セッション後に展開して構造化して保存し、思い出すためではなく場所を特定するためにクエリする）、文章が読みやすくなった後も生のキャプチャ内容をメモ内に保持し、削除しないというルール、そしてフロントマターとセクション見出しを装飾ではなく重要な要素とする検索の契約が含まれています。根拠に関する主張には、認識論上の位置づけが明記されています。構造化形式が非構造化形式を上回ることは裏付けられている一方、LLM による展開は保持効果が測定されていない効率面のみのものであり、「デジタルだと簡単に感じるので浅いに違いない」という見方には異論があると記されています。そのため、ナレッジベースが研究の示す範囲を超えて断定することはありません。

pipeline.md — 根拠 → 下書き → レビュー → 検証。 成果物自身のファイル内で実行する、単一の4段階プロトコルです。パイプラインの実行中は、根拠の表とレビューが必要な項目を作業ファイル内に保持し、最後にSourcesセクションへまとめます。そのため、パイプラインによって段階ごとのサイドファイル（research.md／draft.md／review.md／cited.md）が作成されることはなく、最終的な出力は厳密に1つのファイルになります。サイズ基準により対象を実質的な成果物に限定し、それより小さいものは同じOperating contractのもとでnote-method.mdに従います。

どちらも汎用的で、エージェント間の移植が可能です。特定のランタイムのツールに依存せず、必要な機能、整合性ルール、出力契約を示しています。スキャフォールド作成時には両方のファイルが<vault>/agents/にコピーされるため、ワークスペースは自己完結型で移植可能な状態を保ちます。

agents/フォルダーが含まれるのはフルパイプラインのテンプレートのみで、そこには両方のファイルが含まれます。対象はpaper、theory、learn-a-topic、research-notebookです。これらのテンプレートのAGENTS.mdのOperating contractでは、実質的な研究成果物には4段階の手順を、小さなメモにはメモの手順を適用するよう定めています。talk、phd-application、ielts、study-notesの各テンプレートは、より軽量な根拠重視の契約（no-code + source-grounded + mark-uncertainty。パイプラインなし）を使用するため、agents/フォルダーは含まれません。study-notesでは、必要なキャプチャ → 展開 → 保存 → クエリのルールをAGENTS.mdに直接記載しています。agents/を追加すると、フォルダーを2つに限定する保証が崩れるためです。

事前確認

メニューに触れる前に、短く、まとめて一度だけ確認の質問をします。いくつかにとどめ、面接のようにしないでください。

1. どのような作業で、何をもって「完了」としますか？ プロジェクトと最終成果物についてのユーザー自身の説明です（提出済みの論文、合格したテスト、予定が決まった講演、合格した出願、習得したトピック、またはノートを中心としたその他の知識成果など）。
2. プロジェクトのタイトルと対象ディレクトリ。 現在のディレクトリの正確なパスを示してデフォルトとして提案し、ユーザーに確認するか、別の場所を指定してもらいます。この確認項目への回答が書き込みの承認となるため、同じ確認を繰り返さないでください。
3. 一般的なケースと異なる点はありますか？ たとえば、単独の論文ではなくサーベイ、共著またはパネル形式の講演、複数の試験対策を組み合わせたコース、研究以外の証明プロジェクト、複数の論文にわたる出願サイクルなどです。これによって、以下の「そのまま使う」「調整する」「個別に作成する」のどれにするかが決まります。「特にない。標準的な X です」という回答も有効で、テンプレートをそのまま使えます。

確認は一度だけにしてください。元の依頼ですでに回答が示されている場合は、最初から尋ね直すのではなく、理解した内容をまとめて確認してください。この3項目の回答を超えて詳しい説明を求めないでください。ユーザーが回答したら、その同じターンで足場を作成してください。

手順

1. 明確化のためのヒアリングを実施（上記）し、進め方を決めます。
   • そのまま使用 — 説明が8種類のテンプレートのいずれかに該当し、明示された差異がありません。そのテンプレートを変更せずに使用します。
   • 調整 — 1種類に該当するものの、明示された差異があります。そのテンプレートをベースに、差異に応じて必要な箇所だけを調整します。具体的には、Layout のフォルダーを追加または削除し、references/ ファイルを追加または絞り込み、AGENTS.md の文章（タイトル、Layout、振り分け、タイプのラベル、パス固有の Operating contract の文言）を編集して反映します。ベースのテンプレートに適用される動作上の保証は維持します。具体的には、非コーディングのナレッジワーク、ソースに基づく記述または捏造の禁止、明示的な不確実性の表記、忠実な報告、該当する場合の入力チェック、該当する場合の単一ファイルのパイプラインルール、Merge rules、および Obsidian の書式設定です。ただし、調整後の Layout と契約が一致するよう、フォルダー名とタイプ固有の記述は更新します。agents/note-method.md と note-method の参照ファイルは常に一緒に扱います。learn-a-topic の study-method.md と research-notebook の note-types-and-review-rhythm.md は、どちらも記録方法をこのファイルに委ねています。そのため、調整後の vault にどちらかの参照ファイルを残す場合は agents/ も残す必要があります。agents/ を削除する場合は、vault に存在しないファイルへの参照を残さず、記録方法を参照ファイルに組み込んでください。
   • 個別設計 — 7種類のどれにも当てはまりません。この vault 専用の足場を作成します（このリポジトリの templates/ には決して書き込まないでください）。ほかのテンプレートと同じ構成に沿って、回答に応じた規模のフォルダーツリーと、必須セクション（タイトル、Operating contract、Layout、作業に適合する既存スキルへの振り分け、Obsidian の書式設定ルール）を備えた完全な AGENTS.md を作成します。Operating contract では、作業をノート中心かつ非コーディングと定義し、捏造を禁止し、主張を含む場合はソースに基づく記述と不確実性の明示を求め、完了した作業のみ報告し、下流のスキルを実行する前に必須の入力ノートを確認するよう定めます。作業がソースに基づく大規模な統合や研究成果物である場合は、フルパイプラインのテンプレートと同様に templates/_shared/agents/pipeline.md と templates/_shared/agents/note-method.md の両方も agents/ にコピーします。回答で明確に必要とされない限り、_dashboard/ や references/ は省略します。個別設計の足場は、8つ目の大型テンプレートではなく、ヒアリングで正当化される範囲で簡潔にします。 ヒアリングを終えても2種類の間に実質的な曖昧さが残る場合は、推測せず、どちらにするか質問してください。
2. 確定したターゲットディレクトリを使用します。ヒアリング項目2へのユーザーの回答を確定とします。進捗報告では確定したパスを明記しますが、再確認のために作業を止めないでください。
3. テンプレートを読む。「そのまま使用」または「調整」の場合は、templates/<type>/AGENTS.md を開きます。その Layout セクションをフォルダー一覧の正とし、そこから始めて必要な調整を適用します。「個別設計」の場合は読むべきテンプレートファイルがありません。ヒアリングの回答から AGENTS.md と Layout を直接作成し、構成の参考として最も近い既存テンプレートの形に合わせます。
4. フォルダーツリーを作成します。「調整」または「個別設計」の内容を反映した Layout にあるフォルダーをすべて作成し、空のフォルダーには .gitkeep を追加します。
5. 初期ファイルをコピーまたは作成します。「そのまま使用」の場合は、テンプレートの AGENTS.md、references/、_dashboard/ をターゲットに変更せずコピーします（Merge rules を参照）。「調整」の場合はコピーしてから指定された編集を適用します。「個別設計」の場合は、AGENTS.md と、ヒアリングで必要とされた references/／_dashboard/ を直接作成します。フルパイプライン契約を含むテンプレート（paper、theory、learn-a-topic、research-notebook）または個別設計のソースに基づく統合・研究成果物の場合は、templates/_shared/agents/pipeline.md と templates/_shared/agents/note-method.md の両方を <vault>/agents/ にコピーし、両方のプロトコルが vault と一緒に移動するようにします。talk、phd-application、ielts、study-notes および研究以外の個別設計の足場では、軽量なソース根拠のみの契約を使用し、agents/ フォルダーは作成しません。
6. エントリーファイルのひな形を作成します。<vault>/CLAUDE.md に @AGENTS.md の1行だけを記述します。これにより、CLAUDE.md を読み込んで @ インポートをたどる Claude Code では運用契約が自動で読み込まれ、AGENTS.md をネイティブに読み込むエージェント（Codex など）には影響しません。こうして AGENTS.md を唯一の信頼できる情報源とし、どのランタイムでも vault の動作を同じにします。ielts と個別設計を含め、どのパスでもこれを実施してください。（Merge rules を参照 — 既存の CLAUDE.md を決して上書きしないでください。）
7. 1行のタイトルを記入します。ユーザーがプロジェクト名を提示した場合は、AGENTS.md の先頭にあるプロジェクトタイトルのプレースホルダーをその名前に置き換えます。提示されていない場合は、プレースホルダーをそのまま残します。
8. 報告します。作成したもの、選択した進め方（そのまま使用／調整／個別設計）とその理由を列挙し、最初に実行するスキル（上記の表、または個別設計の場合は適合する既存スキル）を示して、次に何をすればよいかが分かるようにします。

マージルール

既存のディレクトリに対して再実行しても安全です。マージし、上書きはしません。 これらのルールは、そのまま使う、適応する、独自に作成するのいずれの場合にも同様に適用されます。ユーザーがすでにスキャフォールディング済みの保管庫を明示した場合は、インテークでその対象と、不足を補うために必要な情報のみを確認してください。既存のワークスペースを再構成したり、設計し直したりしてはいけません。

• 不足しているフォルダーを作成し、既存のフォルダーには手を加えません。
• シード済みファイルまたは独自作成のファイルは、保存先に同名のファイルが存在しない場合にのみ書き込みます。既存の AGENTS.md、参照資料、ダッシュボード、agents/ 内のファイル、コンテンツファイルを上書きしてはいけません。ユーザーの作業や編集内容が含まれている可能性があります。
• 旧パイプラインの移行（唯一の例外）。 <vault>/agents/ に廃止された4つの役割ファイル（researcher.md、reviewer.md、verifier.md、writer.md）がある場合、それらはユーザーのコンテンツではなく、旧ステージ別設計のシード済みファイルです。保管庫に競合するプロトコルが2つ残らないよう、削除して代わりに pipeline.md と note-method.md を配置することを提案してください。削除する前にユーザーの確認を取り、変更したとユーザーが述べたファイルは、4つのうち該当するものを残してください。
• AGENTS.md がすでに存在する場合は置き換えず、ワークスペースにすでにあることを報告して、それ以上触れないでください。
• CLAUDE.md がすでに存在する場合は置き換えないでください。ユーザー独自のインポートやメモリが含まれている可能性があります。AGENTS.md をまだ取り込んでいない場合は、ユーザー自身で @AGENTS.md を追加できるよう、そのことを報告してください。

注意事項

• テンプレートは Obsidian の保管庫（YAML フロントマター、[[wikilinks]]、_dashboard/ の Dataview）を想定しています。フォルダーは通常のフォルダーなので、コードエディターでも使用できます。Obsidian 専用なのはダッシュボードのみです。
• シード済みおよび生成された Markdown は、ハードラップではなくソフトラップを使用します。各段落やリスト項目は物理的に1行に保ち、Obsidian に視覚的な折り返しを任せてください。新しい段落や Markdown の構造を作る場合にのみ物理的な改行を挿入し、列幅に収めるためだけに改行してはいけません。
• 確認のやり取りは意図的に短く、要件の聞き取りではありません。質問は3つ、まとめて1回、1ターンで行います。目的は、そのまま使う／適応する／独自に作成するのいずれかに振り分け、タイトルとディレクトリを決めることです。完全な仕様を引き出すことではありません。7種類のうちいずれかを明確に指定し、違いについての記載がないリクエストのほとんどは、これまでどおりカスタマイズなしのそのまま使うに該当します。
• このスキルの実行によって、リポジトリの templates/ ディレクトリに書き込むことはありません。適応する場合も独自に作成する場合も、出力先は対象の保管庫のみです。永続的なテンプレートセットの拡充は、意図的に行う別個のリポジトリ変更です（このリポジトリの CLAUDE.md にあるスキル作成規約を参照）。このスキルがユーザーに代わってスキャフォールディングの途中で行うものではありません。
• このスキルは自己完結しています。すべてのテンプレートは、ここの templates/ 配下にあります。