ドキュメント生成

ソースコード変更から対応スキルを自動特定し、どのドキュメントを更新すべきかを提示します スキル内のコード例とソースコードを比較し、差分がないか自動確認します sourcePatterns（監視対象ファイル）の設定が正しいか検証し、設定ミスを防ぎます 複数スキルの sourcePatterns を一覧で確認でき、スキル更新の漏れを防げます ソースコード更新後、対応ドキュメントをどれ更新すべきか分からない開発者 スキルドキュメント（SKILL.md）の差分管理・メンテナンスを自動化したいプロジェクト管理者 複数スキルを管理していて、更新漏れが発生しやすいドキュメント運用担当者 CLAUDE.mdやスキル内容の最新性を定期的に確保したいチームリーダー スキルと対応ソースコードの関係を管理し、変更検出→スキル特定→差分確認→sourcePatterns検証の4ステップで運用します。各スキルには sourcePatterns が定義されており、対応ソースファイルが変更された場合にスキルの更新が必要になります。変更されたファイルと sourcePatterns を照合し、更新が必要なスキルを特定。スキル内のコード例と実際のソースコードを比較し、乖離がないか確認。sourcePatterns が正しく設定されているか検証します。変更検出は git diff（最新5コミット、mainからの差分、特定コミットからの差分）で行い、複数スキル（tumiki-custom-mcp-server-feature、tumiki-dynamic-search-feature、tumiki-ee-ce-separation、tumiki-mcp-proxy-architecture、tumiki-prisma-schema-changes）の対応パターンを一覧で管理します。

新機能の実装完了後、設計書・実装計画書・API比較表・README・チュートリアルをまとめて最新化できます Git の変更履歴から実装内容を自動判定し、どのドキュメントを更新すべきかを特定できます 実装ステータス、API仕様、実装詳細、ファイル構成などを一括更新し、ドキュメントと実装のズレを防げます 新しく実装されたAPIの場合、既存フォーマットに従って自動的に設計書を生成できます 機能を実装した直後、ドキュメント更新を効率的に済ませたい開発者 設計書と実装のズレを最小限にしたいプロジェクト README や API リファレンスを常に最新に保ちたいチーム 新機能追加時に、関連する複数のドキュメントを漏れなく更新したい人 update-docs スキルは 3 フェーズで実行されます。Phase 1（共通）：git diff と git log から変更内容を把握し、実装した機能を特定。Phase 2（開発ドキュメント更新）：設計書（docs/design/）ではステータスブロック・API仕様・Streamlit比較表を更新、実装計画書（docs/impl/）ではフェーズ完了状況・ファイル構成を更新、API比較表（docs/streamlit-api-comparison.md）では ❌ → ✅ に変更；該当ドキュメント未存在時は既存フォーマットに従い新規作成。Phase 3（README更新）：Features・API Reference セクションで新しいAPIを追加、既存フォーマット（TypeScript シグネチャ・パラメータテーブル・使用例）に従って記述。バグ修正・リファクタリング後にも使用可能。

インシデント発生後に、責任追及ではなく「システム改善の機会」として捉えた事後分析ドキュメント（ポストモーテム）を自動作成できます Google SRE のベストプラクティスに基づき、日本語で統一されたフォーマットで記録し、同じ問題の再発を防ぎます タイムライン、根本原因、影響範囲を定量的（ユーザー数、エラー率など）に記載し、チーム全体の学習資産として活用できます ポストモーテム作成に必要な情報を自動収集し、足りない情報を効率的に質問できます 過去の障害だけでなく、ヒヤリハット（重大事故の一歩手前の状況）の分析にも対応します SRE・DevOps・インフラエンジニア：障害対応後のドキュメント化が必須の職種 スタートアップやスケール期の組織：事後分析の文化を早期に確立したい チームリード・マネージャー：障害からの学習を組織全体で共有したい セキュリティ・品質保証チーム：インシデント記録を組織資産として管理したい このスキルは5つの基本原則に基づいています。（1）Blameless（非難しない）：個人の過失ではなくシステムの改善機会に焦点、（2）正直さと透明性：都合の悪い事実も含めて記録、（3）アクション駆動：全アクションに担当者と期限を設定、（4）定量的：影響を数値で表現、（5）学習の共有：他チームが同種問題を予防できるよう知見を記録します。実行時は既存のポストモーテムテンプレート確認→インシデント情報の多角的収集（会話・システムログ・コミット履歴）→必須情報確認→ドキュメント執筆という手順で進めます。

