Skill.md検索

ソースコード変更から対応スキルを自動特定し、どのドキュメントを更新すべきかを提示します スキル内のコード例とソースコードを比較し、差分がないか自動確認します 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）の対応パターンを一覧で管理します。

Conventional Commits形式に自動対応したPRタイトルを生成できるため、リリースノートに反映されやすいPRが作成できます PR本文テンプレートに沿った構造化された説明を自動生成することで、レビューに必要な情報を漏れなく記載できます 破壊的変更（!マーク）や関連URL、プロダクト側対応事項などを体系的に整理できるため、チーム全体の確認漏れを防げます gh CLIのHEREDOC形式に対応したコマンドを提供するため、手作業でのフォーマット確認が不要になります SmartHR UIリポジトリに定期的にコードを貢献する開発者 PR作成時にテンプレート形式を毎回確認するのが手間と感じている人 プロダクト側の対応が必要な変更を忘れずに記載したい人 Conventional Commitsのルールを正確に守りたい人 SmartHR UIリポジトリのPR作成ルールを定義します。PRタイトルはConventional Commits形式（(): ）で日本語記述し、破壊的変更は!で示します。PR本文は「関連URL」「概要」「変更内容」「プロダクト側で対応が必要な事項」「確認方法」の5セクションで構成し、該当なしの場合は「なし」と記載します。変更内容にはBefore/Afterコード例やキャプチャを添付し、破壊的変更の場合は具体的な対応方法を記載します。確認方法ではStorybookやChromatic URLを記載します。実行時はgh pr createコマンドのHEREDOC形式で本文を渡します。

新しくリリースされたFlutterバージョンのBreaking Changes・非推奨APIを自動調査し、プロジェクトへの影響を可視化できます。 コードベース内の非推奨API使用箇所を自動検索し、修正が必要なファイルと行数を特定できます。 mise・GitHub Actions・Shorebird・dependency_overridesなどプロジェクト固有の構成それぞれについて、アップグレード時の対応内容をチェックリスト化できます。 Dart SDK制約やパッケージ互換性を確認し、アップグレード実行時の予期しないエラーを未然に防げます。 リリースノート調査から対応タスク作成まで一貫して進め、アップグレード作業の見落としをなくせます。 モバイルアプリ開発チームの技術リード（Flutter定期更新の計画・実行） Flutterエンジニア（新バージョンリリース時の個別対応確認） DevOps・インフラ担当者（mise・CI/CD・Shorebird等の統合管理） プロジェクトマネージャー（アップグレード作業のスケジューリング・見積もり判断） Flutterアップグレードは3フェーズで進みます。フェーズ1（情報収集）: リリースノート（GitHub Issues、docs.flutter.dev、Breaking Changes、Blogから調査）とプロジェクト現状確認（flutter --version、.mise.toml、pubspec.yaml環境）。hotfixの場合はメジャーリリースの Breaking Changes も併せて調査。フェーズ2（影響分析）: Breaking Changes について Grep でコードベース内の使用箇所を検索。mise・GitHub Actions・Shorebird・dependency_overrides・パッケージ互換性（flutter pub outdated）・Dart SDK制約を個別確認。フェーズ3（対応タスクリスト作成）: 必須タスク（.mise.toml更新、mise install、各ワークフロー確認等）と修正対応（Breaking Changes修正、Shorebird doctor確認等）を整理。各フェーズで WebSearch/WebFetch でアップグレード最新情報を参照します。

