設計・企画・要件定義

非機能要件ヒアリングシート（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最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

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

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

ユーザーからの新機能や変更指示を受け取ると、それに基づいた作業計画書（requirements.md、design.md、tasklist.md）を自動生成できます。 tasklist.md に記載されたタスクを 1 つずつ進捗管理し、完了時にリアルタイムで checklist を更新できます。 プロジェクトの永続ドキュメント（product-requirements.md、functional-design.md、architecture.md など）と整合させながら、一貫性のある設計・実装を進められます。 実装完了後に振り返りドキュメントを自動生成し、次のタスクへの知見を記録できます。 作業指示を受けるたびに「何をやるのか」「どの順序でやるのか」を明確に整理したい PM・チームリード 複数の並行タスクがあり、進捗を可視化・一元管理したい開発チーム 実装完了時に「何をやったか」「なぜそう決めたか」を記録し、チームの知識を蓄積したい人 プロジェクトの永続的な設計方針と日々のタスク実行を同じドキュメント体系で管理したい人 Steering スキルは、.steering/[YYYYMMDD]-[機能名]/ の形式でディレクトリを作成し、requirements.md、design.md、tasklist.md の 3 つのテンプレートに基づいたファイルを生成します。実装時には tasklist.md を常に開いた状態で進め、タスク開始時に [ ] → [x] に更新し、完了時に EditToolで記録することが必須です。重要な原則として、tasklist.md の全タスクが完了するまで作業を継続し、「時間の都合」「別タスク予定」などの理由によるスキップは禁止です。タスクが大きすぎる場合はサブタスクに分割し、スキップが許可されるのは実装方針変更・アーキテクチャ変更・依存関係変更・設計変更など技術的理由に限定されます。スキップ時には tasklist.md に理由を明記し、最後に振り返りドキュメントを作成して実装完了とします。

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 です。

ADR（設計判断記録）、作業プラン、調査メモなどを統一フォーマットで作成・保存できます。 日付とカテゴリで自動的にファイルを整理し、docs/配下に体系的に蓄積できます。 既存ドキュメントを一覧表示して、過去の設計判断や作業履歴を素早く検索できます。 テンプレートを活用することで、設計意思決定を漏れなく記録する習慣がつきます。 技術的な設計判断とその根拠を記録して共有したいエンジニア プロジェクトの実装計画をドキュメント化して、チーム内で認識を統一したいPM・TL 技術調査結果や新ツール導入の検討内容をナレッジとして蓄積したい開発チーム プロジェクト期間中の重要な決定事項を後から参照できる形で残したいすべての職種 docs/配下にadr/（設計判断記録）、plan/（作業プラン）、research/（調査メモ）のディレクトリを用意します。ファイル名はdocs/{category}/yyyy-mm-dd_{タイトル}.mdの形式です。/doc create {category} "タイトル"で新規作成、/doc listで一覧表示ができます。ADRテンプレートは「ステータス→コンテキスト→決定→根拠→影響」の構成、作業プランは「概要→ステップ→対象ファイル→検証方法」、調査メモは「背景→調査結果→結論」の構成です。カテゴリは固定ではなく、必要に応じて新規ディレクトリを作成してよく、テンプレートはガイドラインで内容に応じて自由に調整できます。

