mcpField
E
electronics

electronics

github.com/magnus919その他15353 回インストール今日更新
リポジトリ

electronics について

Electronics は、回路要件を根拠のある設計と検証可能な結果に結び付ける電子工学スキルです。部品選定、計算、測定計画、故障診断を扱い、モデル、シミュレーション、実測の根拠を区別します。

主な機能

  1. 01データシートと動作限界に基づく部品選定
  2. 02許容差、誤差予算、マージンの計算
  3. 03電源、信号、熱経路のレビュー
  4. 04測定と受け入れ試験の計画
  5. 05記録した根拠に基づく故障診断

活用シーン

  1. 01回路要件に照らした部品選定の評価
  2. 02測定誤差や回路マージンの推定
  3. 03安全な範囲を定めたベンチ検証の計画
  4. 04測定結果に基づく故障箇所の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/magnus919/agent-skills --skill electronics

インストール後、Claude Code で/electronicsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
evals/
evals.json
references/
analog-and-digital-building-blocks.md
assembly-and-verification.md
component-selection.md
fault-isolation.md
i2c-integration.md
measurement-and-instrumentation.md
power-thermal-and-protection.md
schematic-to-bench.md
sensors-and-conditioning.md
tolerances-and-error-budgets.md
templates/
assembly-acceptance.md
bus-electrical-budget.md
component-contract.md
design-calculation-record.md
fault-ledger.md
measurement-plan.md
schematic-review.md
sensor-calibration-plan.md

詳細

電子回路

望ましい物理的な動作を、根拠のある回路と、観測可能な検証結果に変換します。回路図、部品、レイアウト、電源、負荷、測定環境、測定設定、環境条件を、ひとつのシステムとして扱います。もっともらしい回路図やシミュレーションの成功は中間成果であり、組み上がった回路が動作する証明ではありません。

作業上の取り決め

  1. 求められている判断を特定します。説明、計算、選定、レビュー、診断、製作、検証のいずれかを見極め、その判断に必要な成果物を作成します。範囲が限定された計算のために、設計資料一式を要求してはいけません。
  2. デバイス固有の主張が重要な場合は、部品と基板を正確に特定します。メーカーのデータシートの改訂版、パッケージ、動作条件を使用します。推奨動作、絶対最大定格、標準性能、保証範囲、実測動作を区別します。
  3. 関連する信号、電力、タイミング、熱の経路をモデル化します。単位、符号規約、仮定、コーナー条件を明記します。提示された仮定入力から有用な条件付き結果を計算しますが、不足している測定値や保証定格を捏造してはいけません。
  4. 実験の前に合否基準を定義します。各測定には、予測値または範囲、計測器の設定、有効条件、解決する判断事項が必要です。
  5. 可能な場合は、一度にひとつの説明変数を変更します。最初に観測された症状を記録し、観測と仮説、推論を区別します。
  6. 配線の変更、電源の投入、信号の印加、接続機器の操作を行う前に、実行前に対象、範囲、ロールバック手順を確認します。読み取り専用の調査は、確認を得ずに進めてもかまいません。実際のエネルギー経路と故障経路に応じた測定計画と復旧計画を用意します。
  7. 次の操作が、確認済みのデバイス、計測器、絶縁の限界を超える場合は停止します。リスクの高い事実が不足している場合は、推測したコマンドや接続ではなく、範囲を限定した証拠の提示を求めます。

作業の振り分け

現在の判断に必要な参照資料だけを読み込みます。各参照資料には、前提、具体的な検討例、故障パターン、合否判定の指針が含まれています。テンプレートを使うと、その検討結果をレビュー可能な成果物にできます。

タスク参照資料成果物
部品を選定または交換する部品選定部品仕様書
比率、しきい値、精度、負荷誤差の範囲を求める許容差と誤差予算計算記録
電源、スイッチ、ドライバー、クランプ、熱の問題をレビューする電力、熱、保護部品仕様書と計算記録
増幅、しきい値、ロジック、インターフェースの動作をレビューするアナログおよびデジタルの基本回路部品仕様書
センサーを組み込み、または校正するセンサーと信号調整校正計画
回路図を実際の接続に置き換える回路図からベンチへ回路図レビュー
測定方法を選択または解釈する測定と計測器測定計画
I2C の電気的動作とトランザクションの証拠をレビューするI2C の統合バスの電気的予算
故障箇所を特定する故障箇所の切り分け故障記録
組み立てと観測された動作を合格判定する組み立てと検証組み立ての合否判定

標準的なエンジニアリング手順

1. 役割と境界を明確にする

回路が何をする必要があるか、どのような状態が故障に当たるかを記録します。電源、負荷、信号範囲、タイミングまたは帯域幅、デューティサイクル、環境、許容誤差、動作モードを特定します。部品、追加回路を備えたモジュール、完成した基板を区別します。写真から正体を推測できることはありますが、ピン配置、定格、絶縁、正常な状態を確認することはできません。