バージョン番号とビルド番号を自動更新：現在のバージョンを確認し、リリース内容に応じてバージョンを bump（例：1.19.0 → 1.20.0）して pubspec.yaml に反映できます。 更新内容を CHANGELOG に自動反映：前回リリース以降のコミットを自動解析し、Added / Changed / Fixed に分類して CHANGELOG を更新できます。 iOS・Android・macOS の任意の組み合わせで同時リリース：プラットフォームを選択するだけで、複数の OS 向けアプリを同時にビルド・署名・配布できます。 GitHub Actions による自動ビルド・署名・配布：タグ push 後、CI/CD パイプラインが自動実行され、TestFlight・Google Play への配布と GitHub Release 作成までが完全自動化されます。 リリース前の自動検証：静的解析とユニットテストをローカルで実行し、問題がある場合はリリースを防止できます。 Flutter アプリの開発・運用チーム：バージョン管理と配布プロセスを統一・自動化したい組織 複数プラットフォーム対応アプリの担当者：iOS と Android を同時リリースする際の手作業を削減したい リリース頻度が高いプロジェクト：毎週・毎日リリースする際の人的ミスを防ぎたい CI/CD パイプラインを構築したい組織：手動ビルド・配布から自動化へ移行したい Flutter アプリのリリースワークフロー全体を自動化します。前提として main ブランチで作業中で未コミット変更がないことが必要です。主な流れは：(1)現在のバージョン確認と差分コミット収集（grep で pubspec.yaml から version を取得、git log で前回タグ以降の差分を確認）→ (2)バージョンとプラットフォームをユーザーに確認（feat/fix コミット有無により minor/patch を推奨、build number は +1）→ (3)CHANGELOG.md を Added/Changed/Fixed で分類更新 → (4)pubspec.yaml の version 更新 → (5)dart analyze と flutter test による検証（失敗時は進まない）→ (6)git add/commit/push と複数プラットフォーム向けタグ打ち（ios/vX.Y.Z+N、android/vX.Y.Z+N、macos/vX.Y.Z+N）→ (7)GH Actions 自動実行（ios-release.yml で TestFlight・GitHub Release、android-release.yml で Google Play）。バージョン形式は X.Y.Z+N（N はビルド番号）です。

コマンドラインから Bridge Server（@ccpocket/bridge）のバージョン bump・CHANGELOG 更新・タグ push を一元管理でき、その後 GitHub Actions が自動で npm publish と GitHub Release を作成します。 前回のリリースタグからの差分コミットを自動解析し、semantic versioning（major / minor / patch）の推奨版を提示してくれるため、バージョン決定の判断が簡単になります。 CHANGELOG を自動で構造化（Added / Changed / Fixed セクション）し、リリースノートの品質を保ちながら手作業を最小化できます。 ローカルで テスト・型チェック・ビルド を実行して検証してから push するため、リリース後の問題を事前に防げます。 Flutter アプリ側の expectedBridgeVersion を同時に更新できるため、Bridge と アプリのバージョンズレによるバナー表示ミスを防げます。 Bridge Server の保守・リリース担当者またはメンテナー バージョン管理・CHANGELOG 更新・リリース自動化を統一したいプロジェクトチーム npm パッケージの semantic versioning を厳密に運用したい組織 GitHub Actions を使った CI/CD パイプラインを構築・運用する開発者 前提: main ブランチで作業中、未コミット変更がないこと。 手順: 1. バージョン確認・差分収集: package.json の現在バージョンを確認し、前回タグからの差分コミット一覧を取得（git log + 条件指定）。 2. バージョン決定: 差分コミットを分析（feat = minor 推奨、fix のみ = patch、破壊的変更 = major）し、AskUserQuestion でユーザーに具体的なバージョン番号を提示・確認。 3. CHANGELOG 更新: packages/bridge/CHANGELOG.md の先頭に新セクション（Added / Changed / Fixed）を追加。 4. バージョン bump: packages/bridge/package.json を更新。 4.5. Flutter 同期: apps/mobile/lib/constants/app_constants.dart の expectedBridgeVersion を同じバージョンに更新（アプリの古いバージョン検出ロジック対応）。 5. ローカル検証: npm run test:bridge / npx tsc --noEmit / npm run bridge:build をすべて実行し pass を確認（失敗時はユーザーに報告・修正待ち）。 6. コミット・タグ: git add → git commit → git push origin main → git tag bridge/vX.Y.Z → git push origin bridge/vX.Y.Z。 7. 完了確認: GitHub Actions (bridge-release.yml) の自動実行を確認。テスト・ビルド・npm publish・GitHub Release 作成が完了したら終了。

