Skill.md検索

修正→レビュー→修正の自動ループ：ドキュメント修正後に自動で全体レビューを実行し、問題が解消するまで繰り返すワークフローで品質を担保します。 4観点の包括的なレビュー：整合性（用語・形式の統一）、完全性（必要情報の網羅）、正確性（論理・技術の矛盾がないか）、統合性（他ドキュメントとの連携）を構造化チェック。 詳細なチェックリスト自動実行：見出しレベル・テーブル形式・コードブロック・用語の統一、JSONスキーマ一致確認など15項目以上を自動検査します。 重要度別の修正ガイダンス：発見した問題を🔴高（必須修正）🟡中（推奨修正）🟢低（任意修正）で分類し、優先順位を明確化します。 修正完了の可視化：レビュー結果をMarkdown形式で出力し、問題内容・修正案・チェック状況を一覧で確認・共有できます。 ドキュメント管理者：.opencode/配下のコマンド定義・スキル定義・設定ファイルの品質を一貫させたい人。 エンジニアドキュメント作成者：README、技術仕様書、API定義などの修正時に、漏れやすい項目を自動チェックしたい人。 チームのドキュメント品質向上を目指す人：修正プロセスを標準化し、重大な矛盾や不完全さを本番化前に検出したい組織。 OpenCode（AI自動化フレームワーク）ユーザー：.opencode/内のドキュメント・設定の整合性を保ちたい人。 .opencode/配下（コマンド定義、スキル定義、エージェント定義、設定ファイル、README）のドキュメント・設定修正時の品質保証プロセス。修正→全体レビュー→問題があれば修正→Phase2に戻るループを問題解消まで繰り返す。Phase1は変更計画（対象ファイル・影響範囲・内容確認）と修正作業。Phase2全体レビューは4観点で実施：①整合性チェック（見出しレベル・テーブル形式・用語の一貫性）、②完全性チェック（構造・関連定義・エラーハンドリング網羅）、③正確性チェック（フェーズ番号順序・条件分岐矛盾・ツール名正確性）、④統合性チェック（クロスリファレンス・ワークフロー連携）。レビュー結果は重要度別テーブル形式で出力。Phase3修正では🔴高を必須修正、Phase2へ戻る。

PR作成前の品質チェック自動実行：Lintエラー、型エラー、フォーマット準拠、テスト合格など、ツールで客観的に検証できる基準をすべて確認できます。 差分ベースの効率的なレビュー：ファイル全体ではなく変更箇所のみを対象にレビューするため、AIの確認がスピーディーで正確になります。 到達可能性チェック：実装したコードがエントリポイント（main.rs、page.tsx等）から実際に呼び出されているか自動検証し、孤立したコードを検出できます。 定義-使用相関チェック：定義された引数やPropsが実際に使用されているか確認し、未使用パラメータを排除できます。 スコア判定と品質基準の統一：複数のレビュアーが同じ基準で判定するため、ばらつきのない一貫した品質管理が実現できます。 PRを頻繁に作成する開発チーム全体（エンジニアの作業効率向上） コード品質を一定水準に保ちたいプロジェクトマネージャー 複数言語・複数領域（バックエンド、フロントエンド、DB等）を扱うチーム（領域ごとに異なるレビュアーを自動割り当て） 品質基準の「ゆれ」をなくしたい組織 このスキルは、PR作成前の必須品質レビュープロセスを定義します。 レビューエージェント選択：バックエンド・フロントエンド・DB・インフラ・セキュリティの5種類のエージェントを、実装内容に応じて自動選択します。 差分駆動レビュー（Token最適化）：git diff main...HEADで変更箇所のみを取得し、周辺コンテキストを含めながらも、ファイル全体の読み込みは構造理解が必要な場合に限定します。 ツール検証可能な客観的基準：①Lintエラー0件（cargo clippy、npm run lint）、②型エラー0件（cargo check、npm run type-check）、③フォーマット準拠（cargo fmt、npm run format:check）、④テスト全通過（cargo test、npm test）、⑤カバレッジ80%以上（推奨）を検証します。 到達可能性チェック：実装コードがエントリポイント（Rust CLI なら src/main.rs、Next.js なら app/page.tsx等）から呼び出されていることを確認。参照がない場合はエントリポイント修正が必須です。 定義-使用相関チェック：定義された引数・Props・パラメータが実装内で実際に使用されているか確認します。スコア判定は9-10点で PR作成、7-8点で修正・再レビュー、6点以下で設計見直しとなります。

