Skill.md検索

テストを先に書くことで、実装すべき機能を明確にし、設計をより堅牢にできます。 赤（テスト失敗）→緑（最小実装）→リファクタ（整理）のサイクルに従い、安全にコード変更を進められます。 数値微分との勾配チェックにより、AI/MLフレームワークの計算精度を自動検証できます。 テストコードで振る舞いを明確に定義することで、リグレッション（予期しない不具合）を防げます。 新しいAPI追加、既存API拡張、バグ修正の各場面で一貫性のあるテスト方法を適用できます。 MbTorchのような数値計算・ML機能を扱うフレームワーク開発者 テストなしのコード変更で不安を感じている開発チーム 計算精度が重要なライブラリ（テンソル演算、勾配計算など）を開発・メンテナンスしている人 リファクタリングやAPIの大幅な変更を安全に進めたい担当者 MbTorchでのテスト駆動開発（TDD）は「テスト → 最小実装 → リファクタ」の3段階サイクルを厳守します。新規API追加、既存API拡張、バグ修正・リグレッション対応、リファクタリング、core/nn/optim/ioレイヤ変更の際に必ず適用します。テスト名は「何をするときに何が起きるか」を言葉で表現し、1テストは1振る舞いのみを検証します。入力値は最小限で再現性を保ち、期待値は手計算済みの定数を使用します。core/tensorやcore/autogradを変更する場合は数値的正確さを最優先とし、演算テスト（手計算・参照実装との一致確認）と勾配チェック（数値微分との比較で相対誤差1e-4以下を目安）を必ず用意することが必須です。nn/レイヤ変更時はフォワードパス出力のshapeと値を検証し、パラメータ更新を確認します。

ONNX・safetensors・.mbt 形式間の変換を設計：PyTorch などの外部フレームワークから学習済みモデルを MbTorch に取り込み、.mbt ネイティブ形式で保存・再ロード・配布できます。 形式仕様に基づく正確なパース実装：フォーマット知識を曖昧な推測ではなく、公式仕様に基づいて実装し、不正なデータは明示的に失敗させます。 I/O と推論ロジックの責務を完全分離：ファイル形式の知識を io/ モジュールに閉じ込め、nn/・core/ レイヤーへの汚染を防ぎます。 メタ情報と重みデータの段階的ロード：モデル構造を先に検証してからテンソルバッファをマップし、エラー時の診断を容易にします。 互換性問題を早期発見・修正：フォーマットバージョンアップや破壊的変更に対応する検証・テスト方針を提供します。 MbTorch フレームワーク開発者：モデル I/O 周辺の実装・レビューを行う 機械学習モデルの形式変換を扱う組織：異なるフレームワーク間のモデル移行を安全に実施したい エッジデバイス向けモデル配布の担当者：.mbt 形式での軽量・高速な保存・ロードを実装したい 互換性テスト・品質保証チーム：形式バージョンアップ時の破壊的変更を検出・テストしたい MbTorch の I/O モジュール（io/）におけるフォーマット設計・実装・テスト方針を定義します。対応形式は3つ：ONNX（読み込み専用、計算グラフ標準表現）、safetensors（読み込み・書き出し、テンソル重み）、.mbt ネイティブ形式（読み込み・書き出し、MbTorch 専用コンパクト形式）。設計原則は責務分離（フォーマット知識を io/ に閉じ込める）、メタ情報と重みデータの分離（先にメタ情報を読んで構造検証してからテンソルバッファをマップ）、I/O 専用の中間表現DTO 活用（ドメイン型とシリアライズ形式の間に仲介層を置く）。仕様参照先：ONNX（https://onnx.ai/）、safetensors（https://huggingface.co/docs/safetensors/）。レイヤリングは mbtorch-architecture、テスト方針は mbtorch-tdd スキルも参照すること。

