project-init

プロジェクト初期化ワークフロー

研究プロジェクトを、単に2つの兄弟リポジトリとしてではなく、制御ルートとして初期化します。

エージェントが <ProjectName>/ から作業し、paper/、code/、および任意の slides/ が独立したコンポーネントリポジトリとして維持される、新しい ML 研究プロジェクトをユーザーが求めている場合に、このスキルを使用します。

このスキルは、以下と組み合わせて使用します。

• コンポーネント間で共有するメモリを初期設定するには、research-project-memory
• 論文リポジトリを作成するには、init-latex-project
• コードリポジトリを作成するには、init-python-project
• 外部の progress-slides テンプレートを使用して、任意のスライドリポジトリを作成または管理するには、research-slide-deck-builder
• コードの実験用ワークツリーや論文のバージョン別ワークツリーを作成するには、new-workspace
• SSH/HPC サーバーでコードを実行する場合は、remote-project-control
• GitHub CLI、リポジトリのリモート、または GitHub Project API の操作を行う場合は、remote-project-control または safe-git-ops
• 重要な Git 操作を行う前には、safe-git-ops

期待されるプロジェクト構成

デフォルトの構成：

<ProjectName>/
├── PROJECT.md
├── AGENTS.md
├── CLAUDE.md
├── memory/
│   ├── project.yaml
│   ├── component-index.yaml
│   ├── current-status.md
│   ├── decision-log.md
│   ├── claim-board.md
│   ├── evidence-board.md
│   ├── provenance-board.md
│   ├── risk-board.md
│   ├── action-board.md
│   ├── handoff-board.md
│   ├── phase-dashboard.md
│   └── source-visibility-board.md
├── paper/                 # independent LaTeX git repo
├── code/                  # independent Python/ML git repo
├── code-worktrees/         # sibling worktree root for code repo branches
├── paper-worktrees/        # sibling worktree root for paper venue/arXiv/camera-ready versions
├── .uv-envs/               # ignored shared uv environments for code repo/worktrees
├── reference/             # project-local sources, cards, processing state, and project-use notes
├── slides/                # optional independent git repo
├── reviewer/              # reviewer simulation state
├── rebuttal/              # real review and response state
├── artifact/              # artifact-evaluation and release handoff state
└── docs/
    ├── overview.md
    ├── designs/
    ├── experiments/
    ├── updates/
    ├── audits/
    └── timelines/

この構造は、リポジトリの README と asset/project-anatomy.png にあるプロジェクト構成図の、テキスト上の唯一の正として扱います。レイアウトを変更する場合は、スキルのテキストと図によるドキュメントを一緒に更新してください。

デフォルトでは、最上位に experiments/ ディレクトリを作成しないでください。実験の実行、実行サマリー、結果レポート、生のアーティファクトへのポインターは、code/ または該当するコードのワークツリー内に配置します。

ルートレベルの docs/ も有用ですが、プロジェクトレベルのドキュメントであり、コード側のエビデンスの代わりにはなりません。paper/、code/、slides/、レビュー、リバッタル、アーティファクト作業を調整する、段階的な手法設計、コンポーネント横断の実験計画、プロジェクト概要、監査、タイムライン、引き継ぎに使用します。

コード側のエビデンスを配置する推奨パス：

code/docs/results/         # stable result summaries, table notes, figure notes
code/docs/reports/         # experiment-report-writer outputs
code/docs/runs/            # run registry, job pointers, config and commit pointers

基本原則