研究開発提案書、申請書、報告書などの定型文書の構造を分析し、再利用可能なテンプレートとして template.md を自動生成できます。 抽出したセクションを「手動入力が必要な表形式・図表」と「AI生成可能な自由記述」に自動分類し、チーム全体で統一されたドキュメント作成フローを確立できます。 生成されたテンプレートを使って新しいドキュメント作成時の下書き自動生成やチェックリスト確認ができるため、抜け漏れなく効率よくドキュメントを完成させられます。 AMED等の公的申請書などの既存テンプレートを参照・カスタマイズできるため、初回作成の手間を大幅に削減できます。 繰り返し作成する申請書や報告書がある研究機関や企画部門の担当者 社内ドキュメント形式を統一・テンプレート化したい企業の管理部門 複数のプロジェクトドキュメント（提案書、計画書など）を効率よく管理したいマネージャー ドキュメント構造を分析し再利用可能なテンプレートを作成するスキル。ワークフローは3段階：(1)ドキュメント分析：docxスキルを使用してXML抽出、またはテキスト内容からセクション見出し特定。(2)セクション分類：「手動入力セクション」（表形式、図表、業績リスト、AI生成困難な項目）と「AI生成可能セクション」（自由記述の文章に記載ガイダンス付与）に分類。(3)テンプレート生成：assets/template.md に「【手動入力セクション】」と「【AI生成可能】」の区分で出力。テンプレート使用目的：構造理解・下書き作成・チェックリスト確認。既存テンプレート例として研究開発提案書テンプレート（AMED申請書ベース）を提供。

セッションの作業内容を自動分析し、セッションログ、ADR、ナレッジベース、実装解説、操作レシピ、改善記録、調査記録のうち作成すべきドキュメントを特定できます。 Gitの変更履歴と会話文脈から、技術選定・設計判断・新パターン導入などの形式知を自動検出します。 必要なドキュメントを確認後、ユーザー確認を待たずに自動作成し、セッション終了後のドキュメント作成の手間を大幅削減できます。 リポジトリに形式知として知見を蓄積し、プロジェクトのナレッジを整理・共有できます。 AIとのセッション終了時にドキュメント作成ルールを確実に守りたい開発者 設計判断やトラブルシューティング内容を自動的にナレッジ化したいチーム 作業内容の記録と共有を仕組み化して属人性を減らしたいプロジェクトリーダー セッション終了時の手作業を自動化して作業効率を高めたい技術者 /wrap-upで呼び出し、オプションで特定ドキュメント種類を指定できます（log/adr/knowledge/impl/recipe/improvement/investigation）。指定なければ全種類をチェックして必要なものを提案します。現在ブランチのコミット一覧と変更ファイル統計から作業を分類し、チェックリスト（セッションログ：コード変更・設計判断、ADR：技術選定・実装方針、ナレッジベース：新ツール・パターン導入、実装解説：設計伴う実装、操作レシピ：非自明な問題解決、改善記録：AI運用の問題、調査記録：トラブルシューティング2回以上）に基づいて必要性を判定します。各ドキュメントの規約に従って自動作成し、セッションログは初回コミット時刻からファイル名を生成、ADRは次番号を確認、ナレッジベースは既存カテゴリを確認して追記か新規判定、実装解説は/explainを自動実行します。

バッジ関連の会話が出た時に、自動的にBADGE_LIST.mdを参照して現在のバッジ一覧を確認できます。 バッジの追加・削除・名前変更・獲得条件変更・レア度変更・画像パス変更をコード実装と同時にドキュメントに反映できます。 lib/data/badge_definitions.dart（ソース）とBADGE_LIST.md（ドキュメント）の同期状態を常に保つことで、ドキュメントの信頼性を確保できます。 バッジ数サマリーや獲得処理の実装状況リストを自動更新できます。 ゲーム・アプリ開発者：バッジシステムの仕様変更を追跡可能な形で管理したい プロダクトマネージャー：バッジ一覧を常に最新状態で確認・共有したい QAテスター：獲得条件やレア度の変更をドキュメントから正確に把握したい 開発チーム：コード変更とドキュメントの乖離を防ぎたい バッジ関連ワード（「バッジ」「badge」「バッジ追加」「バッジ削除」「バッジ変更」「バッジ一覧」「バッジ定義」「レア度」「獲得条件」など）が出たら、BADGE_LIST.mdを参照して現状把握。コード変更を伴う場合は実装後に必ず同期を取る。バッジ定義ソースはlib/data/badge_definitions.dartが正。BADGE_LIST.mdの更新内容は：追加時は該当カテゴリに新行追加、削除時は行削除（廃止時は注記付与）、変更時は該当行修正、新カテゴリ追加時はセクション作成、トリガー実装変更時は「獲得処理」セクション更新、画像変更時は「画像」セクション更新。バッジ数サマリーの合計数が実定義数と一致することを確認し、badge_definitions.dartとBadge_LIST.mdの差分がないことを検証。

