Skill.md検索

CLaudeの開発環境に必要な設定ファイル（CLAUDE.md、settings.json、MEMORY.md等）をヒアリングから自動生成できます。 新規プロジェクトはテンプレートから立ち上げ、既存プロジェクトには非侵襲的に必要なファイルを追加できます。 GitHubテンプレートから fork した場合、テンプレート由来のファイル（CHANGELOG、README、LICENSE等）の扱いをユーザーに確認した上で整理します。 プロジェクトの技術スタック（言語、フレームワーク、DB、ホスティング先、テスト環境等）をヒアリング結果に応じて自動反映します。 「何もしないがデフォルト」という設計原則に基づき、必要なものだけopt-inで質問するため、無駄な手作業を削減できます。 新しいプロジェクトを立ち上げるたびに、設定ファイルやドキュメントを手作業で整備している開発チーム 既存プロジェクトにClaude Code環境を後付けしたいが、何を設定すべきか分からない方 GitHub Templateから fork したものの、どのテンプレートファイルを削除・カスタマイズすべきか悩んでいる方 プロジェクト固有の開発ルール（ブランチ戦略、テストコマンド、コミット規約等）を効率よく定義したい方 基本設計：「何もしないがデフォルト」「既存ファイルを上書きしない」「背景知識不要」「.gitignoreは配置と連動」の4原則で設計されています。 手順：Step 0でCLAUDE.mdの存在確認により新規PJか既存PJかを判定します。新規PJの場合、Step 0.5でテンプレートクリーンアップ（CHANGELOG.md、README、.github/、LICENSE、docs/decisions/の扱いをユーザー確認）、Step 1でプロジェクト名・言語/FW・DB・ホスティング・テスト・チーム規模等の必須項目と、MCP連携・ブランチ戦略・CI/CD・コミット規約等のオプション項目をヒアリングし、全項目の回答を得まで次へ進みません。Step 2で Project Configuration設定（CLAUDE.md生成、Tech Stackテーブル更新、.claude/settings.local.json生成、permissionsとadditionalDirectoriesの設定）を行います。

git pullで自動的に最新コードを取り込む：メインブランチ（main/master/develop）の最新コードを安全に取り込み、更新内容を自動で把握できます。 直近の変更をカテゴリ別に分類・表示する：新機能（feat）、バグ修正（fix）、改善（refactor/perf）、その他に自動分類し、一目で何が変わったかを理解できます。 DB・API・UI変更の有無を自動検出する：データベーススキーマ変更、APIエンドポイント追加、UI更新など、プロジェクトに影響する変更を自動で検出・表示します。 マージされたPRを一覧表示する：PR番号とタイトルで、どのチケットがマージされたかが一目瞭然です。 メインコンテキストを保護して隔離実行できる：Agent ツールで独立実行され、git logの大量出力がメインコンテキストを圧迫しません。 チームで開発しており、定期的に最新の変更を把握したい人 毎日の朝礼で「何が変わったか」を素早く報告したい人 CI/CDパイプラインに統合し、自動で変更レポートを生成したい人 デプロイ前に、DB・API・UI変更の影響範囲を素早く確認したい人 このスキルはAgent ツールで隔離実行され、メインコンテキストを保護します。目的はgit pullで最新化し、前回からの変更を可視化することです。手順は(1)現在のHEADを記録→(2)git pull --ff-only実行→(3)新しいHEAD取得→(4)OLD_HEADとNEW_HEADが同一なら「最新の状態」と表示して終了→(5)異なる場合は変更内容収集（マージPR一覧、個別コミット、DB/API/UI変更検出）→(6)Conventional Commits prefixで自動分類・サマリ生成です。出力フォーマットは[NEW]新機能、[FIX]修正・改善、[DB/API/UI]変更有無、マージPR一覧を含みます。技術的詳細は省略し、ユーザーに見える変化を中心にサマリします。

