Skill.md検索

要件定義書（requirements.md）をもとに、開発作業の設計書（design.md）を自動生成します。 新規機能開発またはパフォーマンス改善など、作業タイプに応じて最適なテンプレートを自動選択します。 永続化ドキュメント（アーキテクチャ仕様書、リポジトリ構造定義書、開発ガイドライン等）を自動参照し、既存のルールに準拠した設計を生成します。 多言語対応（i18n）やNuxt UI v4の最新コンポーネント記法を設計に反映させます。 既存の開発ディレクトリに設計書を追加したり、古い設計書を再生成・更新することができます。 新機能開発を始める際に、要件から設計書を素早く作成したいエンジニア パフォーマンス改善プロジェクトで、最適化戦略を設計書として形式化したい技術リード プロジェクトのコーディング規約やアーキテクチャに準拠した設計を確実に作成したいアーキテクト 複数の開発作業ディレクトリを管理するプロジェクトマネージャー このスキルは開発作業の設計書（design.md）を生成・再生成します。使用シーンは要件定義から設計開始時、パフォーマンス改善の最適化設計時、既存ディレクトリへの設計書追加時、設計書再生成時です。必要情報はディレクトリパス（docs/working/{YYYYMMDD}_{要件名}/）、要件名（英語ケバブケース）、作業タイプ（「feature」または「performance」、デフォルト「feature」）です。前提としてrequirements.mdの存在を推奨します。実行手順：Step 1で企画書を読み込み、テーマ・ターゲット・見出し構成を確認、Step 2でCONTRIBUTING_QIITA.mdとcontext/knowledge/参照、Step 3で記事を執筆し導入セクション・本文・サンプルコード・まとめセクションを記載、Step 4で保存完了です。執筆ルールはCONTRIBUTING_QIITA.md全遵守、本文2,000～6,000文字目安、H1未使用H2から開始、コードブロック最低1個以上、外部リンクは公式ドキュメント優先です。テンプレートはtemplate.mdまたはtemplate-performance.mdを使用し、Nuxt UI v4記法（UFormField使用、UFormGroup禁止、items属性使用、options禁止）を必須とします。多言語対応（i18n）は必須で、ハードコード文字列禁止、翻訳キー構造設計、プレースホルダー対応を明記します。永続化ドキュメント参照は03_architecture_specifications.md（技術スタック確認）、04_repository_structure.md（ディレクトリ構造確認）、05_development_guidelines.md（コーディング規約確認）、06_ubiquitous_language.md（用語確認）、UI設計時は05の「2.4多言語対応」確認が必須です。

複数フェーズにまたがる大規模・長期プロジェクト向けの包括的なドキュメント一式を自動生成します。プロジェクト計画書、要件定義、全体設計、WBS、実装計画といった7～10種類のドキュメントを構造化して作成します。 各フェーズ（通常3～5フェーズ）ごとに詳細設計書・タスクリスト・テスト手順書を生成し、段階的な実装を支援します。 機能追加やアーキテクチャ変更など、複数コンポーネントをまたがる大規模な企画の全体像を、体系的にドキュメント化します。 プロジェクト計画の漏れや曖昧さを防ぎ、チーム全体が同じゴールで動くための基盤を提供します。 大規模な機能追加やアーキテクチャ変更プロジェクトを計画・立案するプロジェクトマネージャー・リードエンジニア 数週間～数ヶ月かかる複雑なプロジェクトの要件・設計・実装計画を、体系的にまとめたい開発チーム タスク数が10個以上、複数コンポーネント横断の改善プロジェクトに取り組む組織 ドキュメント作成の手間を削減しながら、プロジェクトの全体像を明確にしたい人 大規模プロジェクト向けドキュメント生成スキルです。通常の開発作業ドキュメント（generate-working-docs）との違いは、複数フェーズ・数週間～数ヶ月の期間・詳細WBSと技術設計・各フェーズごとの詳細設計書を要することです。使用シーン例：新クエリタイプ追加、アーキテクチャ大幅変更、横断的パフォーマンス最適化、長期リファクタリング。使い分け目安は「タスク10個以上→プロジェクト」「複数コンポーネント横断→プロジェクト」「3フェーズ以上→プロジェクト」です。生成ファイル構造は docs/projects/{プロジェクト名}/ 配下に project-plan.md、requirements.md、design.md（全体概要）、wbs.md、implementation-plan.md、および phases/{phase1,2,3}/配下に各フェーズの design.md・tasklist.md・testing.md を作成します。実行手順：（1）プロジェクト名を英語ケバブケースで確認、（2）プロジェクト目的・主要機能・技術課題・フェーズ数を収集、（3）ディレクトリ作成、（4）各ドキュメント生成。

