Skill.md検索

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でレポートをマークダウン形式で出力します。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：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最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

新機能実装時に 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()（ロール別ブロードキャスト）で実装します。

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。分類後、対象ファイルを直接更新します。

プロダクトアイデアから、実装に耐える詳細な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）」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 5 Why 分析やフィッシュボーン図など体系的な RCA（根本原因分析）手法を使い、表面的な原因ではなく本質的な問題を見つけられます メモリリーク、競合状態、パフォーマンス問題など、複雑なバグのパターンに対応できます デバッグループに陥ったときに自動検出し、別のアプローチを提案して効率的に問題を解決できます GitHub Issue から問題の詳細を抽出し、構造的に調査を進めることができます 本番環境で複雑なバグが発生し、原因が特定しづらい状況に困っている開発者 デバッグに何時間もかかってしまい、効率化したい人 チーム内で「このバグ、何が問題なのか」を説明する必要がある人 パフォーマンス問題やメモリリークなど、実装的な根深い問題に対応したい人 Bug Hunter AI は英語でバグ調査・根本原因分析・フィックス生成を支援するエージェントで、日本語での対話で効率的なデバッグを実現します。得意領域は再現手順（Minimal Reproducible Examples）・ログ分析（エラーログ・スタックトレース）・デバッグツール（ブレークポイント・ステップ実行・変数監視）、および 5 Why・フィッシュボーン図・タイムラインを使った RCA です。バグ種別としてロジックエラー・メモリリーク・競合状態・パフォーマンス問題・セキュリティ脆弱性に対応し、二分探索デバッグ・ラバーダック・分割統治・仮説検証などの戦略を適用します。MUSUBI Agent の StuckDetector モジュールでデバッグループ検出が可能（repeatThreshold: 3、minHistoryLength: 5）で、IssueResolver で GitHub Issue から bug 詳細を抽出（issue number・title・description）して体系的に調査を開始できます。

CHANGELOG.mdから対象バージョン範囲の変更情報を自動抽出し、X（Twitter）投稿用の280文字以内の日本語テキストを生成できます。新機能・バグ修正・改善を変更カテゴリ別に絵文字で分類し、ユーザーにメリットが伝わる文面を自動作成します。 バージョン範囲を「v0.2.4～v0.2.9」「v0.2.9（直前から）」「最新リリース」など柔軟に指定でき、複数バージョンのまとめ投稿にも対応します。 生成された投稿文に概算文字数を表示し、そのままコピペでX投稿できる状態に整えます。 プロダクトマネージャー：リリース告知をSNSで迅速に配信したい人 マーケティング担当者：リリース情報をユーザーフレンドリーに加工したい人 開発チームリード：チーム内での連絡とSNS投稿を効率化したい人 3ステップ実行： 1. バージョン範囲特定：引数から開始・終了バージョン判定（2引数→指定範囲、1引数→直前タグから対象、0引数→最新リリース）、git tagで確認 2. CHANGELOG.md抽出：対象バージョン範囲のセクション全読込、変更内容を収集 3. 投稿文生成：フォーマット規則に従い生成 フォーマットルール：280文字以内（URLを除く）、日本語、カジュアルかつプロフェッショナル。構成＝タイトル行（v{version}リリース🎉）→サブタイトル（進化を簡潔に）→変更箇条書き（絵文字付き、ユーザー向けメリット重視、最大6項目）→固定フッター（CommandMate説明・GitHub link・ハッシュタグ）。変更カテゴリ別絵文字：新機能✨、バグ修正🩹、セキュリティ🔒、パフォーマンス⚡、UI/UX🎨等。

