プロジェクト管理

雑に書かれた議事録やメモを貼り付けるだけで、自動的に構造化された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）を利用してステータス操作を実行。

ドメイン構造の自動初期化: 要件ドキュメントから適切なドメイン分割を判定し、各ドメインの責務を明確に定義できます。 インターフェース定義の事前確定: 複数ドメイン間の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 番号を基にコンテキストを構築し、ブランチ作成・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/ へ作業履歴を自動記録するパターンです。

プロジェクトのタスク・アイデア・イシューを .backlog/ ディレクトリのJSONLファイルで一元管理でき、Excelや外部ツールに頼らず管理できます。 タスク（優先度付き）・アイデア（ブレストストレージ）・イシュー（問題報告）の3種類を区別して追加・完了処理し、プロジェクト段階に応じた柔軟な管理ができます。 全アクティブアイテムの一覧表示や完了アイテムへの移動を自動化し、バックログの鮮度を保つことができます。 バックログの履歴（監査ログ）を自動記録し、意思決定プロセスを追跡可能にできます。 Markdownサマリを自動再生成し、ドキュメント・チーム共有資料を最新に保つことができます。 スクラム・カンバン開発を実践するプロダクトマネージャーやスクラムマスター GitHub Issuesではなくローカルベースでバックログを管理したい開発チーム 振り返り（レトロスペクティブ）や監査ログを重視するプロジェクトマネージャー タスク・アイデア・イシューを柔軟に分類・管理したい研究開発チーム バックログ管理は .backlog/ ディレクトリのJSONLファイル（tasks.jsonl・ideas.jsonl・issues.jsonl）を backlog-cli (Go CLI) で操作。バイナリは .claude/skills/backlog-manage/cli/bin/backlog-cli に配置。未ビルド時は自動ビルド（task backlog:build）。コマンド仕様：add task（title・description・priority・tags）、add idea（title・description・tags）、add issue（title・description・severity・tags）、complete（IDで指定アイテムをdoneファイル移動）、list（全アクティブアイテム表示）。IDプレフィックス（task/idea/issue）から自動ファイル判定し status・done_at・resolved_at を設定。プロジェクトルートから実行、デフォルト--dir .backlog 使用。

天気・ニュース・メール・カレンダー・Tasks・ハテブ・Gyazo・GitHubを30分ごとに自動巡回し、最新の情報を一覧化できます。 メール内容から新しいタスク追加や予定追加の「提案リスト」を自動作成し、ユーザー承認を得てから実行することで、誤操作を防ぎながら効率化できます。 明日のヤマト受取時間を事前確認し、変更が必要な場合は提案できます。 処理済みメールスレッドを状態ファイルで管理し、同じメールの重複処理を確実に防ぎます。 パーソナライズルールで「ヤマト運輸の通知は無視する」など、ユーザー独自の分類ルールを適用できます。 毎日大量のメール・タスク・予定に目を通す必要がある管理職や営業担当者 時間帯ごとの天気やニュースを定期的にチェックしながら仕事を進める人 Gmail・Google Tasks・Google Calendarを統合して一元管理したい人 メール内容から自動的にタスクや予定を提案してほしい人 30分ごとの実行順序（固定）：(1).codex/skills/weather/SKILL.md（make run）で天気取得 → (2).codex/skills/news/SKILL.mdで情報取得 → (3)Gmail・Calendar情報取得 → (4).codex/skills/hatebu/SKILL.md（hatebu ls --json）でブックマーク取得 → (5).codex/skills/gyazo/SKILL.md（gyazo ls --limit 20 --json）でキャプチャ取得 → (6)GitHub情報取得 → (7)取得情報をキャッシュに保存。前提条件：実行バイナリは/home/yuiseki/bin/gogを使用、API操作は--account 必須、GOG_KEYRING_PASSWORDをexport。作業ディレクトリ/home/yuiseki/Workspaces/.ai-secretary/heartbeatを使用。状態ファイル/home/yuiseki/Workspaces/.ai-secretary/heartbeat/state.jsonで重複防止（最新200件スレッドIDを保持、同一スレッド再処理禁止）。パーソナライゼーションルール/home/yuiseki/Workspaces/.ai-secretary/heartbeat/personalization-rules//RULE.md形式で管理、無視ルール優先。非対象：Google Drive・Contacts。

