説明
できること
- ソースコードから読み取れない設計意図を記録: プロジェクトの背景にある思想やなぜそのような構造になっているのかを、AIの推測とユーザーの実際の認識のギャップとして整理し、自動的に保存できます。
- 運用ルールと暗黙の約束を文書化: コードに明示されていない慣習、制約、例外的な扱いなどを一元管理し、チーム内の認識を統一できます。
- ドキュメント整備の優先箇所を自動検出: ソースコードからは認識しにくい部分を抽出することで、どこからドキュメント化するべきかが一目瞭然になります。
- タイムスタンプ付きで体系的に蓄積: 日時とリポジトリ名を自動付与し、
~/.claude/knowledge/配下に整理された形で記録されるため、後から検索・参照が容易です。
こんな人におすすめ
- 技術リード・アーキテクト: プロジェクトの設計思想やなぜそのような実装になっているのかを、新しいメンバーにも分かるようにドキュメント化したい人
- ドキュメント管理担当者: コードとドキュメントのズレを検出し、整備が必要な箇所を効率的に特定したい人
- プロジェクト管理者: チーム内に暗黙のルールが多い場合、それを形式知化して属人性を減らしたい人
- 新規メンバーのオンボーディング担当: プロジェクト独自のルールや背景を、体系的に新入者に伝える資料を準備したい人
# ナレッジ書き出し
ユーザーの求めに応じて対話セッション中で新しく認識したリポジトリの構造やルールについて書き出してください。
書き出し先は `~/.claude/knowledge/${repo_name}/${date time prefix}_$description.md` とします。
date time prefix は以下のようにしてください。
- date コマンドを利用してログ出力処理時の現在時刻を取得する
- フォーマットは `+%Y-%m-%d_%H-%M` とする
- タイムゾーンはAsia/Tokyoとするインストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/shomah4a/claude-code-configure" -o ~/.claude/skills/SKILL.md関連 Skill.md
ドキュメント変更を自動検出して更新を促す
by tsukumijima
ソースコード変更から対応スキルを自動特定し、どのドキュメントを更新すべきかを提示します スキル内のコード例とソースコードを比較し、差分がないか自動確認します sourcePatterns（監視対象ファイル）の設定が正しいか検証し、設定ミスを防ぎます 複数スキルの sourcePatterns を一覧で確認でき、スキル更新の漏れを防げます ソースコード更新後、対応ドキュメントをどれ更新すべきか分からない開発者 スキルドキュメント（SKILL.md）の差分管理・メンテナンスを自動化したいプロジェクト管理者 複数スキルを管理していて、更新漏れが発生しやすいドキュメント運用担当者 CLAUDE.mdやスキル内容の最新性を定期的に確保したいチームリーダー スキルと対応ソースコードの関係を管理し、変更検出→スキル特定→差分確認→sourcePatterns検証の4ステップで運用します。各スキルには sourcePatterns が定義されており、対応ソースファイルが変更された場合にスキルの更新が必要になります。変更されたファイルと sourcePatterns を照合し、更新が必要なスキルを特定。スキル内のコード例と実際のソースコードを比較し、乖離がないか確認。sourcePatterns が正しく設定されているか検証します。変更検出は git diff（最新5コミット、mainからの差分、特定コミットからの差分）で行い、複数スキル（tumiki-custom-mcp-server-feature、tumiki-dynamic-search-feature、tumiki-ee-ce-separation、tumiki-mcp-proxy-architecture、tumiki-prisma-schema-changes）の対応パターンを一覧で管理します。
実装後のドキュメントを自動一括更新できる
by watany-dev
新機能の実装完了後、設計書・実装計画書・API比較表・README・チュートリアルをまとめて最新化できます Git の変更履歴から実装内容を自動判定し、どのドキュメントを更新すべきかを特定できます 実装ステータス、API仕様、実装詳細、ファイル構成などを一括更新し、ドキュメントと実装のズレを防げます 新しく実装されたAPIの場合、既存フォーマットに従って自動的に設計書を生成できます 機能を実装した直後、ドキュメント更新を効率的に済ませたい開発者 設計書と実装のズレを最小限にしたいプロジェクト README や API リファレンスを常に最新に保ちたいチーム 新機能追加時に、関連する複数のドキュメントを漏れなく更新したい人 update-docs スキルは 3 フェーズで実行されます。Phase 1（共通）：git diff と git log から変更内容を把握し、実装した機能を特定。Phase 2（開発ドキュメント更新）：設計書（docs/design/）ではステータスブロック・API仕様・Streamlit比較表を更新、実装計画書（docs/impl/）ではフェーズ完了状況・ファイル構成を更新、API比較表（docs/streamlit-api-comparison.md）では ❌ → ✅ に変更；該当ドキュメント未存在時は既存フォーマットに従い新規作成。Phase 3（README更新）：Features・API Reference セクションで新しいAPIを追加、既存フォーマット（TypeScript シグネチャ・パラメータテーブル・使用例）に従って記述。バグ修正・リファクタリング後にも使用可能。
インシデント後の振り返りを構造化ドキュメント化
by Kaikei-e
インシデント発生後に、責任追及ではなく「システム改善の機会」として捉えた事後分析ドキュメント（ポストモーテム）を自動作成できます Google SRE のベストプラクティスに基づき、日本語で統一されたフォーマットで記録し、同じ問題の再発を防ぎます タイムライン、根本原因、影響範囲を定量的（ユーザー数、エラー率など）に記載し、チーム全体の学習資産として活用できます ポストモーテム作成に必要な情報を自動収集し、足りない情報を効率的に質問できます 過去の障害だけでなく、ヒヤリハット（重大事故の一歩手前の状況）の分析にも対応します SRE・DevOps・インフラエンジニア：障害対応後のドキュメント化が必須の職種 スタートアップやスケール期の組織：事後分析の文化を早期に確立したい チームリード・マネージャー：障害からの学習を組織全体で共有したい セキュリティ・品質保証チーム：インシデント記録を組織資産として管理したい このスキルは5つの基本原則に基づいています。（1）Blameless（非難しない）：個人の過失ではなくシステムの改善機会に焦点、（2）正直さと透明性：都合の悪い事実も含めて記録、（3）アクション駆動：全アクションに担当者と期限を設定、（4）定量的：影響を数値で表現、（5）学習の共有：他チームが同種問題を予防できるよう知見を記録します。実行時は既存のポストモーテムテンプレート確認→インシデント情報の多角的収集（会話・システムログ・コミット履歴）→必須情報確認→ドキュメント執筆という手順で進めます。