説明
できること
- 完了した作業と残りのタスクを自動で整理します — この会話で何をしたか、何が終わったか、何がまだ途中かを自動で記録。次回はこの記録を見て、すぐに続きから始められます。
- Git の最新状態とコード変更の内容を記録できます — 今どのブランチにいるか、最後のコミットは何か、動作するか動作しないか、を記録。別のパソコンやAIに切り替わった時も同じ状態から再開できます。
- 重要な決定理由を文字に残せます — 「なぜこの方法を選んだのか」「なぜあの案は落としたのか」などの判断根拠を記録。後で見直す時に、当時の考え方が分かります。
- 次の会話の開き方まで自動生成されます — 「上次做到了XX，接下来要做XX」という形で、AIが次の最適な再開ポイントを提示。あなたが「どこから続けようか」と悩む時間がなくなります。
- プロジェクトの節目ごとに履歴が積み重なります — 複数の会話を重ねるたびに、進捗の足跡が記録される。後で「あの時はどう決めたんだっけ？」と遡ることができます。
こんな人におすすめ
- 複数日に分けて同じプロジェクトに取り組む人 — 毎回「昨日ここまでやった」と説明する手間がなくなります。
- パソコンを複数台使い分けている人 — ノートパソコンで続きから再開、帰ったらデスクトップで再開、みたいな使い方ができます。
- 大型プロジェクトで、進捗を忘れやすい人 — 記録が自動で残るので、2週間後に再開しても「あ、こんなに進んでた」と思い出せます。
- チーム開発やAIの切り替えを予定している人 — 次のAIや次のメンバーが引き継ぐ時、全てのコンテキストが揃った状態で始められます。
# HANDOFF — 项目交接 & 进度保存 每次对话结束前，把当前状态记录下来，下次打开就能无缝继续。 ## 当用户说 /handoff 或对话即将结束时 ### 自动生成交接文档 检查本次对话做了什么，生成以下内容：
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/zhouxiaohe168/naicha-xuanzhi" -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/ へ作業履歴を自動記録するパターンです。