arduino-workflow-router

組み込みワークフロールーター

組み込み作業全般、または複数分野にまたがる作業への簡潔な入口として、このスキルを使用してください。対象ボードと作業段階が明確な、範囲を絞ったタスクでは、専門スキルを直接読み込んでください。

推奨するライフサイクルの開始手順

実機作業や複数セッションにわたる依頼では、最初に embedded-project-loop を読み込んでください。これにより、目標、次のアクションを1つ、エビデンスの境界、ロールバック手順、ユーザーが担う実機作業のゲートが定まります。その後、ボードとツールチェーンのルーティングのために、ここに戻ってください。

最初に読み込むもの

1. ../../docs/arduino-skill-contract.md を読みます。
2. 作業が複数のセッションや実機での操作にまたがる場合、最初に読み込むスキルとして embedded-project-loop を推奨します。実装前に目標と次の todo の状態を作成し、エビデンスのゲートが満たされるまでその状態を維持してください。
3. ../../docs/board-support/board-profile-template.md に記入するか、不要である理由を明示します。
4. ボード名またはボードファミリーの特定が必要な場合は、ピンを選択する前に ../board-support/SKILL.md と、そのインデックス付きプロファイルを読み込みます。
5. ボードとハードウェアの確認には references/board-intake.md を読みます。
6. IDE、CLI、PlatformIO、またはベンダーのバージョンとライブラリの互換性については、references/toolchain-selection.md を読みます。
7. 以下のルーティング表から専門スキルを選択します。
8. アップロード、起動、電源、ファームウェアの復旧操作を行う前に references/failure-recovery.md を読みます。ネットワーク接続または更新可能なデバイスについては、references/connected-device-security.md を読みます。

これが最初に読み込む順序です。必要に応じて読み込んでください。リファレンスは該当する条件に当てはまる場合にのみ読み込むため、ルーターは500行未満に保たれ、詳細なバリエーションは段階的に開示されます。

トリガーの優先順位

• 複合的な依頼、要件が不明確な依頼、または複数分野にまたがる依頼では、このルーターが最初のルートを決定します。arduino-project-builder や board-selection など、内容が重複する専門スキルより先に読み込んでください。
• 実機作業や複数セッションにわたる依頼では、このルーターより先に embedded-project-loop を読み込み、その後、専門スキルを組み合わせたルートを決めるためにこのルーターに戻ってください。
• ボードとツールチェーンが確定している単一段階の依頼では、最も範囲を絞った専門スキルを直接読み込んでください。
• ボード名を指定したリファレンスの確認や機能の照会では、board-support が正確な識別と出典に基づくプロファイルを担当します。要件に基づいてボードを選択または変更する場合は、board-selection が担当し、board-support からの引き継ぎ情報を利用できます。
• 実装、配線、ライフサイクル作業を伴わないボード選択の依頼は、board-selection から開始してもかまいません。別の分野が加わったら、このルーターに戻り、複合ワークフローの順序を維持してください。
• arduino-serial-monitor と別のシリアルデバッグスキルを同時に読み込まないでください。構造化された実行時エビデンスは、既存のシリアルモニターが担当します。

受付ゲート

ピン、電圧、電流制限、メモリサイズ、周辺機器、プロトコル、ライブラリのバージョン、アップロードコマンドを推測してはいけません。不足している値を確認するか、仮定であることを明確に示し、検証手順を添えて進めてください。正確なボード、フレームワーク、ツールチェーン、ホスト、依存関係のバージョン、希望する証明段階を記録してください。

ルーティングテーブル