ユーザーに一切質問せず、タスクグラフに基づいて全タスクを自律的に完了できます。 テスト・ビルド・検証（受入条件AC確認）をユーザー確認なしで自動実行し、プロトコル（プロトコルパターン）に従って繰り返します。 プロジェクトルール（CLAUDE.md）と関連ドキュメントを自動読み込みし、それらを不変条件として作業を進められます。 最大反復回数を設定可能で、複雑なマルチステップタスクも一度のコマンドで完結させられます。 プロジェクト全体のルールに沿った自動実装を希望する開発チーム テスト・ビルド・検証を含む一連の作業を一度に完了させたい開発者 ユーザー確認を介さず、自律的に判断・実行するAIアシスタントを活用したい組織 繰り返しが必要な研究・開発ループを自動化したいプロジェクト管理者 自律的反復研究ループ「Ralph」は、状態ファイルに基づいてタスクグラフを順次実装し、全受入条件を検証して完了します。ユーザーに対して一切質問しません。Ralph内ではグローバルルールを上書きし、テスト・ビルド・AC検証コマンドはすべて自律実行、git pushは非実行、git commitはtask_graph内に明示的コミットタスクがある場合のみ実行です。使用例は/ralph（既存状態ファイル使用）、/ralph "prompt" (skip-planモード)、/ralph "prompt" --max-iterations Nです。処理フロー：①CLAUDE.mdを読込、②変更ディレクトリに応じてdocs/配下ドキュメント読込、③状態ファイル読込（セッション固有またはクロスセッション検出）、④Plan/Operationモード分岐、⑤タスクグラフ実行→AC検証→状態更新の反復。最大反復回数はデフォルト25回。

開発中の判断事項（CSV か JSON か、認証方式など）を structured な質問として docs/qa/questions.jsonl に記録できます。 質問投稿後、自動的に Slack/Discord に通知し、チームからの回答を約1分間待機します。 回答がない場合は仮決定（provisional decision）を自動採用して作業を継続し、判断遅延を防ぎます。 全ての質問と回答を JSON Lines 形式で履歴管理でき、後から /qa/check で確認・監査できます。 分散チーム・リモート開発で、チーム意思決定を記録・追跡したい人 プロジェクトマネージャーで、重要な判断ポイントの履歴を残したい人 開発がブロックされることなく、非同期で意思決定をキャッチアップしたい人 使用例：/qa/ask "CSV or JSON?"、/qa/ask --type provisional --decision JSON "Data format preference?"、/qa/ask --type deferred --stub "auth_placeholder()" "Authentication method?"。パラメータ：question（必須）、--type（provisional|deferred、デフォルト provisional）、--decision（provisional の仮決定）、--stub（deferred のスタブコード）、--options（選択肢カンマ区切り）。実装：scripts/qa/models.Question、qa.store.QAStore を使用。ワークフロー：(1)ブランチ名から Issue 番号抽出、(2)次の質問ID生成（Q001,Q002,…）、(3)Question オブジェクト作成、(4)docs/qa/questions.jsonl に追記。投稿後、wait_for_answer 関数で約60秒間 answers.jsonl をポーリング（5秒間隔）。回答受信時は「✅ 回答を受信」とログ出力。タイムアウト時、provisional の decision がある場合は notify_decision で Slack スレッドに仮決定を投稿して作業継続。answer が null なら「⏳ タイムアウト。後で /qa/check で確認してください」と案内。

GitHubのIssueを自動的にクローズし、GitHub Projectsのステータスを「Done」に変更できます。 現在のブランチ名からIssue IDを自動抽出し、複雑な指定なしに作業完了処理を実行できます。 セッション中の作業内容から完了サマリを自動生成し、Issueボディを更新することで、作業内容の記録と履歴管理が自動化されます。 プロジェクト設定ファイル（.config/project.yml）から必要な情報を読み込み、複数リポジトリ・複数プロジェクト環境に対応できます。 チーム開発でGitHub Projectsを使用している人：作業完了時の定型処理（クローズ、ステータス更新、備考記入）を自動化したい タスク駆動開発を行う人：Issue単位で細かく管理しており、完了処理の煩雑さを減らしたい 複数ブランチで並行開発している人：ブランチ名からIssueを自動判定し、作業完了を素早く報告したい 使用方法は/dev-done [Issue ID]で、Issue番号を指定するか省略してブランチ名から自動判定します。処理フロー：1. Issue特定：ブランチ名からgit branch --show-currentで取得、Issue IDを抽出。2. 完了サマリ生成：セッション中の作業内容から要約。3. Issue情報取得・更新：現在のボディを取得、「作業状況」セクションを更新（✅完了、成果、PR参照、ブロッカーなし）。4. Issueクローズ：gh issue close。5. GitHub Projects Status更新：GraphQL mutationで「Done」ステータスを設定。6. 完了報告：Issueリンクと完了サマリを表示。設定ファイル.config/project.ymlからgithub_project.project_id、project_number、repository、fields.status.id、fields.status.options.doneを読み込みます。別リポジトリへのPR作成時は完全修飾名（owner/repo#number）が必要です。