iOS / Android のストアスクリーンショットを自動撮影・合成し、最新のUI状態をアップロード用に準備できます。 最新の CHANGELOG を分析して、App Store・Google Play 向けのリリースノートや説明文を自動生成・更新できます。 UI変更があったかどうかを判定し、更新対象（スクリーンショット、リリースノート、説明文等）をユーザーに提案できます。 Simulator × モック画面 × Marionette MCP を組み合わせることで、手作業のスクショ撮影・編集をほぼ自動化できます。 iOS・Android アプリのリリース時にストアメタデータを何度も手で更新しているエンジニア ストアスクリーンショットの撮影・編集に毎回時間をかけているプロダクトマネージャー CHANGELOG 更新後、App Store・Google Play・fastlane メタデータを同期更新したい開発チーム モバイルアプリの多言語対応（英語、日本語など）で、各言語のメタデータ更新に手間がかかっている人 ワークフロー三段階: Step 1 - バージョン確認・変更分析（git tag、pubspec.yaml、CHANGELOG確認）。Step 2 - 更新対象選択（8スクリーンショットシナリオ + 9メタデータテキストファイル）。Step 3 - メタデータテキスト更新（CHANGELOG ベースに release_notes・description・promotional_text を自動生成）。 スクリーンショット 8 シナリオ: Session List（ライト）、Approval List、Multi-Question Approval、Markdown Input、Image Attach、Git Diff、New Session、Session List（ダークモード）。各シナリオ用に ccpocket.navigateToStoreScenario カスタムエクステンション実行後、Simulator からスクショ撮影。 メタデータファイル: fastlane/metadata/en-US/release_notes.txt（iOS EN）、ja/release_notes.txt（iOS JA）、en-US/description.txt（App Store EN）、ja/description.txt（App Store JA）、promotional_text.txt、android/en-US/full_description.txt（Play Store EN）、ja-JP/full_description.txt（Play Store JA）、android/en-US/changelogs/default.txt（Play Store リリースノート EN）、ja-JP/changelogs/default.txt（Play Store リリースノート JA）。ファイルパスは apps/mobile/ からの相対パス。

Issue番号またはPR番号を指定するだけで、対応に必要な情報をまとめたレポートが自動生成されます。 バグ報告、機能要望、プロンプト要望など、Issue の種別を自動判定し、対応すべき内容を明確にします。 コードベースを調査して、その要望を実現するために変更が必要なファイルや影響範囲を自動で洗い出します。 実装の難易度を Low / Medium / High / Very High で判定し、工数目安を提示するため、優先度判断がしやすくなります。 既存機能との重複がないか、プロトコル変更が必要か、セキュリティ上の懸念はないかなど、多角的に対応判断を支援します。 GitHub上の Issue / PR が大量に溜まっており、どれから対応すべきかを判断したい プロジェクトマネージャーやチームリード バグ報告や機能要望の優先度を決める際に、実装難易度を知りたい開発者 新しい外部PRの内容をサッと把握して、マージ判定する必要がある レビュアー 実装前に関連コードや影響範囲を把握したい エンジニア GitHub Issue / PR 番号を入力するとトリアージレポートが自動生成されます。手順は4フェーズで実行されます。Phase 1ではghコマンドで Issue またはPRの詳細情報、コメント、レビューを取得し、テンプレートやラベルから種別（Bug / Feature / Prompt Request / Dependabot / 外部PR）を判定します。プラットフォームサポート状況も評価し、実機検証が必要な環境（Windows Bridge Server、macOS Flutter等）は experimental / best-effort として区別します。Phase 2では関連コード、既存機能との重複、影響範囲、プロトコル変更の必要性をExploreサブエージェントで並列調査します。PRの場合は変更ファイル一覧、diff、規約準拠、テスト追加の有無、セキュリティ懸念をチェックします。Phase 3では調査結果をもとに難易度を判定（工数目安：Low ~1時間、Medium 数時間、High 1日以上、Very High 数日以上）し、具体的なファイルパスと変更箇所を根拠として示します。Phase 4でレポートをマークダウン形式で出力します。

大きなコード変更を、別の独立したAIコンテキストから客観的にレビューして問題がないか確認できます 変更規模に応じて自動判定（小規模なら自己レビュー、大規模ならサブエージェント活用）して効率的にレビューします 重大な問題・軽微な問題・問題なしを判定して、修正が必要か完了可能かを明確にします 問題が見つかった場合は自動で修正→再レビューループを回し、LGTM判定になるまで繰り返します コミット前に変更内容を客観的に確認したい開発者 コードレビュー品質を高めたいチームリード 重大な不具合をコミット前に防ぎたいプロジェクト このスキルは、タスク完了前に実行するセルフレビュー手順です。トリガーは /self-review コマンドまたは大きな変更をコミットする前です。4つのフェーズで構成されています。Phase 1 で変更差分を収集（git diff で変更ファイルと内容を取得）、Phase 2 でサブエージェント（code-reviewer）によるレビューを実行（ただし変更規模が30行以下の場合はサブエージェント不要）、Phase 3 で判定（LGTM=PASS、軽微な問題=MINOR、重大な問題=FAIL）、Phase 4 で FAIL の場合は修正→Phase 1-3 再実行を繰り返します。変更規模別に調整可能で、30行以下は自己レビューのみ、31-100行は code-reviewer サブエージェント、100行以上は詳細分析を加えます。

