Skill.md検索

完了済みの作業メモから改善案を自動抽出し、GitHub Issueとして記録できます。 メモのライフサイクルを自動管理し、処理済みメモを整理できます。 手作業でIssueを作成する手間を削減し、改善案の見落としを防げます。 重複するIssueの作成を自動チェックして防止できます。 プロジェクト管理者で、日々の振り返り結果をIssue化する必要がある人 チーム開発で改善案を体系的に管理したい人 メモの管理と課題追跡を一元化したい人 retroスキルで完了済みとなった作業メモから改善案を抽出し、GitHub Issueとして作成します。実装は行わず、Issue作成とメモファイルの移動のみに専念します。メモは${WORKSPACE_DIR}/.tmp/memo/（進行中）→memo/done/（retro完了）→memo/issued/（Issue化検討済み）のディレクトリを遷移します。memo/done/配下のメモのみを処理対象とし、memo/直下のメモは絶対に触りません。禁止事項としてコード実装、コミット・プッシュ、ブランチ操作、memo/直下メモへのアクセス、readyラベル付与があります。ワークフローは①memo/done/の.mdファイルを列挙②既存Issue一覧を1回取得③メモから改善案を抽出④重複チェック後Issue化⑤処理済みメモをissued/へ移動、という流れです。

現在の作業ブランチのコミット内容を自動解析し、適切なプルリクエストタイトルと本文を生成できます。document-specialist エージェントと協力してコミット内容を正確に把握し、わかりやすい PR 説明を作成します。 scripts/pr-create.sh を使用してプルリクエストを自動作成し、GitHub との連携作業を効率化できます。タイトルと本文の入力だけで PR が生成される仕組みです。 作成後に scripts/pr-get.sh で PR 情報を取得し、期待値と実際の内容を自動検証します。不一致が検出された場合、scripts/github-rest.sh で自動修正されるため、手動操作が最小化されます。 PR 作成から検証・修正まで一連の処理が自動化されており、エラーが発生した場合は詳細なログとともにユーザーに報告されます。 開発効率を重視するエンジニア：プルリクエスト作成の手作業を削減したい チーム開発を行うプロジェクト：PR 品質（タイトル・説明文の正確性）を自動保証したい CI/CD パイプラインの構築者：PR 作成から検証までの工程を自動化したい 日々多くの PR を作成する開発者：ルーチンワークを効率化し、コード実装に集中したい 手順 1：現在のブランチを確認（main ブランチなら PR 作成不可と通知）。手順 2：ブランチコミット内容を把握。手順 3：document-specialist と協力して PR タイトルと本文を作成し、変数に保持。手順 4：.claude/skills/managing-github/PR-OPERATIONS.md の「PR作成」セクション参照して scripts/pr-create.sh で PR 作成。手順 5：検証と自動修正を実施。scripts/pr-get.sh で実際の PR 情報取得、期待値（手順 3）と実際の値を比較検証。不一致検出時は詳細をログ出力、scripts/github-rest.sh で PATCH /repos/{owner}/{repo}/pulls/{PR番号} を実行して自動修正。修正成功時は完了報告、失敗時はエラーを報告して手動修正依頼。一致時は次へ。手順 6：作成した PR のタイトルと URL をユーザーに通知して作業終了。

直前の作業内容を振り返り、スムーズだった点と問題点を整理できます。 改善が必要な点を洗い出し、ルール・スキル定義ファイルへの明文化が必要な改善案をまとめられます。 既存のGitHub Issueを検索し、同じ改善案が既にIssue化されていないか確認できます。 新しい改善案を自動的にGitHub Issueとして作成し、関連ファイルと修正内容を記載できます。 完了したタスク後に改善点を整理したい開発者 チーム開発でプロセスの問題を記録・共有したい人 ルール・スキル定義の改善提案を仕組み化したい人 試行錯誤から得た知見をIssueに落とし込みたい人 振り返り専用スキル。コード実装・修正・コミット・プッシュは禁止。作業メモ（.tmp/memo/ ブランチ名対応ファイル）を参照し、実施タスク・使用スキル・スムーズだった点・問題点を振り返る。改善案にはルール（.claude/rules/）・スキル定義（.claude/skills/）への明文化を含める。既存 Issue との重複確認後、未化のもので変更対象ファイルを明記して Issue 作成。振り返り報告と Issue 作成で完了し、実装には進まない。