ドメイン分析とアーキテクチャ評価の結果をもとに、ターゲットアーキテクチャを段階的に設計します。各マイクロサービスの責務・API・イベント・データモデルを詳細に定義します。 サービス間通信（REST・gRPC・イベント駆動）の方式を判定し、同期・非同期パターンを組み合わせた最適な通信設計を提案します。 移行ロードマップを策定して、段階的な変換手順を明確にします。運用・フィードバック計画も含め、完全な設計ドキュメントを自動生成します。 レガシーモノリシックシステムをマイクロサービス化したいアーキテクト・エンジニア ドメイン駆動設計（DDD）に基づいた境界づけられたコンテキスト設計を体系的に進めたい方 段階的な移行計画とリスク軽減戦略が必要な大規模システム改革に取り組んでいる方 このエージェントは、マイクロサービス設計の7つの基本原則（単一責任・疎結合・高凝集・ビジネス能力軸分割・分散ガバナンス・障害耐性・進化的設計）に基づいて実行されます。各サービスに対してサービスID・責務・API設計（エンドポイント・メソッド）・イベント定義・データモデル・依存関係・非機能要件（可用性・レイテンシ・スループット）を設計します。通信パターンではREST・GraphQL・Event Sourcing・CQRS・Sagaを適切に選定。データ設計ではサービス専用DB所有権と同期パターン（Event-Carried State Transfer・API Composition）を定義します。出力はreports/03_design/にtarget-architecture.md「transformation-plan.md「operations-feedback.mdとして保存されます。

既存システムの分析結果をもとに、ScalarDB Clusterを用いた分散トランザクション対応のデータアーキテクチャ全体を設計します。複数のマイクロサービス間で一貫性のあるトランザクション処理を実現する方式を策定します。 クラスター構成やストレージバックエンド（PostgreSQL、DynamoDB、Cassandraなど）の選定、テーブル設計、パーティションキー・クラスタリングキーの最適化を含むスキーマ設計を提供します。 Sagaパターンなど分散トランザクション戦略、マイクロサービス間のデータ連携方針を立案します。 既存DBからの移行戦略とマイグレーション計画も含めた実装ロードマップを策定します。 マイクロサービスアーキテクチャへの移行を検討しており、分散トランザクションの複雑さに直面しているアーキテクト・エンジニア 複数の異種DBシステムを統一的に管理し、データの一貫性を保ちたいシステム設計者 スケーラビリティとトランザクション保証の両立を実現したい大規模システムの開発チーム HTAP（トランザクション＆分析処理の融合）アーキテクチャの構築を検討している企業 ScalarDB ClusterはgRPCベースの集中型トランザクションコーディネーターで、異種DBs間の分散トランザクションを実現するエンタープライズ向けHTAPプラットフォームです。設計対象は（1）クラスターアーキテクチャ（ノード構成、HA構成、ストレージバックエンド選定）、（2）スキーマ設計（テーブル設計、パーティション・クラスタリングキー、セカンダリインデックス）、（3）トランザクション設計（分散トランザクション戦略、Sagaパターン、コンシステンシーモデル）、（4）マイグレーション計画です。前提条件として、01_analysis配下の分析結果と03_design/target-architecture.mdが存在すること。アーキテクチャは、Application Layer（複数サービス）→ScalarDB Cluster（トランザクションコーディネーター3ノードのHA構成）→Storage Layer（PostgreSQL、DynamoDB、Cassandra等）という3層構成です。

評価駆動開発の実装: 実装前に期待される動作を評価として定義し、開発中に継続的にテストを実行して品質を確保できます。 能力評価とリグレッション評価の自動実行: Claudeが新しくできるようになったことをテストする一方、既存機能が壊れていないことを同時に確認できます。 複数の評価方法を組み合わせ: コード内の決定論的チェック（Grep、ビルド確認）、AIによる自由形式評価、人間のレビューフラグを柔軟に組み合わせられます。 pass@kメトリクスで信頼度を数値化: 「k回の試行で成功」という形式で実装の安定性を定量的に測定できます。 評価レポートを自動生成: 能力評価、リグレッション評価、メトリクスをまとめた詳細レポートで進捗を可視化できます。 Claude Codeを使ってAIに実装させる開発者・プロダクトマネージャー テスト駆動開発（TDD）の考え方を好む人 AI生成コードの品質が不安な人、安定性を重視する人 変更ごとにリグレッション（機能低下）がないか追跡したい人 eval-harness は「評価駆動開発（EDD）」の原則を実装するフレームワークです。能力評価（チェックリスト形式で期待される動作を定義）とリグレッション評価（既存機能の動作確認）の2種類の評価タイプを提供します。評価方法は3種類：(1)コードベース評価者（Grep、テスト実行などの決定論的チェック）、(2)モデルベース評価者（Claudeが自由形式で出力を評価）、(3)人間評価者（手動レビュー）です。メトリクスとしてpass@k（k回試行で1回以上成功）およびpass^k（k回全て成功）を使用。ワークフローは4ステップ：定義（コード前に評価項目を記述）→実装（評価に合格するコードを作成）→評価実行→レポート生成。詳細なレポート形式とテンプレートが用意されています。