会話の中で行われた仕様判断や設計判断を ADR（Architecture Decision Record）として構造化して記録し、後から参照・検索できるようになります 「なぜこう決めたのか」という判断理由を背景・検討内容・理由とともに残すことで、チーム内での知見共有や、後から参加した人の理解が早くなります docs/decisions/NNNN-タイトル.md のフォーマットで一貫性を保ちながら、ステータス（承認済み・検討中・却下・廃止）管理も統一できます README.md に ADR の一覧が自動更新され、プロジェクトの判断履歴が可視化され、類似判断時の参考になります 廃止される仕様があった場合は、元 ADR のステータスを「廃止（Superseded by ADR-XXXX）」と自動更新し、判断の遷移経路が追跡可能になります API 設計やデータベーススキーマなど、重要な仕様判断を後から参照したい開発チーム 複数のバージョンやマイルストーンにまたがるプロジェクトで、時系列で判断理由を記録したい PM やアーキテクト 新しく参加したチームメンバーに「なぜこの仕様になっているのか」を説明する資料が欲しい方 設計レビューや意思決定プロセスの透明性を高めたいスタートアップやアジャイルチーム このスキルは、会話で行われた仕様判断を docs/decisions/ に ADR として記録します。手順は以下の通りです：Step 1 では既存の ADR ファイルから次の番号を決定（4桁ゼロ埋め連番）。Step 2 では背景・選択肢・決定内容・理由をユーザーに確認。Step 3 では NNNN-タイトル.md ファイルを生成し、「ステータス（承認済み）・背景・検討内容（表形式）・決定・理由・影響」セクションをテンプレートとして採用。Step 4 では docs/decisions/README.md の一覧にリンクを追記するか、存在しない場合は作成します。ファイル命名は NNNN-タイトル.md（NNNN は 0001 からの連番、タイトルは kebab-case の英語）とし、コンテンツはプロジェクトの言語で記載。重要な注意事項として、ADR は仕様レベルの判断のみを対象とし、コード実装の詳細（変数名やアルゴリズム選択）は含めません。ステータスは「承認済み」「検討中」「却下」「廃止」のいずれか、日付は必須、廃止時は元 ADR に「Superseded by ADR-XXXX」と記載します。

MEMORY.md の定期棚卸し: Active Work の完了状況、Backlog の重複・陳腐化項目を自動検出し、整理案を提示できます。 フィードバック資産の圧縮: 複数のfeedbackファイルから同趣旨の内容を検出し、統合候補を提案します。 知識の昇格判定: thinking.md に昇格済みのfeedback を確認し、思考OS還流（思考プロセスの改善）に反映すべき項目を抽出できます。 ADR（アーキテクチャ決定記録）の同期確認: 「検討中」のまま放置されている ADR を検出し、ステータス更新を促せます。 Notion タスクDB との連携確認: Tasks DB投入フラグ付きの項目を確認し、24時間以上更新されていないタスクを報告できます。 チーム内の知識・ドキュメント管理者で、蓄積データの肥大化に悩んでいる人 個人の学習フィードバックを定期的に整理・統合したい研究者やエンジニア Notion や Git 連携を含む複数の資産を一元管理している人 週1回〜月1回のペースで運用資産をメンテナンスしたい人 目的: 蓄積された運用資産（feedback、バックログ、知識還流フラグ）を定期的に圧縮・整理する。close-chat が「セッション単位の蓄積」なら、weekly-review は「蓄積の圧縮」です。実行タイミングは手動で、目安は週1回〜月1回。 主な処理: 1. MEMORY.md の行数・Active Work件数・Backlog未完了件数・feedbackファイル数をスナップショット報告 2. Active Work クリーンアップ：「STG確認待ち」で1週間以上経過したエントリ、git worktree の不整合を検出 3. Backlog 整理：完了済み項目（[x]）、重複項目、陳腐化項目（1ヶ月以上前）を削除候補提示、優先度を再評価 4. 行数が200行上限に近づいている場合、完了済みコメント圧縮やCRITICAL RULESの CLAUDE.md 昇格を提案 5. feedback 圧縮：thinking.md §1 に昇格済みのfeedback を確認、同趣旨の統合候補を検出、thinking.md 昇格候補を references/feedback-compression-rules.md に基づいて判定 6. 知識還流フラグ処理：Backlog 内の [ベース昇格] [思考OS還流] プレフィックス付き項目を一括確認 7. Tasks DB 棚卸し（NOTION_ENABLED=true の場合のみ）：[Tasks DB投入] フラグ付き項目確認、Doing タスクで24h以上更新なしを検出 8. ADR 同期確認：直近追加・検討中の ADR 検出、Notion 連携プロジェクトの未同期 ADR を抽出