異なるテストファイルの修正、複数のバグ調査など、関連のない複数のタスクをエージェントに分散させて同時に進めることができます。各エージェントは独立した文脈で作業するので、互いに干渉しません。 タスクごとに「スコープ」「ゴール」「制約」を明確に指定することで、エージェントが迷わず集中して問題を解決できるようになります。 セッションの全コンテキストを引き継がせずに、必要な情報だけを正確に構成するので、メインエージェントのコンテキストを温存でき、別の調整作業に充てられます。 異なるサブシステムやドメインの複数の障害が同時に発生している場合、それぞれを並列に調査できるため、全体の作業時間を大幅に短縮できます。 複数のテストが同時に失敗していて、それぞれを順番に調査するのは時間がかかると感じる開発者 異なるサブシステムが独立して壊れている状況を早期に把握・修正したい人 プロジェクトのコンテキストを温存しながら、複数の並列タスクを効率良く実行したい 関連のない複数のバグ・不具合を同時に対応する必要があるエンジニア このスキルは独立したドメインの特定、集中的なエージェントタスクの作成、並列ディスパッチ、レビュー・統合の4段階で構成されます。使用タイミングは、複数の障害が存在し、各々が独立していて、調査間で共有状態がない場合です。エージェントプロンプトは集中的（ひとつの明確な問題ドメイン）、自己完結的（問題理解に必要なコンテキストを含む）、出力が明確（何を返すべきか明示）の3点が要件です。障害が関連している場合や全体状態の理解が必要な場合、エージェント間の干渉がある場合は使用しません。

活動記録をamemに自動保存しながらDiscordに同時通知：amem keepコマンドで進捗を記録する際、環境変数を読み込むことで自動的にDiscordに通知できます。記録と通知の二重手作業が不要になります。 チーム全体に進捗を可視化して連携を円滑化：進捗情報がDiscordチャンネルに流れることで、チームメンバーが最新の進捗状況をリアルタイムで把握でき、フローをスムーズにできます。 マイルストーン完了時に要点だけを素早く通知：長い進捗報告ではなく、短く要点をまとめた通知をDiscordに送信でき、通知疲れを防ぎながら情報共有できます。 amem記録が正で、Discordは補助的な通知として一貫性を維持：記録の正出所をamemとすることで、情報の信頼性を保ちながら、Discordの利便性を活用できます。 必要に応じて即座にアラートや周知を手動通知：acomm --discord --agentで直接通知できるため、緊急時の連絡や記録とは別の重要通知にも対応できます。 進捗報告の手作業を減らしたい開発チーム：amem記録時に自動Discordミラーが動作するため、別途Slack・Discord投稿の手間が不要になります。 チーム内の情報共有をリアルタイムで活性化させたいスクラムマスター：Discordの即時通知で、チーム全体の進捗可視性が向上します。 作業記録と情報発信の一元管理を実現したい個人開発者・起業家：amem + Discord一体運用により、記録管理と報告作業を同時に処理できます。 プロジェクトマイルストーンを体系的に追跡したい技術リード：進捗がamemに蓄積され、かつDiscordで確認可能になるため、追跡と遡及が容易になります。 amem-discord Skillは、amem keep進捗記録時に~/.config/yuiclaw/.envを事前読み込みしてDiscord ミラー（acomm --discord --agent）を有効化するスキル。使用場面：進捗をamem記録しながらDiscord反映、マイルストーン完了を短く通知、「amem-discord で報告」指示対応。基本手順（推奨）：（1）環境変数読み込み（Discord ミラー用），（2）amem keepで活動記録追加。コマンド例：set -a; source ~/.config/yuiclaw/.env; set +a; amem keep "" --kind activity --source 。直接Discord通知（必要時のみ）：ミラー設定無い、または即時通知必要時にacomm使用。コマンド例：set -a; source ~/.config/yuiclaw/.env; set +a; acomm --discord --agent ""。運用ルール：amem優先（記録が正）・Discord短く要点・秘匿情報非送信・細かい頻度で連投回避。トラブルシューティング：amem無い場合は/home/yuiseki/Workspaces/repos/amemのcargo run使用、Discord流れない場合は環境変数export確認・ミラー設定確認・acomm --discord --agent直接使用。

