Agent Skills by ALSEL
汎用ドキュメント⭐ リポ 308品質スコア 94/100

knowledge-base

このスキルは、ヘルプセンターのアーキテクチャ設計、サポート記事の執筆、検索とセルフサービスの最適化が必要な場合に活用できます。ナレッジベース、ヘルプセンター、サポート記事、セルフサービス、記事テンプレート、検索最適化、コンテンツ分類、ヘルプドキュメントの設計・管理に関するあらゆるタスクで動作します。

description の原文を見る

Use this skill when designing help center architecture, writing support articles, or optimizing search and self-service. Triggers on knowledge base, help center, support articles, self-service, article templates, search optimization, content taxonomy, and any task requiring help documentation design or management.

SKILL.md 本文

SKILL.md 日本語翻訳


name: knowledge-base version: 0.1.0 description: > ヘルプセンターアーキテクチャの設計、サポート記事の作成、または検索と セルフサービスの最適化を行うときにこのスキルを使用します。ナレッジベース、ヘルプセンター、サポート記事、セルフサービス、記事テンプレート、検索最適化、コンテンツタクソノミー、およびヘルプドキュメント設計または管理が必要なタスクでトリガーされます。 tags: [knowledge-base, help-center, self-service, articles, documentation, experimental-design, writing, performance, search] category: operations recommended_skills: [customer-support-ops, internal-docs, technical-writing, second-brain] platforms:

  • claude-code
  • gemini-cli
  • openai-codex license: MIT maintainers:
  • github: maddhruv

主要な原則

  1. 読むのではなくスキャンするために書く - ユーザーは特定の問題を持って到着し、答えをスキャンします。短い段落、番号付きステップ、キーワードの太字、明確な見出しを使用します。長々とした文章は誰も読まない記事です。すべてのセクションは2秒のスキャンで見つけられるべきです。

  2. 構造はユーザーのメンタルモデルを反映する - コンテンツを製品の内部機能構造ではなく、ユーザーが完了しようとするタスクと経験する問題の周辺で整理します。「チームメイトを招待するにはどうすればいいですか?」は「ユーザー管理 > 招待 > 招待の作成」より優れています。ユーザーはメニューではなく成果について考えます。

  3. 検索がプライマリナビゲーション - ほとんどのユーザーはカテゴリツリーを閲覧することはありません。クエリを入力して最初に妥当な結果をクリックします。すべての記事タイトル、概要、キーワードセットは、製品チームが内部で使用する言葉ではなく、ユーザーが実際に入力する言葉に対して最適化される必要があります。

  4. ページビューではなくデフレクションを測定する - ページビューは何を見ているかを示します。デフレクションはそれが機能したかどうかを示します。チケット数対ヘルプセンタートラフィック、記事の評価、失敗した検索、記事表示後のお問い合わせクリック数を追跡します。高トラフィックの記事で高いお問い合わせ率を持つ記事は失敗している記事です。

  5. 無慈悲に保守する - 古い記事は記事がないことより悪いです。虚偽の自信を生じさせ、「記事に従ったが機能しなかった」というサポートチケットを生成します。すべての記事は所有者、レビュー日、機能が変わったときに廃止または削除とマークするための明確なプロセスが必要です。


コアコンセプト

情報アーキテクチャ

情報アーキテクチャ(IA)は、コンテンツがどのように整理、ラベル付け、リンクされるかです。優れたIAは、ユーザーがヘルプセンターホームページから2クリック以内で答えを見つけることができることを意味します。

タクソノミー設計原則:

  • トップレベルカテゴリは製品機能ではなくユーザーの目標にマップします
  • 5~8個のトップレベルカテゴリがナビゲーションが圧倒的になる前の実用的な最大値です
  • 各記事は正確に1つのプライマリカテゴリに属します(クロスリンクは問題ありません。デュアルホーミングはメンテナンスの負債を生成します)
  • カテゴリ名は平易な言語を使用します:「Revenue Operations」より「Billing & Payments」がよいです
  • サブカテゴリは1レベルの特異性を追加します - 2レベルを超えるネスティングを避けます

タクソノミー検証テスト: カテゴリ構造を、それを見たことのない5人のユーザーに見せます。一般的な特定のタスクをどこで探すかを聞きます。5人中4人以上が正しいカテゴリを見つけられない場合、ラベルを再設計します。

記事タイプ