新機能やAPI変更、動作変更をコード実装時に自動でドキュメントに反映できます。 git diffを分析して変更種別を自動判定し、README、CLI仕様書、設定ドキュメント等の該当箇所を一括更新できます。 ユーザー向け変更を発見可能にするため、簡潔・例示優先・検索可能なドキュメント形式を自動適用できます。 内部実装詳細やデバッグ専用オプションなど、ユーザーに不要な情報を自動的に除外できます。 新機能実装時にドキュメント更新を忘れたくない開発者 複数のドキュメント箇所を一括で同期させたい技術リード ユーザー向けドキュメントの内容と実装の齟齬を防ぎたい品質管理者 API仕様やCLI仕様の変更を自動で反映させたいマイクロサービスチーム ユーザー向け変更を発見可能にするため、変更種別に応じたドキュメント箇所を更新する。決定マトリックス：新public API→README.md+mod.ts(JSDoc付export)、新機能→README.md+docs/usage.md、動作変更→README.md既存記述更新+CHANGELOG.md、CLI変更→docs/breakdown/interface/cli_commands.ja.md、パス解決変更→docs/breakdown/interface/path_resolution.ja.md、設定変更→docs/breakdown/interface/configuration.ja.md、ドメイン設計変更→docs/breakdown/domain_core/配下、内部変更→CLAUDE.md(開発ワークフロー影響時のみ)。手順：git diff --name-only→変更分類→該当ドキュメント更新→コード例動作確認。守則：簡潔・例示優先・検索可能。記載禁止事項：内部実装詳細、一時的ワークアラウンド、デバッグ専用オプション。

フェーズの完了状態に合わせて AGENT_TEAM_GUIDE.md と IMPLEMENTATION_ROADMAP.md を自動で最新状態に整理・更新できます。 完了したフェーズに「（完了）」マークを追加し、現在実行中のフェーズを明記できます。 Firestore設定、画面設計、機能定義、ビジネスモデル、営業資料など、関連ドキュメント最大7種類を一括で同期できます。 チェックボックス形式のタスク管理から、完了済みタスクを自動判定して複数ドキュメントに反映させます。 「フェーズが完了したのでガイドを整理して」といった依頼を1つの指示で一括処理できます。 複数の設計ドキュメントを管理しており、更新漏れが心配なプロジェクト担当者 フェーズごとの進捗を記録し、チーム全体で最新情報を共有したい開発リーダー 営業資料や機能説明資料を自動で同期させたいビジネス責任者 手作業でドキュメント更新する時間を削減したい誰もが このスキルは、ユーザーからの「手順書を更新して」「フェーズが完了したのでガイドを整理して」「ロードマップを更新して」といった依頼を受けると、以下4つのステップで自動実行されます。 Step 1: IMPLEMENTATION_ROADMAP.md と AGENT_TEAM_GUIDE.md を読み込み、各フェーズのチェックボックス状態とステータスを確認します。 Step 2: IMPLEMENTATION_ROADMAP.md を整理し、全チェックボックスが完了した（[x]）フェーズの見出しに「（完了）」を追記します。 Step 3: AGENT_TEAM_GUIDE.md の各フェーズステータスを更新します。完了済みフェーズは日付付きで「完了」に変更、次フェーズは「実行中」に変更、部分完了は該当プロンプトタイトルに「（完了済み）」を追記します。 Step 4: 完了したタスク内容に基づき、関連ドキュメント7種類（FIRESTORE.md、USER_APP_SCREENS.md、SERVICE_FEATURES.md、BUSINESS_MODEL.md、STORE_SALES_PRESENTATION.md、STORE_FEATURE_GUIDE.md）を確認・修正します。Firestore変更、画面作成・変更、機能追加・変更、ビジネスモデル変更、営業資料・機能説明資料の同期が必要な場合のみ更新を行います。

