Skill.md検索

Plan モードで実装予測を事前作成 - EnterPlanMode ツールを使用し、tasks.md と design.md から対象タスクの実装予測レポートを生成します。 TDD 実装を自動実行（spec-impl 委任） - Plan 承認後、/kiro:spec-implスキルが tasks.md・design.md を自律的に読み込み、Red → Green → Refactor サイクルで実装します。 実行記録を自動生成 - テンプレートに従ったタスクログを自動作成し、予測と実際の結果を比較記録します。 Spec-Driven Development の厳格な順守 - Plan → 実装 → 記録の3ステップを強制し、規約違反（直接実装やスキップ）を防止します。 Spec-Driven Development（SDD）を厳格に実践したいチーム 実装前に設計・予測を文書化し、レビュー可能な形式で管理したい開発者 TDD と仕様書を統合した開発プロセスを導入したいプロジェクト dev-cycle は cc-sdd（Spec-Driven Development）に基づく開発サイクルを実行します。実装コードを直接書かず、全て/kiro:spec-implに委任します。 Step 1 - Plan モード: EnterPlanModeでモードに入り、tasks.md・design.md から対象タスクの実装予測を作成。予測は「指示」ではなく、spec-impl が自律的に参照するための情報源です。 Step 2 - spec-impl 実行: Plan 承認後、/kiro:spec-impl を呼び出し。spec-impl は tasks.md・design.md・requirements.md を読み込み、TDD で実装・tasks.md チェックボックスを更新。 Step 3 - 実行記録: テンプレート（.claude/skills/dev-cycle/references/task-log-template.md）を読み込み、docs/02_TaskLog/-.mdに記録を作成。予測と実際を比較。 禁止事項: spec-impl をスキップして直接実装、承認前実装、記録省略。必ず順序通り実行。

実装したコードが仕様書の要件をすべて満たしているか自動的に確認でき、仕様逸脱リスクを早期に発見できます。 spec-compliance-checkコマンドで仕様準拠率（目標95%以上）を定量的に把握でき、達成状況を数値で可視化できます。 仕様書と実装の照合を自動化することで、機能要件・非機能要件・データ整合性・UI/UX要件など複数カテゴリの準拠性を一括チェックできます。 仕様書の参照方法・チェックリスト・判断基準が明確に定義されているため、仕様書の読み間違いや実装漏れを防止できます。 仕様変更時に既存実装への影響範囲を素早く特定でき、変更リスクを最小限に抑えられます。 仕様書通りに実装できているか不安なエンジニア、QAテスター 大規模プロジェクトで仕様準拠率を厳密に管理する必要がある開発チーム 仕様変更が頻繁に発生するプロジェクトのプロダクト・マネージャーや要件定義者 Phase C以降の新機能実装を担当するすべての開発者 このSkillは、新機能実装前・実装中・実装後・仕様変更時の4つのタイミングで自律的に使用すべきと定義。spec-compliance-checkコマンドは、Doc/01_Requirements配下の仕様書全ファイルを読み込み、実装コードと仕様書を照合し、仕様逸脱リスク特定と仕様準拠率算出を実行。準拠率目標として全体95%以上、機能要件100%、非機能要件90%以上、データ整合性100%、UI/UX要件85%以上を設定。仕様書の構成は機能仕様書・非機能要件定義書・DB設計書・UI_UX仕様書の4種類。仕様書参照手順は機能特定・仕様精読・ビジネスルール理解・テストケース設計の4ステップ。仕様準拠チェック項目として、機能要件（実装有無・ビジネスルール・バリデーション）、非機能要件（パフォーマンス・セキュリティ・可用性・保守性）の確認項目を定義。