タイプ目的ユーザーの主な意図
ハウツータスクのステップバイステップの指示「Xを実行したい」
トラブルシューティング特定のエラーまたは症状を診断および修正する「Xが壊れているか機能していない」
FAQ一般的な質問への短い答え「Xについて簡単な質問があります」
リファレンス完全な仕様、オプションテーブル、または用語集「Xのすべての値/設定を知る必要があります」
コンセプト機能またはワークフローを高レベルで説明する「使用する前にXがどのように機能するかを理解したい」

ほとんどの記事はハウツーまたはトラブルシューティングである必要があります。ナレッジベースがほぼコンセプト記事である場合、ユーザーは実行可能な答えを見つけていません - 彼らはロックを解除する代わりに教育されています。

検索最適化

ナレッジベースの検索はセマンティック理解ではなくキーワードマッチングとランキングです(AI駆動の検索でも、明示的な最適化が引き続き有効です)。

3層キーワード戦略:

レイヤー1 - タイトルキーワード: ユーザーが何をしたいか知っている時に入力する言葉
                          (「パスワードをリセット」、「サブスクリプションをキャンセル」、「CSVをエクスポート」)

レイヤー2 - 同義語:      同じコンセプトの代替用語
                          (「リセット」 = 「忘れた」、「変更」、「復旧」)
                          (「キャンセル」 = 「アカウント削除」、「アカウント閉鎖」、「登録解除」)

レイヤー3 - エラー文字列: ユーザーが検索にコピーペーストする正確なエラーメッセージ
                          (「Error 403: Forbidden」、「SMTP認証失敗」)

検索ツールの同義語辞書に同義語を格納して、両方の用語が同じ結果に解決されるようにします。ユーザーに「正しい」用語を推測させないでください。

デフレクションメトリクス

デフレクションは、ナレッジベースで答えを見つけてサポートチケットを開かないユーザーの割合です。ナレッジベースのプライマリヘルスメトリクスです。

デフレクション率の公式:

デフレクション率 = 1 - (KBアクセス後にオープンされたチケット / 合計KBアクセス)

追跡する補助メトリクス:

メトリクス測定内容健全な目標
デフレクション率全体的なKB有効性> 70%
記事評価(サムズ)記事ごとの満足度> 80% ポジティブ
失敗した検索率ゼロ結果を返すクエリ< 10%
記事表示後のお問い合わせクリック率解決に失敗した記事記事あたり < 5%
記事の古さ(レビューからの日数)コンテンツの鮮度< 180日
検索からクリック率検索結果がクリックされる頻度> 60%

一般的なタスク

ヘルプセンターアーキテクチャ - タクソノミーを設計する

ステップ1: チケットデータを掘り下げる

90日間のサポートチケットを引き出し、各チケットに関連する機能ではなくユーザーの基本的な目標をタグ付けします。ボリュームの上位10個の目標がカテゴリの候補になります。

ステップ2: カードソート検証

8~10人の代表的なユーザーに20~30個の記事タイトルをカード上に与えます。記事をカテゴリにグループ化し、各グループに名前を付けるよう求めます。8人中6人以上のグループ化に現れるパターンは検証されたカテゴリです。

ステップ3: 階層を構築する

レベル0: ヘルプセンターホーム
レベル1: 5~8個の目標ベースカテゴリ  (例「はじめに」、「請求」、「アカウント設定」)
レベル2: レベル1あたりのサブカテゴリ  (例「請求 > インボイス」、「請求 > 支払い方法」)
レベル3: 個々の記事

ステップ4: 既存コンテンツをマップする

新しいタクソノミーに対してすべての既存記事を監査します。各記事について:保持、マージ、再作成、またはアーカイブします。古い記事は移行しないでください - 移行はコンテンツを保持する価値があるかどうかを決定する強制的な機能です。

効果的なサポート記事を書く - テンプレート

完全なテンプレートについては、記事タイプ別に references/article-templates.md を参照してください。

普遍的な執筆ルール:

  • タイトル形式:動詞+目的語+オプションコンテキスト。「パスワードリセット」ではなく「パスワードをリセットする」
  • 最初の文:記事が何をカバーし、誰のためかを正確に述べます
  • ステップは番号付きリストを使用します。サブステップはインデントされた番号付きリストを使用します
  • UI配置があいまいなステップにはスクリーンショットとビデオを追加します
  • UI要素の最初の提及を太字にします:「変更を保存」をクリック
  • すべての記事は「これは役に立ちましたか?」評価とサポートへのリンクで終わります

長さのターゲット:

記事タイプターゲット単語数
ハウツー150~400語
トラブルシューティング200~600語
FAQ答えあたり50~150語
リファレンス必要な限り;ナビゲーションにアンカーリンクを使用