テキスト分析ツール（Linter）で文法と表記をチェック：npx textlint コマンドを実行し、日本語の文法、表記ゆれ、冗長表現、助詞の不自然さなどを機械的に指摘。すべての指摘を修正することで品質を担保します。 ドキュメント全体の文体を「ですます調」で統一：「だ・である調」を排除し、一貫した敬体で記述。読み手にやさしく、プロフェッショナルな印象のドキュメントに。 AIっぽさや不自然な表現を排除：「あなたが」「〜いるんです」といった砕けすぎた表現や、押し付けがましい断定を削除。淡々と事実を述べた自然な日本語に改善します。 太字や構成を最適化：本当に強調すべき技術用語だけに絞り、冗長な前置きや不要な感想文を削って、伝わる構成に整備します。 GitHub等でREADMEやドキュメントを公開している開発者：ドキュメントの質を高め、ユーザーの読みやすさを向上させたい人。 技術仕様書や設定ガイドを社内で共有する人：文体を統一し、誰が読んでも分かりやすいドキュメントを作りたい人。 複数人で執筆したドキュメントの表現を統一したい：チーム内の文体のゆらぎを修正し、統一感を持たせたい人。 初稿は完成したが、言葉遣いや流れが自然か不安な人：客観的な校正で、プロフェッショナルなドキュメントに仕上げたい人。 日本語Markdownドキュメントの校正スキルは、README・技術ドキュメント・ガイドなどを対象に、①トーン（「ですます調」統一、AIっぽさ回避、不自然な主語の繰り返し削除、感情表現の抑制、押し付けがましい断定の回避、仰々しい表現の排除）②冗長性（冗長な前置き削除、不要な説明削除、簡潔化）③太字（重要用語初出・本質的違い・表対比のみ、ラベルや普通の名詞は除外）④文書構成（不要な感想削除、防衛的表現回避、事実を簡潔に述べる）⑤Linter指摘対応（textlint-jaの指摘をすべて修正、「述語+コロン」パターンのAI直訳表現を避ける、markdownlintの構文問題も修正）をチェック。必須で校正前後に npx textlint "ファイルパス" を実行し、エラー0を目指します。Edit toolで修正を一度にすべて反映させます。

ユーザーの作業指示から要件・設計・タスクの3つのドキュメントを自動生成し、.steering/ ディレクトリに整理して保存できます。 タスクリストに基づいて実装を進め、完了したタスクを逐一ドキュメント記録して進捗を可視化できます。 実装完了後に振り返りドキュメントを作成し、プロジェクトの成果・課題・学習内容を永続記録します。 複雑な機能実装を体系的に計画し、漏れなく完了させたい開発者 プロジェクトの意思決定過程や設計理由を後から参照できる形で残したい人 チーム内での作業進捗を共有可能なドキュメント形式で管理したい人 タスク完了率を追跡し、品質を保ちながら確実に納品したい人 ステアリングファイル（.steering/[YYYYMMDD]-[機能名]/）管理スキル。モード1では永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を読んでプロジェクト方針を理解し、テンプレート（.claude/skills/steering/templates/）を参照しながらrequirements.md・design.md・tasklist.mdを生成。tasklist.mdはrequirements.mdとdesign.mdに基づいて詳細化。モード2（実装・最重要）では tasklist.mdを常時参照し、タスク開始・完了時にEditツールで必ず更新。全タスク完了が絶対原則。スキップ禁止（「時間不足」「複雑」などの理由は禁止）。技術的理由のみスキップ許可（実装方針変更・アーキテクチャ変更・依存関係変更・設計変更）。タスク分割でサブタスク化して対応。