• <ProjectName>/ はエージェント制御のルートです。
• paper/、code/、slides/ はコンポーネントリポジトリであり、単なるフォルダーではありません。
• code コンポーネントは、アルゴリズムの実装、実験の実行、実行記録、結果レポート、サーバー実行状態、コードのワークツリーを管理します。
• コードのワークツリーは、デフォルトでは code/ の中にネストしないでください。Git、IDE、検索ツール、エージェントがワークツリーを通常のソースファイルと混同しないよう、兄弟ルートの code-worktrees/ を使用してください。
• 同じプロジェクト内のコードワークツリーは、デフォルトで 1 つのコード用 uv 環境（例：<ProjectName>/.uv-envs/code）を共有し、アクティブなワークツリーから絶対パスの UV_PROJECT_ENVIRONMENT と uv run を使って呼び出します。依存関係、Python/CUDA スタック、破壊的なパッケージテスト、または実際の同時同期リスクがある場合に限り、ステージ専用の環境を作成してください。
• paper コンポーネントは、論文ソース、投稿先テンプレート、投稿モード、arXiv／公開ソースのクリーンアップ、カメラレディ版の改訂、論文のワークツリーを管理します。
• reference コンポーネントは、プロジェクト固有のソース（論文、共同研究者のドキュメント、メモ、仕様、スクリプト、バンドル）、ソースカード、処理状態、プロジェクトでの利用に関するメモ、ソースからプロジェクトへの引き継ぎを管理します。
• 論文のワークツリーは、デフォルトでは paper/ の中にネストしないでください。投稿先の変更、arXiv での公開、査読への回答に伴う論文の編集、カメラレディ版のブランチには、兄弟ルートの paper-worktrees/ を使用してください。
• 論文ソースの可視性は投稿先とは独立しています。paper/main が Overleaf にリンクされている、または共著者に見える場合は、非公開ではなく author-visible として扱い、そのブランチにエージェント専用ファイルを置かないでください。
• プロジェクトメモリーには、コンポーネントをまたいで保持する状態を保存します。ルートの docs/ にはプロジェクトレベルの設計・計画資料を、コードのドキュメントにはコード側の実装、実行、結果の詳細を保存します。
• ルート Git の使用は任意です。有効にする場合は、ユーザーが明示的にサブモジュールを希望しない限り、ネストされたコンポーネントリポジトリを誤ってコミットしないでください。
• GitHub Project は、任意で利用できるクラウド上の調整機能です。コンポーネントリポジトリをまたいで、共同研究者に見える issue、PR、ブロッカー、ロードマップビューを追跡します。ルートの memory/、コンポーネントの .agent/、リポジトリ固有のエビデンス用ドキュメントの代わりにはなりません。
• ツールチェーンのゲートは、プロジェクトの明示的なポリシーです。コード、論文、Git/GitHub、リモート実行、リリース、成果物の各ワークフローでは、その確認コマンド、変更ルール、最新状態の要件を記録し、場当たり的なエージェントの記憶に頼らないでください。

ステップ 1 - プロジェクト情報の収集

以下の項目について、1 回のメッセージで質問します。

1. プロジェクト名と親ディレクトリ。
2. 研究の概要：手法のアイデア、対象とする問題、データセット、ベースライン、評価指標、現在の成熟度。
3. 目標とする投稿先またはマイルストーン（分かっている場合）。
4. コンポーネントの選択：
   • 論文リポジトリ：新規作成、既存のものに接続、または今回はスキップ
   • コードリポジトリ：新規作成、既存のものに接続、または今回はスキップ
   • スライドリポジトリ：新規作成、既存のものに接続、またはスキップ
   • 参考資料ライブラリ：reference/ を作成、既存の PDF／ソースフォルダーに接続、初期ソースバンドルに接続、またはスキップ
   • レビュアー／反論／アーティファクト用の状態ディレクトリ：今作成するか、後で作成するか
5. Git のポリシー：
   • ルートのコントロールプレーン Git リポジトリ：有効／無効
   • 論文／コード／スライドの各コンポーネントのリモート（利用可能な場合）
   • コンポーネントリポジトリをサブモジュールにするか、ルート Git で無視するか
   • GitHub／GitLab リポジトリを今作成するか、作成する場合は gh auth status が有効かどうか
   • この研究プロジェクト用の GitHub Projects ボードを 1 つ作成またはリンクするか
   • デフォルトのツールチェーンのゲートを有効にするかどうか：
     • コード：uv、ruff、mypy、pytest、pre-commit
     • 論文：tex-fmt、submit-paper、Overleaf／GitHub のコンパイル証跡
     • 調整：git、gh、GitHub Projects／PR チェック
     • オプションの品質管理：gitleaks、shellcheck、shfmt、actionlint、nbstripout、taplo、yamllint、lychee
6. ワークツリーのポリシー：
   • デフォルトの兄弟ディレクトリルート：<ProjectName>/code-worktrees/
   • デフォルトの論文用兄弟ディレクトリルート：<ProjectName>/paper-worktrees/
   • 共有コード uv 環境のパス：デフォルトは <ProjectName>/.uv-envs/code
   • サーバーのワークツリールート（異なる場合）
   • ブランチの命名規則（あれば）
   • 論文ソースの可視性ポリシー：
     • paper/main を Overleaf／GitHub にリンクするかどうか
     • paper/main を author-visible にするか、agent-private にするか
     • .agent/、AGENTS／CLAUDE ガイダンス、生 CSV、プロットスクリプト、内部の結果ドキュメントを配置する場所

