Skill.md検索

技術選定の透明化 — 新しいgem・npmパッケージ・ライブラリ・フレームワーク導入時に、「これは何か」「なぜ必要か」「他の選択肢との比較」を初学者向けに提示 設計判断をユーザーに委譲 — A案とB案のどちらを選ぶか、専門用語を平易に説明した上で、ユーザーの明示的な承認を取得 理解負債の防止 — 「コードは動くが、なぜそうなっているのか説明できない」という状態を作らず、実装と同時に学習・理解も進める 設計判断をADRとして記録 — 確定した設計判断を別スキル（adr）で自動的にArchitecture Decision Recordに落とし込む プログラミング初学者・エンジニア初心者 — コードの背景にある技術選定や設計理由を学びながら実装を進めたい人 プロジェクトマネージャー — チーム全体の技術的な理解を揃え、将来のメンテナンス負荷を下げたい人 AI-人間協働開発チーム — AIが高速でコード実装する際に、人間の理解ペースに合わせたチェックポイントを設けたい場合 発動条件は7つ：(1)新技術導入時（gem・npm・ライブラリ・ツール追加）、(2)設計判断が必要な場合（複数実装方法から選択）、(3)構造変更時（ディレクトリ構成・ファイル配置・モジュール構成）、(4)外部連携（OAuth・外部API・第三者サービス）、(5)パターン適用（デザイン・アーキテクチャパターン）。ユーザーが指示しなくても自動で発動。技術選定時のルール：実装前に3点提示（これは何か、なぜ必要か、代替案比較）。表形式で選択肢の長所・短所を提示し、おすすめを明記。設計判断時ルール：選択肢と比較表提示後に承認取得、専門用語は初出時に平易説明を括弧で添える。説明レベル：ユーザーはプログラミング初学者なので、専門用語に平易説明を必ず付加。コード内コメントは「なぜ」を書く（CLAUDE.md準拠）。当たり前の概念も初出なら説明。スキル連携：設計判断確定後はadrスキル呼び出し、新技術導入後はlearning-noteスキル利用を提案。発動不要ケース：既存技術の再利用・標準ツール通常使用（RSpec・Vitest・RuboCop等）・バグ修正での新技術伴わない場合・リファクタリングで設計方針不変の場合。

Conventional Commits（日本語）形式でコミットメッセージを統一し、チーム全体で一貫性のあるGit履歴を保つことができます。 PR作成時に自動実行されるClaude Code Reviewの結果に対し、効率的な修正・再確認フローで対応できます。 mainへのマージ戦略をMerge commit統一で運用し、履歴追跡とロールバック対応を容易にできます。 「盲従しない」ルールに基づき、local Claude（この環境のClaude）が指摘の妥当性を検証してから修正を進め、品質を保証できます。 Recollyプロジェクトのメイン開発者・IKさん（コードレビュー・マージ判断担当） チーム内でコミットメッセージやPRタイトルの形式を統一したい開発チーム GitHub Actions上のAIコードレビューと手元のAIアシスタント間の連携を効率化したい組織 GH Actionsのコスト削減と開発速度の両立を目指すプロジェクト管理者 RecollyプロジェクトのGit運用ルール（コミット規約、マージ戦略、PRルール、コードレビュー）を定めます。コミットメッセージはConventional Commits日本語形式（feat:、fix:、chore:、test:、docs:、refactor:など）で統一。マージ戦略は全PRをMerge commit統一、Squash/Rebaseは不可、main直接プッシュ禁止。PRタイトルもConventional Commits形式。初回レビューはPR open/ready_for_review/reopenedトリガーで.github/workflows/claude-code-review.ymlが自動実行。再レビューはsubsequent pushでは自動実行せず、@claudeメンション（gh pr comment）で手動発動させます。対応フロー：①local Claudeが指摘の技術的妥当性を検証（盲従ゲート）、②妥当な指摘のみ修正、③修正報告＋@claudeメンションをgh pr commentで投稿、④GH Actions Claudeが再確認。IKさんはコンテキスト共有・マージ判断のみ、@claudeコメントタイプや指摘反映はlocal Claude代行。