コードベースから自動的にアーキテクチャを可視化: ディレクトリ構造と命名規則を分析し、プロジェクト全体の設計思想を文書化できます。 技術スタックを一元管理: 使用フレームワーク、ライブラリ、ツール、技術的な制約や決定を記録し、すべてのメンバーが参照できます。 ビジネス背景を文書化: 製品目的、ターゲットユーザー、コア機能をまとめ、「なぜこの設計なのか」の背景を共有できます。 アーキテクチャ決定の歴史を記録: ADR（アーキテクチャ決定記録）形式で過去の判断理由を保存し、同じ議論の繰り返しを防げます。 チーム間でナレッジを共有・継承: セッション終了時に学習を自動抽出・保存し、他のメンバーやプロジェクトで再利用できます。 コードとドキュメントのズレを検出: 実装の変化を追跡し、古い情報を更新するよう提案できます。 AI エージェントと協働開発するチーム（steering 情報を全エージェントが参照） 新しいメンバーがプロジェクトに参画し、素早くキャッチアップが必要な場合 複数プロジェクトを並行管理し、ナレッジを移植したい組織 アーキテクチャ決定の理由を後で参照・学習したい長期プロジェクト steering スキルは「プロジェクトの記憶」を生成・維持するコンテキスト管理スキル。3つの steeringドキュメント（structure.md：アーキテクチャパターン・ディレクトリ構造・命名規則、tech.md：技術スタック・フレームワーク・制約、product.md：ビジネスコンテキスト・目的・ユーザー）と 4つのメモリドキュメント（memories/：アーキテクチャ決定記録 ADR、開発ワークフロー、ドメイン知識、CLI コマンド集、教訓）を管理。Agent Memory CLI（musubi-remember v3.5.0）で extract/export/import/condense/list/clear 操作が可能。セッション間の学習抽出、チーム間のナレッジ共有、プロジェクト間の ベストプラクティス移植、長時間セッションのメモリ最適化をサポート。重要：すべてのドキュメントを英語版（filename.md）と日本語版（filename.ja.md）で作成することが必須。乖離検出とアーキテクチャ改善提案も実装。

ユーザーの指示内容から作業計画書・要件書・設計書・タスクリストを自動生成し、体系的に整理・記録できます。 タスクリストに基づいて実装を段階的に進め、各タスクの完了状況をドキュメントにリアルタイム更新します。 実装完了後に振り返り記録を作成し、プロジェクト全体の成果と学習ポイントをドキュメント化します。 大規模な機能開発や複数タスクを確実に完了させたい開発者 作業の進捗を可視化し、チームや後続の参照用に記録したい人 タスク漏れやスキップを防ぎ、実装品質を保ちたい人 プロジェクトの意思決定や設計思想を永続的に残したい人 ステアリングファイル（.steering/）に基づく実装支援スキル。モード1（ステアリングファイル作成）では日付形式でディレクトリを作成し、永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を確認した上で、テンプレートからrequirements.md・design.md・tasklist.mdを生成。モード2（実装・最重要）では tasklist.mdを常に参照しながら実装を進め、タスク開始・完了時にEditツールで即座に更新する。全タスク完了が絶対原則で、「時間不足」「難しい」などの理由でスキップを禁止。未完了タスク残存での終了や振り返り記入を禁止。タスク分割やサブタスク追加で対応。技術的理由のみスキップ許可（実装方針変更・アーキテクチャ変更・依存関係変更・設計変更）。

