c-systems について
C11以降のシステムコード、ライブラリ、ネイティブ拡張の実装とレビューを支援するスキルです。リポジトリの規約、実行時安全性、エラー処理、ビルド検証を重視します。
主な機能
- 01リポジトリの慣例とABIの維持
- 02所有権の明示と失敗し得る呼び出しの確認
- 03外部入力と割り当て量の制限
- 04初期化処理の再入防止
- 05ビルドとサニタイザー付きテストの検証
活用シーン
- 01範囲を限定したCシステムコードの変更
- 02メモリと入力の安全性レビュー
- 03リリースビルドでのネイティブコード検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ iliaal/ ai-skills --skill c-systemsインストール後、Claude Code で/c-systemsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
SPEC.mdreferences/build-and-measurement.mdcorrectness-traps.mdimplementation-structure.mdlegibility-standard.mdmemory-safety.mdphp-extension-c.mdruntime-safety.md詳細
C システムとネイティブコード
ライブラリ、システムコード、ネイティブ拡張向けの C11 以降を扱います。C++(RAII、テンプレート、ムーブセマンティクス)については、ia-cpp-systems スキルを参照してください。
作業ルール
- リポジトリで認められている慣用表現と ABI を維持してください。範囲を限定した修正を、コードスタイルの全面変更に広げないでください。
- 所有権を明示し、失敗する可能性のある呼び出しを確認し、公開境界を検証し、内部不変条件をアサートしてください。
- オプティマイザーの前提外でも復旧処理を維持してください。 アサーションが前提条件に変換されると、偽の場合を処理する分岐が削除されることがあります。復旧可能なチェックは実行時分岐として維持し、診断専用のアサーションはデバッグ用のプリプロセッサガードの内側に置いてください。最適化されたリリースビルドでフォールバックを実行してください。
- 段階的な初期化では再入を防いでください。 コールバックを呼び出す可能性のある処理の前に、すべてのコンストラクターまたはファクトリーパスで処理中マーカーを設定してください。失敗後の再試行は、部分的な状態を完全に解放してリセットした後にのみ許可してください。再帰的なエントリーと、初期化失敗後の再試行をテストしてください。
- 外部入力の走査に上限を設け、割り当てや縮小変換の前にサイズを確認してください。
- 概念に名前を付ける、エラーを管理する、または副作用を切り離す場合にのみヘルパーを選んでください。
- 実際に再ビルドされた成果物を検証してください。安全性には計測機能付きテストを、パフォーマンスには代表的なリリースビルドを使用してください。
リポジトリの規約をこのスキルより優先してください
コードを書く前に、リポジトリの AGENTS.md/CLAUDE.md、公開ヘッダー、および隣接する .c ファイルを 2 つ読んでください。以下のルールと矛盾する場合は、リポジトリの規約を優先し、その旨を差分に記載しないでください。
この確認を省略しないでください。確立された C コードベースでは、以下のルールであれば指摘される慣用表現も認められている場合があります。
| ローカルの慣用表現 | 適切な使用箇所 |
|---|---|
| タブによるインデント | php-src とその拡張機能、Linux カーネル |
goto cleanup / goto err | カーネル、OpenSSL、curl、php-src:複数リソースを解放する際の主要な慣用表現 |
return を含むマクロ | PHP 拡張機能の RETURN_*/RETVAL_*、CPython の Py_RETURN_* |
| プロジェクト独自のステータス型 | zend_result、CURLcode、errno を伴う int:既存の型と並行する独自の列挙型を作らないでください |
隣接する未変更の C コードがこのルールより古いという理由で、範囲を限定した作業をリポジトリ全体のコードスタイル変更に広げないでください。
対象が PHP 拡張機能の場合(php_*.h、PHP_FUNCTION、zend_、config.m4)、以下のルールを適用する前に php-extension-c.md を読み込んでください。レイアウト、マクロ、エラーモデル、メモリ、アサーションにはすべて拡張機能固有の例外規定があります。特にメモリに関する規定は基本方針と逆で、拡張機能では malloc/free ではなくリクエストスコープのアロケーターを使用します。
検証
- リポジトリの警告設定でビルドが成功し、新たな警告がないこと(新規プロジェクトでは
-Wall -Wextra -Werror -Wconversion -Wshadowの全オプションを適用し、警告ゼロであること) -fsanitize=address,undefinedを使用したテストスイートで報告がないこと- テストスイートを実行できる場合、
valgrind --leak-check=full --error-exitcode=1で問題がないこと - 新たに追加した失敗する可能性のある呼び出しをすべて確認し、新たに追加したエラー値の生成元を追跡できること
- 新たに追加した状態変更を行うリーフ関数にすべてアサーションがあること
- リポジトリで認められた形式または前方への単一ジャンプによるクリーンアップ以外の
gotoが追加されていないこと。外部入力の再帰がなく、名前付きの上限を設けずに外部入力をループ処理していないこと
タスク固有のリファレンス
該当する動作を実装またはレビューする前に、関連するリファレンスを読んでください。
- モジュール構成、命名、分解、制御フロー、エラー、型、マクロについては、implementation-structure.md を参照してください。
- メモリ、外部入力、アサーション、ABI の変更、共有ヘルパーの契約については、runtime-safety.md を参照してください。
- コンパイラーのセットアップ、テスト、ビルドの来歴、パッケージング、パフォーマンスに関する主張については、build-and-measurement.md を参照してください。
該当するトピックに応じて、既存の専門リファレンスも参照してください。