リポジトリ構造を自動反映 — 現在のディレクトリ構成を確認し、docs/repository-structure.md に自動的に反映。手作業での記述を削減できます。 セクション別に構造を整理 — ルート直下、app/、docs/、proto/ などセクション別に構造を記載。必要に応じて再帰的に配下のファイルも記録します。 隠しファイルも含めて管理 — ドット（.）から始まるファイル名やディレクトリ名も含めて構造化。プロジェクト全体を正確に把握できます。 ディレクトリ変更後の同期が簡単 — ディレクトリ構成の変更時に本スキルで更新するだけで、ドキュメントを最新に保つことができます。 プロジェクトの全体構成を把握したい人 — ドキュメント化されたリポジトリ構造で、ディレクトリ間の関係と配置を一目で理解できます。 新しいメンバーのオンボーディングを担当する人 — 構造化されたドキュメントがあれば、プロジェクトの全体像を素早く説明できます。 ディレクトリ構成を変更する開発者 — 実装完了後に本スキルでドキュメントを更新すれば、手作業の記述ミスを防げます。 ドキュメントの最新性を保ちたいプロジェクト — 定期的にスキルを実行することで、ドキュメントとコードのズレを最小化できます。 docs/repository-structure.md を更新対象とし、ディレクトリ構成の変更を反映します。更新手順：①ルート直下のファイル・ディレクトリを ## 全体構造 に反映（再帰的検索なし）、②app/ 配下の全ファイル・ディレクトリを ## appディレクトリ に反映（再帰的検索あり）、③docs/ 直下を ## docsディレクトリ に反映（再帰的検索なし）、④proto/ 直下を ## protoディレクトリ に反映（再帰的検索なし）。注意事項として、ドット（.）から始まるファイル名やディレクトリ名も含める必要があります。

ソースコードから読み取れない設計意図を記録: プロジェクトの背景にある思想やなぜそのような構造になっているのかを、AIの推測とユーザーの実際の認識のギャップとして整理し、自動的に保存できます。 運用ルールと暗黙の約束を文書化: コードに明示されていない慣習、制約、例外的な扱いなどを一元管理し、チーム内の認識を統一できます。 ドキュメント整備の優先箇所を自動検出: ソースコードからは認識しにくい部分を抽出することで、どこからドキュメント化するべきかが一目瞭然になります。 タイムスタンプ付きで体系的に蓄積: 日時とリポジトリ名を自動付与し、~/.claude/knowledge/ 配下に整理された形で記録されるため、後から検索・参照が容易です。 技術リード・アーキテクト: プロジェクトの設計思想やなぜそのような実装になっているのかを、新しいメンバーにも分かるようにドキュメント化したい人 ドキュメント管理担当者: コードとドキュメントのズレを検出し、整備が必要な箇所を効率的に特定したい人 プロジェクト管理者: チーム内に暗黙のルールが多い場合、それを形式知化して属人性を減らしたい人 新規メンバーのオンボーディング担当: プロジェクト独自のルールや背景を、体系的に新入者に伝える資料を準備したい人 ユーザーの求めに応じて対話セッション中に新しく認識したリポジトリの構造やルールをマークダウンで書き出します。書き出し先は ~/.claude/knowledge/${repo_name}/${date time prefix}_$description.md で、date time prefix は date コマンドで現在時刻を取得し、フォーマット +%Y-%m-%d_%H-%M、タイムゾーン Asia/Tokyo に従います。記録対象は、AIがソースコードから推測した内容とユーザーの実際の認識のギャップです。具体的には、プロジェクトの設計思想や意図でソースコードからは読み取れないもの、コード構造の背景にある理由、運用上の制約や慣習、ビジネスロジックの前提条件、暗黙のルールや例外的な扱いが含まれます。これらのギャップはソースコードからの認知が困難な箇所を示しており、ドキュメント整備が必要な箇所の特定に繋がります。

install.sh または install.ps1 を編集した際に、関連ドキュメント（README.md、日本語版）との整合性を自動チェックできます。 コマンドラインオプションの追加・削除・変更が README のオプションテーブルに正しく反映されているか確認できます。 ヘルプテキスト（show_help() / Show-Help）と README の説明が一致しているか検証できます。 英語版 README と日本語版 README.ja が両方とも更新されているか整合性をチェックできます。 just lint で自動的にリント検証を実行し、エラーを検出・修正できます。 インストールスクリプトを頻繁に更新・改善している開発プロジェクトのメンテナー 英語版・日本語版の両方のドキュメントを維持管理している多言語対応プロジェクト スクリプトの変更がドキュメント未更新のまま放置されているプロジェクト CI/CDでドキュメント検証を組み込みたいチーム 対象トリガーファイル：install.sh、install.ps1。チェック対象ドキュメント：README.md（Quick Start、Command Line Options）、docs/README.ja.md（対応セクション）、install.sh内 show_help() 関数、install.ps1内 Show-Help 関数。チェック項目：(1)オプションの追加・削除・変更がREADMEのオプションテーブルに反映、(2)show_help()/Show-Help内のヘルプテキストとREADMEが一致、(3)install.sh と install.ps1 で同名オプション説明が一致、(4)Quick Start使用例が現在のスクリプト動作と一致、(5)前提条件に変更なし、(6)README.md（英語）と docs/README.ja.md（日本語）が両方更新済み、(7)両言語のオプションテーブル構造・内容が一致。手順：git diff で差分確認→ヘルプテキスト読み込み→READMEと比較→日本語版も確認→ドキュメント更新→just lint 実行→エラー修正。