Bridge Server（TypeScript）のユニットテスト実行、TypeScript型チェック、カバレッジ測定を順番に実行し、全てのテストがパスすることを自動確認できます。 テストファイルのみを指定したり、ウォッチモード（開発中は自動再実行）で効率的にテストを回すことができます。テストファイルと型チェック対象の関係を正確に管理します。 vitest規約に基づいたテスト記述方法（ファイル配置・命名・import・テスト構造）の標準を適用し、チーム全体で一貫性のあるテストコードを保証します。 parser.ts、claude-process.ts、image-store.tsなど、現在テスト対象のモジュールを管理し、新しく純粋関数が追加される際のテスト追加ガイダンスを提供します。 外部依存（プロセスspawn・ファイルシステム・WebSocket）を除いた、ROIの高い純粋ロジックのテストに集中できます。 Bridge Server開発でコード品質を保ちながら継続的にテストを実行したい開発チーム TypeScriptの型チェックとテスト自動化で本番バグを事前に防ぎたい品質管理者 テスト記述規約を統一して、チーム内の開発効率と保守性を向上させたい技術リード 新機能追加時に既存機能の回帰テストを確保したいCI/CD環境構築者 Bridge Server（TypeScript）のテスト実行・型チェック・テスト記述ガイド。実行手順①ユニットテスト（npm run test:bridge、特定ファイル指定可、ウォッチモード対応）②TypeScript型チェック（npx tsc --noEmit、テストファイルと vitest.config.ts は tsconfig.json の exclude に含まれ型チェック対象外）③カバレッジ測定（任意）。テスト記述規約：ファイルはソースと同ディレクトリに .test.ts 配置、vitest のみ import（jest互換は不可）、テスト対象モジュールは .js 拡張子で import（NodeNext moduleResolution）、describe でグルーピング・it は英語三人称現在形・1つの it は1振る舞い検証。テスト対象は純粋関数・ロジック中心（高ROI）。現在テスト対象モジュール：parseClaudeEvent、claudeEventToServerMessage、parseClientMessage（parser.ts）、parseRule、matchesSessionRule、buildSessionRule、toolNeedsApproval（claude-process.ts）、ImageStore.extractImagePaths（image-store.ts）。新テスト追加時は純粋関数があれば追加検討、internal関数テストは export に変更OK。