ファイルを作成する前に、ユーザーの回答を待ちます。

ステップ 2 - コントロールルートの作成

以下を作成します。

<parent-dir>/<ProjectName>/
├── memory/
├── docs/overview.md
├── docs/designs/
├── docs/experiments/
├── docs/updates/
├── docs/audits/
├── docs/timelines/
├── reference/.agent/runs/
├── reference/sources/
├── reference/cards/
├── reference/project-use/
├── reference/notes/
├── reference/summaries/
├── reviewer/.agent/
├── rebuttal/.agent/
├── artifact/.agent/
├── .uv-envs/
├── code-worktrees/
└── paper-worktrees/

ユーザーが今すぐスライドコンポーネントを希望する場合にのみ、オプションの slides/ を作成します。

ルート Git を有効にする場合は、<ProjectName>/ で初期化し、ユーザーがサブモジュールを明示的に希望しない限り、コンポーネントリポジトリとワークツリーを無視するルート .gitignore を追加します。

/paper/
/code/
/slides/
/.uv-envs/
/code-worktrees/
/paper-worktrees/

ユーザーがサブモジュールを希望する場合は、偶発的なネストされた Git の動作に頼らず、サブモジュールコマンドを意図的に使用します。

セットアップ中に GitHub／GitLab リポジトリを作成する場合は、まず gh auth status などでホスティング CLI の認証を確認します。認証に失敗した場合は、ローカルのワークスペースのセットアップを完了し、Git リモートの作成をブロッカーとして記録します。リポジトリ作成の失敗によって、プロジェクト初期化の結果が分かりにくくならないようにします。

ユーザーが GitHub Projects ボードを希望する場合：

1. ボードは、複数のリポジトリにまたがる 1 つの研究プロジェクト用の、任意のクラウド調整機能として扱います。
2. gh project ... コマンドの前に gh auth status を確認します。トークンに project スコープがない場合は、ユーザーに承認を求めるか、gh auth refresh -s project を実行するよう依頼します。
3. エージェントのランタイムがサンドボックスから macOS Keychain または GitHub API にアクセスできない場合は、ユーザーに何度もログインを求めるのではなく、GitHub Projects のセットアップをブロッカーとして記録します。
4. 所有者が明確になってから、プロジェクトを作成またはリンクします。所有者は @me／a-green-hand-jack などのユーザーアカウント、または組織です。
5. 適切な場合はコンポーネントリポジトリをボードにリンクします。ただし、ルートリポジトリとコンポーネントリポジトリのリモートは分けておきます。

便利な CLI パターン：

gh project create --owner <owner> --title "<ProjectName>"
gh project view <number> --owner <owner>
gh project link <number> --owner <owner> --repo <owner>/<repo>

推奨フィールド：

• Component：root、code、paper、slides、reviewer、rebuttal、artifact
• Workstream：method、experiment、writing、review、release、infra
• Status：Backlog、Ready、In Progress、Blocked、Review、Done、Parked
• Priority：P0、P1、P2、P3
• Target：投稿先、マイルストーン、締め切り、arXiv、最終版
• Claim ID、Evidence ID、Worktree、Blocker

推奨ビュー：Roadmap、Board、Experiments、Paper、Risks、Worktrees。

ステップ 3 - プロジェクトメモリーの初期設定

research-project-memory のテンプレート、または同等のファイルを使用して、以下を作成します。

• memory/project.yaml
• memory/component-index.yaml
• memory/current-status.md
• memory/decision-log.md
• memory/claim-board.md
• memory/evidence-board.md
• memory/provenance-board.md
• memory/risk-board.md
• memory/action-board.md
• memory/handoff-board.md
• memory/phase-dashboard.md
• memory/source-visibility-board.md

コンポーネントインデックスには、以下を記録します。