実行計画テーブルから未完了タスクを自動抽出し、次々と着手します。TreeWalk実装→VM同期→回帰検出のサイクルを自動繰り返すため、人間の指示なしに開発が進みます。 タスク完了時に自動で計画を「完了」に更新し、changelog.mdに記録するため、進捗管理の手作業がなくなります。 パフォーマンス改善タスク（P3、G2）は自動的にベンチマークを記録し、改善効果を数値で確認できます。 ビルドエラーやテスト失敗を検出した場合、原因調査→修正を試みてから次タスクに移るため、問題が連鎖しません。 CLAUDE.md、plan/memo.md、plan/roadmap.mdなどのプロジェクトドキュメントを毎回参照するため、規約や設計を外さない実装が実現します。 長時間の反復開発を効率化したい開発チーム テスト合格・ベンチマーク記録まで自動で行いたい開発者 計画書とコードの同期ズレを防ぎたいプロジェクトマネージャー 朝出勤時に計画を立てたら昼には完了タスクが溜まっていてほしい人 このスキルは毎イテレーション時にgit logとgit statusで現状を把握した後、plan/memo.mdの実行計画テーブルから未完了の最初のタスクを選定します。開発手順は「TreeWalkで正しい振る舞いを実装」→「VMを同期（同じ結果を返すように）」→「--compareで回帰検出（zig build run -- --compare -e '(test-expr)'）」→「テスト追加・実行（zig build testで baseline=1036 pass）」です。タスク完了時は計画表の該当行を「完了」に更新し、changelog.mdも追記します。パフォーマンス系（P3、G2）タスクでは必ずベンチマークを記録（bash bench/run_bench.sh --quick --record --version="..."）します。意味のある単位でgit commitしたら、設計判断が必要な場合はplan/notes.md`に選択肢を記録し最適な方を選んで進みます。ビルドエラー・テスト失敗は原因調査・修正を試みた後、止めずに次タスクへ移行します。

サブエージェント化の必要性を自動判定: コンテキスト独立性、専門知識、Web検索など複数の基準に基づいて、本当にサブエージェント化が必要なタスクを自動判別します。 5つのタイプに応じた最適なエージェントを設計: 調査系（research）、フィードバック系（feedback）、アイデア出し系（ideation）、検証系（validation）、並列チェック系（parallel-check）の5タイプから最適なエージェント定義を自動生成します。 Skill 群に紐付けた専門エージェントを自動生成: 関連する Skill を識別し、それらを携帯した專門エージェント定義（.claude/agents/*.md）を自動作成できます。 設計原則に基づいた堅牢な定義を作成: サブエージェント設計ガイドに従い、入力・出力・判定基準が明確に定義されたエージェント定義が生成されます。 QC による品質保証: 生成後、QC Subagent（qa-skill-qc）が自動で評価基準に照らし合わせて検証します。 複数の専門分野を扱う大規模プロジェクトの管理者: 分野ごとの専門エージェントが自動設計されるため、システム全体の構造が整理され、保守性が向上します。 並列処理を活用して処理時間を短縮したい人: 調査・検証・アイデア出しなどを同時実行可能なエージェント構成が自動で提案されます。 エージェント設計の手法を統一したい人: ガイドラインに基づいた一貫性のある設計が自動生成されるため、組織全体の エージェント品質が保たれます。 Skills 群に対応するサブエージェント（.claude/agents/*.md）を設計・生成するワークフロー。主成果物は output/{domain}_agent/.claude/agents/ 配下のサブエージェント定義。 フロー: ①./assets/subagent_design_guide.md と既存 Skills を確認；②SKILL.md の recommended_subagents を抽出；③サブエージェント化の判定（コンテキスト不要・専門知識・Web検索・ブレスト・仮説検証・フィードバック等が該当）；④設計（name、type、携帯 Skills、入力・出力を YAML で定義）；⑤agent-name.md を生成（name、description、type、tools を含むフロントマター＋ 携帯 Skills・実行手順・入力・出力・判定基準セクション）；⑥タイプ別テンプレート適用（research/feedback/ideation/validation/parallel-check）；⑦qa-skill-qc Subagent に QC 委譲し ./evaluation/subagent_criteria.md に基づいて評価。単なる評価軸チェック（チェックリスト確認等）は evaluation/*.md で対応し、agents/*.md は作成しない。

因果関係ループ図の作成 - システム思考に基づいた因果構造を可視化し、施策の優先順位と最適な実装順序を提示します。 MSP（最小販売可能製品）計画の立案 - 顧客価値の提供と早期販売開始を実現する必要最小限の機能・サービス計画を生成します。 ゴール記述モデルの細分化 - MSP計画の各作業項目を「誰が・何を・いつまでに・どのように」という具体的なゴールに分解します。 完成度の高い企画書の生成 - 匠Methodの全成果物（因果関係・MSP・ゴール）を統合した、実装チーム向けの企画書を自動作成します。 段階的実行による品質保証 - 4つのステップを順番に実行することで、各段階の出力が次のステップに正確に引き継がれることを確保します。 新規事業企画者・プロダクトマネージャー - 要件から実装計画まで、一貫した企画書を高速で作成したい コンサルタント・ビジネスアナリスト - 顧客とのワークショップ後、すぐに企画成果物をまとめたい プロジェクトマネージャー - 要件・計画・ゴール・企画書の整合性を確保したまま運用したい スタートアップ・新規部門 - 限られたリソースで、最小限の投資で市場投入を実現したい このスキルは4つのSubSkillを順番に実行します。前提条件として Phase 4完了、/vm-all実行済み（vm-compare-score.md存在）、および requirement-tree-*.tsv と requirement-tree.json が必要です。 Step 1（planning-causal-loop-diagram）：要件分析ツリーから因果関係ループ図を生成し、企画の効果的な進行を可視化。 Step 2（planning-msp-plan）：MSP計画を立案（出力：msp-plan.md）。 Step 3（goal-description）：ゴール記述モデルを細分化（出力：goal-description-model.tsv）。 Step 4（planning-proposal-make）：企画書を生成（出力：proposal-format1.mdまたはformat2.md）。 全ステップ完了後、出力ファイル一覧、因果関係ループのレバレッジポイント要約、MSP計画概要（フェーズ数・主要要件）、ゴール記述モデル総数・期間、企画書フォーマットと構成を報告します。

既存システムの分析結果をもとに、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層構成です。

ドメイン分析とアーキテクチャ評価の結果をもとに、ターゲットアーキテクチャを段階的に設計します。各マイクロサービスの責務・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として保存されます。

ユビキタス言語集を生成: ビジネスドメインで使用される専門用語を設計書とコードから抽出し、定義をまとめたドキュメント化。 アクター・ロール・権限を整理: システムに関わる人・役割・権限の関係を可視化し、認可ロジック（リファクタリング＝コードの整理・改善）と対応付け。 ドメイン-コード対応表を作成: 設計書の概念とコード上の実装を行ごとに紐付け、ドメイン理解を加速。 現行システム概要を文書化: 技術スタック、アーキテクチャ、モジュール構成を自動抽出し、新規開発者のオンボーディング資料に。 中間ファイルを逐次出力: 各ステップ完了時にすぐ結果ファイルを生成し、分析の進捗を可視化。 レガシーシステムをリプレイスまたはリファクタリングする開発チーム 既存システムの設計思想を新しいメンバーに学習させたい技術リーダー 設計書とコードの乖離を把握し、ドメインモデルを再構築したいアーキテクト マイクロサービス化やモジュール分割の検討時に現行構造を詳しく知りたい人 システム分析エージェントが既存システムの設計書とコードを分析し、ドメイン理解の基礎情報を抽出します。出力は reports/01_analysis/ ディレクトリに記載。Step 1 では mkdir でディレクトリ作成と対象スキャン、project-metadata.json 出力。Step 2 では設計書解析（ドキュメント読取、ビジネス用語抽出、アクター・ロール特定、機能・非機能要件整理）。Step 3 ではコードベース解析（mcp__serena__get_symbols_overview でシンボル一覧取得、ディレクトリ構造・名前空間・クラス・外部依存を観点に）、system-overview.md 出力。Step 4 ではユビキタス言語抽出（設計書の要件定義書・ER図・ユースケース、コードのクラス名・メソッド名・Enum値・コメント)、ubiquitous-language.md 出力。Step 5 ではアクター・ロール・権限整理（ユースケース図・認証コード・権限設定から）、actors-roles-permissions.md 出力。Step 6 では domain-code-mapping.md 出力（設計書概念とコード表現の対応表）。各ステップ完了時に即座にファイル出力すること。

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。

Gemini・OpenAI・Claudeなどの最新APIモデル名と料金情報を確認できます。 新しいプロジェクト開始時に、最新のAPIバージョンを選択できます。 Preview版（プレビュー版）と正式版の違いを理解した上で実装できます。 古いAPIバージョンを誤って使うのを防げます。 新しいAIプロジェクトを立ち上げるエンジニア APIコールの実装前に最新情報を確認したい開発者 複数のAI APIサービスを比較・検討する必要がある人 既存プロジェクトで使用中のモデルが最新か確認したい人 このスキルは自動的にロードされます。詳細情報はCLAUDE.mdの「Latest APIs Reference」セクションに記載されています。提供内容は以下の通りです： 何を提供するか Gemini APIの最新モデル名 OpenAI APIの最新モデル名 その他主要APIの最新情報 Preview/Beta版と正式版の仕様比較 使用場面 新規プロジェクト開始時：どのモデルを採用するか決定する際 APIコール実装時：最新の仕様に基づいた実装 最新情報の問い合わせ時：「最新のAPI情報を教えて」という質問への対応

depup の各言語パーサ（Node.js/Python/Rust/Go/Ruby/PHP/Java/Swift）が、公式のバージョン指定仕様にどこまで対応しているかを網羅的に監査できます。 実装コードと公式ドキュメントを突き合わせて、対応済み・未対応（実害あり）・未対応（軽微）の3段階に分類し、レポートを自動生成します。 未対応の構文については、パーサへの実装追加とテストケース記述を行い、品質を確保できます。 depup プロジェクトのメンテナーで、パーサの仕様カバー率を把握・改善したい方 複数言語のバージョン管理ツールを開発・保守している方 公式仕様と実装のギャップを系統的に可視化・埋めたい方 このスキルは5段階のワークフローで構成されています。Phase 1では各言語の公式バージョン指定仕様を references/version_specs.md で確認します。Phase 2では8言語のパーサファイル（src/parser/*.rs）とマニフェストファイル（src/manifest/*.rs）を読み取り、対応している構文をリストアップします。Phase 3では公式仕様の各構文を「対応済み」「未対応（実害あり）」「未対応（軽微）」の3カテゴリに分類し、Phase 4ではMarkdown形式でレポートを出力します。Phase 5では未対応（実害あり）の項目についてパーサに対応を追加し、テストケース記述と cargo test・cargo clippy による品質確認を行います。判断基準としてパースと VersionSpecKind 分類が最重要であり、セマンティクス計算や workspace:*/file: 等プロトコル参照はスコープ外です。

返信やプロフィール遷移を増やすための投稿設計を逆算で行い、実装可能な具体策を自動生成できます。 マーケティング・コンパスのWHO×WHATから、ターゲットユーザーとメッセージの整合性を検証し、一貫性のあるアカウント戦略を立てられます。 ドラマ・断定・実験ログ・共感など4つのレーン（投稿パターン）を自動分配し、SNSの「揺れ」を保ちながら効果的な運用ができるようになります。 Promise（約束）・Proof（証拠）・Path（次のステップ）の観点からプロフィール設計を最適化し、ユーザーの行動喚起を促進できます。 アカウント設計の変更を自動的にSSOT（_codex配下のルール定義）に反映させ、チーム全体で統一的な運用ルールを共有できます。 SNSを事業の重要なチャネルとして活用したい起業家やマーケティング責任者 X（Twitter）での発信効果を高め、プロフィール訪問やフォロワー増を目指す個人事業主やPM 複数人でSNSアカウントを運用し、投稿ルールを一元管理したい組織 投稿内容のバリエーション（レーン）を保ちながら、戦略的にプロフィール遷移を促進したい運用チーム SNS Account Factoryは、返信・プロフィール遷移を起点にbrainbaseのSSOT（_codex）と工場ラインへ落とすアカウント設計を行います。参照すべきSSOTは_codex/sns/x_account_profile.md、_codex/sns/sns_strategy_os.md、_codex/sns/x/00_line_charter.md、_codex/sns/x/ops/variety_gate.md、_codex/sns/x/ops/runbook.mdです。ワークフローは行動ゴールからの逆算（返信/プロフィール遷移→低コスト回答→A/B選択）、WHO×WHAT再確認（少人数経営者向けマネジメント自動化ログ）、Promise/Proof/Pathでのプロフィール設計、レーン分け（ドラマ・断定・実験ログ・共感），返信/遷移トリガー設計、SSOTへの反映（line_charter/variety_gate/runbook/account_profile更新）で構成されます。全投稿に同一ルールを当てず、レーン運用で揺れを残すことが必須。出力はPromise/Proof/Path案、レーン配分、SSOT差分。

既に実装されている機能の仕様変更をする際に、要件定義書→基本設計→コード→テストを一貫して同期させます。 変更内容の種別（見た目のみ/動作ロジック変更/機能追加）を自動判定し、必要な更新範囲を特定します。 変更したい機能が他の機能に依存している場合の影響範囲を、依存グラフから自動抽出して可視化します。 仕様書の統一基盤（unified-base）を確認し、新しい概念が出た場合は用語集（glossary）に自動追記します。 API変更がある場合、openapi.yaml の存在確認と更新を含めた一括チェックができます。 開発チームのリーダーで、仕様変更の影響範囲を正確に把握したい方 プロダクトマネージャーで、要件変更時に開発側への負担を最小化したい方 技術仕様書とコード実装のズレを防ぎたい方 複雑なシステムで、変更による予期しない副作用を事前に検出したい方 分析フェーズでは①該当Spec読み込み、②2段階探索によるコード全体把握、③spec-map.yml による依存Spec健全性チェック（confirmed == spec_version の確認）、④openapi.yaml 存在確認（API変更時）を実施します。変更種別を自動判定し、見た目変更のみならばコード修正のみ、動作変更なら要件定義書・基本設計・コード・テスト全て同期更新を行います。依存グラフ影響分析では推移的閉包を構築し、直接依存と推移的依存を区別して影響範囲を特定します。循環依存検出、dependency-graph.md との突合も含まれます。

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倍）。このパラダイムシフトは単なるツール導入ではなく、組織設計の根本的革新による結果。従来の「人を増やして売上を伸ばす」モデルから脱却し、戦略的意思決定の質へボトルネックを転換。

AWS、Azure、GCP、Red Hat OpenShift 向けの Kubernetes マニフェスト（Kustomize base/overlay パターン）を自動設計・生成できます。 Terraform、Pulumi、CloudFormation などの IaC（インフラストラクチャ・アズ・コード）コードでクラウドリソースを定義できます。 OpenShift 固有リソース（Operator、Route、SCC、Project 等）を含むインフラ構成を生成し、アーキテクチャ図やデプロイ手順書も同時に出力できます。 dev/staging/production の環境別に異なるマニフェストやコンフィグを自動生成できます。 Kubernetes や IaC を使ったインフラ構築を自動化したいクラウド・DevOps エンジニア マイクロサービスアーキテクチャのインフラ設計・実装を迅速に進めたい方 ScalarDB を含む複雑なインフラ構成を複数環境で管理・運用する必要がある方 インフラコードと設計ドキュメントを一貫性を保ちながら生成したい方 このエージェントは以下の6つの生成タスクを実行します。(1) Kubernetes base manifests 生成 - Kustomize base/overlay パターンでサービス別マニフェスト生成。(2) 環境別 overlay 生成 - dev/staging/production の環境分離。(3) IaC 生成 - Terraform/Pulumi/CloudFormation でクラウドリソース定義。(4) OpenShift 構成生成 - Operator、Route、SCC、Project など OpenShift 固有リソース。(5) ScalarDB Cluster Helm values 生成 - エディション・環境別の values.yaml。(6) インフラドキュメント生成 - アーキテクチャ図、デプロイ手順書、環境マトリクス。前提条件として /design-microservices の出力（target-architecture.md）が必須であり、推奨として /scalardb-sizing-estimator や /design-scalardb、/select-scalardb-edition の出力が参考になります。出力先は reports/08_infrastructure/ と generated/infrastructure/ です。各ステップ完了時に即座にファイルを出力することが重要です。

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