説明
できること
- テキスト分析ツール（Linter）で文法と表記をチェック：
npx textlintコマンドを実行し、日本語の文法、表記ゆれ、冗長表現、助詞の不自然さなどを機械的に指摘。すべての指摘を修正することで品質を担保します。 - ドキュメント全体の文体を「ですます調」で統一：「だ・である調」を排除し、一貫した敬体で記述。読み手にやさしく、プロフェッショナルな印象のドキュメントに。
- AIっぽさや不自然な表現を排除：「あなたが」「〜いるんです」といった砕けすぎた表現や、押し付けがましい断定を削除。淡々と事実を述べた自然な日本語に改善します。
- 太字や構成を最適化：本当に強調すべき技術用語だけに絞り、冗長な前置きや不要な感想文を削って、伝わる構成に整備します。
こんな人におすすめ
- GitHub等でREADMEやドキュメントを公開している開発者：ドキュメントの質を高め、ユーザーの読みやすさを向上させたい人。
- 技術仕様書や設定ガイドを社内で共有する人：文体を統一し、誰が読んでも分かりやすいドキュメントを作りたい人。
- 複数人で執筆したドキュメントの表現を統一したい：チーム内の文体のゆらぎを修正し、統一感を持たせたい人。
- 初稿は完成したが、言葉遣いや流れが自然か不安な人：客観的な校正で、プロフェッショナルなドキュメントに仕上げたい人。
# 日本語Markdownドキュメントの校正スキル 指定されたMarkdownファイルを読み込み、以下のガイドラインに基づいて校正を行い、修正案を提示します。 ## 校正の重点項目 ### 1. トーンと文体の確認 **文体は「ですます調」を使用**
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/imudak/maruhuku-contents" -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）学習の共有：他チームが同種問題を予防できるよう知見を記録します。実行時は既存のポストモーテムテンプレート確認→インシデント情報の多角的収集（会話・システムログ・コミット履歴）→必須情報確認→ドキュメント執筆という手順で進めます。