検索を最適化する - キーワードと同義語

キーワード監査ワークフロー:

  1. 過去30日間の失敗した検索をエクスポート(ゼロ結果またはゼロクリックのクエリ)
  2. 同様の失敗した検索を同義語グループにクラスター化
  3. 各クラスタについて:関連記事が存在しますか?はい場合、同義語を追加します。いいえ場合、コンテンツバックログに追加します。
  4. 低クリック率の検索をエクスポート(結果が表示されたがクリックされていない) - これはタイトルの不一致を示します
  5. 低クリッククエリでユーザーが使用する言語と一致するように記事タイトルを書き直します

同義語辞書の構築:

グループ:パスワード
同義語:パスワードを忘れた、パスワードをリセット、パスワードを変更、アカウントを復旧、
       ロックアウト、ログインできない、ログインヘルプ

グループ:アカウント削除
同義語:アカウント削除、アカウント閉鎖、登録解除、アカウント削除、
       サブスクリプション停止、[製品名]を終了

グループ:請求
同義語:インボイス、レシート、料金、支払い、クレジットカード、サブスクリプション費用、価格

新しい失敗した検索データを使用して、同義語辞書を四半期ごとにレビューおよび拡張します。

デフレクション率を測定および改善する

デフレクション測定セットアップ:

  1. ヘルプセンターにセッションの追跡を装備します
  2. 「デフレクションイベント」を定義します:ユーザーがKBをアクセスし、同じセッション内で「サポートに連絡」をクリック またはチケットをオープンしない
  3. 「失敗イベント」を定義します:ユーザーがKBをアクセスしてチケットをオープン またはサポートに連絡をクリック
  4. 計算します:デフレクション率 = デフレクションイベント / (デフレクション + 失敗イベント)

デフレクション改善プレイブック:

問題シグナル根本原因対策
高い失敗検索率記事の欠落または不正なキーワード不足しているコンテンツを書く;同義語を追加
特定の記事での高いお問い合わせ率記事が問題を解決しないより明確なステップで書き直す;エッジケースを追加
特定の記事での低い評価コンテンツが間違った、古い、または混乱している現在の製品に対して監査;書き直す
全体的に低いデフレクション不正なIA;ユーザーが記事を見つけられないカードソートを実行;タクソノミーを再構成

記事タイプ別テンプレートを作成する

references/article-templates.md を参照してください:

  • ハウツー記事
  • トラブルシューティング記事
  • FAQ記事
  • リファレンス記事

の既製テンプレートについて。

メンテナンスワークフローを構築する

コンテンツ所有モデル:

すべての記事は指名された所有者(チームではなく個人)を持たなければなりません。所有者は関連する機能が変わるときと定期的なペースに記事をレビューする責任があります。

レビュー頻度:

記事タイプレビュー頻度
ハウツー(頻繁に変わる機能)60日ごと
ハウツー(安定した機能)180日ごと
トラブルシューティング90日ごと
リファレンス(仕様/設定テーブル)60日ごと
FAQ90日ごと

メンテナンスワークフロー:

トリガー:   機能リリース、製品変更、またはスケジュールされたレビュー日
ステップ1:  所有者は各ステップを現在の製品に対して検証します
ステップ2:  スクリーンショット、ステップコピー、およびオプション名を更新します
ステップ3:  記事メタデータの「最後にレビュー」日をバンプします
ステップ4:  記事が削除された機能をカバーする場合:削除しないでアーカイブ
            (外部リンクは壊れます;アーカイブ記事は通知にリダイレクトすべき)
ステップ5:  重大な変更については、進行中のチケット向けにサポートチームに通知

古さ検出オートメーション: 「最後にレビュー」日がレビュー閾値を超えた記事にフラグを立てるスクリプトまたは統合を設定します。これらを記事所有者に送信される毎週の「コンテンツヘルス」レポートにパイプします。

製品内ヘルプを実装する - 文脈付きガイダンス

文脈付きヘルプは、ユーザーが製品から離脱することなく、必要な瞬間に製品内で正しい記事を提供します。

文脈付きヘルプパターン:

パターン使用時期実装
ツールチップ1つのフィールドまたはオプションを説明フィールドの横の?アイコン;最大1~2文
インラインヘルプテキスト入力の下の永続的なヒント静的テキスト;自明でない要件に使用
ヘルプパネル複雑なフォームまたはワークフロー用ステップバイステップガイダンススライドアウトパネル;完全なKB記事にリンク
空状態リンク初回使用時にユーザーをガイド空状態に「最初のXを追加する方法」
エラーメッセージリンクインラインエラーからトラブルシューティングにリンク「Error 403.[なぜこれが起こるか説明を見る]」

