Menu
実装時に遵守すべきコード品質ルール（500行ルール、固定アーキテクチャ、SOLID原則、命名規則、テストカバレッジ要件）を定義
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
PR作成後のCI監視、失敗時の分類と対応、自動マージまでの完全なワークフローを定義
GitHub Issue間の依存関係（Is blocking / Blocked by）を設定・取得するためのAPI操作を提供
GitHub Issueのラベルとメタデータを使用した環境状態管理。worktree/ホスト環境すべてからアクセス可能なSingle Source of Truth
PRの作成からマージ、クリーンアップ、ロールバックまでの標準フローを定義
バージョン整合性チェック→提案→承認→GitHub Release作成までの標準リリースフロー（マルチエコシステム対応）
Git worktree を作成し、並行開発用の独立したブランチ環境を構築する。プラットフォーム固有コード開発時に使用。
| name | code-quality-rules |
| description | 実装時に遵守すべきコード品質ルール（500行ルール、固定アーキテクチャ、SOLID原則、命名規則、テストカバレッジ要件）を定義 |
本ドキュメントは、実装時に遵守すべきコード品質ルールを定義します。 すべてのエージェントはこのルールに従って実装を行います。
1ファイルあたり500行を上限とします。 これはクリーンアーキテクチャ/オニオンアーキテクチャの単一責任の原則に基づきます。
| 条件 | 対応 |
|---|---|
| 500行以下 | OK |
| 500行超過 | 自動分割を実行 |
| レイヤー | 分割方針 |
|---|---|
| Domain | Entity → Value Object抽出、Domain Service分離 |
| Application | UseCase分割、Query/Command分離（CQRS） |
| Infrastructure | Repository実装分割、外部サービスAdapter分離 |
| Presentation | Controller分割、DTO/Transformer分離 |
| Frontend | コンポーネント分割、カスタムHook抽出 |
以下の場合は500行超過を許容：
Adaptive Strategy: プロジェクトの特性やフレームワークに合わせて最適なアーキテクチャを選択する。 一律の「固定アーキテクチャ」強制は廃止。
実装エージェントは以下の優先順位で採用するアーキテクチャを決定します。
docs/architecture.md または設計書（基本・詳細）に明記されたアーキテクチャ。プロジェクト固有の定義がない場合の標準セットです。
| 領域/規模 | 推奨パターン | プロンプト指定 | 備考 |
|---|---|---|---|
| Backend (Simple) | Layered (Controller-Service-Repository) | Layered Architecture | 一般的なWeb API |
| Backend (Complex) | Onion Architecture + DDD | Onion Architecture | ビジネスロジックが複雑な場合 |
| Frontend (App) | Framework Standard (e.g. Next.js App Router) | Next.js App Router | フレームワーク推奨に従う |
| Frontend (Component) | Atomic Design | Atomic Design | 大規模なUIコンポーネント設計時 |
| Script/Tool | Single File / Module based | Modular | 過剰なレイヤー化は禁止 |
選択されたアーキテクチャ名をプロンプトに含めるだけで、詳細説明は省略可能です（80-90%トークン削減）。
// Next.jsの場合
"Next.js App Router標準構成。Server ComponentsとClient Componentsを適切に分離。"
// 複雑なドメインの場合
"オニオンアーキテクチャ + TDD。Domain層の依存を排除。"
// 小規模ツールの場合
"シンプルなモジュール構成。過剰な抽象化は避けること。"
| 原則 | 説明 | チェック項目 |
|---|---|---|
| Single Responsibility | 単一責任 | 各クラス・関数は1つの責務のみ |
| Open/Closed | 開放閉鎖 | 拡張に開き、修正に閉じている |
| Liskov Substitution | リスコフ置換 | サブタイプは親を代替可能 |
| Interface Segregation | インターフェース分離 | 必要なインターフェースのみ実装 |
| Dependency Inversion | 依存性逆転 | 抽象に依存、具象に依存しない |
| 原則 | 説明 |
|---|---|
| DRY | Don't Repeat Yourself（重複を避ける） |
| YAGNI | You Aren't Gonna Need It（必要になるまで作らない） |
| KISS | Keep It Simple, Stupid（シンプルに保つ） |
| 対象 | 規則 | 例 |
|---|---|---|
| ファイル名 | kebab-case | user-repository.ts |
| ディレクトリ名 | kebab-case | use-cases/ |
| 定数 | UPPER_SNAKE_CASE | MAX_RETRY_COUNT |
| 対象 | 規則 | 例 |
|---|---|---|
| クラス名 | PascalCase | UserRepository |
| メソッド名 | camelCase | findById() |
| 変数名 | camelCase | userName |
| テーブル名 | snake_case, 複数形 | users |
| カラム名 | snake_case | created_at |
| 対象 | 規則 | 例 |
|---|---|---|
| コンポーネント | PascalCase | UserCard.tsx |
| カスタムHook | camelCase, use接頭辞 | useAuth() |
| 変数名 | camelCase | isLoading |
| イベントハンドラ | handle接頭辞 | handleClick |
| 対象 | 閾値 |
|---|---|
| 新規コード | 80%以上 |
| 全体 | 70%以上（推奨） |
| 種類 | 対象 | 優先度 |
|---|---|---|
| Unit Test | ドメインロジック、ユーティリティ | 高 |
| Integration Test | API、DB連携 | 高 |
| E2E Test | ユーザーシナリオ | 中 |
| 言語/フレームワーク | Linter | Formatter |
|---|---|---|
| TypeScript | ESLint | Prettier |
| JavaScript | ESLint | Prettier |
| PHP | PHP_CodeSniffer | PHP-CS-Fixer |
| Python | Ruff / Flake8 | Black |
| Go | golangci-lint | gofmt |
以下のチェックをコミット前に実行：
| 禁止事項 | 理由 |
|---|---|
any 型の使用（TypeScript） | 型安全性の破壊 |
ts-ignore` skill` / ts-expect-error skill | 型エラーの隠蔽 |
空のcatchブロック catch(e) {} | エラーの握りつぶし |
| 機密情報のハードコード | セキュリティリスク |
console.log の本番コード残存 | デバッグコードの漏洩 |
| テスト削除による「修正」 | 品質の低下 |
todo!, unimplemented! の残存 | 実装漏れ（リリースビルドでパニックする） |
| 禁止事項 | 例外条件 |
|---|---|
| 新規依存パッケージの追加 | 既存で代替不可の場合のみ |
| グローバル状態の使用 | 明確な理由がある場合のみ |
| 直接DOM操作（React/Vue） | パフォーマンス上必要な場合のみ |
| 日付 | バージョン | 変更内容 |
|---|---|---|
| 2026-01-02 | 1.0.0 | 初版作成（ai-frameworkからの取り込み） |