Communitygithub.com

BackboneNeo/ai-skills-cad-engineering

FreeCADおよびCADエンジニアリングワークフローのための再利用可能なCodexスキル。信頼性の高いCAD操作を実現します。

ai-skills-cad-engineering とは?

このスキルは、CADエンジニアリングワークフローを体系的かつ信頼性高く実行するためのAIエージェント(Codexなど)向けスキルです。主にFreeCADを対象とし、リポジトリのガイドラインや検証ツールを最優先の情報源として扱います。スキルは「契約の確立」「変更前の検査」「最小限の変更実装」「階層的検証」「リリース候補の作成」「誠実な報告」という6つのフェーズで構成され、各フェーズで具体的な手順と禁止事項が定義されています。特に、ネイティブCADドキュメントの編集、ベースライン管理、検証レポートの比較、リリーストラックの選択など、実践的なワークフローをカバーしています。このスキルは、CADモデルの変更を安全かつ追跡可能に行い、不適切なジオメトリ修復や未検証のリリースを防止するのに役立ちます。

対応~Claude Code✓Codex CLI~Cursor
npx skills add BackboneNeo/ai-skills-cad-engineering

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

CADエンジニアリングワークフロー

リポジトリの指示とリポジトリ所有のバリデーターを信頼できる情報源として扱います。このスキルを使用して作業を体系的に進めます。プロジェクト固有の要件を汎用的な仮定で置き換えないでください。

1. 契約の確立

  1. 該当するすべてのAGENTS.md、プロジェクトガイド全体、アクティブな図面スナップショット、および要求されたIssueを、コードを書く前にすべて読んでください。
  2. 不変のベースラインタグ、CADパス、SHA-256、座標系、単位系、現在のコンポーネント在庫、期待される印刷可能なボディ、およびリリースターゲットを特定します。
  3. 情報源の間に矛盾がある場合、またはベースラインが検証できない場合は、編集を始める前に停止します。
  4. 要求された結果と関連Issueのコンテキストを分離します。バックログをタスクに吸収しないでください。
  5. Issue、リポジトリポリシー、またはユーザーによって宣言されたリリーストラック(デジタルCAD/図面、または物理的に認定された製品)を選択します。図面リリースは製品認定を意味しません。
  6. 各受け入れ基準を、その権威ある契約に従って、計算、視覚、物理、またはオペレーター専用に分類します。図面トラックでは、「適合」「取り付け」「取り外し」「クリップ」「作動」「配線」「アクセス」などの用語は、契約が製造サンプルや実地試験を明示的に要求しない限り、デジタルジオメトリ/パス検証を意味します。汎用的なエンジニアリングリスクを必須のゲートに昇格させたり、物理的な基準がジオメトリのみで合格したと報告したりしないでください。

ベースラインの選択または検証時にはbaseline-and-source-truth.mdを読んでください。既存の失敗候補を修復する前にfailure-patterns.mdを読んでください。

2. 変更前の検査

  1. 既存のネイティブCADドキュメントを開き、そのツリー、オブジェクトタイプ、式、プロパティ、配置、グループ、ソリッド、可視性、および再計算状態を検査します。

  2. 機械可読なベースラインレポートを記録します。FreeCADが利用可能な場合は、以下を実行します。

    python scripts/run_inspect_fcstd.py --freecad FreeCADCmd.exe --file <baseline.FCStd> --output <baseline-report.json>

  3. メッシュ、STEP、スクリーンショット、スナップショット、またはブートストラップジェネレーターから既存のネイティブドキュメントを再構築しないでください。

  4. タスクがそれらの変更を明示的に要求しない限り、ユーザーが保存した配置、色、可視性、式、または手動編集を上書きしないでください。

  5. リポジトリルールによって過去のリリースが不変である場合、新しいバージョン管理されたパスで作業します。

3. 最小限の完全なエンジニアリング変更を実装する

  1. 正確で固定されたコンポーネントソースを使用します。編集可能なソース、正確なインポート成果物、原産リビジョン、およびSHA-256を一緒に保持します。
  2. 外部コンポーネントをリポジトリの埋め込みソースグループに配置し、検証済みモデルからマウントジオメトリを導出します。
  3. レガシージオメトリは、そのネイティブ上流フィーチャで置き換えます。パッチ、プレート、プラグ、スキン、フィラー、またはコプラナー修復を下流の完成ボディに融合させることにより、廃止された穴、ポケット、逃げ、またはマウントフィーチャを隠さないでください。
  4. ネイティブなフィーチャ前のボディまたは編集可能な構築チェーンを復元できない場合は、ブロッカーで停止します。単に要求された最終エンベロープを取得するために、追加的な修復ジオメトリを代用しないでください。
  5. リポジトリがSketcherベースの制御を要求する場合、制御ジオメトリを編集可能かつ完全拘束のままにします。
  6. すべての制御フィーチャを、検査可能な依存関係またはシーケンシャルブールチェーンを介して最終印刷可能ボディに接続します。スケッチやカッターが存在しても、統合が証明されたわけではありません。
  7. コンポーネントを交換するときは、廃止されたコンポーネント固有のカット、逃げ、ラベル、アクティブな埋め込みソース、および下流の残骸を削除します。
  8. 付随的な変更を制限します。関連のないコンポーネントの配置、印刷可能ボディ、座標系、外観、およびドキュメント構造を保持します。