文脈付きヘルプコピーのルール:

  • 二人称で書く:「このプランでは最大5人のチームメンバーを追加できます」
  • システムが何をするかではなく、ユーザーが何ができるかを述べます
  • 2文以上を必要とするものについて完全なKB記事にリンク
  • ツールチップに完全な記事を複製しない - 要約してリンク

アンチパターン

アンチパターン失敗する理由代わりにすること
機能/メニューパスで整理ユーザーは製品構造を知りません - 彼らは問題を知りますユーザーの目標で整理;記事本文でのみ機能名を使用
ハウツーステップの散文段落執筆ユーザーは散文をスキップしてステップを見落とします;より多くのチケット発生各ステップで1つのアクションを含む番号付きリストを使用
UI ラベルをタイトルに逐語的にコピーUIラベルはスペース用に設計され、検索性のためではないユーザーが完了しようとするタスクの周辺でタイトルを書く
同義語辞書がない異なる言葉を使用するユーザーはゼロ結果を取得同義語辞書を構築および保守;月次レビュー
成功を測定するページビュー不正な記事の高ビューは成功に見えるデフレクション率と記事評価を測定;ページビューは見栄え
古い記事をアーカイブしないユーザーは古い指示に従い、製品のせいでチケットをオープン削除または大きく変わった機能の記事を1スプリント内にアーカイブ

落とし穴

  1. 失敗した検索データは最も価値のあるシグナルであり、ほとんどのチームが無視する - ほとんどのヘルプセンター分析ダッシュボードはページビューと記事評価を表示します。最高シグナルのデータは失敗した検索(ゼロ結果またはゼロクリックを返すクエリ)です。これらはヘルプを探して空で去ったユーザーです。このレポートを週次で引き出し、コンテンツギャップバックログとして扱います。

  2. ユーザーのメンタルモデルではなく製品機能構造で整理するとバウンス率が高くなる - ユーザーが「Workspace Settings > Members > Invitation Flow」のようなカテゴリを見たときに、彼らは問題(「誰かを追加するにはどうすればいいか」)を製品の内部タクソノミーに翻訳する必要があります。3秒でカテゴリを見つけられないユーザーは去ってチケットをオープンします。常にカテゴリ名を起動前に実ユーザーで検証します。

  3. SEO用に書かれたが、スキャン用ではないタイトルは検索でのクリック率が低い - 「アカウント設定でのパスワード管理の完全ガイド」のようなタイトルは冗長で、アクションを埋めます。「パスワードをリセット」を検索してスキャンしているユーザーは、これらの言葉をタイトルで見る必要があります。タイトルを短く、動詞最初、ユーザーが検索時に入力する正確な言語と一致させておきます。

  4. 古い記事の高い評価は虚偽のヘルス信号を生成する - 回避策を見つけたか、自力で解決したユーザーは、部分的に間違っていても、しばしば記事をポジティブに評価します。記事の古さ追跡(最後のレビューからの日数)は評価と並行して実行する必要があります - 変わる機能で18ヶ月レビューされていない4つ星記事はまだ負債です。

  5. セッションレベルの追跡がないと、デフレクション率の低下は見えない - 「オープンされたチケット/合計KBページビュー」ではなくセッションレベルでデフレクションを測定する場合、チケットをオープンしたユーザーも最初にKBをアクセスしたかどうかを判断できません。セッションレベルの追跡(ユーザーはKBをアクセスしてから同じセッション内でチケットをオープン)は唯一の正確な失敗シグナルです。


リファレンス

詳細なテンプレートとパターンについては、references/ から関連ファイルを読み込みます:

  • references/article-templates.md - 注釈付き例を含むハウツー、トラブルシューティング、FAQ、リファレンス記事の既製テンプレート

リファレンスファイルは、現在のタスクがそれを必要とする場合にのみ読み込みます。


コンパニオンチェック

このスキルが会話で最初に有効化されるとき:コンパニオンスキルをインストールしているかを ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null を実行して確認します。結果をこのファイルの frontmatter の recommended_skills フィールドと比較します。欠落しているものについては、一度それを言及し、インストールを提供します:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>

recommended_skills が空であるか、すべてのコンパニオンが既にインストールされている場合はスキップします。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
mkurman
リポジトリ
mkurman/zorai
ライセンス
MIT
最終更新
2026/5/11

Source: https://github.com/mkurman/zorai / ライセンス: MIT

本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: mkurman · mkurman/zorai · ライセンス: MIT