実装前にテストケースを計画リスト化し、最もシンプルなケースから順序立てて実装できます。 Red（失敗するテスト作成）→ Green（最小限の実装）→ Refactor（コード整理）のサイクルを自動管理し、確実に動作するコードを組み上げられます。 実装の各段階でテストと自動チェック（フォーマット、Lint）を実行し、品質を保ちながら進められます。 仮実装（定数返し）から段階的に本実装に進めることで、大きな失敗を防げます。 テスト駆動開発（TDD）で堅牢なコードを書きたい開発者 実装途中のバグを減らしたい人 複雑な機能を小さな単位で確実に進めたい人 テスト漏れや品質低下を防ぎたいチーム Phase 1でテストケースをTODOコメントとして列挙（実装は行わない）。Phase 2で Red-Green-Refactor サイクルを繰り返す：Red は最もシンプルなケース1件選択・テスト実装・失敗確認、Green はテスト通過の最小限実装・PASS確認、Refactor は重複排除と整理（テストは変更しない）。各段階後に gofmt、golangci-lint、go test を実行し、Green/Refactor 後にコミット（Red でのコミット禁止）。複数テストの同時 Red 化、テスト前のプロダクション実装、Refactor 中のテスト変更は禁止。

ストーリーIssueのフィードバックコメントを自動検出し、改善要望や変更依頼を抽出できます。 受け入れ条件の内容が実際のサブタスク実装と一致しているか確認し、完了判定ができます。 未対応フィードバックがある場合は受け入れ条件を自動更新するか、追加タスクIssueを作成するか判断します。 すべての受け入れ条件を満たしている場合、ストーリーを受け入れ完了としてユーザーをassigneesに追加できます。 複数のサブIssueやコミット履歴、PRを確認して、総合的に完了判定を行います。 アジャイル開発でストーリーの受け入れ判定を行うプロダクトマネージャーやスクラムマスター スプリント終了時にストーリーの完了度をチェックしたい開発リーダー GitHub Issueで管理されたタスクの最終確認を効率化したい技術者 チーム全体で受け入れ基準を統一し、品質を確保したい組織 ストーリーのフィードバック確認と受け入れ条件検証を行うスキルです。引数でストーリーIssue番号を指定し、未指定の場合はユーザーに指定を促して処理を終了します。issue-comments.shでコメント一覧、issue-sub-issues.shでサブIssue一覧を取得し、最新サブIssue作成日時を特定します。OWNER、COLLABORATOR、MEMBERの著者によるコメントで、サブIssue作成日時より後に作成された、改善要望・変更依頼・不備指摘が含まれるものを未対応フィードバックとして検出します。フィードバックが検出された場合、issue-get.shで本文全体を取得し「受け入れ条件」セクションを抽出して更新するか、issue-create.sh（--label task付き）で追加タスクを作成してsub-issue-add.shで登録するか判断します。フィードバック対応完了をissue-add-comment.shでコメントします。未対応フィードバックなしの場合、Issue本文から受け入れ条件（チェックボックス-[ ]形式）を抽出し、存在しなければ処理を終了します。その後、git logで最近のコミット、pr-get.shで関連PRを確認し、各受け入れ条件が満たされているか判定します。満たされていない条件があれば追加タスクを作成し、全条件を満たしていればgh api userでGitHubユーザー名を取得してassigneesに追加します。

GitHub Issue を指定すると、理解→実装→自己レビュー→lint/format→PR 作成→自動レビュー→修正→マージ→振り返りを全て自動で実行し、Issue 解決まで完結できます。 チェックリスト形式の進捗管理で、13 ステップの進行状況を可視化でき、途中から再開する場合も実施済みステップを確認した上で続行できます。 各ステップ完了時に作業メモ（.tmp/memo/ 配下）に自動記録され、セッション再開時に履歴から続きの作業が自動判定され、効率的に進められます。 ユーザーの確認待ちがなく、ステップ間を自動で遷移するため、対話型のコマンド実行と比べて大幅に時間短縮できます。 実装、PR 作成、自動レビュー、PR ローカル修正、振り返りを統合的に処理するため、手作業による人為的ミスを削減できます。 Issue 対応の一連の手作業を自動化し、開発効率を最大化したい開発者 Issue 対応プロセスを標準化し、チーム全体の生産性を向上させたいリードエンジニア セッション中断後の「続きどこだっけ」を避けたい忙しい開発者 開発フローの透明性を確保し、Issue 対応の履歴を記録として残したいマネージャー このスキルは 13 ステップのチェックリストに従い完全自動で実行されます：ステップ0（Issue 状態確認）→ステップ1（Issue 理解）→ステップ1.5（実装済みチェック）→ステップ1.6（依存Issue チェック）→ステップ2（実装）→ステップ3（自己レビュー）→ステップ4（lint/format）→ステップ5（重複チェック）→ステップ5.5（rebase チェック）→ステップ6（PR 作成）→ステップ7（fix-pr-local）→ステップ8（振り返り retro）→ステップ9（全作業完了通知）。重要な継続ルール：各ステップ完了後、ユーザーの指示を待たず自動的に次のステップへ進む。サブスキル（commit-commands:commit-push-pr など）実行完了後も即座に次ステップへ進む。スキル返答が「結果なし」の場合も正常完了として次へ進む。作業メモは .tmp/memo/ に「ブランチ名サニタイズ.md」として記録され、既存ファイル上書きせず追記する。セッション再開時（ステップ1.5で既存コミット検出時）は、git log・gh pr list で実施済みステップを特定し、メモを補完した上で次へ進む。