components:
  code:
    path: code
    worktree_root: code-worktrees
    worktree_index_path: code/.agent/worktree-index.md
    shared_uv_environment: .uv-envs/code
    owns:
      - algorithm implementation
      - experiment execution
      - code-side result reports
      - server execution state
  paper:
    path: paper
    worktree_root: paper-worktrees
    worktree_index_path: paper/.agent/worktree-index.md
    default_visibility_tier: author-visible
    source_visibility_board: memory/source-visibility-board.md
    owns:
      - paper claims and narrative
      - figures and tables selected for submission
      - venue/arXiv/camera-ready versions
      - source visibility and cleanup policy
  slides:
    path: slides
    status: optional
  reviewer:
    path: reviewer
  rebuttal:
    path: rebuttal
  artifact:
    path: artifact

ルートメモリーには、詳細な実行ログを重複して記載するのではなく、コード側のエビデンスへのポインターを保存します。

デフォルトのツールチェーンゲートを memory/project.yaml に記録します。

toolchain_gates:
  policy: check-before-mutate
  code:
    environment_check: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv sync"
    format_check: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run ruff format --check src tests experiments scripts"
    lint_check: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run ruff check src tests experiments scripts"
    type_check: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run mypy src"
    test_check: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run pytest tests -v"
    local_gate_runner: "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run pre-commit run --all-files"
    mutate_only_when_requested:
      - "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run ruff format src tests experiments scripts"
      - "UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code uv run ruff check --fix src tests experiments scripts"
  optional_hygiene:
    secret_scan: "gitleaks dir --no-banner --redact ."
    shell_lint: "shellcheck jobs/*.sh scripts/*.sh"
    shell_format_check: "shfmt -d jobs scripts"
    notebook_output_check: "nbstripout --dry-run notebooks/*.ipynb"
    github_actions_lint: "actionlint .github/workflows/*.yml"
    toml_format_check: "taplo fmt --check pyproject.toml"
    yaml_lint: "yamllint ."
    link_check: "lychee --no-progress README.md docs/**/*.md"
  paper:
    source_format_check: "tex-fmt --check --nowrap --recursive ."
    submission_check: "bash <submit-paper-skill-dir>/scripts/check.sh \"$PAPER_DIR\""
    compile_truth: "Overleaf/GitHub or local LaTeX compile log"
    mutate_only_when_requested:
      - "tex-fmt --nowrap --recursive ."
  coordination:
    git_status_check: "git status --short --branch"
    whitespace_check: "git diff --check"
    github_auth_check: "gh auth status"
    github_pr_check: "gh pr checks"

既存のリポジトリを接続する際は、コンポーネント固有の既存ツールを保持します。たとえば、コードリポジトリですでに black、isort、pyright、pre-commit、gitleaks、shellcheck、shfmt、actionlint、nbstripout、または CI 固有のコマンドを使用している場合は、デフォルトのスキャフォールドポリシーを強制するのではなく、実際のコマンドを記録します。ML 以外のリポジトリでは、存在しない場合に experiments や scripts などのデフォルトパスを省略します。

GitHub Project ボードが存在する場合は、memory/project.yaml に記録します。

github_project:
  enabled: true
  owner: <github-user-or-org>
  title: <ProjectName>
  number: <project-number>
  url: <project-url>
  sync_policy: issue-pr-links
  scope_required: project

ボードは存在するものの、エージェントが管理すべきでない場合は、sync_policy: none を使用します。ユーザーがその情報を明示的に公開することを希望しない限り、非公開の研究上の根拠や、非公開の論文レビューに関するリスクを GitHub のフィールドに反映しないでください。

ステップ 4 - ルートレベルのエージェント向けガイダンスを作成する

ルートに両方のエージェントエントリーポイントを作成します。

• Codex および汎用エージェント向けの <ProjectName>/AGENTS.md
• Claude Code との互換性を保つための <ProjectName>/CLAUDE.md

意味的に同じ内容になるようにします。内容をミラーリングするか、Claude Code に AGENTS.md をプロジェクト管理ルートの正式なポリシーとして参照するよう指示する短い CLAUDE.md を作成します。

ルートのガイダンスには、次の内容を記載します。