複数の読み込み・書き込みタスクを並列実行できる順序に自動分析し、最短完了時間で実行できます。手作業の待ち時間を大幅削減できます。 実行前に必須チェックリスト（Pre-flight）を自動出力し、実行後にも結果検証（Post-flight）を行うため、設定ミスやエラー見落としが防げます。 タスクごとに最適なAIモデル（haiku で十分な検索・パース、より高度なモデルで生成・分析）を自動選択し、実行コスト・速度を最適化できます。 キャッシング機能により、同じ分析を何度も実行する時間を短縮できます。 違反ルール（モデル指定漏れなど）を検出したら即座に中断し、修正指示を出力するため、無駄な実行を防げます。 複数ファイルの同時分析・生成を手がけるプロジェクト管理者 大規模リファクタリングやマイグレーションで作業を高速化したいエンジニア コンテキスト収集やドキュメント生成を並列化したいAI活用チーム チェックリスト・ガバナンスを重視するプロジェクト Turbo Mode v3.0 は「分析 → バッチ → 実行 → 検証」サイクルを強制実行するプロトコルです。v2.0との核心変化は、Pre-flight/Post-flight チェックリスト、Model Routing Policy、Evidence Caching が全て MANDATORY（省略不可）になった点です。Pre-flight では作業リスト生成、依存性グラフ分析、バッチ構成、モデルパラメータ明示を確認。Model Routing Policy で Task ツール呼び出し時に model パラメータ必須（ファイル検索・パース = haiku、生成・分析 = より高度なモデル）。Post-flight で実行結果を検証。違反時即座に中断し事由を報告。全 6 項目の Pre-flight チェックリスト（作業リスト生成、タイプ指定、依存性分析、バッチ構成、モデルパラメータ、ID確定）を ✅/❌ で確認後、実行進行です。

タスク委譲の自動化: 指揮者・セクションリーダー・ミュージシャンといった階層に応じて、タスクを正しいレベルのエージェントに自動で割り当てることができます。 階層違反の防止: Conductor が直接ファイルを編集するなどの禁止行為を自動検出してブロックし、組織的なタスク実行を強制します。 並列タスク実行: 複数のタスクを同時に下層エージェントに委譲し、効率的に並列処理できます。 正しい委譲経路の強制: Conductor からは Section Leader を経由する、など正しい委譲ルートを自動チェックします。 複数エージェントを組織的に管理したい人: 階層的な指示体系が自動で守られるため、組織全体の秩序が保たれます。 大規模なタスクを効率的に処理したい人: 複雑なタスクを自動で分解・委譲し、並列実行できるため処理時間が短縮されます。 ヒューマンエラーを減らしたい人: 手動でタスクを割り当てる際の誤りが発生しなくなります。 上位エージェント（Conductor/Section Leader）がタスクを下位エージェント（Musician）に委譲するスキル。階層違反を防ぎ、正しい委譲パターンを強制します。 コマンド形式: /delegate （直接委譲） /delegate --to section_leader （特定レベルに委譲） /delegate --parallel | | （並列委譲） 階層ルール: Conductor は Section Leader または Musician に委譲可能。Section Leader は Musician にのみ委譲可能。Musician は委譲不可（自分で実行）。委譲時は Task ツールで subagent_type="general-purpose"、model="sonnet" を使用。禁止事項として、Conductor/Section Leader による直接 Edit/Write、Conductor による Musician への直接指示、Musician によるサブエージェント spawn がブロックされます。エラー発生時は enforce-hierarchy.py フックが検出します。

先週の週報をベースに、複数のNotionデータベースから今週の情報を自動で集約し、差分を反映した新しい週報を作成できます。新規作成の場合でもテンプレートから自動生成されるため、ゼロから作る手間が不要です。 求人票のURLを提供すると、AIが自動的に企業情報や求める人物像を読み込み、志望動機作成の参考情報として提示します。 プロジェクトDBと照合して、管理対象のプロジェクトのみを週報に自動選別・記載するため、他チーム案件の混在を防げます。 情報源を自動でタグ付け（[src: MeetingNote ] など）し、変更箇所に `` フラグを付与するため、後で検証・修正が容易です。 MLシステム開発ユニットのマネージャーやリーダーで、毎週の週報作成・更新業務を効率化したい方 複数のNotionデータベースから情報を集約するのに時間がかかるプロジェクト管理者 メンション機能で担当者にすぐに確認依頼を送りたい方 タイトルパターン 【週次報告】週 共同研究 MLシステム開発 に合致する直近の先週版を検索し、先週版をベースにNotionから今週の更新情報を収集・差分反映します。先週版が存在しない場合のみテンプレートから新規作成します。複数のNotionリンク（プロジェクトDB、タスクDB等）から情報を集約し、新規発生は追記、状況変化は本文更新、完了は削除または「完了」と記載変更します。確証が薄い項目に ` を付与し、担当者がわかる場合はコメント機能でメンション。Notion発行時のPage名は 【週次報告】週 共同研究 MLシステム開発` で、ドキュメントデータベースに登録。最後に新規ページの存在・プロパティ・本文の整合を検証します。