設計・仕様が確定した作業を、実装→テスト→コードレビュー→PR作成まで完全自動で実行でき、ユーザーが他のタスクに専念できます 自動実装中にテストが失敗した場合も、最大3回まで自動で修正を試みるため、エラーで止まることなく処理が進みます コードレビュー後に指摘があった場合も、自動で修正→再レビューを繰り返し、最終的にマージ可能な品質まで引き上げます 実装・レビュー・修正過程で発見した新しい知識や判断ルールが自動で記録され、チーム全体で活用できるようになります 単純で決まった作業が多く、人手をかけたくない開発チーム 24時間稼働させたい・夜間に自動で作業を進めたいプロジェクト 実装を並列化したい大規模開発 設計・仕様がしっかり固まっているスプリント内での効率化を求める場合

このセッションで対応しきれなかった設計検討・実装・テスト項目を自動で抽出し、次のセッションで優先度をつけて実行できるようにバックログ化します 判断が下りたが未記録だった設計判断（ADR）を自動で検出し、チーム全体で参照可能なドキュメントとして記録できます 実装中に発見した「プロジェクト全体に適用すべき原則」と「プロジェクト固有の落とし穴」を自動で分類し、知識として蓄積できます チャット内で議論した継続検討事項を記録しておくため、次回セッションで「あのとき何を決めていたか」をすぐに思い出せます 複数回にわたる長期プロジェクトで、セッション間の引き継ぎをスムーズにしたい 判断や学びが散逸してしまう問題を抱えている開発チーム プロジェクト特有のルール・パターンを次のメンバーに引き継ぎたい場合 設計・実装の決定理由を後から参照可能にしておきたいチーム

プロジェクトルール・命名規則・アーキテクチャ方針への違反を自動検出し、コード整合性を保つことができます。変更が実装直後に基準をクリアしているかチェックできるため、レビューの手戻りを減らせます マジックナンバーの検出・重複ロジックの抽出・過度な複雑性の指摘など、将来の保守を困難にする問題を早期に発見し、実装段階で修正できます データベース設計の正規化漏れ・インデックス漏れ・外部キー制約の妥当性・破壊的マイグレーションを検証することで、本番環境でのパフォーマンス低下やデータ整合性の問題を防げます 変更箇所と同種のコード全体を調査し、同じ問題が他の箇所に散在していないかを検出することで、コード品質を一貫して保つことができます セキュリティ脆弱性（SQLインジェクション・XSS・認証漏れ・通信暗号化）を検査するため、リリース前に潜在的なセキュリティリスクを洗い出せます エンジニアで、自分が書いたコードが品質基準に合致しているか多角的にチェックしたい人 コードレビュアーが指摘すべき項目を体系化し、レビュー品質を高めたい開発チーム レガシーシステムのリファクタリングを行うエンジニアで、品質低下を防ぎながら改善したい人 データベーススキーマの変更時に、正規化やパフォーマンスをまとめて検証したい人

UI/UXの一貫性を検証 — ボタン、色、フォント、スペーシングなど、既存の画面と統一されているかを確認し、ユーザーが迷わないデザインになっているかチェックできます。 デザインシステム準拠を確認 — プロジェクトで定めたカラーやタイポグラフィのルールに従っているか、また既存コンポーネントの再利用が可能な場所で新しく作られていないかを検証できます。 アクセシビリティ（a11y）を自動チェック — 画像のalt属性、フォームのラベル、キーボード操作対応、色のコントラストなど、誰もが使いやすいデザインになっているかを確認できます。 レスポンシブ対応を検証 — スマートフォンやタブレットなど、異なる画面サイズで問題なく動作するかを確認できます。 プロジェクト独自ルールをチェック — ブランドガイドラインやCSS規約など、プロジェクト固有のデザイン規則への準拠状況を検証できます。 デザイナー・フロントエンドエンジニア — デザイン品質を保ち、統一感のあるUIを作成・レビューしたい方 プロダクトマネージャー — ユーザー体験の一貫性やアクセシビリティ対応の状況を把握したい方 QA・テスター — UI品質の問題を早期に発見したい方