• タスクが明示的にコンポーネント内に限定されていない限り、エージェントは <ProjectName>/ から作業を開始します
• コンポーネントリポジトリの調査やリポジトリ内のコマンドには、git -C code ...、git -C paper ...、git -C slides ... を使用します
• プリフライト後の通常の最終ブランチプッシュでは、生の git push、git -C <repo> push、cd <repo> && git push、シェルでラップしたプッシュの代わりに project-push <repo> <remote> <branch> を使用します
• コードのワークツリーは、デフォルトで code-worktrees/ の下に配置します
• venue、arXiv、カメラレディ版の論文ワークツリーは、デフォルトで paper-worktrees/ の下に配置します
• 論文ソースの可視性階層は agent-private、author-visible、anonymous-submission、public-preprint、camera-ready-public、publisher-artifact です
• paper/main を GitHub 経由で Overleaf と同期する場合、その可視性は author-visible です。この可視ソースには .agent/、AGENTS.md、CLAUDE.md、生の CSV、内部用の結果ドキュメント、プロットスクリプト、査読者対応戦略、非公開パスを含めてはいけません
• tex-fmt がインストールされている場合、論文のフォーマットチェックでは tex-fmt --check --nowrap --recursive . を使用します。フォーマットが要求された場合に限り tex-fmt --nowrap --recursive . を実行し、プッシュまたは投稿の前に差分を確認します
• コードのチェックには、UV_PROJECT_ENVIRONMENT が共有プロジェクトコード環境を指すようにして、uv sync、uv run ruff format --check、uv run ruff check、uv run mypy src、uv run pytest tests -v、uv run pre-commit run --all-files を使用します。ただし、コードリポジトリに既存の別の方法が記載されている場合は除きます
• 関連するファイルとツールが存在する場合の任意の品質チェックには、gitleaks、shellcheck、shfmt、actionlint、nbstripout、taplo、yamllint、lychee を含めます
• ruff format、ruff check --fix、shfmt -w、--dry-run なしの nbstripout、tex-fmt のフォーマットモードなど、ファイルを変更するフォーマット／修正コマンドには、明示的な依頼または文書化されたプロジェクトポリシーが必要です。実行後は差分を確認します
• ルートの docs/ は、プロジェクト全体の概要、段階的な手法設計、コンポーネント横断の実験計画、監査、タイムライン、引き継ぎに使用します
• code/docs/ は、コード側の結果概要、実行記録、実装レポート、サーバー実行メモに使用します
• 実験結果は code/docs/results/、code/docs/reports/、code/docs/runs/、またはコードのワークツリー内の同じパスに保存します
• 生の出力、ログ、チェックポイント、wandb／tensorboard のキャッシュは、プロジェクトルートの成果物にしません
• 論文のバージョンに関するメモは該当する論文ワークツリーの .agent/worktree-status.md に記録し、長期的に保持する決定事項はルートの memory/ に記録します
• ワークツリー横断の集約情報は code/.agent/worktree-index.md、paper/.agent/worktree-index.md、ルートの memory/component-index.yaml に記録します
• GitHub Project が設定されている場合、課題、PR、ブロッカー、目標、ロードマップのビューを共同作業者に提示するボードとして使用します。ルートの memory/ は長期的に保持する研究メモリとして維持します
• arXiv／公開ソース向けの論文ワークツリーでは、ソース公開前に TODO、内部コメント、非表示の図表説明、査読者への回答メモ、著者コメント用マクロを削除します
• 論文がまだ公開されていない場合でも、著者に見える Overleaf ブランチにはエージェント専用ファイルを含めません
• 匿名査読用の学会論文ワークツリーでは、開催 venue の匿名性およびフォーマット規則を遵守します
• プロジェクトメモリには、主張、エビデンス、出典、リスク、アクション、引き継ぎの概要を長期的に保持します
• プロジェクトメモリでは、主張のライフサイクル、エビデンスの出典、モジュール間の引き継ぎ、フェーズダッシュボードの状態を追跡します
• リリース時だけでなく、コード変更中にも update-docs を使用します
• コード、論文、成果物、ルートの安定版マイルストーンには add-git-tag を使用します

ステップ 5 - コンポーネントリポジトリを初期化または接続する

論文

新しい論文リポジトリを作成する場合は、次の場所にある init-latex-project を使用します。

<ProjectName>/paper/

既存の論文リポジトリを接続する場合は、クローンするか、そのパスとリモートを記録します。その後、エージェント専用ファイルを作成または追跡する前に、Overleaf にリンクされているか、共著者から見える状態かを確認します。

エージェントが編集する場合は、論文のワークスペースに paper/AGENTS.md と paper/CLAUDE.md の両方があることを確認します。ただし、これらはデフォルトでエージェント専用のガイダンスとして扱います。現在のブランチが author-visible、anonymous-submission、public-preprint、または camera-ready-public の場合は、これらのファイルを未追跡にするか、無視するか、agent-private ワークツリーに配置し、公開ソースへプッシュしないでください。論文固有のコンパイル、投稿先、ソースの衛生管理、図、表、メモリに関する同じルールに沿うよう維持します。

