Skill.md検索

未ステージの変更を検出し、ファイルを選別して自動的にコミット・pushする PR番号を指定またはブランチから自動検出し、GitHub CLIでマージとリモートブランチ削除を実行する マージ後、ローカルのmainブランチを更新し、作業用ブランチを削除する 親Issueを検出してクローズし、レビュー関連資料を削除してワークスペースをクリーンアップする worktreeの依存関係を確認してから安全に削除し、クリーンなリポジトリ状態を保つ レビュー完了後のコミット・push・マージ・クリーンアップを手動で行う手間を削減したい開発者 PR番号を指定して、現在のブランチに関わらず該当PRを出荷したい人 複数のPRを次々と処理する際に、各段階での手作業を自動化したい人 worktreeで分離された作業を安全にクリーンアップしたい人 実行前に、メイン作業ディレクトリがmainブランチであることを確認（必須条件）。main以外の場合は自動切り替え。 ワークフロー：(1)PR番号を特定（引数優先、なければgh pr viewで検出）、(2)PR情報取得（headRefNameからブランチ名取得）、(3)作業方式判定（現在ブランチとPR対象の同一性確認）。 変更のコミット：git statusで未ステージを確認、git diff HEADで差分表示。.claude/settings.json・.claude/settings.local.json・scripts/review/output/は除外。git log --oneline -5でコミットスタイル確認後、prefix（fix/feat/refactor/test/docs/chore）を選択。git add→git commit（Co-Authored-Byを付与）→git push。 マージ・ブランチ削除：gh pr merge {PR番号} --merge --delete-branchでマージ実行。その後、git fetch origin main && git merge origin/main --ff-onlyでmain更新。ローカルブランチ削除前にgit worktree listでworktree依存確認、存在時はgit worktree removeで削除。 親Issue・資料クリーンアップ：PR本文やコミットメッセージから親Issue番号を探し（[Feature]/[Fix]プレフィックス）、未クローズならgh issue closeで実行。scripts/review/output/review-prompt-pr{番号}-*.mdとreview-result-pr{番号}-*.mdを削除。

1日の作業を自動で記録: 本日の日付（currentDate）から history/YYYY-MM-DD.md を自動作成し、この会話で完了した全ての作業を記録します。 作業内容を構造化フォーマットで整理: 作業概要・完了した作業の詳細（問題・修正・対象ファイル）・変更ファイル一覧・ブランチ状況・次ステップを自動で整理できます。 既存記録を失わず追記: 同じ日付の記録がある場合も上書きせず末尾に追記するため、追加作業の記録も保存されます。 変更内容を一覧で確認: テーブル形式で変更ファイルと変更内容を自動集計し、何が変わったかが一目瞭然です。 次のアクションを明記: 残タスクや次にやることを記録できるため、明日の着手がスムーズになります。 開発者: 日々の作業ログを自動記録でき、後から進捗レビューやドキュメント作成に活用できます。 プロジェクトマネージャー: チーム全体の作業履歴を可視化でき、進捗報告や振り返りが簡単になります。 チームリーダー: 誰が何をしたかが記録に残るため、知見共有や品質把握が効率化します。 フリーランス・副業開発者: 業務時間の記録が自動化でき、請求書作成や成果報告の根拠になります。 1日の作業を history/YYYY-MM-DD.md にまとめて保存するスキル。User invocableで、Read・Write・Bashツール利用可能。手順：(1)currentDateから本日の日付を取得し history/YYYY-MM-DD.md を作成、(2)会話内容から完了した作業をMarkdown形式でまとめる（作業概要・完了した作業セクション＝作業タイトル・問題・修正・対象ファイル、変更ファイル一覧テーブル、ブランチ状況、次ステップ）、(3)既存ファイル時は末尾に追記（上書き不可）、(4)完了後に「history/YYYY-MM-DD.md を作成しました」と報告。

新機能の概要をざっくり説明するだけで、実装に必要な詳細要件がすべて埋まった定義書が自動生成されます。 ユーザーストーリー・機能要件・技術設計・影響範囲を体系的にヒアリングして、「実装者が迷わず着手できる」レベルまで落とし込みます。 セッションをまたいで途中保存・再開できるので、複数回に分けての要件整理が可能です。 新機能の企画段階で、実装チームへの引き渡しまでを効率化したいPM・企画者 要件の曖昧さから実装の手戻りを減らしたい開発マネージャー 機能の詳細設計を体系的に整理して、GitHub Issue と実装計画書まで自動生成したい人 新機能の要件定義を徹底ヒアリングで行い、要件定義書・実装手順書・GitHub Issueを生成するスキルです。起動モードは、引数で指定された機能名の docs/features// ディレクトリ有無や requirements.md のステータス値で自動判定（新規作成・途中再開・実装手順書再開）。ヒアリングフローは Step 2a～2d で、ユーザーストーリー → 機能要件 → 技術設計 → 影響範囲を順に掘り下げ、各セクション完了時に requirements.md をフロントマター（status/completed_sections/next_section）付きで自動保存。実装段階では Step 4b で実装手順書・GitHub Issue を生成。すべてフロントマター付きMarkdownファイルで docs/features// 配下に保存され、ユーザー対話は日本語で行われます。