コードの変更ファイルを検査し、「どのドキュメントを更新すべきか」を自動で特定します。マッピングテーブルを照合することで、変更漏れを防ぎます。 Lambda関数・Terraform・フロントエンド・dbtモデルなど、ファイルパスごとの対応ドキュメントを一覧表示し、更新が必要な箇所を明確にします。 各ドキュメントの更新内容を草案として提示するため、ドキュメント担当者や自動更新ツールが具体的に何を修正すればよいか判断できます。 「要更新」「確認が必要」「更新不要」の3段階で分類し、優先度をつけた対応が可能になります。 ユーザーの明示的な確認なしのドキュメント自動修正は行わず、提案段階にとどめるため、手動チェックを経由した安全な更新を実現します。 PR作成後、対応するドキュメント更新が漏れていないか確認したい開発者 コード変更と同期してドキュメントを最新状態に保ちたい技術リード・PM インフラ・API・データモデル等の変更時に、関連ドキュメントの更新漏れを防ぎたいチーム ドキュメント更新の自動化を目指しつつ、人間の最終判断を挟みたい組織 マッピングテーブルはlambda/*/handler.pyのAPI変更がdocs/API_REFERENCE.mdに対応、lambda/*/handler.pyの新規追加がdocs/LAMBDA_DEVELOPMENT.mdに対応するなど8パターンで構成されています。実行手順は「Step 1: 変更ファイルの取得（git diff main...HEAD --name-only）→Step 2: ドキュメント更新候補の特定（マッピングテーブル照合）→Step 3: 更新内容の草案提示」の3ステップです。出力は「要更新」「確認が必要」「更新不要」の3セクションで分類し、各セクションで対象ドキュメント・更新理由・更新箇所を明記します。禁止事項としてユーザー確認なしのドキュメント自動更新とコードファイルの変更は行いません。documentation エージェントが参照する際は自動参照され、user-invocable は false に設定されています。

議事録・手順書・メモなどのテキストファイルから、業務の流れ（登場人物・タスク・判断分岐）を自動抽出できます。 抽出した情報をJSON形式で構造化し、スイムレーン形式のMermaid図として可視化できます。 Miro出力用の高品質JSONを生成でき、デジタルホワイトボードツールに直接エクスポートできます。 8つの品質ポイント（座標計算・最小間隔・差戻し構造・タイムライン等）に完全準拠し、プロフェッショナルな図を保証します。 使用ドキュメント・システム・承認フローなど、業務全体の関連要素も同時に抽出・整理できます。 業務改善・BPR（ビジネスプロセス・リエンジニアリング）を推進する部門スタッフ システム導入時に現状業務フローを可視化・分析する必要がある要件定義者 複数部署間の業務連携を整理・最適化したい経営企画・業務推進部門 ヒアリング結果を図面化して、ステークホルダーと認識を合わせたいプロジェクトマネージャー Phase 1〜4の4段階で処理： Phase 1（分析）: 業務情報からアクター（部署・役職・システム）、タスク流れ、依存関係、分岐点、使用ドキュメント・システム、タイミング情報を抽出。 Phase 2（構造化）: 抽出情報をJSON形式（業務名・目的・アクター配列・プロセス配列・ドキュメント・システム）で整理。各プロセスには、ステップID・タスク名・実行者・内容・使用物・所要時間・次ステップ・条件分岐を含める。 Phase 3（可視化）: Mermaid図をスイムレーン形式で生成。アクターごとにsubgraph、タスク→[]、判断→{}、ドキュメント→[/~/]、システム→[()]で表現。差し戻しは点線で可視化。 Phase 4（Miro出力）: 8つの品質ポイント（①50pxグリッド整列、②カード間350px以上の最小間隔、③差戻し構造の色分け（青/赤）と線種、④左→右のタイムライン、以下省略）に準拠したJSON生成。