tex-fmt を利用できる場合は、論文固有のガイダンスにソース形式チェッカーとして記録します。フォーマットの状態は、論文のワークツリー／ソースの公開状態と合わせて管理します。Overleaf のコンパイル証跡の代わりにはなりません。

コード

新しいコードリポジトリを作成する場合は、次の場所にある init-python-project を使用します。

<ProjectName>/code/

ML プロジェクトでは、コードリポジトリに次のものがあることを確認します。

code/AGENTS.md
code/CLAUDE.md
code/docs/results/
code/docs/reports/
code/docs/runs/

コードリポジトリを初期化または接続する際は、そのツールチェーンのゲートを code/AGENTS.md、code/CLAUDE.md、および memory/project.yaml に記録します。プロジェクト管理ルートのレイアウトでは、新しいコードのゲートはデフォルトで UV_PROJECT_ENVIRONMENT=<absolute-project-root>/.uv-envs/code を指定して実行し、code/ と code-worktrees/* で同じ依存関係環境を共有するようにします。uv sync のみでよいのは、スタンドアロンのコードリポジトリ、またはワークツリーごとの環境を明示的に選択しているリポジトリに限ります。既存のリポジトリに CI、pre-commit、black、isort、pyright、gitleaks、shellcheck、shfmt、actionlint、nbstripout、またはカスタムコマンドがある場合は、それらのコマンドを維持して文書化します。

既存のコードリポジトリを接続する場合は、完全なスキャフォールドを無理に適用しないでください。不足している重要度の高いメモリ／ドキュメントのパスは、ギャップを報告してから追加します。

コードリポジトリが上流プロジェクトからクローンされたものである場合、origin に書き込み可能とは限りません。origin が上流、フォーク、新規作成したプロジェクトリポジトリのいずれかを記録し、ルートの管理プレーンリポジトリのリモートとは分けて管理します。

スライド

依頼があった場合は、次を作成または接続します。

<ProjectName>/slides/

スライドは独立した git リポジトリにしてもかまいません。ローカルのスキャフォールドを独自に作るのではなく、外部の progress-slides テンプレートをスライドコンポーネントとして使用することを推奨します。

git clone https://github.com/a-green-hand-jack/progress-slides.git <ProjectName>/slides

クローンした後は、編集する前に slides/README.md、slides/package.json、既存のスライドソースファイルを確認します。デッキの構成、テンプレート互換のソース作成、プレビュー／ビルドコマンド、および slides/.agent/ のストーリー、対象読者、ソース証拠、古くなった証拠に関するメモには、research-slide-deck-builder を使用します。

slides/ は複数のデッキを扱うワークスペースとして管理します。ルートとスライド固有のエージェントガイダンスには、長期保存するデッキを slides/decks/<YYYY-MM-DD>-<audience-or-purpose>-<slug>.md に配置し、slides/slides.md はアクティブ／デフォルトのデッキ、ステージングファイル、またはテンプレートサンプルとしてのみ使用することを記載します。デッキの履歴は slides/.agent/deck-index.md に記録し、必要に応じてデッキごとのメモを slides/.agent/decks/<deck-id>.md に保存します。また、次の例のように、対象のデッキファイルを指定して Slidev を実行します。npx slidev decks/2026-05-02-advisor-plan.md

ステップ 6 - ワークツリーのポリシーを確立する

デフォルトのコードポリシー：

main code repo:       <ProjectName>/code/
code worktree root:   <ProjectName>/code-worktrees/
worktree path:        <ProjectName>/code-worktrees/<branch-type>-<branch-name>/

デフォルトの論文ポリシー：

main paper repo:      <ProjectName>/paper/
paper worktree root:  <ProjectName>/paper-worktrees/
worktree path:        <ProjectName>/paper-worktrees/<version-type>-<venue-or-name>/

次の場合は論文用ワークツリーを使用します。

• テンプレートやスタイルファイルが異なる、投稿先の学会が異なる場合
• メインブランチが Overleaf／共著者に表示される状態で、エージェント専用の原稿を作成する場合
• LaTeX ソースが公開される可能性のある arXiv／プレプリントを公開する場合
• 採択後にカメラレディ版を作成する場合
• メインの投稿ブランチに影響させない論文のみの査読回答の修正を行う場合

論文のバージョン管理：

• エージェント専用：.agent/、AGENTS.md、CLAUDE.md、執筆メモ、出典情報、内部の結果文書、CSV、プロット用スクリプトを含めてもかまいません。表示対象のリモートと同期しないようにしてください。
• 著者に表示／Overleaf：.agent/、AGENTS.md、CLAUDE.md、生の CSV、内部の結果文書、プロット用スクリプト、査読者対応戦略、非公開パス、エージェント専用のメモを除外します。
• arXiv／公開ソース：TODO、TeX コメント内の図表に関する内部説明、査読者向けメモ、非表示コメント、著者コメント用マクロ、匿名化の残りを削除します。
• 匿名の学会投稿：匿名性、投稿先のモード、書式を徹底します。ソースがアップロードされる場合、ソース内のコメントが安全だと決めつけないでください。
• カメラレディ版：匿名化を解除し、謝辞／助成金情報を追加し、査読回答での約束に対応し、草稿のみのメモを削除します。

以下に記録します。

• memory/project.yaml
• memory/component-index.yaml
• memory/source-visibility-board.md
• <ProjectName>/AGENTS.md
• <ProjectName>/CLAUDE.md
• サーバーでの実行が関わる場合は code/docs/ops/current-status.md

実行サーバーにコードリポジトリしかない場合は、サーバー固有のワークツリーのルートを code/infra/remote-projects.yaml または code/docs/ops/current-status.md に記録します。サーバーに paper/ やルートのプロジェクトメモリがあると決めつけないでください。

ステップ 7 - PROJECT.md を作成する

templates/PROJECT.md から <ProjectName>/PROJECT.md を作成します。<ProjectName> と1行の説明を入力し、GitHub Project Board のステータスを none、linked、または planned に設定します。その他のセクションはすべて安定したデフォルトです。プロジェクトのコンポーネント構成、可視性ポリシー、またはメモリ構造がデフォルトと異なる場合に限り、編集してください。

ステップ 8 - 最終サマリー

以下を報告します。

Project initialized: <ProjectName>
Control root: <path>

Components:
  paper: <created|connected|skipped>
  code: <created|connected|skipped>
  slides: <created|connected|skipped>
  reviewer/rebuttal/artifact state: <created|deferred>
  GitHub Project: <created|linked|deferred|not requested>
  Toolchain gates: <configured|deferred|inherited from existing repos>

Code worktree root:
  <ProjectName>/code-worktrees/
Paper worktree root:
  <ProjectName>/paper-worktrees/

Next skills:
  research-project-memory -> inspect or update project state
  new-workspace -> create a code branch/worktree or paper version worktree
  remote-project-control -> configure SSH/HPC execution for code
  experiment-design-planner -> plan first experiment matrix
  research-slide-deck-builder -> create progress/advisor/lab slides with progress-slides

最終確認

完了前に、以下を確認してください。

• ルートのエージェント向けガイダンスが AGENTS.md と CLAUDE.md の両方に存在する
• エージェントが編集するコンポーネントリポジトリに、対になる AGENTS.md と CLAUDE.md がある
• ルートのメモリファイルが存在するか、明示的に保留されている
• paper/、code/、slides/ の Git 境界が明確である
• GitHub／GitLab の設定が関わる場合、ルートとコンポーネントの Git リモートを個別に確認している
• リポジトリの作成を試みる前に、gh auth status または同等のホスティング用 CLI の認証を確認している
• GitHub Project の設定が memory/project.yaml と PROJECT.md に記録されているか、アクション／ブロッカーとして明示的に保留されている
• ツールチェーンのゲートのデフォルトが memory/project.yaml に記録されているか、既存のコンポーネント固有のゲートが継承されるものとして文書化されている
• gh project ... コマンドを実行する前に、gh トークンに project スコープがある
• code-worktrees/ のポリシーが記録されている
• paper-worktrees/ のポリシーが記録されている
• 論文ソースの可視性ポリシーが記録されている。特に paper/main が Overleaf／GitHub を通じて author-visible かどうかが明確である
• ユーザーが明示的に要求していない限り、トップレベルに experiments/ ディレクトリがない
• ルートの docs/ のプロジェクトレベルでの役割が明確で、code/docs/ と混同されない
• コード側のエビデンスパスが code/docs/ 内にある
• コンポーネントのリモートとルートの Git ポリシーが曖昧でない