障害シナリオへの対応を確認 — データベースやAPI、外部サービスが使えなくなった場合にシステムがどう動くか、ユーザーに与える影響は最小限か確認できます。 二重処理やデータの不整合を防げるか確認 — 同じリクエストが2回来たときや複数ユーザーが同時に操作したときに、データが壊れないか確認できます。 問題の早期発見を可能にする可観測性をチェック — ログ、エラー通知、パフォーマンス監視など、本番で問題が起きたときに気づいて対応できる体制になっているか確認できます。 個人情報の安全性を検証 — ログやエラーメッセージに個人情報が誤って記録されていないか、API応答に不要な個人情報が含まれていないかを確認できます。 デプロイ後の問題対応を確認 — 問題が見つかったときに素早く前のバージョンに戻せるか、データベースの変更を戻せるかを確認できます。 コスト増加を予防 — クエリ数や外部APIの呼び出し頻度が妥当なレベルか、思わぬコスト増加を招いていないかを確認できます。 バックエンドエンジニア・SRE — システムの堅牢性と運用性を確保したい方 DevOpsエンジニア — 本番環境での安定性と障害時の対応体制を整えたい方 プロダクトマネージャー・事業責任者 — サービスの可用性とコスト管理の状況を把握したい方

API契約の互換性を検証 — APIのレスポンス形式が変わったときに、既存のアプリやクライアントが正常に動き続けるか確認できます。 破壊的変更を検出 — 必須パラメータの追加やレスポンス構造の変更など、既存ユーザーに影響を与える変更を事前に警告できます。 仕様書と実装の乖離を発見 — 設計書やドキュメントに書かれた内容と実装が一致しているかを確認し、齟齬があれば指摘できます。 プロジェクトの設計方針を守れているか確認 — ADR（設計決定記録）やCLAUDE.mdで定めたルールに沿っているかを検証できます。 DB スキーマ変更時の安全性を確認 — マイグレーション中も古いコードと新しいコードが共存する設計になっているかを確認できます。 バックエンドエンジニア・API開発者 — API仕様の品質を維持し、クライアント側の問題を防ぎたい方 フロントエンドエンジニア — API変更による影響を事前に把握したい方 テックリード・アーキテクト — 設計方針の遵守とシステムの整合性を確保したい方

テストの漏れを検出 — 新しく作ったコードやロジックに対してテストが書かれているか、変更したコードのテストが更新されているか確認できます。 テストケースの網羅性を確認 — 正常系だけでなく、エラーが起きる場合や境界値（0件、空文字など）のテストが書かれているかを確認できます。 テスト品質の問題を指摘 — テストの名前が不明確、弱いアサーション（値をきちんと検証していない）、テスト同士の依存関係など、テストの信頼性を損なう問題を検出できます。 モック（模擬オブジェクト）の正確性を検証 — テストで使っているモックが、実際のデータベースやAPI応答と一致しているか、信頼できるテストになっているかを確認できます。 テストが実装と矛盾していないか確認 — テストが通ってもモックが不正確だと本番で問題が起きる可能性があります。そうした矛盾を検出できます。 テストエンジニア・QA — テストの質と網羅性を高めたい方 バックエンドエンジニア・フロントエンドエンジニア — 自分たちが書くテストの品質を確保したい方 テックリード・開発マネージャー — チーム全体のテスト文化と品質基準を維持したい方

複数の視点から一括検証 — コード品質、テスト、運用安全性、デザイン、API仕様など、5つの専門的な観点からコードを同時にチェックし、問題を見落とさないようにできます。 効率的に重要なチェックを実行 — 変更内容に応じて必要なレビュー観点を自動判定し、不要なチェックはスキップして無駄を削減できます。 矛盾や漏れを検出 — コードは通っているのにテストが不十分、運用で問題が起きそう、といった異なる観点間の矛盾を発見できます。 プロジェクト固有ルールの遵守を確認 — ビジネスルールや不変条件といったプロジェクト独自のチェック項目も組み込んで検証できます。 総合的な判定結果を得る — 複数の観点の結果を統合し、マージできるか、対応が必要か、一目でわかるレポートが得られます。 テックリード・開発マネージャー — チーム全体のコード品質と開発速度のバランスを取りたい方 開発チーム全体 — コミット前またはPR作成前に、多角的な品質チェックを自動化したい場合 プロジェクトの品質責任者 — 本番品質を保ちながら、開発効率を損なわないようにしたい方