ミーティング終了後、文字起こしと当日メモを入力するだけで、自動的に議事録・要約・タスク抽出を実行できます。 プロジェクト関連資料（README、過去の実験結果、前回MTG記録）を自動で読み込んで文脈を理解し、より正確な要約を生成します。 Notion参照との照合を自動化し、抽出されたURLが全てReference管理されているか確認した上で要約を進めます。 研究室・プロジェクトチームで定期的にMTGを実施する人 ミーティング議事録の作成・整理・タスク化を自動化したい Notion・タスクリスト・研究ノートを連携して管理したい 議事録の品質をはやく確保して、すぐに行動に移したい このスキルはPhase別ワークフローを採用しています。Phase 1では初期確認でプロジェクト名・日付・参加者を確認し、自動的にREADME・仕様書・実験結果・前回MTGなどを読み込みます。Rawファイルを自動作成してユーザーに文字起こし貼り付けを依頼します。Phase 2では当日メモからNotion URLを自動抽出し、既存のReference管理ファイルとの照合を行います。すべてのURLがReference化されていることを前提条件として、要約開始へ進みます。このプロセスにより、単なる議事録作成だけでなく、文脈理解→Notion連携→タスク抽出→プロジェクト管理更新を一気通貫で実施できます。

コーディング規約（命名規則・エラーハンドリング・テスト実装・セキュリティ）をドキュメント化し、チーム全体で同じ基準で開発できます。 Git Flow ブランチ戦略・PR プロセス・Conventional Commits などの開発フロー（デベロップメント・プロセス）を統一します。 テスト戦略（テストピラミッド・カバレッジ目標）とコードレビュー基準を明確にし、品質を確保できます。 CI/CD パイプラインと Makefile による品質自動化の方針を定義し、手作業を減らせます。 既存ガイドラインがある場合はそれを優先しながら、足りない部分を補完できます。 チーム開発を始める際に、実装ルールと開発フローを整備したい人 プロジェクトの技術スタックに合わせた具体的なコーディング規約を作りたい人 コードレビューやテスト戦略のベストプラクティスをチーム全体で共有したい人 既存ガイドラインを保ちながら、新しい規約や改善点を追加したい人 チーム開発に必要な2つの要素「実装時のコーディング規約（implementation-guide.md）」と「開発プロセスの標準化（process-guide.md）」をカバーします。開始前に docs/architecture.md（技術スタック）と docs/repository-structure.md（ディレクトリ構造）を確認します。優先順位は①既存の docs/development-guidelines.md ②このスキルのガイド ③汎用的なベストプラクティスです。新規作成時はスキル内ガイドとテンプレートを参照し、docs/development-guidelines.md に保存します。implementation.md では型定義・命名規則・関数設計・エラーハンドリング・並行処理・コメント・セキュリティ・テスト・リファクタリング・品質自動化を網羅します。process.md では基本原則・Git Flow ブランチ戦略・コミットメッセージ・PR プロセス・テストピラミッド・コードレビュープロセス・品質自動化を定義します。使用シーンごと（新規開発・レビュー・テスト設計・リリース準備）にガイドを参照できます。

ユーザーが提示したタスク内容から自動的にタスク名（英語・kebab-case）を決定し、YYYYMMDD-{タスク名} という標準化されたディレクトリを作成できます。 タスク用README.md（目的・ゴール・実装方針・完了条件・作業ログ）をテンプレートから自動生成し、関連ドキュメント（plan.md・tech.md・structure.md）の参照内容を提示できます。 実装方針をユーザーに提示して確認を取った後、GitブランチをTaskManager（TodoWrite）で自動細分化でき、実装ステップをプロジェクト管理できます。 完了時には作業ログを記載し、PR作成コマンド（/autodev:create-pr）へスムーズに引き継げます。 タスクの開始から完了まで、ドキュメント・ブランチ・進捗管理を統一したい開発チーム 複数のタスクを並行進行する際に、各タスクのコンテキスト（目的・方針・進捗）を見失わないようにしたい人 API実装→UI実装→テスト→PR作成という一連の流れを自動化し、手作業での手戻りを減らしたいプロジェクトマネージャー 8つの手順：①タスク名決定（$ARGUMENTS→英語kebab-case、例：image-detail-view）、②.ai-agent/tasks/YYYYMMDD-{タスク名}/README.md作成、③README.md記載項目（目的・ゴール・実装方針・完了条件・作業ログ空欄）、④関連ドキュメント確認（plan.md・tech.md・structure.md）、⑤ユーザー方針提示・確認取得、⑥ユーザー確認後にgit checkout -b {タスク名}でブランチ作成（main pull は後）、⑦TodoWrite でタスク細分化、⑧実装開始。実装中の注意：各ステップで動作確認・API後curl確認・UI後Playwright MCP確認・tmp使用可・ユーザー確認取得。完了時：完了条件チェック→作業ログ記載→ユーザー報告→/autodev:create-pr でPR作成。

