説明
できること
- 言語別対応で精密なテキスト分割：19言語に対応した言語感知型テキスプリッター（Vectra TextSplitter）を使用し、コメント・文字列・インデント構造を理解した上でコード/ドキュメントを意味単位で分割できます。
- 外部APIに依存しない完全ローカル処理：Oramaエンジンをローカルで実行し、全文検索・ベクトル検索・ハイブリッド検索をクラウド無しに高速実行できます。
- 3種類の検索モードを自由に組み合わせ：キーワード全文検索・セマンティック検索（ベクトル）・ハイブリッド検索から、ユースケースに応じて最適な検索方式を選択できます。
- インクリメンタル更新で差分反映が容易：変更されたファイルのみを再インデックスでき、大規模なコードベースでも更新コストを最小化できます。
- JSON形式での永続化・復元：インデックスをJSONで保存・復元できるため、検索インデックスをバージョン管理に含めたり、チーム間で共有したりできます。
こんな人におすすめ
- 社内コードベース・ドキュメント・ナレッジベースから素早く必要な情報を検索したい開発者・技術者
- プライバシー・セキュリティの理由でクラウド検索サービスを使えない企業の情報システム担当者
- 大規模なコードリポジトリ内から文脈に合った関連コードを自動抽出し、LLMプロンプトを拡張したい機械学習エンジニア
# RAG — 本地语义检索集成指南 > 将代码/文档切片 → embedding → 存入 Orama → 全文/向量/混合检索。全程零外部服务依赖（embedding 除外）。 ## 激活条件 - 需要对代码库或文档集进行语义搜索时 - 构建本地知识库、上下文召回管道时 - 需要增量索引变更文件时
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/themarshs/claude-setup" -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）学習の共有：他チームが同種問題を予防できるよう知見を記録します。実行時は既存のポストモーテムテンプレート確認→インシデント情報の多角的収集（会話・システムログ・コミット履歴）→必須情報確認→ドキュメント執筆という手順で進めます。