説明
できること
- 不確実な設計判断を明確にする マイクロサービス化やモジュール分割など、「どう分けるべきか」という問いに対して、性能・可用性・保守性といった非機能要件とのトレードオフを整理し、複数の選択肢から最適解を選べます。
- 設計内容を記録・共有できる 設計判断が「なぜそうしたのか」とともにADR（Architecture Decision Record）で記録されるため、将来の変更時に過去の判断根拠を参照でき、組織の知見が蓄積されます。
- 運用を前提にした設計を立てられる 障害検知・復旧手順・ログ設計を含めた包括的なアーキテクチャを提案でき、本番環境での問題対応がスムーズになります。
- データの所有権や責務の曖昧さを解消できる コンポーネント間の依存関係やデータ流向きを明確化し、実装時に「この責務はどこに置くべき？」という迷いが減ります。
- スケール変化に対応しやすい構造にできる アーキテクチャの段階的な成長戦略を設計でき、今必要な最小構成から始めつつ、将来の拡張を見越した構造になります。
こんな人におすすめ
- バックエンドエンジニア・アーキテクト 新規プロジェクトや大規模な設計変更で、説得力ある提案ができるようになります。
- テックリード・エンジニアリングマネージャー チーム全体の設計判断を可視化・合意形成でき、実装の上流で問題を潰せます。
- プロダクトマネージャー・PO 技術的な実現可能性と制約を理解した上で、優先度やスケジュール計画が立てられます。
- スタートアップの初期メンバー 限られたリソースの中で、今必要な構造と将来への投資バランスを判断できます。
# Architecture Expert Skill ## 発火条件（リポジトリ判定） - まず `doc/input/rdd.md` を確認し、非機能要件/制約/運用要件/参照が存在する場合、このSkillを優先適用する。 - 記載が薄くても、依頼が「構造」「責務分離」「データフロー」「境界」「スケール」「運用」「観測性」「ADR」なら適用する。 ## このSkillの基本方針（整理軸） - 基本方針: 正解を断言しない。制約→選択肢→トレードオフ→決定→検証、の順で合意形成する。 - 設計対象: コンポーネント境界/依存方向/インタフェース/データ所有権/失敗時の振る舞い/運用（監視・ログ・復旧）までを含める。 - 進め方: まず最小の全体像（1枚の図）を作り、次に「一番危険な不確実性」を潰す。
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/mae616/ai-template" -o ~/.claude/skills/SKILL.mdタグ
関連 Skill.md
議事録をタスク化して自動でIssue登録
by kayac
雑に書かれた議事録やメモを貼り付けるだけで、自動的に構造化されたGitHub Issueに変換できます。 単語や語句を途中で改行しない、意味のまとまりを保つなど、日本語テキストの改行位置を自動で最適化できます。 GitHub Projects（Kanban風プロジェクト管理ツール）の初期セットアップを自動実行し、カスタムフィールドやステータス列を一度に構築できます。 Issue State（Open/Closed）と Kanban Status（Todo/In Progress/Done）を区別して管理し、プロジェクト全体のタスク状態を正確に追跡できます。 Epic・Feature・Story・Task・Bugの5階層チケット構造に従ってタスクを自動分類し、粒度を統一できます。 ミーティング後に議事録をそのままGitHub Issueに落とし込みたいプロダクトマネージャーやスクラムマスター GitHub Projectsを使いこなしたいが初期設定が複雑に感じるチームリード 既存のIssueを整理・分析し、より効果的なタスク管理体制を構築したい開発チーム KanbanステータスとIssueステートの違いをしっかり管理したいプロジェクト管理者 このSkillはPhase 1（入力分析）で、引数がない場合は対話形式で操作を選択させ、あれば「初期設定」「setup」「整理」「analyze」などのキーワードをチェックして該当フローを実行します。Phase 2（認証・リポジトリ確認）ではgh auth statusとgit remote get-url originでリポジトリ情報を取得し、Organizationか個人リポジトリかを判定。議事録からタスク作成時はテキストを解析し、Epic→Feature→Story→Taskへと粒度に応じて階層化。Taskは3時間以内で完了する単位として設計。Projects初期セットアップ時は、カスタムフィールドを自動作成し、Kanban Status（Todo/In Progress/In Review/Done）とは別にIssue State（Open/Closed）を管理。「Status」という日本語が来た場合はKanbanステータスを意図していることに注意。内部スクリプト（pm-project-fields.sh）を利用してステータス操作を実行。
複数チームで並行開発できる3層構造を自動構築
by i-standard1
ドメイン構造の自動初期化: 要件ドキュメントから適切なドメイン分割を判定し、各ドメインの責務を明確に定義できます。 インターフェース定義の事前確定: 複数ドメイン間のAPI・データ型・イベントを先に決めることで、各チームが独立して実装できるようになります。 共通基盤の優先実行: 複数機能が使う共通UIやユーティリティを最初に完成させ、その後の開発をブロッキングなく進められます。 並列実行フェーズの自動調整: フェーズ0〜3に分けて、どの機能が同時実行できるか自動判定し、無駄な待ち時間を削減します。 マージ順序の自動制御: 各フェーズの完了後に自動的にmainへのマージを促し、古いブランチからの分岐によるコンフリクトを防ぎます。 複数機能を同時に開発したいプロジェクトマネージャー: チーム間の依存関係を構造的に管理でき、スケジュール遅延を防げます。 大規模なバックエンド開発を指揮する技術リード: ドメイン駆動設計（DDD）の考え方を実装段階で具体化できます。 初期段階で全体の設計を定めたい開発チーム: 曖昧なインターフェース定義のままコードを書き始める問題を回避できます。 複数チームの調整役を務める人: 「何をいつ開始するか」の判断基準が明確になり、進捗報告がしやすくなります。 SuperPMは判断と調整のみ行い、コード実装は行いません。domains/ディレクトリが存在しない場合、初期化フェーズで要件定義書とインターフェース定義から各ドメインを決定し、テンプレートをコピーしてドメイン間IF定義ファイルを作成します。並列実行時は「フェーズ0（IF定義確定）→ フェーズ1（共通基盤）→ フェーズ2（独立機能）→ フェーズ3（依存関係あり機能）」の4段階に分割し、各フェーズ完了後にmainマージしてから次フェーズを開始します。共通基盤は複数機能が共通で必要とするUI・ユーティリティ・認証などを特定し、shared-components.mdにインターフェース付きで記録。全機能の要件分析から不足コンポーネントを洗い出し、共通基盤タスク完了まで個別機能を起動しません。2回目以降は既存shared-components.mdで不足部分を確認する仕組みです。
Issue対応作業を効率的に開始・終了できる
by ka2kama
作業開始時に Issue 番号を基にコンテキストを構築し、ブランチ作成・Draft PR 作成まで自動実行して、準備段階を完結させます。 現在のブランチ・PR 状態から「新規着手」「PR 欠落」「通常再開」「レビュー中」のいずれかを自動判定し、ステップを スキップして効率化できます。 作業完了時に .tasks/plans/ のタスク履歴を自動記録し、コンテキストクリア後のステップ喪失を防止します。 GitHub Issue 駆動開発を導入しているチームのすべての開発者 セッション終了時に作業状態を記録し、次のセッション開始時にスムーズに再開したい開発者 ブランチ・PR・Issue の管理を手動で行うのが煩雑だと感じている開発者 計画→実装→テスト→レビューの流れを統一的に進めたいプロジェクト Step 1 で main 最新化、Step 2 で Issue 番号を特定（ブランチ名抽出か引数から）、Step 3 で ブランチ・PR 状態から4種類のワークフロー状態を検出します。A（新規）は ブランチ・PR 両方なし、B（欠落）はブランチあり PR なし、C（通常再開）はブランチ PR 両方 Draft、D（レビュー中）はブランチ PR 両方 Ready の判定です。Step 3.5 で Issue 精査コメント有無を確認し、ステップ遷移は確認なしで自動進行（破壊的操作・複数選択肢がある場面のみ確認）します。/wrap-up と対になり、セッション終了時に .tasks/ へ作業履歴を自動記録するパターンです。