リリース前の検証（CI状態確認）から、Release workflowの実行、完了待機、新規releaseの検出まで一連のリリース運用を再現可能な手順で実行。 リリースノートから関連Issue・PRを自動抽出し、Issue返信文とSNS投稿案（Bluesky）を自動生成。手作業での返信文作成が不要。 --dry-runオプションで事前検証。本実行前に動作確認してからリリースを進められるので安全。 Codex LLMと同梱スクリプトの役割分離。確定的な検証・実行はスクリプト、非確定的な文章生成はLLMが担当する堅牢な設計。 obsidian-another-quick-switcherのメンテナー。毎回のリリース作業を効率化・標準化したい。 オープンソースプロジェクトの管理者。リリースフローの属人性を減らし、再現可能な手順を確立したい。 チーム開発で複数人がリリース対応する環境。誰でも同じ品質でリリース運用できる仕組みが欲しい。 GitHub Actionsと連携したリリース自動化を実装している人。リリースノート生成やIssue通知まで含めた完全自動化を目指す。 実行前提：bun、gh、gh auth statusが利用可能。Codex CLI実行時はghコマンドを最初からエスカレート実行（sandbox・host間の認証コンテキスト差異対応）。基本フロー：リポジトリルートでbun .agents/skills/another-quick-switcher-release/scripts/release.ts実行→スクリプト出力のJSON（RELEASE_RESULT_JSON）を読み取り→assets/templatesのテンプレート使用して標準出力（Bluesky投稿案・Issue返信テンプレート）。Script Options：--branch （対象ブランチ指定、既定master）、--dry-run（dispatch/git pull非実行）、--skip-issue-notify（Issue候補表示スキップ）。Output Contract：スクリプトはJSON出力でrelease・issueCandidatesフィールドを含む。Issue返信はPR除外（isPullRequest=false対象）、author重複除去、tagName・URL置換。Bluesky投稿は利用者視点の日本語要約・URL直記載で標準出力。失敗時は references/release-workflow.md のtroubleshooting参照。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：AWS Well-Architected フレームワークの6つの視点（信頼性、セキュリティ、コスト最適化、運用上の優秀性、パフォーマンス効率、持続可能性）から包括的に分析し、改善案をレポート化します。 AWSベストプラクティスとの整合性を自動検証：最新のAWSドキュメントやサービス仕様と照合し、推測ではなく公式情報に基づいた指摘を提供します。 平易な説明とエンジニア向け詳細の両立：技術レベルに依存しない図解と、実装根拠となる詳細なドキュメントリンクを同時に提示します。 リージョン可用性やサービス最新機能を自動確認：新機能やリージョン対応状況を都度確認し、古い情報に基づく指摘を排除します。 非機能要件IPA分類とW-Aの柱の対応を自動マッピング：設計の品質要件を構造化し、どの柱でカバーされているか明確にします。 クラウドアーキテクト・ソリューションアーキテクト：新規プロジェクトの設計レビュー、既存システム改善の根拠提示に 開発チームリード・PMO：AWSベストプラクティス準拠をスケーラブルに検証したい セキュリティ・コンプライアンス担当：セキュリティ要件、コスト削減余地、リスク評価を構造化したい クラウド移行プロジェクト推進者：移行後の設計が大規模採用に耐えられるか定量的に判定したい AWS Well-Architected フレームワークの6本の柱に基づいてレビューを実施。対象は本リポジトリの設計テンプレート（design/doc_source/）、ヒアリングシート（survey/doc_source/）、ワークショップ資料（workshop/doc_source/）。ワークフローは①入力理解（ファイルパスまたはトピック名から対象を特定）、②ドキュメント読み込み（Glob・Read・Grep ツール活用）、③AWS最新ベストプラクティス確認（aws-knowledge MCPで Well-Architected・サービス固有・最新アップデート・リージョン可用性を検索）、④6本の柱による分析（非機能要件カテゴリ定義を参照して対応関係を確認）。出力は日本語で統一、AWS サービス名は英語表記のまま。AWS ドキュメントリンクは英語版URLを使用。

非機能要件ヒアリングシート（8ファイル）に記載されたAWSサービスの仕様が最新版と一致しているか自動チェックできます。 SLA・クォータなどの数値、サービス機能、ベストプラクティスが現在の公式情報と乖離していないかを検証できます。 旧サービス名のままで記載されている、サービス提供が終了している、新機能が言及されていないなどの課題を特定できます。 チェック範囲を全体・特定ファイル・カテゴリごとに指定でき、効率的に更新対象を絞り込めます。 AWS最新情報との照合結果をレポートにまとめ、ドキュメント更新の優先度判断ができます。 AWSソリューションアーキテクトやクラウド設計者 定期的にAWSドキュメント・ベストプラクティスを最新に保ちたい企業 長期運用しているAWSプロジェクトの非機能要件定義を刷新したい PM・要件定義者 信頼性・セキュリティ・コスト最適化など特定カテゴリの陳腐化を重点的にチェックしたいアーキテクト 非機能要件ヒアリングシート（reliability・security・cost-optimization等8ファイル）に記載されたAWSサービス情報を最新の公式仕様と照合します。検索範囲は $ARGUMENTS で指定可能（引数なし=全体、ファイル名指定、カテゴリ指定）。 ワークフローは4段階です。Step 1: nfr-taxonomy.mdとチェック対象ファイルを読み込み、Step 2: 各ファイルからAWSサービス名・SLA数値・機能記述・ベストプラクティスを抽出、Step 3: aws-knowledge MCPサーバーで照合（SLA正確性、サービス機能最新性、リブランド有無、新サービス欠落、非推奨サービス記載の5観点）、Step 4: 照合結果を日本語レポートで出力。AWS最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