判断に影響する不足情報だけを求めます。それぞれについて、判断を妨げる情報、確度向上に役立つ情報、現在の計算には不要な情報のいずれかを明示します。仕様が矛盾している場合は、その矛盾を示し、名目上の妥協案を黙って選ぶのではなく、実現可能な変更案を提示します。

2. モデルを構築してコーナー条件を比較する

実際のトポロジーを使用します。重要な場合は、並列経路、信号源と負荷のインピーダンス、バイアス/漏れ電流、電源投入時の状態、温度依存性を含めます。誤差予算が保証される上限値なのか統計的な推定値なのかを、その合成方法が妥当である理由とともに示します。相関のある系統誤差を、独立したノイズとして合成しないでください。

部品と計測器の制約を合わせて評価します。メーターやプローブは、測定対象の回路に影響を与えます。DC誤差が小さくても、整定、安定性、帯域幅、ノイズ性能が保証されるわけではありません。保護デバイスは、該当する故障波形に耐え、保護対象デバイスをその許容範囲内に保つ必要があります。

判断を左右するコーナー条件とマージンを記録し、不確かさによって判断が逆転する可能性のある前提を特定します。文書化されていない部品モデルを使った複雑なシミュレーションより、独立した確認が可能な単純なモデルを優先します。

3. 物理的な実装を確認する

電流ループ、リターン経路、極性、基準ノード、コネクター、電源投入順序をたどって確認します。回路図の接続と、実際のブレッドボードまたは組み立て品を照合します。電源が切れたデバイスへ逆給電する経路を特定します。基板のロジックピンと負荷の電力経路を分けます。ドライバーと保護回路の選択は、実際の負荷と故障条件によって異なります。

一般的なレイアウト上の助言を、検証済みのPCB設計として扱わないでください。関連する結合メカニズムまたは電流リターンの仕組みをたどり、対象部品の実際のガイダンスを参照し、提案する配置のテスト方法を明示します。

4. 範囲を限定した検証を計画し、実施する

適切な無通電状態での目視検査と導通/抵抗チェックから始め、次に電源を制御しながら機能を段階的に有効化します。測定では、メーターのモード、リードのジャック、プローブの定格、基準接続、エネルギー源が適切でなければなりません。電流制限は、蓄積エネルギーや計測器の接地経路を理解する代わりにはなりません。

接続されたハードウェアについては、対象の識別情報、計測器の設定、初期状態、期待結果、観察結果、復旧手順を記録します。バススキャンは能動的なトランザクションであり、デバイスの状態を変える場合があります。ACKは、デバイスの識別や機能のテストにはなりません。

5. 判断し、証拠を残す

結論は次のいずれかにします。明示された条件下で受け入れ可能、判断を左右する故障を理由に不受け入れ、明示した前提の下で条件付き受け入れ可能、または判断に必要な最小限の次のテストを示した上で判断不能。モデル化、シミュレーション、物理測定による証拠を区別します。ソフトウェアが回路に影響する場合は、設計/ファームウェアのリビジョンを記録します。

測定診断では、回答が短い場合でも、簡潔な証拠行を含めます。測定量/テストポイント、明示された計測器の設定、モデルによる予測、報告された観察結果、解釈、次の確認事項を記載します。提供された測定値にはユーザー報告と明記し、未実施の測定には予定と明記します。予測を観察結果として主張しないでください。より大きなタスクには測定テンプレートを使用します。

トラブルシューティングでは、収束しない試行を3回行った時点で停止し、証拠、除外した仮説、残る不確実性、次に必要な専門家または成果物をまとめます。新たな仮説なしに部品交換やスキャンの反復を続けないでください。

使用しない場合

  • ESP32 ボードの識別、ピンの制約、ファームウェアのフレームワーク、書き込み、ブート/リカバリー、OTA については、リポジトリの esp32-development スキルを使用してください。このスキルは、接続された回路の電気的モデルと測定に関する推論を引き続き担当します。ここではフレームワークの手順を重複して記載しないでください。
  • プログラマブルロジックのアーキテクチャ、RTL、シミュレーション、合成、タイミング収束については、リポジトリの fpga-development スキルを使用してください。電気的な互換性は引き続きこのスキルの対象です。
  • 特定の CAD、シミュレーター、プログラマー、計測器の自動化システムについては、該当するツールのドキュメントまたは既存の運用スキルを参照してください。存在しないカタログのルートを作り上げないでください。
  • 商用電源、高エネルギー、RF/高速レイアウト、機能安全、医療、その他の規制対象となる適合性評価には、適切な専門家による根拠とレビューが必要です。このスキルでは要件と根拠を整理できますが、認証を付与したり、そうした分野の専門知識に基づく作業の代わりを務めたりすることはできません。

完了基準

求められた判断に具体的な成果物があり、前提と不明点が明示され、計算と単位を再現でき、選択した動作条件に妥当な根拠があり、関連する測定または未実施の試験が記録され、結論が根拠の強さと範囲に見合っていること。分析タスクは、妥当な条件付きの結論をもって完了できます。ハードウェアの検証タスクは、計算やシミュレーションだけでは完了できません。

コメント