身元確認/eKYCの実装に必要な5つの決定項目（実施方法、申込みプロセス、外部サービス、verified_claims、必須スコープ）をヒアリングを通じて整理できます。 決定内容に基づいて、身元確認テンプレート設定用のJSON（テンプレートID、processes、execution、result.verified_claims_mapping_rules）を自動生成できます。 外部eKYCサービス（API連携）の認証方式、リクエスト/レスポンスマッピングを含めた実装設定ガイドが得られます。 認可サーバー拡張設定で身元確認を必須スコープ化し、セキュリティ要件を満たすための設定が簡単に実装できます。 身元確認申込みAPI（/v1/me/identity-verification/applications）と結果API（/v1/me/identity-verification/results）のアクセス権限設定がクリアになります。 本人確認機能をプロダクトに組み込みたいフィンテック・マーケットプレイス開発者 外部eKYCサービス（API連携）を初めて統合する認証実装担当者 セキュリティ要件として身元確認を必須化する設計をしているセキュリティアーキテクト idp-server経由の申込み方式と結果のみ登録方式の使い分けをしたい PM・企画者 身元確認/eKYCユースケースの設定ガイドです。ヒアリング項目は5項目（実施方法：idp-server経由/結果のみ登録、申込みプロセス：ステップ順序、外部eKYCサービス：APIエンドポイント・認証方式、verified_claims：保存情報・trust_framework、必須スコープ）で、各項目は身元確認テンプレートの設定に直結します。 設定対象は身元確認テンプレート設定（API: POST /v1/management/organizations/{org-id}/tenants/{tenant-id}/identity-verification-configurations）で、JSONスキーマでは必須項目（last_name、first_name、birthdate）と任意項目（email_address、address等）を定義します。execution セクションではhttp_requestで外部eKYCサービスのURLを指定し、OAuth 2.0認証（Password Grantフロー）でトークン取得後、body_mapping_rulesでリクエストボディをマッピングし、response_bodyからapplication_idを抽出して保存します。verified_claims_mapping_rulesで確認結果のデータ構造とtrust_framework、必須スコープ設定で認可要件が完成します。

複数ファイルに分割されている仕様書を自動で解析し、重複セクション・矛盾・バージョン差異を検出できます。 検出した重複・矛盾をレポートとして可視化し、ユーザーの確認・判断を得た上で統合を実行します。 バージョン判定基準（ファイル名・コミット日時・バージョン番号）に基づき、古い記述と新しい記述を自動判別し、より詳細・より新しい内容を優先的に採用します。 ID 重複時には内容の詳細度を比較し、既存要件の強化か完全新規追加かを分類。ベースファイルへの追記・上書き・新セクション追加を最適に実行します。 統合完了後、吸収済みファイルの削除やインデックス更新までの後処理を自動化し、仕様書の一元化を完結させます。 大規模プロジェクトで複数チームが作成した仕様書を統合し、単一の要件定義書にまとめたい PM・要件定義者 仕様書が複数ファイルに分散しており、矛盾や重複を手動で整理するのに手間がかかっている方 バージョン管理の複雑さから、どちらの記述が正しいのかが不明確な場合が多い方 統合時に要件情報の欠落を防ぎ、品質を確保した上で安全に統合したい方 このスキルは 4 フェーズのワークフローで仕様書統合を実行します。フェーズ1（精読・分析） ではすべての対象ファイルを Read し、重複検出（同じID・機能の記述重複、非機能要件の複数記載）、矛盾・整合性問題（ID内容不一致、バージョン新旧混在、成功基準不一致）をリスト化。バージョン差異判定は「既存要件の強化」か「完全新規追加」かで分類。フェーズ2（レポート提示・確認） では統合分析レポートをユーザーに提示し、対象ファイル・重複セクション一覧・矛盾内容・推奨統合方針を表示。AskUserQuestion でベースファイル（dest）の確認を取得。フェーズ3（統合実行） では優先順位（重複ID時は詳細・新しいものを採用、セクション重複時は両情報保持、矛盾時はユーザー指定に従う）に基づき Edit で段階的に実施。フェーズ4（後処理） では吸収済みファイルをユーザー確認の上で削除、目次・インデックス更新を実施。情報欠落・ID重複・ユーザー確認省略は厳禁。

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