対話履歴を自動解析：Claude Code、GitHub Copilot Chat、Cursor、Clineなど複数のAIエージェントツールのログを自動検出し、過去の会話データを一元収集できます。 技術理解度を推定：プロンプトの質や複雑さから、自分がAIにどの程度の指示を出せているか、技術的な深さはどのレベルかを診断します。 AI依存度をスコア化：日々のコーディング作業でAIをどの程度頼っているか、自分でやっている部分とAI任せの部分のバランスを数値で見える化します。 レポートを自動生成：分析結果を日本語のMarkdownレポートとして自動出力し、期間や特定プロジェクト単位での比較も可能です。 複数のAIツールを使い分けている開発者：どのツールをどの場面で活用しているか、全体像を把握したい人 AI時代のスキルを自己評価したい人：AIと協働する中で、自分の技術力がどう変化しているか知りたい人 チームのAI活用状況を把握したい管理職：メンバーのAI依存度やスキル傾向を客観的に分析したい人 学習の効果を数値で見たい人：Linter指摘のような客観的な指標で、自分の成長を可視化したい人 このスキルは、ユーザーが「プロンプトをレビューして」「対話履歴を分析して」「理解度を診断して」と依頼したときや /prompt-review コマンドで呼び出されたときに動作します。前処理スクリプト scripts/collect.py を実行してClaude Code、GitHub Copilot Chat、Cursor、Cline、Roo Code、Windsurf、Antigravity、Gemini CLI、OpenAI Codex、OpenCodeのログを自動検出し、フィルタ済みのJSONを取得します。引数処理は柔軟で、数値のみで日数フィルタ（例：30日分）、文字列のみでプロジェクト名フィルタ、両者の組み合わせに対応。タイムスタンプ付きファイル名を生成し、スクリプト出力を保存・参照することで、複数の対話ソースからデータを統合。結果は日本語Markdownレポート（reports/prompt-review-YYYY-MM-DD.md）として出力されます。

新機能実装時に NotificationService を呼び出すだけで、ベルアイコン・ドロップダウン・トースト通知が自動表示されます セキュリティ・システム・アクション・情報・警告など、事前定義された6種類の通知タイプから選ぶだけで実装できます 特定ユーザーへの個別通知と、管理者などの特定ロール全体へのブロードキャスト通知（ブロードキャスト通知）が両方対応できます 通知はPostgreSQLに自動永続化され、未読数・既読・削除などの管理が APIエンドポイント経由で自動処理されます 日本語・英語対応で、多言語対応アプリでもそのまま使用できます 新機能実装時に通知周りの複雑な実装を避けたい開発者 ユーザーへのイベント通知を統一的に管理したいプロダクトマネージャー セキュリティアラート・アクション要求など、重要な通知を確実に配信したいシステム担当者 通知センターのUIを共通化して、アプリケーション全体の一貫性を保ちたいデザイナー NotificationServiceは、アプリケーション内での重要なイベントをユーザに通知する統一システムです。通知センター（ヘッダーのベルアイコン）、トースト通知（Sonnerでリアルタイム表示）、DB永続化（PostgreSQL×Prisma）で構成されています。6つの通知タイプ（SYSTEM・SECURITY・ACTION・INFO・WARNING・ERROR）と4段階の優先度（URGENT・HIGH・NORMAL・LOW）があります。ファイル構成は lib/services/notification-service.ts（通知発行）、lib/stores/notification-store.ts（Zustandストア）、lib/i18n/notifications.ts（翻訳）、app/api/notifications/route.ts・[id]/route.ts・read-all/route.ts・unread-count/route.ts（APIエンドポイント）、components/notifications/NotificationBell.tsx他（UIコンポーネント）です。API呼び出しは NotificationService.securityNotify()・systemNotify()・actionNotify()（個別通知）、NotificationService.broadcast()（ロール別ブロードキャスト）で実装します。