技術決定の根拠を素早く確認: 新機能・ライブラリ選定時に、過去の意思決定（ADR）から最適な方法を参照できます。 実装ルール・アーキテクチャ基準を一箇所で管理: namespace設計、テスト方針、実装規約など、プロジェクト固有のルールを体系的に参照します。 過去の問題解決策を活用: 同じ問題で別プロジェクトが経験した解決策を活用し、試行錯誤を減らせます。 新しいADR作成判断をサポート: 既存ADRをすべて確認した上で、新規ADR作成が本当に必要かを判断できます。 複数プロジェクトを進行中: プロジェクト固有のルール・決定事項を忘れずに参照したい人 チーム開発で一貫性を保ちたい: 実装方法・アーキテクチャが人によってぶれないようにしたい人 技術選定に時間がかかっている: 過去の判断根拠を再利用して、決定を加速したい人 このスキルはADR（Architecture Decision Record）知見の体系的参照・適用を提供します。使用タイミングは：技術決定時（新技術選定、アーキテクチャ設計、ライブラリ選定）、問題発生時（過去の類似問題参照）、ADR作成判断時、実装時（ADR準拠確認）。主要ADR抜粋は ADR_010（実装規約：詳細コメント、MainAgent責務分担、Fix-Mode活用）、ADR_013（SubAgentプール方式：13種類定義、並列実行）、ADR_016（プロセス遵守違反防止：コマンドは契約、承認必須、手順変更禁止）、ADR_019（namespace設計：Bounded Context別、階層制限3-4層）、ADR_020（テストアーキテクチャ：レイヤー×テストタイプ分離、命名規則）、ADR_021（Playwright統合：MCP+Agents統合、93.3%効率向上）。ADR検索方法は Grep ツール使用またはADR番号から Doc/07_Decisions/ 配下から検索。

エミュレータへのワンステップデプロイ: WSL2 上のプロジェクトを Android エミュレータにビルド・デプロイし、画面表示や動作をリアルタイム確認できます。 古いバンドルキャッシュの問題を自動解決: git stash/checkout 後のタイムスタンプ更新漏れで古い JS バンドルが再利用される問題を、ビルド前の強制クリアで防ぎます。 ビルドモード・デバッグオプションを柔軟に選択: debug/release ビルド、logcat ストリーミング、アプリデータ初期化（--clean）など、確認シーンに応じたオプションが選べます。 ネイティブ変更の自動判定: expo prebuild 実行の要否を自動判定し、不要な再ビルドを防ぎながら変更を確実に反映します。 React Native/Expo で Android アプリを開発している人 WSL2 上で開発環境を構築している人 画面デザイン・動作確認をエミュレータで素早く進めたい開発者 キャッシュトラブルで古い状態が反映される問題に悩んでいる人 このスキルは WSL2 + Gradle + adb による Expo Android エミュレータワークフロー。引数で --debug（debug ビルド・Metro 接続）/ --release（デフォルト）/ --logcat（デプロイ後ストリーミング開始）/ --clean（デプロイ前クリア）を指定可能。環境：Android SDK /mnt/c/Users/ka837/AppData/Local/Android/Sdk、パッケージ com.voicescoreboard.app、AVD Pixel_7a、アーキテクチャ x86_64。Step 1 で adb devices でエミュレータ確認（未起動時は -avd Pixel_7a で起動）、DEVICE_SERIAL=emulator-5554 格納。Step 2 で --clean 時に pm clear 実行。Step 3 でネイティブ変更判定（android/ 非存在時/ app.json 変更時に expo prebuild、JS/TS のみなら不要）。Step 4 で JS バンドルキャッシュを強制削除（常に実行・必須）。Step 5 で x86_64 ビルド実行。

Red-Green-Refactorサイクルの自動進行 — テスト駆動開発の3段階（失敗するテストを書く→最小実装→リファクタリング）を段階的に進め、テスト品質とコード品質を両立させることができます。 テストカバレッジを自動維持 — 品質基準（全体80%以上、Domain層100%）を自動チェックするため、テスト不足による本番バグを事前に防ぐことができます。 unit-testエージェントとの連携 — 複雑なテスト作成時にはunit-testエージェント（テスト専門AI）に自動委託し、効率的にテストコードを生成できます。 新機能実装時の品質確保 — 実装前にテストを書くため、要件漏れを早期に発見でき、修正にかかる時間と費用を大幅削減できます。 リファクタリングの安全性向上 — テストが常に有効なため、コード改善中に誤って動作を変えてしまう『退行（リグレッション）』を防ぐことができます。 バックエンド・フロントエンドエンジニア — 品質の高い保守性の良いコードを書きたい、開発後のバグ修正の手間を減らしたい人。 テック主導のスタートアップ — 限られたリソースで最大の品質を実現し、本番バグによるダウンタイムを最小化したい組織。 レガシーコードの改善担当者 — テストを書きながら段階的にコードを改善し、動作を壊さずにリファクタリングしたい人。 開発チームリード — チーム全体のテスト品質基準を統一し、誰が書いても一定の品質を保つ仕組みを構築したい人。