レビューコメントを自動的に読み込んで、各コメントごとに「対応が必要」「対応不要」「承認」のいずれかを判定し、タスクファイルを生成します。 生成されたタスク一覧を tmp/todo フォルダで確認でき、コメント対応の進捗を視覚的に管理できます。 コメント投稿者や対象ファイル、完了条件がタスクに記載されるため、対応漏れなく確実にコメント対応を進められます。 複数のレビューコメントが入ったPRを整理して、着実に対応したい開発者 レビューコメントの対応状況を一覧で追跡・管理したいプロジェクトマネージャー レビューコメント返信や確認の手順をシステム化したいチーム GitHub のプルリクエストレビューコメントを確認して、対応用タスクファイルを生成するスキルです。手順は、github スキル（thread-list.sh）でPRレビューコメント取得 → 必要に応じて thread-details.sh で詳細確認 → コメント1件ごとに内容判定してタスクファイル作成。判定は、レビュワー意見で対応必要判定なら「コメント対応する」タスク、対応不要判定なら「対応不要返信」タスク、承認を表す場合は「スレッド resolve」タスク。ファイル名フォーマットは pr_{PR番号}_task_{2桁0埋み連番}_{概要}.md。テンプレートは対応概要・詳細・レビューコメント情報（PR番号・スレッドID・投稿者）・編集対象ファイル・完了条件・備考で構成。関連スキルに github スキル（返信・resolve対応）を使用するよう記載されています。

自動ツール（linter）でチェック不可能な設計面の問題—インターフェース設計、エラーハンドリングの方針、テスト戦略—を一覧でチェックでき、初期段階での品質問題を防げます。 コミット・PR作成後に即座にフィードバックを得られるため、問題をコードレビュー段階で引きずることなく、素早い改善が可能になります。 チーム全体で統一された品質基準を適用することで、コード品質のばらつきが減り、チーム全体の保守性が向上します。 良い実装パターンを積極的に認識させるため、チーム内でベストプラクティスが共有・継承されやすくなります。 開発チームのリード・アーキテクト：チーム内のコード品質水準を統一・向上させたい人 スタートアップ・成長期企業のエンジニア：レビュー時間を短縮しながら品質を保ちたい人 バックエンド・インフラエンジニア：エラーハンドリングやインターフェース設計の一貫性を重視する開発環境 新人エンジニア教育に力を入れるチーム：実装後すぐに「良い設計」「悪い設計」のパターンを学ばせたい人

実装前にテストケースを明確にできる：実装対象の機能をテストリストとして整理することで、作るべき機能が曖昧になるのを防げます。 最小限のコードから始めて段階的に機能を完成させられる：仮実装（定数を返す）から始め、テストが通ることを確認しながら進むため、大きな失敗を避けられます。 コード品質を保ちながら重複を排除できる：テストで保護されている状態でリファクタリングを行うため、機能を壊さずにコードを整理できます。 テストコミットの一貫性が保証される：赤→緑→リファクタのサイクルで進むため、常にテストが通った状態でコミットでき、ビルド失敗が減ります。 デバッグ時間を削減できる：小さなステップで進むため、どこで問題が発生したかが特定しやすく、修正も簡単です。 品質が求められるプロダクション環境のコードを書いているエンジニア：テストで保護された実装により、バグの混入を最小化できます。 複数人でコードレビューしながら開発しているチーム：テストが常に通った状態でコミットするため、レビュー時間が短縮されます。 TDDのやり方を習得したい初心者から経験者：明確なワークフロー（テストリスト作成→赤→緑→リファクタ）に従うことで、TDDの型を身につけられます。 既存プロジェクトにテストを導入したい開発者：TDDのプラクティスを新機能から段階的に導入でき、徐々にテストカバレッジを高められます。

Issue・PRの自動作成: タイトルと説明文を指定するだけで、GitHub上にIssueやPRを自動生成できます。事前チェック（テスト・Lint）も自動実行されます。 レビューコメントの一括取得: PRに付いた未解決のレビューコメント（スレッド）を一覧表示し、対応すべき指摘を見落としません。 レビュースレッドへの自動返信: レビュー指摘に対して、返信内容を指定するだけで自動的にコメントを投稿できます。メンション機能で対象者に確実に通知します。 レビュースレッドの解決処理: コード修正後に指摘を「解決済み」に変更し、レビュープロセスをスムーズに進められます。 レビュー履歴の詳細表示: 各コメントの作成者・日時・内容を時系列で表示し、議論の経過を正確に把握できます。 開発チーム全体でコードレビューを実施している方 GitHubのIssue・PRを頻繁に作成・管理する開発者やマネージャー レビューコメント対応が多く、手作業での返信・解決処理に時間がかかっている方 チームのコード品質向上とレビュープロセスの効率化を図りたい組織