自然言語で知識グラフを検索: 「トヨタの前回レポートは？」のような日本語の質問をそのまま入力すると、Neo4j に蓄積された過去データから該当する情報を自動で探します。 複数の過去情報源を横断検索: 過去のレポート、スクリーニング結果、取引記録、リサーチ、市況データなど、複数の情報源からまとめて検索できます。 保有銘柄の自動標記: 検索結果に現在の保有銘柄が含まれていれば「保有中」マークを自動付記し、ポートフォリオ管理の効率化を図ります。 最新データとの比較を提案: 過去レポートの検索結果が返ったら、「最新データとの差分を確認するなら /stock-report 推奨」と自動的にアドバイスを提供します。 Markdown形式で結果を表示: 検索結果をわかりやすいMarkdown形式で表示。データがない場合はその旨を明確に表示します。 投資分析担当者: 過去のリサーチレポートや取引記録をすばやく引き出したい人 ポートフォリオマネージャー: 銘柄の過去レポートと現在のポジションを関連付けて確認したい人 市場分析者: 過去の市況データやスクリーニング結果を参考に、最新分析の背景を確認したい人 経営判断支援: 過去のリサーチ結果を素早く参照し、意思決定の根拠を確認したい人 実行方法: python3 .claude/skills/graph-query/scripts/run_query.py "自然言語クエリ" でNeo4jに接続し、自然言語を解釈してグラフクエリに変換・実行します。自然言語→スキル判定は .claude/rules/intent-routing.md に従います。 結果表示と統合ルール: 結果はMarkdown形式で表示され、データが見つからない場合はその旨を表示。Neo4jが未接続の場合は「データが見つかりませんでした」と表示します。前提知識統合ルール(KIK-466)に基づき、クエリ結果に保有銘柄が含まれれば「保有中」マークを付記、過去レポート検索結果には「最新データとの差分を確認するなら /stock-report 推奨」と自動促示します。

PRD（企画書）と機能設計をもとに、システムの技術構成を決定し、図面として記録できます。 採用するプログラミング言語、データベース、API通信方式などの技術選定を、一覧表・図解・テキストで明確に文書化できます。 既存の設計書がある場合は優先し、ない場合は提供テンプレートを使って新規作成できます。 後続の実装チームが「どんな技術を使うのか」「どの部品がどう連携するのか」を一目で理解できる設計書を作成できます。 作成した設計書は docs/architecture.md に自動保存され、プロジェクト全体で参照可能になります。 システム構築の前に「技術全体像」を整理したいプロジェクトマネージャー・PO 開発チーム全体の共通理解を作りたいテックリード・アーキテクト 既存プロジェクトの技術選定を見直す必要がある開発責任者 複数チームで並行開発するときに技術的な一貫性を保ちたい組織 このスキルは、PRD（docs/product-requirements.md）と機能設計書（docs/functional-design.md）の前提条件を確認した上で、アーキテクチャ設計書を作成します。既存設計書（docs/architecture.md）がある場合はそれを優先し、ない場合は提供されたテンプレート（./template.md）とガイド（./guide.md）に従い新規作成します。アーキテクチャ設計は、PRDの要件と機能設計を技術的に実現するためのシステム構造とテクノロジースタック（使用言語・フレームワーク・DB・ミドルウェアなど）を定義します。出力先は docs/architecture.md です。

PR レビューのコメントやセッション中の発見を自動分析し、プロジェクト設定ファイル（CLAUDE.md・スキル・エージェント設定）に学習結果を即座に反映できます。 CodeRabbit や人間レビュアーからの指摘をルール化し、同じ品質問題の再発を未然に防げます。 セッション終了時に会話全体から学習ポイントを自動抽出し、次回からの作業効率が向上します。 複数 PR の共通パターンを検出でき、プロジェクト全体の設計方針をアップデートできます。 繰り返す品質指摘に疲れているレビュアー チーム開発でルール定義が曖昧なプロジェクト セッション終了後の成果物を自動的に記録・更新したいエンジニア データ駆動でプロジェクト方針を改善したい技術リーダー Retro は PR レビューのフィードバックやセッション中に得た知見を分析し、CLAUDE.md・skills・agents・memory に学びを自動反映する振り返りスキルです。実行パターンは3つ：PR番号指定で該当PR分析、recentで直近マージ済みPR分析、sessionで今セッションの発見を処理。各コメントから「事象（何が問題か）」「原因（なぜか）」「対処（解決策）」「ルール化候補」を抽出します。CodeRabbit フィルタリング（⚠️ Critical/Major → 分析、🟡 Minor → 判断、nitpick → スキップ）を適用。学びは判定ツリーで分類：普遍ルール → CLAUDE.md、ワークフロー改善 → skill/command、エージェント指針 → agents、運用知識 → MEMORY.md。分類後、対象ファイルを直接更新します。