AIに業務の80%以上を実行させる「業務主体性の逆転」により、人間のボトルネック（調整・ルーチンワーク・中間管理）を排除した組織構造を構築できます。 Midjourneyのように11人のチームで年間300億円規模の売上を実現するなど、従来型企業の約50倍の一人当たり生産性を達成する仕組みを設計できます。 マネジメント・アズ・コード（MaC）により、組織ポリシーや技術標準をコードベースのガバナンスに転換し、人間の介入なしにコンプライアンスとベストプラクティスを自動保証できます。 エンジニアリング中心主義（組織の60%をエンジニアで構成）により、AIシステムの構築・維持・改善能力を最大化する人材配置戦略を立案できます。 戦略的判断の質と創造性に組織のボトルネックを転換することで、スケーリングを人件費や採用難易度に左右されない構造に変革できます。 少人数で大きな成果を上げたいスタートアップの経営者やファウンダー 組織の生産性向上に課題を感じている企業の経営幹部やCEO AIを事業の中核に据えて組織全体を再設計したいテクノロジー企業のリーダー 中間管理機能をコード化して意思決定の質を高めたいエンジニアリング組織の責任者 このスキルは、AIファースト企業が採用する「人間をボトルネックとしない」組織論と仕組み化戦略を詳細に解説しています。 三つの基本原則： 1. 業務主体性の逆転（AI実行率80%の法則） - 従来の人間主体から、業務の80%以上をAIが実行する体制へシフト。Midjourneyはコンテンツ生成100%、カスタマーサポート90%、マーケティング85%をAI実行。 2. エンジニアリング中心主義（60%人材配置ルール） - エンジニア60%以上、プロダクト20%、ビジネス20%の構成。AIシステムの構築・維持・改善能力の最大化を図る。 3. マネジメント・アズ・コード（MaC） - 従来のマネジメント機能をコードベースのガバナンスシステムに代替。Cursorなど経営者不在の組織で実践。組織ポリシーをAIエージェント実行コンテキストに直接適用し、人間介入なしに自動で保証。 生産性指標の破壊的インパクト：Midjourneyの11人チームが年間$200M収益、一人当たり年間$18M達成（従来型スタートアップの約50倍）。このパラダイムシフトは単なるツール導入ではなく、組織設計の根本的革新による結果。従来の「人を増やして売上を伸ばす」モデルから脱却し、戦略的意思決定の質へボトルネックを転換。

NAISTポータルに自動ログインして、成績・履修状況・お知らせをSlackに送信します。 「成績確認して」「お知らせは？」のような音声指示で、面倒なブラウザ操作なしにポータル情報をSlackで確認できます。 SAML（セキュアな認証方式）とTOTP（時間ベースのワンタイムパスワード）による2段階認証に対応しており、セキュアにアクセスします。 成績・単位情報、履修中の科目リスト、ポータルからのお知らせを見やすいフォーマットで自動整形します。 NAIST（奈良先端科学技術大学院大学）の学生で、頻繁に成績確認やお知らせをチェックする人 ブラウザでポータルにログインする手間を省きたい人 Slackを日常的に使用しており、Slack上で情報を一元管理したい人 セキュアな認証が必要な学務システムの自動化に興味がある開発者 このスキルはNode.js環境でPlaywright（ブラウザ自動化）とotplib（TOTP生成）を使用します。認証情報はmacOS Keychainに安全に保存され、初回セットアップ時にsetup-keychain.shで登録します。ポータルアクセス時はSAML認証フローに従い、TOTP認証が必要です。スキル実行時はnode scripts/read-portal.js --mode grades|notices|allコマンドで動作し、成績情報またはお知らせをJSON形式で取得してSlackの決められたフォーマット（表組み形式、新着件数表示）で投稿します。セッションタイムアウトやHTML変更時には自動リトライ機能が働き、エラー時は/tmp/naist-portal-error.pngにスクリーンショットを保存します。

