Issue対応作業を効率的に開始・終了できる

雑に書かれた議事録やメモを貼り付けるだけで、自動的に構造化された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で不足部分を確認する仕組みです。

プロジェクトのタスク・アイデア・イシューを .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 使用。