Skill.md検索

Issue要件との整合性を確認: チケットに書かれた要件（AC: Acceptance Criteria）が実装で満たされているか自動判定し、達成・未達成・部分的をレポート化 可読性を構造的に評価: 命名規則・コード構造・Swiftイディオムが読みやすいかチェックし、改善提案を提示 保守性をアーキテクチャ観点で診断: DI（依存性注入）・テスタビリティ・将来の変更耐性を評価し、技術的負債を可視化 構造化されたレポートを自動生成: 指摘を[Must]（必須修正）/ [Imo]（意見）/ [Nits]（細かい点）/ [FYI]（参考情報）で分類 GitHub Issue・PR・ブランチに対応: Issue番号やPR番号を指定するだけで、自動的にコードと要件を照合 iOSアプリ開発チーム: チーム開発時のコードレビューを効率化し、品質基準を統一したい プロジェクトマネージャー: Issueに書いた要件が本当に実装されているか確認したい 新人エンジニア: Swiftベストプラクティスを学びながら、レビューコメントを理解したい QA・テスターエンジニア: 実装がテスト可能な構造になっているか事前確認したい iOS/Swiftプロジェクト向けコードレビュースキルで、3つの観点で評価します。Issue要件チェックでは、GitHubのIssue番号や直接入力されたIssueテキストから機能要件・AC・非機能要件を抽出し、実装での対応状況を確認。可読性レビューでは命名・構造・イディオムを評価。保守性レビューではアーキテクチャ整合性・テスタビリティ・Concurrency対応を診断します。コードはファイル直貼り・PR番号・ブランチ名で指定でき、差分だけでなく周辺コードも読んで整合性を確認。レポートは参照ドキュメント（output-format.md・swift-readability.md・architecture-patterns.md）のテンプレートに従い、種別ラベル付きで出力します。Issueがない場合はそのセクションをスキップ。

複数の変更が混在している場合、意味のある単位に分割して複数コミットに分けるべきか判断できます。 コミットメッセージのルール（「何を」「なぜ」を含めるなど）に従い、後から読んでも意図が伝わるメッセージを自動生成できます。 コミット前に、デバッグコードの混入や意図しないファイルがないかをチェックし、不要な変更を防ぎます。 分割案や生成したメッセージをユーザーに提示して確認を取るため、意図と異なるコミットが作成されるリスクを減らせます。 GitHubのコミット履歴を後から読みやすくしておきたい開発者 チームで「どの粒度でコミット分割するか」という基準を統一したい人 コミットメッセージの形式を統一して、プロジェクト全体の品質を上げたい人

ユーザーの報告や会話の中から、GitHub Issue として立てるべき内容を認識し、構造化されたフォーマットで自動生成できます。 完了条件（Acceptance Criteria）を検証可能な形で追加するため、「終わったのか終わってないのか判断できない」という状態を防ぎます。 リポジトリのラベル一覧から適切なラベルを自動選定し、Issue を分類・管理しやすくします。 Issue本文をプレビューしてユーザーに確認を取るため、意図と異なるIssueが作成されるのを防ぎます。 生成したIssueはコードレビュー時の「Issue要件チェック」と連携し、チーム全体のワークフローを効率化します。 バグ報告や機能要望を頻繁に受け取り、Issue 化する作業を効率化したい人 Issue テンプレートを統一して、チーム全体の Issue 管理を標準化したい人 PR作成前に、要件を Issue で明確にしてから実装に入りたい開発者やリーダー

ブランチ作成からPR公開まで一括自動化: 「PRを作って」と指示するだけで、ブランチ作成・コミット・プッシュ・PR作成が順番に実行されます。 Issue番号から自動的にPRを生成: Issue番号を指定するか、ブランチ名から自動判定して、関連するPRを効率的に作成できます。 PR本文を自動フォーマット: テスト項目やサマリーなどを統一フォーマットで自動入力し、レビュー準備を時短できます。 コミット後のスムーズなPR化: コード完成後に「PRに進みますか？」と聞かれて承認するだけで、面倒なコマンド入力なしにPRが完成します。 GitやGitHubの複雑なコマンドを覚えたくないエンジニア 毎日何度もPRを作成する開発生産性を高めたい人 PR作成の手順を統一したいチームリーダー・マネージャー