Spring Boot で HTTP/REST API の実装レイヤーを正しいアーキテクチャパターンに従って構築できます。 Controller・Exception Handler・Filter・Spring Security 統合を適切に実装し、ビジネスロジックを HTTP ↔ DTO 変換に留めます。 アクセストークン検証・権限検証を実施し、OperatorPrincipal を SecurityContextHolder に正しくセットできます。 組織レベル API で URL から OrganizationIdentifier を解決し、マルチテナント環境に対応した実装ができます。 グローバル例外ハンドラーで例外を HTTP ステータス・エラーレスポンスに一貫して変換できます。 Spring Boot で OAuth/OIDC サーバーや管理 API を実装する開発者 マルチテナント環境でのセキュリティ・アクセス制御を適切に実装したい人 Bean 定義・Configuration・Filter の使い分けを正しく学びたい初〜中級開発者 Controller に ビジネスロジックが混在するのを防ぎ、関心の分離を徹底したい人 idp-server-springboot-adapter は HTTP/REST API の実装レイヤー。Controller（HTTP リクエスト → EntryService/Control-Plane API 呼び出し）、Configuration（Spring Bean 定義：DataSource・Repository）、Exception Handler（例外 → HTTP エラーレスポンス変換）、Filter（認証・CORS 前処理）を提供。鉄則：Controller にビジネスロジック一切含まず、HTTP ↔ DTO 変換のみ。モジュール構成：adapters/springboot/application/restapi/oauth（OAuth/OIDC エンドポイント）、control_plane/restapi（管理 API）、configuration（Spring Bean 定義）。Controller 命名：管理 API={Domain}ManagementV1Api、OAuth={OAuthV1Api 等}。実装パターン：HttpServletRequest を RequestAttributes に変換（Phase 1）→ control-plane API 呼び出し（Phase 2）→ HttpStatus を含むレスポンス生成（Phase 3）。@AuthenticationPrincipal OperatorPrincipal で認証ユーザー取得。ParameterTransformable implements で HttpServletRequest → RequestAttributes 変換メソッドを実装。

Identity Provider（IDP）サーバーの管理API層（Control Plane）を新規設計・実装し、システムレベルと組織レベルの階層化した管理機能を構築できます。 組織・テナント・クライアント・認証ポリシー・ユーザーなど複数のドメイン管理APIを統一されたパターンで実装できます。 73個のデフォルト管理者権限（DefaultAdminPermission）をidp:resource:action形式で定義し、細粒度のロールベースアクセス制御（RBAC）を実現できます。 全変更操作でDry-runモード（実行前の予行演習）をサポートし、本番リスクを低減した安全な管理操作ができます。 リクエスト/レスポンス変換パターンとHandler・EntryServiceの責務分離により、メンテナンス性の高い管理APIを構築できます。 マイクロサービス基盤でID認証・認可機能を担当するバックエンド開発者 SaaS・マルチテナント型IDPの構築・拡張を行うアーキテクト 管理API層の設計・実装ガイドラインを統一したいプロジェクトリード RBAC（ロールベースアクセス制御）の細粒度設計を必要とするセキュリティエンジニア Control Plane（管理API）はidp-serverの管理API層で、システム全体の設定管理・組織テナント管理・リソース構成を担当。2層構造（System Level・Organization Level）、Dry-runモード、73のデフォルト管理者権限を備える。モジュール構成は idp-server-control-plane（API契約）・idp-server-use-cases（EntryService）・idp-server-core（ドメインロジック）の3層。API設計パターンは ManagementApi→EntryService→Handler の流れで、各層が責務を分担。OrganizationManagementApi・TenantManagementApi・ClientManagementApi・AuthenticationPolicyManagementApi・UserManagementApi など各ドメイン別APIを実装。Handlerで Validator による検証後、Repositoryで永続化。ドキュメント参照：resource-overview.md・overview.md・system-level-api.md・organization-level-api.md。