プロジェクトの「なぜやるのか」「どんなビジョンか」「スコープはどこまでか」など10の重要な問いに体系的に答えられます ビジネスアーキテクチャ分析書をもとに、チーム全員が同じ方向を向くためのドキュメント（インセプションデッキ）を作成できます 概念アーキテクチャ図やマイルストーンのGanttチャートを自動生成して、複雑な情報を視覚化できます 既存のインセプションデッキを新しい条件に合わせて更新・修正することもできます 作成したドキュメントからPowerPointスライドを生成してステークホルダーへプレゼン準備もできます プロジェクトを立ち上げる際にチーム全体の認識を揃えたいプロジェクトマネージャー・プロダクトマネージャー ビジネス要件と技術要件の落としどころを整理したい設計者・アーキテクト プロジェクトの中盤で「実は認識がズレていた」という手戻りを減らしたい企画・開発チーム 不明な点が残ったままプロジェクトを進めたくない、仮定を明記して進めたい方 ビジネスアーキテクチャ分析書（業務分析の成果物）をもとに、10の問い形式でインセプションデッキを作成。情報源：ケイパビリティヒートマップ（問い1）、ビジネスプリンシプル（問い2・9）、価値提案（問い3）、バリューストリーム・ケイパビリティマップ（問い4）、組織マップ（問い5・8）、ガイディングプリンシプル（問い6）、リスク環境（問い7）、フェーズ分割マイルストーン（問い10）。新規作成時はテンプレート（@docs/template/インセプションデッキ.md）をコピーして使用。概念アーキテクチャ図（問い6）とマイルストーンGanttチャート（問い10）はPlantUMLで作成。既存デッキの更新時は該当する問いのみを修正。完成後は generating-slides スキルでPowerPoint化可能。テンプレートは編集禁止。

Rust プロジェクト（koe：Ubuntu 向け音声入力ツール）を3つの独立した開発ストリームに分割して並列開発できます 音声パイプライン、設定UI、設定永続化＆統合をそれぞれ別のワークツリーで同時に進められます 各エージェントは自動で cargo check を実行してコンパイルエラーを検出・修正し、テストを3回実行して安定性を確認します 共有型をあらかじめ src/types.rs に定義することで、マージ時のコンフリクトを最小化できます 3つのストリームが完了後に一括で検証・マージして品質を保証できます 複数の開発者でRustプロジェクトを進めており、並列開発の効率性を上げたいチームリード オーディオ処理・UI開発・設定管理など異なる領域を同時に開発したい開発チーム git worktree を活用した並列開発の運用方法を確立したいチーム マージ時のコンフリクトを減らし、統合テストの負担を減らしたい方 koe の開発を3つの独立したストリーム（Stream 1: Audio Pipeline、Stream 2: Settings UI、Stream 3: Config & Integration）に分解。各ストリームは git worktree add で別々のワークツリーを作成。各エージェントは以下のルール適用：編集ごとに cargo check 実行・即座に修正、テストスイートを最低3回実行して安定性確認、共有型は src/types.rs に定義。ワークツリー: .worktrees/audio-pipeline, .worktrees/settings-ui, .worktrees/config-persist。完了時にサマリー報告（動作状況）。3ストリーム完了後に共有型コンフリクト解決 → cargo check → cargo test → cargo build で全体検証 → main/develop にマージ。既知注意点：settings-ui ワークツリーが前回セッションから存在、GTK4 設定保存コールバック未解決の可能性、whisper-rs ビルドに libclang-dev が必要。