プロジェクト固有の用語と技術用語を体系的に定義・管理できます。 要件定義書、設計書、アーキテクチャなど複数ドキュメントから用語を統一的に抽出できます。 既存の用語集がある場合、その構造を保ちながら追加・更新できます。 全チームで用語の意味を共通認識化し、ドキュメント作成時の表記ゆれを防げます。 プロジェクトマネージャーで、チーム内の用語定義を統一したい人 ドキュメント作成者で、用語の一貫性を保ちたい人 新しいプロジェクトを立ち上げるときに用語体系を整備したい人 用語集を作成するための詳細ガイドです。前提条件として、①docs/product-requirements.md（PRD）②docs/functional-design.md（機能設計書）③docs/architecture.md（アーキテクチャ設計書）④docs/repository-structure.md（リポジトリ構造）⑤docs/development-guidelines.md（開発ガイドライン）を確認します。既存ドキュメント優先順位は①既存docs/glossary.md（最優先、プロジェクト固有定義）→②このスキルのガイド（参考資料）です。新規作成時はテンプレート使用、更新時は既存構造・内容を維持します。出力先はdocs/glossary.md、詳細ガイドは./guide.md、テンプレートは./template.mdを参照します。

PRDの要件を技術実装の詳細設計に落とし込み、機能設計書を素早く作成できます。 既存の設計書がある場合は自動的にそれを参考にし、構造を保ちながら更新・補足できます。 テンプレートとガイドが用意されているため、何から書き始めるか迷わずに執筆を開始できます。 設計書を docs/functional-design.md に一元管理し、チーム全体で設計内容を共有できます。 プロダクト企画者が決めた要件を、開発者向けに技術的な実装方法として落とし込みたい人 チームメンバーに「この機能はどう実装する予定？」を分かりやすく説明したい人 新しいプロジェクトやフェーズの開始時に、設計ドキュメントの骨組みをすぐに整えたい人 既存の設計書を保ちつつ、内容を段階的に充実させたい人 機能設計書作成の前提として、docs/product-requirements.md のPRDが存在する必要があります。設計書の優先順位として、既存の docs/functional-design.md がある場合はそれを最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート（./template.md）と詳細ガイド（./guide.md）を参照してください。作成した機能設計書は docs/functional-design.md に保存され、既存設計書がある場合は構造と内容を維持しながら更新します。

プロダクトアイデアから、実装に耐える詳細なPRD（プロダクト要求定義書）を対話的に作成できます。 ターゲットユーザー、課題、機能要件、非機能要件、成功指標をテンプレートに沿って体系的に整理します。 曖昧な要件を具体的・測定可能な形に落とし込み、「これは実装可能か」をAIが検証します。 機能を優先度（P0必須/P1重要/P2検討）で分類し、MVP範囲を明確にします。 既存PRDがある場合は構造を維持しながら更新、新規作成時はテンプレートガイドを参照できます。 起業家・プロダクトマネージャーで、アイデアを実装可能な形に落とし込みたい方 デザイナーや開発チームのリーダーで、要件の曖昧さを事前に潰したい方 投資家向けプレゼン資料としても使える、説得力のあるドキュメントを作成したい方 プロダクト開発の初期段階で、「作る前に仕様を決め切る」プロセスを回したい方 PRD作成の前提条件として、docs/ideas/initial-requirements.md に初期要求（アイデア、課題、ターゲット、主要機能、MVP範囲）を保存する必要があります。既存の docs/product-requirements.md がある場合は最優先し、このスキルのテンプレートは参考資料として使用します。作成プロセスは①initial-requirements.md 確認、②テンプレートに従ってドラフト生成、③5つの観点（ビジョン明確性、ユーザー具体性、成功指標測定可能性、機能詳細化レベル、非機能要件網羅性）でレビュー、④指摘を改善・再レビュー、です。重要な方針として「具体性と測定可能性」「ユーザー中心設計」「優先順位の明確化（P0/P1/P2）」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。