Markdownファイル群（セキュリティレポート・技術ドキュメント・マニュアル等）を、単一の自己完結したHTMLファイルに変換できます。 複数リポジトリのドキュメントをタブ型ナビゲーションで統合表示し、横断検索が可能になります。 サイドバーナビゲーション・ダークモード・フィルタリング・ソート・シンタックスハイライト等、Webアプリ級の機能が組み込まれています。 外部依存ゼロで、インターネット接続なしでもオフライン動作するため、機密ドキュメントの配布に最適です。 XSS対策が施されており、セキュリティレポートなど機密情報の掲載にも安全に対応できます。 セキュリティレポートや監査ドキュメント等、複数部門のドキュメントを一つのダッシュボードで管理したい人 MarkdownファイルをHTMLに変換して、チーム全体で簡単に共有・検索できる形にしたい人 GitHubなどにあるドキュメントを、Web UIで参照しやすくしたい開発チーム・プロダクトチーム 複数プロジェクト・複数リポジトリの技術ドキュメントを統合・一元管理したいエンタープライズ環境 単一Pythonスクリプト（scripts/generate_dashboard.py）でMarkdownをHTMLに変換。実行方法：単一リポジトリはpython3 .claude/skills/markdown-dashboard/scripts/generate_dashboard.py > /index.html、複数リポジトリは3つ以上のディレクトリを指定してスクリプト実行。 処理の内部動作：①全ディレクトリから全.mdファイルを読込、リポジトリ情報付与（パスから2階層上のディレクトリ名を自動判別）②各ディレクトリのvulnerabilities.jsonを読込・統合③統計情報を集計（全体+リポジトリ別）④JSON化し`タグ内に埋め込み⑤テンプレートHTMLに埋め込み、テンプレート破損を自動検出・修正⑥完成HTMLを標準出力。出力先は最初のディレクトリにindex.html`を生成。 実装機能：複数リポジトリ統合・タブナビゲーション、統計ダッシュボード（vulnerabilities.json 活用）、脆弱性テーブル（フィルタ・ソート）、階層的サイドバー、ダークモード（LocalStorage保存）、VULN-IDクロスリファレンス自動化、YAMLメタデータテーブル自動生成、CVSSバッジ色分け、Markdownテーブル自動変換、シンタックスハイライト（PHP/JS/Python/SQL/Bash等）、完全XSS対策、外部依存ゼロ、レスポンシブ対応、WCAG AA準拠。

ソースコード・ドキュメント・Web リソースを徹底的に読み込み、調査内容を体系的にまとめる 調査結果を report/.md に自動保存し、基準コミットを記載した正式なレポートを生成する 調査内容の要約をわかりやすく報告し、分析根拠となるコード箇所やドキュメント参照を明記する プロジェクトの全体像を把握したい企画・マネージャー 技術的な課題や仕様を調べる際に、正式な記録に残したい開発チーム 意思決定の根拠となる詳細な調査レポートが必要なリードエンジニア ユーザーから調査・分析を依頼されたときの実施手順。①調査対象に関連するソースコード（関連モジュール全文）、ドキュメント（README.md, CLAUDE.md, TODO, plan.md, backlog/）、Web リソース（必要に応じて Web 検索）を徹底的に読み込む。②調査結果を report/.md に保存し、冒頭に基準コミット（git rev-parse --short HEAD）を記載する。③要約、詳細分析、根拠となるコード箇所・ドキュメント参照を含めてレポート構成する。④調査結果の要約をユーザーに報告する。禁止事項として、部分的なファイル読み取りで全体確認と報告すること、推測や一般論のみでレポート構成、レポート作成なしの口頭のみ報告、基準コミット未記載での作成を禁止。

仕様書・設計ドキュメント・API定義（api.yaml）など複数ファイルを機械的にスキャンし、矛盾や用語ブレを一覧表示できます。 用語の同概念別名・エンドポイントのパス/メソッド違い・ステータス値の食い違い・数値の不一致を整理できます。 各問題の重大度（Blocker / Major / Minor）と該当箇所（ファイルパス＋引用）を明示し、レビューしやすいリスト形式で提供できます。 複数ファイルに及ぶ修正が必要な場合、修正案をバンドルにしてタスク生成に渡せます。 設計整合性をチェックするレビュー担当者 新機能設計後に既存ドキュメントとのズレを確認したい人 要件・API定義・実装の食い違いを統一したい開発者 ドキュメント管理の一貫性を保ちたいチームリード 複数の仕様・設計ドキュメント（requirements/features、system-designs、api.yaml等）間の矛盾検出専用。比較対象を明示し、用語（同概念別名）・エンドポイント（パス・メソッド・ボディ）・状態機械（ステータス値）・非機能（数値）・動画（尺とコマ数）の観点で機械的にスキャン。各問題を重大度（Blocker/Major/Minor）と該当引用（ファイルパス+要約）で列挙。「どちらが正か」推測できない場合は質問として残す。修正が複数ファイルに及ぶ時は task-generator 向けバンドル提案。spec-answer は判定機であり改変機ではなく、直接編集はオーナー合意後。