古い記法を自動検出: プロジェクトのドキュメント内で Nuxt UI v3 の廃止された記法（UFormGroup、options= など）を一括スキャンし、問題箇所を特定します。 修正方法を自動提案: 検出された各問題に対して、v4 の推奨記法への修正方法を自動生成します。 一括自動修正: 検出された問題を確認後、ワンコマンドで全てのドキュメントを修正できます。 修正品質の確保: 説明文とコードブロックを区別し、意図的に書かれた v3 の例まで誤検出を避けます。 チェック対象の柔軟指定: 特定ディレクトリのみのチェック、または全体チェック（docs/、.claude/skills/ など）を選択できます。 Nuxt UI フレームワークを使用するフロントエンド開発者 プロジェクトのドキュメント品質を統一したい技術リード v3 から v4 への移行を進めているプロジェクトマネージャー 複数人で書かれたドキュメントのメンテナンスを担当する編集者 docs/working/ を中心にプロジェクト内の Markdown ドキュメントをスキャンし、Nuxt UI v3 の古い記法を検出・修正します。検出パターン：UFormGroup → UFormField、:options=/options=/v-bind:options= → :items=、UButtonGroup → UFieldGroup。実行手順は (1)スコープ確認、(2)ファイルスキャン（find で .md ファイル検索）、(3)パターン検出（grep` で各パターン検索）、(4)結果レポート（問題箇所を一覧表示）、(5)修正オプション提示（自動修正・手動修正・スキップ）。自動修正時は各ファイルに Edit ツール適用し置換実行。検出ロジックではコードブロック内のみを対象、説明文での意図的な v3 例は除外し、文脈確認で誤検出を回避します。

新規機能開発またはパフォーマンス改善の要件定義書を自動生成し、開発作業の方向性を明確にできます。 プロダクト全体の仕様との整合性を確認しながら、矛盾のない要件を定義できます。 既存の要件定義書を再生成して、内容を最新の状態に更新できます。 作業タイプ（新規機能 or パフォーマンス改善）に応じた適切なテンプレートで生成できます。 開発作業を開始する前に、要件を整理して共有したいPM・企画担当者 チーム全体で開発方針を統一したいエンジニア 既存要件に変更が生じたため、定義書を更新したい開発責任者

要件定義と設計に基づいて、開発タスクを自動で分割・リスト化できます。 各タスクの実装順序や依存関係を明確にし、効率的な開発進捗を計画できます。 進捗状況を一元管理するタスクリストを自動生成し、チーム内で共有できます。 既存のタスクリストを再生成して、内容を最新化できます。 開発タスクを細分化して、メンバーの役割分担を明確にしたいプロジェクトリーダー タスク管理ツールに頼らず、ドキュメント中心で進捗を可視化したいチーム 複雑な開発作業を体系的に整理したいエンジニア

要件と設計に基づいて、手動テスト手順を自動で作成できます。 ユーザー視点での操作手順を中心に、確認すべき項目を網羅できます。 パフォーマンス改善の場合、Before/After の測定方法を自動で定義できます。 手動で確認できない項目のみ自動テストを追加し、効率的なテスト設計ができます。 実装後のテストを体系的に計画したいテストエンジニア ユーザー目線での動作確認を重視したい開発チーム パフォーマンス改善の効果を定量的に検証したい最適化担当者

要件定義書、設計書、タスクリスト、テスト手順書を一括自動生成できます。 開発作業用ディレクトリを自動で作成し、ドキュメントを整理・管理できます。 プロダクト全体の仕様を参照しながら、一貫性のあるドキュメント群を生成できます。 要件から実装・テストまでの流れを体系的に計画できます。 新規機能開発をスムーズに進めたいプロジェクトマネージャー ドキュメント作成の手間を削減したいエンジニア チーム全体でドキュメント構成を統一したい開発リーダー