本番障害を素早く原因特定して修正できる 5分以内に障害内容・原因箇所・修正方針をユーザーに提示し、コード修正に集中できます。 修正範囲を最小限に保てる ホットフィックスモードで「余計なリファクタリング」を排除し、障害の原因箇所のみの修正に限定できるので、予期しない副作用を防げます。 修正後の設計書同期を忘れずに実施できる コード先行を許可しながらも、24時間以内のSpec同期を自動で催促し、設計書とコードの乖離を防げます。 被依存Specへの影響確認ができる 修正対象の要件に依存している他の仕様を逆引きで特定し、回帰テストを漏らさないようサポートします。 再発防止策まで提案できる 根本原因のレビュー後、テスト不足・設計不備・監視不足のいずれが原因かを分析し、次のアクション（テスト追加、仕様見直し、非機能要件の拡充）を提案できます。 本番環境で障害が発生し、「今すぐ直さないといけない」という場面にいる開発者・プロジェクトマネージャー 通常の「設計書ファースト」フローでは間に合わない、緊急度の高いバグ修正に対応したい人 セキュリティ脆弱性など、即座の修正が必要な案件を扱う人 ホットフィックス後も、Spec同期や再発防止を体系的に進めたい人 緊急修正（ホットフィックス）は設計書ファースト原則の例外措置。使用条件：本番環境で障害が発生している、ユーザーが「緊急」「至急」「ホットフィックス」と指示、セキュリティ脆弱性の即時修正が必要。該当しない場合は revise-spec への誘導を提案。フェーズ1障害把握（5分以内）：ユーザーから障害内容を聞く、該当REQ-IDを特定（不明なら REQ-HOTFIX-NNN で仮採番）、2段階探索（code-search-2stage.md）で原因箇所を特定、修正方針をユーザーに提示（障害・原因・修正方針・影響範囲）。フェーズ2コード修正：hotfix/[Spec ID] ブランチ作成（feature/ ではなく hotfix/ を使用）、最小限の修正で障害原因箇所のみに限定、既存テスト全てパス確認、障害再現テストを追加（可能な場合）、コミットメッセージに [HOTFIX] と障害内容記載（Spec同期：未完了（24h以内に実施すること）を明記）。フェーズ3Spec同期（24時間以内）：修正デプロイ後、該当Spec要件定義書を更新、spec-map.yml操作ガイドに従い spec-map.yml を更新、基本設計への影響があれば設計書も更新、docs: [HOTFIX] Spec同期 コミット。フェーズ3b被依存Spec影響確認：spec-map.yml で修正対象REQ-IDに依存しているSpec（被依存先）を逆引きで特定、実装済みSpec のテスト実行で回帰確認（不可能な場合は manual-test-cases.xlsx に「[REQ-YYY] ホットフィックス後の回帰確認」追加）、該当Spec一覧をユーザーに通知。フェーズ4振り返り：障害根本原因をユーザーに報告、再発防止策を提案（テスト不足→gen-testsで補強、設計不備→revise-specで仕様見直し、監視不足→非機能要件追加）、finish-impl.md同様のテンプレートフィードバックチェック。ルール：修正最小限、Spec同期必須24時間以内、仮REQ-ID は後で統合、PR作成は不要（コミットまで）。

Rust依存関係の更新確認：cargo update --dry-runまたはcargo outdatedで、アップデート可能なRustライブラリを一覧表示します。 Node依存関係の更新確認：npm outdatedを実行して、アップデート待ちのNode.jsパッケージを把握できます。 セキュリティ脆弱性の監査：cargo auditとnpm auditで既知の脆弱性を検出し、修正が必要な依存関係を特定します。 必要なツールの自動判定：未インストールツールを自動スキップし、インストール方法を案内するため、環境準備の手間を削減できます。 安全な確認のみ：実際の更新・インストールは行わないため、確認後に安心して判断・実施できます。 Emberプロジェクトの保守担当者：定期的に依存関係の最新化状況をチェックしたい セキュリティ管理者：脆弱性がないか定期監査したい 開発チームリーダー：プロジェクトの技術債を把握・計画したい DevOps/CI/CD管理者：自動化されたセキュリティスキャンを組み込みたい Emberプロジェクトの依存関係を確認するツール。引数で対象を選択可能：rust（cargo update --dry-runで更新可能なRust依存表示、cargo outdatedがインストール済みならそちらを優先）、node（cd apps/desktop && npm outdatedでNode依存表示）、audit（セキュリティ監査：cargo auditとcd apps/desktop && npm auditを実行）、all（引数なしのデフォルト：rust、node、auditを順に実行）。cargo-outdated・cargo-auditが未インストール時はスキップしインストールコマンドを案内。依存の更新・インストールは行わない（確認のみ）。