開発サイクル終了後、GitのコミットログとPRレビューから変更全体の構造的パターンを自動分析できます。 「よかったこと」「伸びしろ」の2観点で分析して、再発しうる教訓のみを抽出できます。 抽出した教訓をAGENTS.md、各CLAUDE.md、development-principles.mdなど適切なドキュメントに自動反映できます。 反映後にRETROSPECTIVE.mdを構造化フォーマットで上書きして、サイクルの知見を記録・保持できます。 メモリファイルの鮮度を検証して、古い情報を削除・更新できます。 開発チーム：サイクルごとの教訓を組織的に蓄積して、次サイクルに活かしたい プロジェクトマネージャー：何度も同じミスが繰り返されるのを防ぎたい リードエンジニア：開発プロセスのボトルネックを可視化して改善したい スタートアップ：チーム全体の暗黙知を形式知に変えたい 開発サイクル終了後、git log・git diffで全体像把握。workspace/plan.mdがあれば計画と実績を比較、PRレビューコメント（gh pr view）も確認。3観点で分析：（1）計画通りに進んだ点・うまくいった判断、（2）手戻り・追加修正の原因・見落とし・改善点、（3）構造的パターン抽出（ワークフロー候補、チェックリスト候補、開発原則候補、スキル更新候補）。抽出した再発しうるパターンのみをAGENTS.md、各CLAUDE.md、開発原則ドキュメントに反映（単発の出来事は含めない）。反映後、RETROSPECTIVE.mdを上書き：「よかったこと」「伸びしろ」「ネクストアクション」の3セクション構成。ネクストアクションはドキュメント改善を除き、実装タスクや手動確認など実行が必要な項目のみ。最後にMEMORY.mdの矛盾を検証し、サイクル知見で有用なメモリは追加・更新、不要なら削除。

コードベースを走査して、README・CLAUDE.md・docstring・コメント等のドキュメントと実際の実装がズレている箇所を自動検出し、カテゴリ別に一覧表示します。 API シグネチャの乖離（関数名や引数の不一致）、依存ライブラリ情報の乖離、実行コマンドの乖離、ファイルパス・ディレクトリ構造の乖離、設定パラメータの乖離、CLAUDE.md 規約と実装の乖離など、6つのカテゴリで体系的に検出します。 検出した乖離をユーザーに提示し、対話しながら ドキュメント側を修正するか、実装側を修正するか確認してから更新します。 「ドキュメントが古くなっているのを知っているけど、何がズレているか全体把握できていない」という状況の人 README や CLAUDE.md と実装の乖離を一気に洗い出し、効率的に修正したい開発チーム Hydra 設定、MLflow experiment、環境変数、依存ライブラリなど複数の層でドキュメントと実装が分散している Python プロジェクトの管理者 3フェーズ: (1) Scan — README.md、CLAUDE.md、docs//*.md、src//*.py の docstring、pyproject.toml、dvc.yaml などを走査し乖離候補を収集。(2) Report — 乖離を A〜F のカテゴリ（API・シグネチャ乖離、依存ライブラリ乖離、コマンド・スクリプト乖離、ファイルパス・ディレクトリ乖離、設定・パラメータ乖離、CLAUDE.md 規約乖離）に分類して一覧表示。(3) Fix — ユーザーの確認を取りながら修正。 検出対象の詳細: 公開 API、関数シグネチャ、クラス定義、docstring のパラメータ記述（:param, Args, Returns, Raises など）、pyproject.toml の dependencies と README の記載の対比、Makefile/justfile のターゲット、相対パスの存在確認、Hydra 設定キー、MLflow experiment 名、環境変数パターン。除外: node_modules, .venv, __pycache__, .git, mlruns, htmlcov。