すべての交換またはサイズ変更された開口部について、native-feature-replacement.mdを読み、それに従ってください。コンポーネント作業についてはcomponent-integration.mdを、ネイティブモデリングおよびブール演算についてはparametric-geometry.mdを読んでください。

4. 階層的に検証する

意味のあるジオメトリグループごとに、最後だけでなく検証を実行します。

  1. 再計算し、ドキュメントエラーを拒否します。
  2. 保存、閉じて、再度開き、再計算、保存し、再度開きます。
  3. 期待される印刷可能ボディ数、ソリッド数、境界、体積、およびトポロジーを確認します。
  4. 要求されたフィーチャが意図された最終ボディに影響を与えていることを証明します。
  5. 交換の場合、影響を受けるローカルソリッドが、新しい意図された操作のみが適用されたネイティブ未変更フィーチャと等しいことを証明します。残留するレガシー輪郭、追加的な修復依存関係、余分なコプラナー境界、および隠れたフィラーボディを拒否します。
  6. 干渉と必要な接触を別々にチェックします。必要なマウント接触は不要な干渉ではありません。
  7. 該当する場合、アセンブリ順序、取り外し経路、コネクタ挿入経路、ファスナー軸、ツールエンベロープ、端子アクセス、配線スペース、曲げ半径、およびストレインリリーフをデジタルでチェックします。この証拠を「幾何学的」とラベル付けします。物理的な適合性、力、または耐久性を主張しないでください。
  8. 使い捨てコピーでパラメトリック編集可能性をテストし、元のパラメータを復元します。
  9. 必要なSTLおよびSTEP成果物をエクスポートし、エクスポートごとに個別に再度開きます。
  10. コンポーネントを表示した状態と非表示にした状態でクローズアップをレンダリングし、ネイティブ開口部と周囲の壁が確認できるようにします。
  11. 保存されたFCStdをレンダリングします。近似のパラレルモデルはレンダリングしません。
  12. ランナーによって制御されるすべてのリポジトリ所有テストを正確に実行します。

run_inspect_fcstd.pyを使用して候補レポートを生成し、次に以下を使用してベースラインと比較します。

python scripts/compare_fcstd_reports.py --baseline <baseline-report.json> --candidate <candidate-report.json>

各ゲートに必要な証拠については、validation-matrix.mdを読んでください。

5. 一貫性のあるリリース候補を組み立てる

  1. ネイティブCAD、埋め込みソース、エクスポート、プレビュー、レイアウト、マニフェスト、スナップショット、バージョンノート、およびアクティブインデックスを相互に一貫させます。
  2. 最終成果物の生成後にのみSHA-256を再計算します。ハッシュを含むファイルが変更された後は、検証を再実行します。
  3. 履歴ベースラインの不変性を、差分または保存されたハッシュで証明します。
  4. プロジェクトポリシーが自動生成を禁止している場合、手動専用形式を空のままにします。
  5. 必須ゲートが不完全な場合、タグまたはリリースを作成または承認しないでください。
  6. 必要なデジタルゲートが合格した場合、オプションの将来の物理認定が実行されていなくても、図面リリースを許可します。決して「製品準備完了」または「物理認定済み」とラベル付けしないでください。
  7. 製品認定リリースは、必要な物理的なビルド、測定、アセンブリ、およびエンジニアのサインオフが合格した後の、正確な図面コミットからのみ作成します。

リリーストラックとタグポリシーを選択するには、release-lifecycle.mdを読んでください。完了を宣言する前にrelease-gate.mdを読んでください。

6. 正直に報告する

  • 選択されたリリーストラックに必要なすべてのタスクゲートが合格した場合、completedを返します。
  • 権威あるタスクまたはリポジトリソースが不完全な物理的またはオペレーターゲートを明示的に要求する場合にのみ、完了した候補を保持した状態でblockedを返します。
  • 要求された状態が既に存在することを証明した後にのみ、no_change_neededを返します。
  • 要求されていないクーポン、サイクル、振動、ピン配列、配線、またはその他の物理的テストは、ブロッカーではなくフォローアップ推奨事項として記録します。受け入れ基準をでっち上げないでください。
  • 各ブロッカーを証拠と1つの実行可能な次のステップとともに個別にリストします。
  • not_run、failed、passedを区別します。証拠の欠如を成功に変換しないでください。
  • リリースブロッカーをリスクや要約テキストに隠さないでください。

関連スキル