1仕組みと動作原理
SKILL.md 自体はわずか 93 行 / 3.2KB のルーティングテーブルとして機能します。本文の「Skill Contents」で 7 つの docs、5 つの examples、2 つの templates、1 つの cheatsheet を一覧化し、コンテキストに 50KB 以上のドキュメントを一度に流し込むのではなく、エージェントがタスクに応じて該当ファイルをロード（段階的開示）します。
skills/webgpu-threejs-tsl/SKILL.md
- `docs/compute-shaders.md` - GPU compute with instanced arrays
ここでの処理内容: SKILL.md はインデックスの責務のみを担い、「いつ何をロードするか」をホストモデルに委ねています。容量の対比: SKILL.md は 3.2KB、docs/ 配下の 7 本は計 56.6KB、REFERENCE.md は 9.1KB です。
Cursor 側では同様の開示戦略を明示的な記述に落とし込んでいます。.mdc の本文には 3〜5 行の要約のみを残し、@file 参照で skills/ 配下の元ドキュメントを指し示しています（5 つの .mdc は合計わずか 5.9KB ですが、10 本の @ 参照が含まれています）。
.cursor/rules/webgpu-threejs-tsl.mdc
The source-of-truth documentation lives under `skills/webgpu-threejs-tsl/`. Reference these files directly when deeper guidance is needed:
README ではこれらの .mdc を thin shims と呼んでいます。@skills/... の参照行は grep で 1 つずつ確認可能です（webgpu-threejs-tsl.mdc に 4 行、compute-shaders.mdc に 3 行、post-processing.mdc に 2 行、device-loss-and-limits.mdc に 2 行、wgsl-integration.mdc に 1 行）。
「正しいコードを書ける」ための真の要は、ドキュメントで繰り返し強調されている TSL のセマンティクストラップです。TSL はノードプロパティの代入のみをインターセプトし、JS 変数の再代入は検知できません。そのため、If() 内で value = value.add(1.0) と記述しても暗黙的に無視されます（エラーを出さず古いノードを返します）。
skills/webgpu-threejs-tsl/docs/compute-shaders.md
**TSL can intercept property assignments on nodes, but NOT JavaScript variable reassignment.**
なぜこれが重要か: これは TSL における最も典型的なサイレントバグ（コンパイルは通るが結果が不正）です。スキル内では core-concepts.md §「⚠️ CRITICAL: Property Assignment vs Variable Reassignment」、compute-shaders.md の冒頭、templates/compute-shader.js のヘッダーコメントの 3 箇所で同一の警告を繰り返し、select()、.toVar()、直接 element.assign() という 3 つの正しい書き方を提示しています。
単にルールを与えるだけでなく失敗のメカニズムも説明することで、モデルが別の書き方で同じ過ちを繰り返すのを防ぎます。ドキュメントでは、JS 変数の再代入が新しいノードを作成し TSL がその代入を認識できないこと、およびスカラーは .x/.y プロパティを持たないためプロパティ代入で回避できないことを解説しています。
skills/webgpu-threejs-tsl/docs/compute-shaders.md
**Why it fails:** `value = value.add(1.0)` creates a new TSL node and reassigns the JavaScript variable to point to it.
同セクションの補足論述: 「Since `value` is a scalar float (no `.x`/`.y` properties), you can't use property assignment.」メカニズムを深く理解させることで、ドキュメントに記載されていない状況にもモデルが汎化して対応できるようになります。
バージョンの差異は実行時の検出ではなく、ドキュメントの記載項目として固定化されています。スキルはユーザープロジェクトの three バージョンを読み取るのではなく、r17x〜r18x の破壊的変更を対照項目としてまとめ、モデル自身に照合させます。
skills/webgpu-threejs-tsl/docs/post-processing.md
> **Note:** `PostProcessing` was renamed to `RenderPipeline` in r183. `PostProcessing` still works as a compatibility wrapper but is deprecated.
該当する記載例: REFERENCE.md の「Version Notes」における r178+ の節（PI2→TWO_PI、transformedNormalView/World→normalView/World）、compute-shaders.md の「computeAsync() is deprecated since r181」、post-processing.md における DOF の r181 全面刷新と r177 の blur sigma 再調整、r182+ で追加されたエフェクト一覧など。SKILL.md 本文には「まずプロジェクトバージョンを確認する」というステップは一切ありません。
テンプレートは擬似コードではなく、そのまま利用可能なファイル全体のスケルトンです。セクション構成（CONFIG/GLOBALS/INITIALIZATION/SCENE/ANIMATION/EVENT）、挿入ポイントの明示、外部デバッグ用に内部オブジェクトを export する設計となっています。
skills/webgpu-threejs-tsl/templates/webgpu-project.js
// Export for external access if needed
webgpu-project.js のヘッダーには利用法が明記されています: 「1. Copy this file to your project 2. Install Three.js: npm install three 3. Replace placeholder content with your scene」。compute-shader.js も同構造で、init/update/interaction の 3 つのパスのプレースホルダーと export を備えています。シェーダーとは無関係なプロジェクト構築、依存関係の導入、レンダリングループの記述をスキップできる点に価値があります。
WGSL エスケープハッチ: TSL で表現できない場合や既存の WGSL を移植する必要がある場合、wgslFn() を使って WGSL 関数全体を TSL ノードグラフに埋め込むことができます。またドキュメントには WGSL の型、構文、組み込み関数のリファレンスも付属しており、モデルが TSL から離れても正しい WGSL を記述できるよう配慮されています。
skills/webgpu-threejs-tsl/docs/wgsl-integration.md
TSL allows embedding raw WGSL (WebGPU Shading Language) code when you need direct GPU control.
wgsl-integration.md には simplex noise や FBM などの完全な長文関数のソースコードが含まれており、そのまま転用可能なリソースです。ドキュメントでは「複雑な数学処理には WGSL、単純なロジックには TSL」というハイブリッドな指針も示されています。
WebGPU 特有の実行時障害（デバイスロスト、limits/features）もコーディング指針に組み込まれており、単に動作するだけでなく GPU のクラッシュやバッファ上限にも配慮したコードを生成します。
skills/webgpu-threejs-tsl/docs/limits-and-features.md
Three.js accepts `requiredLimits` as a renderer constructor option, which gets passed through to `requestDevice()`:
補足内容: limits-and-features.md にはデフォルト limits（maxBufferSize 268435456、すなわち 256 MiB など）と「adapter を事前に確認してから要求する」安全な記法が列挙されています。device-loss.md では device.lost の検知、3 つの復帰戦略（ページ再読み込み / GPU コンテンツのみの再構築 / 状態復元付き）、destroy() や about:gpucrash によるテスト手法、Chrome のクラッシュ制限表を網羅しています。
2コア機能
01WebGPU レンダラー + TSL プロジェクトの初期化およびレンダリングループのスケルトン（renderer.init() を待ってから compute/render を実行）
02TSL ノードマテリアルの完全な網羅: 12 種類の *NodeMaterial と、colorNode/roughnessNode/metalnessNode/clearcoatNode/transmissionNode/iridescenceNode/sheenNode/anisotropyNode/dispersionNode などのプロパティマッピング
03GPU コンピュートシェーダー: instancedArray/attributeArray ストレージバッファ、Fn().compute(count, [workgroupSize])、コンピュート組み込み変数、ワークグループ/ストレージバリア、アトミック操作
04ポストプロセスパイプライン: bloom/blur/FXAA/SMAA/DOF/SSR/SSAO/film/outline などの組み込みエフェクト、各種 MRT パス、Fn() によるカスタムエフェクトとエフェクトチェーン
05WGSL 統合: wgslFn() によるカスタム WGSL 関数（simplex noise や FBM を含む）の埋め込みと TSL ノードとの併用
06デバイスロスト（device loss）の検知、復帰、テスト（状態の保存/復元およびフォールバック通知を含む）
07WebGPU の limits / オプション features の確認と要求（requiredLimits の透過、確認後の要求、Three.js による features の自動要求）
08実行可能なサンプルとスターターテンプレート: 5 つの examples + 2 つの templates（最小プロジェクト、カスタムマテリアル、10 万粒子のコンピュート、ポストプロセスチェーン、大気効果付き手続き型地球）
3外部依存関係
| Kind | Dependency / Endpoint |
|---|---|
| package | three（npm 包，生成项目需自装） |
| package | three/addons 子路径（OrbitControls、BloomNode 等 addons 模块） |
| network | 文档引用链接（仅 markdown 里的参考资料链接，仓库内无任何抓取/请求代码，不被 skill 调用） |
4推奨統制措置と判定根拠
安全運用のための推奨統制措置
Agent 向け
自動ロード可能
管理者向け
ソースとバージョンの記録
判定根拠（ファイルパスと抜粋）
- SKILL.md: スクリプト実行や外部への影響を伴わない、純粋なプロンプト指示およびルールテキストです。
監査ノート： グリーン判定、純粋な静的知識アセット: git ls-tree によるリポジトリ内ファイルは 24 個のみで、すべて .md / .mdc / .json / 読み取り専用の .js コーパスで構成されています。package.json、scripts/ ディレクトリ、.sh/.py スクリプトは存在せず、scripts_executed は空です。リポジトリ全体を grep しても fetch、XMLHttpRequest、curl、wget、importmap、CDN ドメイン（unpkg/jsdelivr など）のヒットはゼロ件で、ネットワーク面も空です（README/REFERENCE.md に記載された threejs.org、toji.dev、webgpureport.org は単なる Markdown 内の参考リンクであり、プログラムによるリクエストではありません）。process.env、.env、トークン、Cookie、資格情報への参照もなく、クレデンシャル面も空です。スキル自体がファイルを書き出すこともありません（localStorage は docs/device-loss.md においてユーザーアプリが状態を保持する方法を示すサンプルコード内のみに登場します）。唯一留意すべき点は、知識の陳腐化リスクと Cursor ルールの要約が docs より遅れていることによる二重メンテナンスの乖離ですが、これらはコンテンツ品質の課題であり、実行面でのリスクには該当しません。
5二重目の独立検証
- [ok] pin commit 与工作副本一致 — git rev-parse HEAD 输出 af2319bd01bb7cc881267a9ef42cafdaf5e9029d，与 .git/shallow 首行相同，等于任务 pin commit；结论只对该 commit 有效。
- [ok] skill 目录定位 — skills/webgpu-threejs-tsl/SKILL.md 存在且 frontmatter name: webgpu-threejs-tsl 与 slug 对应；同目录含 REFERENCE.md、docs/×7、examples/×5、templates/×2，路径写入 skill.path。
- [discrepancy] license 声明与仓库实际文件 — README.md 有『## License』段声明 MIT License，.claude-plugin/plugin.json 也写 "license": "MIT"；但 git ls-tree -r 全量清单里没有 LICENSE / LICENSE.md 文件，全仓 grep -il license 只命中 plugin.json、README.md 与 5 个 examples 的注释，与 GitHub API license=null 一致。即：许可为『源码内声明』而非仓内标准许可文件。
- [discrepancy] README 自述的 skill 结构图 vs 实际文件 — README『## Skill Structure』的 docs/ 分支只列 core-concepts / materials / compute-shaders / post-processing / wgsl-integration / device-loss 六篇（以 `└── device-loss.md` 收尾），而 docs/ 实有 7 篇——漏列 limits-and-features.md；SKILL.md 的 Skill Contents 则完整列出七篇。属 README 文档漂移。
- [discrepancy] Cursor 摘要与 docs 的 API 世代是否一致（后处理） — .cursor/rules/post-processing.mdc 仍教 `import { PostProcessing } from 'three/webgpu';` 并说 postProcessing.renderAsync()，而 docs/post-processing.md 开篇即注明 r183 已改名 RenderPipeline、旧名仅为兼容包装，examples/post-processing.js 实际用的是 `new THREE.RenderPipeline(renderer)`。README 自称 shim 会『edits flow through automatically』——该说法对手写摘要句不成立。
- [discrepancy] Cursor 摘要与 docs 的 API 世代是否一致（compute 派发） — .cursor/rules/compute-shaders.mdc 写『dispatched via `renderer.computeAsync()`』与『- `renderer.computeAsync(kernel)` to dispatch』，而 docs/compute-shaders.md『Execution Methods』明确『// Note: computeAsync() is deprecated since r181.』并给出『await renderer.init() at startup, then renderer.compute() synchronously』；templates/compute-shader.js 与 examples/particle-system.js 用的都是 renderer.compute(...)。同一漂移问题的第二例。
- [ok] 外部依赖反查：是否存在 CDN/网络调用 — 全仓 grep -riE 'unpkg|jsdelivr|cdn\.|importmap|import-map' 零命中；templates/examples 的 import 全部是裸包名（three、three/webgpu、three/tsl、three/addons/...），无 URL 形式的模块来源。故 external_deps 只列 npm 包，security.network_calls 为空。
- [ok] 脚本/凭证面反查 — git ls-tree 全清单只有 .md/.mdc/.json/.js；无 package.json（因此无 npm scripts、无依赖安装钩子）、无 scripts/、无 .sh/.py；危险 token 扫描对 child_process/eval/new Function/process.env/.env/token/secret/document.cookie/credentials 均无命中。scripts_executed 与 credential_reads 为空有据。
6結論
最適な用途： Three.js で WebGPU/TSL アプリケーションを開発しているフロントエンドおよびグラフィックス開発者、ならびにシェーダー作成を AI エージェントに任せたいチームに最適です。プロジェクトが Three.js r171〜r183 世代である場合に最も高い価値を発揮し、特にカスタムノードマテリアル、コンピュート粒子、ポストプロセスチェーン、WGSL の併用といったタスクに向いています。また、Claude Code プラグインや Cursor ルールとしてプロジェクトに直接組み込むことで、*.js/*.wgsl ファイルの記述時にエージェントが適切な API 世代と落とし穴の警告を自動適用できるようになります。プロジェクトを手早く立ち上げたい場合は、templates/webgpu-project.js をそのままコピーして使用できます。
不向きな用途： Three.js のバージョンが r171〜r183 から大きく乖離しているプロジェクト（旧バージョン r15x や将来の大規模改訂では非推奨 API を参照してしまう恐れがあり、手動での確認が必要）、Cursor ルールのみを唯一の情報源とする用途（2 箇所の要約が現状と乖離しているため、詳細な実装時は skills/ 配下の docs を参照する必要があります）、素の WebGPU/WGSL または WebGL/GLSL のプロジェクト（対象は three/webgpu + TSL のみ）、即座に実行可能なビルド成果物や自動テストを求める環境（スクリプト、ビルド、テストは含まれず、正確性はモデルがドキュメント通りに記述することに依存します）、リポジトリ内に標準的な LICENSE ファイルの配置を必須とするコンプライアンス要件には適していません。
Install Agent-Ready
① Verified Mirror 2026-09-15
Option A · Direct DownloadDownload webgpu-three-js.tar.gz
sha256:
Option B · Copy Guide for Agentafb594cdc14fec2b…Agent はこの JSON ガイドから自動的にダウンロードして検証します。
② Upstream GitHub
GitHub Repo ↗
Pinned to commit af2319bd01.