ニーズ	次に読み込む項目	根拠の重点
Zephyr 開発	zephyr-development	対象固有の根拠
STM32 開発	stm32-development	対象固有の根拠
Pico SDK 開発	pico-sdk-development	対象固有の根拠
MicroPython 開発	micropython-development	対象固有の根拠
プローブのデバッグ	probe-debugging	対象固有の根拠
障害のフォレンジック調査	fault-forensics	対象固有の根拠
バスのデバッグ	bus-debugging	対象固有の根拠
起動とフラッシュの復旧	boot-flash-recovery	対象固有の根拠
メモリとタイミングのデバッグ	memory-timing-debugging	対象固有の根拠
USB のデバッグ	usb-debugging	対象固有の根拠
要件またはボードの選定	board-selection、次に board-support、続いて arduino-project-builder	判断と設計
ボード名の参照または機能の検索	board-support、次に該当する専門項目	正確な識別情報とソースに基づく制約
ピン配置または GPIO 宣言	board-support、次に pin-assignment、続いて wiring-safety-check	ボードの制約とハードウェア
配線、電圧、電流、またはプルアップ	wiring-safety-check、power-budget-calculator、circuit-debugger	ハードウェア
ADC／センサーのノイズ、サンプリング、フィルタリング、または信号調整	board-support、wiring-safety-check、sensor-signal-filtering、検出が実証された後に sensor-calibration-workbench	信号チェーンの設計と実測されたハードウェアの動作
コードパターンまたはボードの抽象化	arduino-code-generator、non-blocking-patterns、memory-budgeting	ビルドとメモリ
ライブラリまたはフレームワークの依存関係	library-selection、次にコード／プロジェクトのスキル	互換性とメモリ
データシート、コンポーネント、またはプロトコルに関する不確実性	datasheet-interpreter、i2c-bringup-diagnostician	ハードウェアに関する前提
コンパイル、ボード検出、アップロード、またはポート	arduino-cli-skill と error-message-explainer	ビルドとアップロード
PlatformIO、ネイティブ ESP-IDF、混合ビルド、CI、または SDK の移行	embedded-build-workflow。Arduino CLI の分岐の場合のみ arduino-cli-skill を使用	明示的なフレームワーク／マネージャーとビルドマトリックス
制御ループの期限、アクチュエーターの所有権、過負荷、または動作タイミング	realtime-control-design、プリミティブには freertos-patterns	設計上の予算と実測されたタイミング
UDP／ESP-NOW のテレメトリー、AP+STA の共存、または無線トレースの分析	wireless-telemetry、キャプチャ／デスクトップ連携には arduino-serial-monitor	最新性、プロトコル、測定範囲
実行時ログまたは現場での症状	arduino-serial-monitor、error-message-explainer、hardware-tdd	ハードウェアとシステム
タイミング、ブロッキング、またはウォッチドッグのリスク	non-blocking-patterns、hardware-tdd	ビルドとシステム
メモリまたはフットプリントのリスク	memory-budgeting、library-selection	ビルドと実行時
キャリブレーションまたはセンサーのドリフト	検出が実証された後に sensor-calibration-workbench	システム
アプリケーション全体	arduino-project-builder、次に該当するドメインスキル	設計とビルド
接続状態での更新または現場へのデプロイ	ota-deployment-guardian とセキュリティリファレンス	デプロイ
部品、PCB 周辺、または筐体の作業	bom-generator、enclosure-designer、readme-generator	設計と保守
ホスト／シミュレーション／ターゲットのテスト計画	物理作業が保留中の場合は hardware-tdd と embedded-project-loop	根拠
複数セッション、物理作業、または復旧作業	まず embedded-project-loop、次にこのルーター	永続的な状態とユーザーが管理するゲート

複合ワークフロー

ツールチェーンの優先順位：リポジトリで PlatformIO またはネイティブ SDK が選択されている場合、ビルドの受付は embedded-build-workflow が担当します。ネイティブの app_main、Zephyr、Pico SDK、Rust のプロジェクトを、デフォルトで Arduino CLI に回さないでください。フレームワーク、ターゲット、ホストが検証済みだと主張する前に、 サポートマトリクスを確認してください。混在ビルド、個別のフラッシュ／PSRAM 設定、無線接続の証跡、OTA、ベンチ制御については、最新の BottleSumo の教訓を参照してください。

スキルは組み合わせて使用できます。各判断の担当は一つに定め、その成果物を次のスキルに引き渡してください。複合的な依頼では、簡潔なデフォルトの順序として次を使用します。

loop (if long-running) -> board selection/intake -> wiring safety -> library/memory -> project/code/timing -> toolchain build/upload -> serial and hardware tests -> system/calibration -> deployment/security/maintenance

複合タスクのデフォルトの順序：arduino-workflow-router -> board-selection -> board-support -> pin-assignment -> wiring-safety-check -> sensor-signal-filtering -> non-blocking-patterns -> arduino-serial-monitor -> hardware-tdd。作業が複数のセッションや物理的なゲートにまたがる場合は、 まず embedded-project-loop を開始し、その後の各段階でも次の TODO と証跡台帳を開いたままにしてください。

ユーザーがすでに正確でサポート対象のボード識別情報を提示している場合は、 board-selection を省略して board-support から開始してください。ピンや電気に関する助言の前に、 board-support を省略してはいけません。

• バッテリー駆動の Wi-Fi センサー：ボードの受付 -> データシート -> 電源 -> プロジェクトビルダー -> コードジェネレーター -> ツールチェーン -> シリアル／キャリブレーション -> OTA セキュリティ -> メンテナンス用 README。
• Uno R4 WiFi のアップロード障害：ボードファミリーのリファレンス -> IDE／CLI の検出 -> シリアルおよびエラーの診断 -> USB／電源の確認 -> ブート復旧 -> アップロードの 証明 -> ランタイム／システムの証明。../../docs/board-support/uno-r4-family.md を参照してください。
• ロボットコントローラー：ボードの受付 -> プロジェクトビルダー -> 電源／BOM -> 回路と コード -> シリアル／システムテスト -> 筐体 -> 署名付きアップデートとロールバック。
• マルチボード対応センサーライブラリ：ボードプロファイル -> データシート／プロトコルの 初期化 -> コードジェネレーター -> IDE／CLI／PlatformIO の分岐 -> ボードごとのビルド証明と 未サポートの動作の文書化。
• 4 ボタンの ESP32 コントローラー：ボードの選択 -> ピン割り当て -> 配線の 安全性 -> ノンブロッキングのデバウンス -> コードジェネレーター -> ビルド証明 -> ハードウェア ゲート -> シリアル／システムの証跡。

表の行を、スキルが実行された証明として扱わないでください。実際に使用したスキル、 それらが生成した成果物、未検証のまま残っている証跡段階を報告してください。

出力仕様

../../docs/arduino-skill-contract.md を使用してください。前提条件、必要なツールと バージョン、実装手順、証明段階ごとのテスト／証跡、既知の制限事項、復旧／セキュリティに関する注意事項を記載してください。