フロントエンド設計書、バックエンド設計書、セキュリティ設計書など、機能開発に必要なテンプレートを一括で利用できます。 コンポーネント構成、状態管理、API連携、フォームバリデーション、ルーティング、パフォーマンス最適化、テスト方針を体系的に設計書に落とし込めます。 テンプレートを埋めるだけで、開発チーム全体が同じレベルの理解を得られる共通の設計書が完成します。 メタ情報や親設計書への参照を自動含めるため、複数機能の設計書を整理・管理しやすくなります。 フロントエンドエンジニア：複雑な画面機能の設計を整理したい 技術リード：チーム全体で設計ドキュメント品質を統一したい スタートアップ・成長期企業：設計規律を導入し、コード品質を上げたい エンジニアリングマネージャー：オンボーディング時の理解スピードを上げたい 本スキルはフロントエンド設計書テンプレートを中心に構成。テンプレート構成：（1）メタ情報：ドキュメントID（DETAIL-{機能ID}-FRONTEND-001）、親設計書参照。（2）1. コンポーネント構成：コンポーネント階層図（Mermaid）、コンポーネント一覧表（名称・種類・責務・Props）。（3）2. 状態管理設計：状態の種類表（種別・スコープ・管理方法・永続化）、グローバル状態の型定義（TypeScript）。（4）3. カスタムフック設計：フック一覧表（フック名・責務・引数・戻り値）。（5）4. API連携設計：使用エンドポイント表（API・メソッド・用途・フック）、エラーハンドリング表（エラーコード・画面表示・リカバリ）。（6）5. フォームバリデーション：フィールド一覧表（フィールド名・ルール・ライブラリ・エラーメッセージ）。（7）6. ルーティング設計：ルート一覧表（パス・コンポーネント・認証・ガード）。（8）7. パフォーマンス考慮：最適化項目表（不要な再レンダリング防止・遅延読み込み・仮想スクロール等の実装方法）。（9）8. テスト方針：テスト種別表（Unit・Integration・E2E、対象・ツール）。（10）9. 呼び出し元（Integration Points）：⚠️ 必須項目として他機能からの参照を記載。

複数のIssueを独立したDocker環境で同時に処理でき、ブランチ切り替え時の競合を完全に排除できます Issue#42と#43など異なる作業を環境ごとに独立させることで、依存関係の競合やビルドキャッシュの混在を防ぎます 既存環境の一覧確認・作成・開く・設定といった基本操作と、PostgreSQL/Redisなどのサービス追加を自動化できます container-use環境で開発・テストを行うことで、ローカル環境を汚さず再現可能な環境を保証できます DBサービスを安全にテストでき、PRマージ後に環境をクリーンアップして資源を効率的に管理できます 複数のIssueやプルリクエストを同時に進めるエンジニア 開発環境の汚染を防ぎ、再現可能な環境を重視する開発チーム マイクロサービスやDB連携機能をテストするバックエンド開発者 環境の統一管理とリソース効率を求めるプロジェクトマネージャー container-use環境は、Dockerコンテナ内での開発・テストをサポートするツール群です。メリットは環境の再現性確保、チーム間での同一環境共有、複数Issue並行処理時の環境分離などです。必須ルール：実装作業はcontainer-use環境で行い、ホスト環境での直接実装は禁止（例外はimplement-issues.md参照）。並行作業時はIssueごとに1つの環境を作成し、環境IDをGitHub Issueメタデータで追跡します。基本フロー：環境一覧確認→既存環境確認→なければ環境作成→環境設定→サービス追加判断→サービス追加（必要時）→作業開始。主要ツール：environment_list（一覧取得）、environment_create（新規作成）、environment_open（既存環境を開く）、environment_config（環境設定）、add_service（サービス追加）など。プラットフォーム固有コード（macOS/Windows API）はLinuxコンテナでビルド・テスト不可であり、例外ポリシー参照が必要。