日本語コンベンショナルコミット自動生成: feat（新機能）・fix（バグ修正）・refactor・docs・styleなど、タイプと日本語説明を組み合わせたコミットメッセージを自動作成。Working Documentsから変更スコープも自動判定できます。 セマンティックバージョニング管理: MAJOR.MINOR.PATCH+BUILDの自動算出。破壊的変更・新機能・バグ修正の種別に応じてバージョンを自動更新し、pubspec.yamlに反映できます。 変更履歴（リリースノート）の自動生成: Gitログからコンベンショナルコミットを抽出し、追加・修正・変更の3セクション形式で整形。Markdown形式で出力できます。 Working Documents連携: 現在のブランチ（例：fix/#123-xxx）からIssue番号を自動抽出し、対応する設計ドキュメントから変更対象ファイルを取得。スコープを自動決定できます。 デプロイ前チェック自動化: 構文チェック・テスト実行・ビルド作成を一括実行。Android・iOS・Web・Windowsの各プラットフォーム対応です。 リリースマネージャー・DevOps: バージョン管理とリリースノート生成を統一ルールで自動化し、運用を効率化したい人 開発リーダー: コミットメッセージの形式を統一し、チーム全体で一貫性のあるGit履歴を保ちたい人 フロントエンド・モバイルエンジニア: マルチプラットフォーム（iOS・Android・Web・Windows）でのビルド・デプロイを統一管理したい人 テクニカルライター・ドキュメント担当: 自動生成されたリリースノートをベースに、ユーザー向けドキュメントを素早く作成したい人 コミットメッセージ形式は type(scope): 日本語説明（50文字以内）+ body（箇条書き）+ footer（Closes #番号）+ Co-Authored-By。タイプは feat・fix・refactor・docs・style・perf・test・chore・ci の9種。スコープ例は機能名（list・ocr）・レイヤー名（provider・service）・画面名。Working Documents参照では①ブランチからIssue番号抽出②docs/working/配下で検索③design.mdの「変更対象ファイル」から抽出④単一機能時は機能名・複数機能時は最大影響をスコープに選択。フォールバックはファイルパスから判断。コミット手順は git diff --staged で確認→複数行メッセージはHEREDOC使用。バージョニングはMAJOR.MINOR.PATCH+BUILD（pubspec.yamlの version フィールド更新）。MAJOR は破壊的変更・MINOR は新機能・PATCH はバグ修正。リリースノート自動生成は uv run scripts/generate-release-notes.py --from --version --output で実行。デプロイ前チェックは flutter analyze && flutter test 。プラットフォーム別は Android（appbundle）・iOS（Codemagic→TestFlight）・Web（GitHub Actions→Firebase Hosting）・Windows。

Lizardで関数の循環的複雑度（CCN）と論理行数（NLOC）を測定し、リファクタリング対象関数を自動抽出。CCN値に応じて「正常（1-10）」「注意（11-15）」「警告（16-25）」「危険（26-50）」「即対応（51+）」と5段階評価し、優先順位を明確化します。 Gitleaksでgitリポジトリ内のシークレット漏洩（APIキー、パスワード等）を自動検出し、セキュリティリスクを即座に把握できます。 複雑度が高い関数には「ガード節導入」「関数抽出」「ストラテジーパターン」などの具体的なリファクタリング手法を提案し、実装の指針が得られます。 監査結果から自動的にリファクタリング Issue を作成、Working Documents を生成することで、発見から実装着手まで一気通貫できます。 大規模プロジェクトのコード品質をCCN等の指標で可視化・改善したい開発チーム PR作成前に複雑度とセキュリティリスクを一括チェックしたい開発者 リファクタリング計画を優先順位付けして立てたい技術リーダー 継続的にコード品質を監視し、技術負債を削減したい組織 スキルは Lizard（複雑度解析）と Gitleaks（シークレット検出）を統合。前提条件として pip install lizard 、Gitleaks 公式サイトからのインストールが必要（Windows の場合は C:\Users\kensa\bin にインストール済み）。実行は uv run .claude/skills/project-maintenance/scripts/run-project-maintenance.py --output maintenance-report.mdで統合監査。--complexity・--security フラグで個別実行も可能。--ccn-threshold（デフォルト15）・--nloc-threshold（デフォルト50）でカスタマイズ。CCN重症度は1-10（正常）、11-15（注意）、16-25（警告）、26-50（危険）、51+（即対応）。分析手順は Step1 で監査実行、Step2 で優先度判定（セキュリティ最優先→CCN 51+→CCN 26-50）、Step3 で具体的なリファクタリング手法提案（ガード節、関数抽出、ストラテジーパターン、テーブル駆動、Widget分割等）、Step4 で Issue 自動作成と Working Documents 生成、Step5 でリファクタリング実装。