コード変更を自動検知してドキュメント更新箇所を提案する 新しいAPI追加、既存API変更・削除、使用例の追加などが行われたとき、どのドキュメントを更新すべきか自動で判定できます。 README・APIリファレンス・使用例を一貫したスタイルで生成する MbTorch（MoonBit製AI/MLフレームワーク）の標準文体・コード例形式に従った、品質が統一されたドキュメント提案ができます。 コピー&ペーストで動くコード例を作成する 実際に動作検証済みの例を提示し、ユーザーが試行錯誤せずすぐに使い始められるようにできます。 破壊的変更の説明を文書化する APIの廃止や仕様変更があった場合、ユーザーへの影響とマイグレーション方法を自動で説明記事として出力できます。 開発チーム内の知識共有を効率化する コード変更内容をドキュメント形式で他の開発者に素早く説明でき、レビューやディスカッションが円滑になります。 MbTorchコントリビューター・メンテナー フレームワークに機能を追加・更新するとき、ドキュメント作成の手間を削減したい開発者 テクニカルライター API仕様の変更が頻繁に起こるプロジェクトで、ドキュメント更新を自動化したい人 オープンソースプロジェクトの運営者 ユーザーに正確で最新の情報を素早く届けたい場合 開発チームのリード チーム内のドキュメント品質を統一・維持したいエンジニアリーダー MbTorchのテクニカルライター兼ドキュメントコーディネーターとして、コード変更に連動してドキュメント更新を行います。対象は4種類：README（README.md、エンドユーザー向け概要・クイックスタート）、APIリファレンス（docs/、関数・型・メソッド詳細仕様）、Example解説（examples/*/README.md、使用例とコメント）、開発者ガイド（.claude/CLAUDE.md、アーキテクチャ・ワークフロー）。更新タイミング：READMEは主要API追加・変更時、docs/はAPI仕様変更時、examples/は新ユースケース追加時、CLAUDE.md/AGENTS.mdは開発フロー変更時。文体は英語主体で短く明快に。Markdownは見出し##と###、コードブロック言語タグ必須。コード例は10～15行以内で、importや出力をコメント含め完全に示す形（コピー&ペースト可能）。

MbTorch（MoonBit製の軽量AI/MLフレームワーク）のリポジトリ構成・責務分担・レイヤリングルールを確認した上で、一貫性のあるコード変更・機能追加を行えます。 新しい関数やモジュール追加時に「この機能は core/tensor に置くべきか nn に置くべきか」という依存関係を正しく判定できます。 既存コード内の設計ルール違反（例：core が nn を参照している）を発見したとき、依存方向を正しく直すリファクタ案を作成できます。 テンソル型・自動微分（autograd）・ニューラルネットワークレイヤー・最適化器・モデルI/O など、各レイヤーの責務を明確に分離した設計を提案できます。 WebAssembly・ブラウザ・エッジデバイスをターゲットにした小バイナリで高速実行可能なアーキテクチャを保ち続けられます。 MbTorch プロジェクトで新機能を追加したい開発者・コントリビューター 既存コードに修正・リファクタリングを加えるとき、設計ルール違反を避けたいエンジニア モジュール間の依存関係が複雑になってきたプロジェクトで、設計を整理し直したいアーキテクト WebAssembly・ブラウザ環境での実行を前提にした小バイナリ設計を理解したい開発責任者 MbTorch は MoonBit で書かれた軽量 AI/ML フレームワークで、WebAssembly・ブラウザ・エッジデバイスをターゲットとしています。リポジトリは core/（tensor・autograd）、nn、optim、io、examples、tests の 6 ディレクトリで構成されます。レイヤリングルール：core/tensor は外部ライブラリのみに依存；core/autograd は core/tensor に依存（逆向き依存は禁止）；nn は core のみに依存；optim は core・nn に依存；io は core・nn に依存；examples・tests はすべてに依存可。NG パターン：core が上位層を import、nn が optim・io を import、io が optim を import など。変更前の Workflow：対象モジュール特定 → 既存コード全確認 → 依存方向チェック → リファクタ・提案実施。ルール違反発見時は即座に実装を止め、代替設計を提示します。

アーキテクチャに関わる重要な決定を「MADR形式」という標準的なフォーマットで記録できます。 背景・検討案・最終判断・理由を構造化して文書化し、チーム全体が決定理由を後から参照できます。 git履歴やPR・Issue のテキストから設計決定の記録を逆算でき、暗黙的な判断を可視化できます。 既存の設計決定記録を修正・更新する際も、フォーマットを保ちながら効率的に反映できます。 大事なアーキテクチャ判断の理由を後輩に伝える必要があるリード・アーキテクト プロジェクト内の「なぜこの技術を選んだのか」という質問に対応したいエンジニア チーム内の設計判断を一元管理し、重複検討を避けたいプロジェクトマネージャー 技術選定の背景を明確に記録することで、将来の見直しに備えたい開発チーム MADR形式で1個のADRを完成させます。パターン1（新規作成）では自由形式の説明をMADR構造にマッピング。パターン2（git逆算）ではコミット・PR・Issue から推測を含めて構成し、推測箇所に「(assumption based on git history)」と明記。パターン3（既存更新）では既存ADRと変更要件から再生成。フォーマットはID・タイトル、Status/Date/Deciders等メタデータ、Context and Problem Statement、Decision Drivers（3～7個）、Considered Options（箇条書き），Decision Outcome（理由3～7個），Pros and Cons of the Options（各選択肢にPros/Cons），Linksの構成。不明な事実は埋めずに(assumption)と明記。A4 1～2ページを目安に冗長にしません。

API 命名の統一化: PascalCase の型名（Tensor, Linear, Adam）、snake_case の関数名（new, from_onnx, save_mbt, zero_grad）を統一ルールで提案できます。 使う側からの API 設計: コード例を先に書き、実装の都合ではなく「利用者が書くコード」を基準に API シグネチャを決定できます。 層別（core/nn/optim/io）の責務明確化: 新しい公開 API がどのレイヤーに属するか、レイヤリングルールを守っているかをレビューできます。 既存 API との一貫性チェック: PyTorch・JAX などの先行フレームワークの命名と MbTorch の既存コードを参照し、API 品質を統一できます。 API Design Checklist による品質保証: 責務・配置・シグネチャ・エラーハンドリングなどを体系的に検査できます。 MbTorch フレームワークで新しい公開 API（関数・メソッド・型）を設計・追加する開発者 core / nn / optim / io モジュールの公開インターフェイスを整理・改善したいメインテナー examples を書きながら API 設計を同時進行させ、ドキュメント化コストを最小化したい人 既存 API の命名・シグネチャのゆらぎを検出し、フレームワーク全体の「使い心地」を統一したい人 Role: Claude は MbTorch の API デザイナー兼レビューア。コード実装前に「この API は MbTorch ユーザーにとって自然か」を問い、実装の都合ではなく利用者が書くコードを起点に API 形状を決定する。 命名規約: 型名は PascalCase（Tensor, Linear, Conv2d, Adam）、関数・メソッド名は snake_case（new, from_onnx, save_mbt, zero_grad, step, shape, matmul）。モジュール名は機能ベースで責務の明確さ重視（tensor_ops, io_onnx, optim_adam）。 Sample-first Approach: API 設計時は必ずコード例を先に書く。例：load_onnx は Model::from_onnx("resnet18.onnx") というユーザーコードから、シグネチャ（String → Result）が決まる。訓練ループの例から Adam::new の引数（parameters, lr）の形式が決定される。書いたコード例は README・examples に転用可能。 API Design Checklist: 責務と配置（どのレイヤーか）、レイヤリング違反確認、シグネチャの自然さ（引数順・型）、エラーハンドリング、ドキュメント化可能性などを体系的に検査。