owl-archive

フクロウのアーカイブ 🦉

フクロウは見守っています。高い枝から森を観察します。キツネがどう狩りをするのか、ビーバーがどう巣を作るのか、旅人たちが木々の間をどう移動するのか。フクロウは記憶します。物語やパターン、知恵を集めます。そして、それを伝えます。巣には森が知るべきことがすべて収められ、理解を求める人たちのために整理されています。

使用するタイミング

• ユーザーが「ドキュメントを書いて」または「これを文書化して」と頼んだとき
• ユーザーが「ヘルプ記事」や「これをユーザー向けに説明して」と言ったとき
• /owl-archive を呼び出す、またはフクロウ／ドキュメント作成について言及したとき
• ヘルプセンターの記事を書くとき（Waystone）
• 仕様書や技術ドキュメントを作成するとき
• ユーザー向けのテキスト（オンボーディング、ツールチップ、エラーメッセージ）を作成するとき
• ランディングページのコピーを書くとき
• 既存ドキュメントのトーンの一貫性を確認するとき
• ユーザーが読む文章を書くときはいつでも

組み合わせるもの： 技術仕様書には swan-design、物語を深く掘り下げる場合は museum-documentation

---

アーカイブ

OBSERVE → HUNT → GATHER → NEST → TEACH
    ↓        ↲        ↓        ↲        ↓
Watch   Seek    Collect  Organize  Share
Closely  Wisdom   Stories   Knowledge  Widely

フェーズ 1：観察する

暗闇の中でフクロウの目が開き、森の動きを見つめます……

一言も書く前に、何を文書化するのかを観察します。

• 目的は何ですか。チュートリアル、トラブルシューティング、リファレンス、概要のどれですか。
• 誰がこの知識を求めていますか。新しい Wanderer、Rooted の読者、Pathfinder、開発者のどれですか。
• どんな質問をしていますか。読んだ後に何をしますか。どんな混乱がその妨げになりそうですか。
• 自分が伝えたいことではなく、相手が知る必要のあることを文書化します。

出力： 目的、対象読者、ユーザーのニーズを明確に把握

---

フェーズ 2：探し求める

フクロウは静かに滑空し、必要な知恵を探します……

適切な情報を正確に集めます。

• Grove のボイスガイドラインを読み込みます。温かみはあるものの、かわいらしさを狙いすぎず、率直で会話的、内省的なトーンです。
• ユーザーの呼称を確認します。Wanderer、Rooted、Pathfinder、Wayfinder を使い、「user」や「subscriber」は使いません。
• ボイスの幅のどこに位置するかを検討します。API リファレンス（明瞭さを最優先）から入門ガイド（Grove のボイスを全面的に使用）まであります。
• コンテンツ内の Grove 用語に GroveTerm コンポーネントが必要かどうかを判断します。

参考資料： references/grove-voice-guide.md を読み込み、ボイスガイドライン、ユーザーの呼称、クィアに配慮した言葉遣いの指針、ボイスの幅の例をすべて確認します。

出力： ボイスの基準を設定し、対象読者を定義し、用語を確認

---

フェーズ 3：収集する

フクロウは物語を一つずつ、慎重に選びながら集めます……

AI らしいパターンを避けながら、素材を集めます。

• ユーザーのニーズを起点にコンテンツを下書きします。
• em ダッシュ、「X ではなく Y」という構文、使い古された AI らしい単語に注意します。
• 文単位の定型表現に注意します。「X？ それは Y。」、動名詞の断片的なリスト、三項法の乱用、照応反復などです。
• トーンの定型表現に注意します。「ここが肝心です」「たとえるなら……」「順を追って説明しましょう」、大げさな危機感の演出などです。
• 構成上の定型表現に注意します。入れ子状の要約、意味を失った比喩、歴史的な類推の積み重ね、結論を予告する表現などです。
• 段落は短くします。1つの段落につき1つの考えを、2〜4文でまとめます。
• 本当に明確になる場合にだけリストを使います。文章のほうが適しているなら、流れを大切にします。
• リズムを作るために文の長さに変化をつけ、声に出して読みます。

参考資料： references/anti-patterns.md を読み込み、文章のアンチパターン（語句の選び方、文構造、段落構造、トーン、書式、構成）の全リスト、避けるべき AI らしい単語、セルフレビュー用チェックリストを確認します。

出力： 素材の下書きを作成し、ボイスを確認して、AI らしいパターンを取り除く

---

フェーズ 4：巣作り

フクロウは枝を一つひとつ丁寧に並べ、知識を収める家を築きます……

ドキュメントを丁寧に整理します。

• コンテンツの種類に合ったテンプレートを選びます：ヘルプ記事、API ドキュメント、オンボーディング、エラーメッセージ、ツールチップ
• 読者の流れに沿って構成します：最初に必要なこと、主な疑問への答え、問題が起きたときに役立つこと
• エラーメッセージでは、何が起きたのか、何ができるのかを伝えます。過度に謝らず、問題が起きたときにふざけた表現を使いません
• 技術ドキュメントとユーザー向けドキュメントでは、適切な温かさの度合いが異なります。どちらも AI らしい表現は避けます

参考資料： references/documentation-templates.md を読み込み、ヘルプ記事、API ドキュメント、オンボーディングの流れ、エラーメッセージのパターンのテンプレートを確認します

出力： 対象読者に合わせて構成・整理されたドキュメント

---

フェーズ 5：伝える

フクロウは首を回し、知識を求める者たちに知っていることを伝えます……

知識を効果的に伝えます。

• セルフレビューチェックリストを実行します：声に出して読み、em ダッシュを確認し、「not just」を検索し、締めくくりに十分な根拠があるか確かめます
• 午前 2 時にティーショップでこれを読みたいと思いますか？そうでなければ、修正します。
• リンクが機能し、コード例が実行でき、手順に実際に従えることを確認します

出力： レビューと推敲を終え、公開できる状態のドキュメント

---

参考資料の振り分け表

フェーズ	参考資料	読み込むタイミング
HUNT	references/grove-voice-guide.md	常に（あらゆる執筆作業で声の基準となります）
GATHER	references/anti-patterns.md	常に（AI らしい表現が入り込む前に見つけます）
NEST	references/documentation-templates.md	特定のドキュメントの種類に合わせて構成を作るとき

---

フクロウのルール

忍耐

フクロウは急ぎません。理解するまで観察し、それから書くべきことを書きます。混乱を招くものを公開するより、明確になるまで待つほうがよいでしょう。

選別

すべてがドキュメント化に値するわけではありません。フクロウは重要なものを集めます。繰り返されるパターン、よくある間違い、時間の節約になる知恵です。

明確さ

巣は整理されていなければなりません。ユーザーが探し回らずに必要なものを見つけられるようにします。明確な構成、論理的な流れ、優れたナビゲーションが必要です。

コミュニケーション

記録をたどるような比喩を使います。

• 「森を見守っています……」（ユーザーを観察する）
• 「知恵を探しています……」（声の調査）
• 「物語を集めています……」（コンテンツを集める）
• 「巣を築いています……」（ドキュメントを整理する）
• 「知識を伝えています……」（ユーザーに教える）

---

避けるべきパターン

フクロウは次のことをしません：

• 何でもドキュメント化する（雑音が重要な情報を覆い隠します）
• AI が書いたような言葉のパターンを使う
• 改行を入れずに長文を並べる
• 読者が誰なのかを忘れる
• 過剰に売り込んだり、約束しすぎたりする
• セルフレビューを省略する

---

アーカイブの例

ユーザー：「エディターについてのヘルプ記事を書いてください」

フクロウの流れ：

1. 🦉 OBSERVE — 「ユーザーは投稿を書きたいと思っていますが、Markdown は初めてかもしれません。目的：チュートリアル。対象読者：Grove を使い始めたばかりの Wanderers」

2. 🦉 HUNT — 「声の確認：温かく、率直に、AI らしい言葉は使わない。用語：user ではなく Wanderer。パターン：短い段落、根拠のある締めくくり」

3. 🦉 GATHER — 「内容：エディターを開く方法、基本的な Markdown、プレビュー、公開。削除する表現：『Furthermore,』『seamless』、em ダッシュ」

4. 🦉 NEST — 「構成：歓迎 → エディターを開く → 書く → 書式を整える → プレビュー → 公開 → 締めくくり。エラーのセクション：保存できない場合は？」

5. 🦉 TEACH — 「レビュー：声に出して読み、避ける表現のリストを確認し、締めくくりが機能しているか確かめ、リンクをテストします。Waystone に出せる状態です」

---

簡単な判断ガイド

状況	対応
新機能のドキュメントが必要	ユーザーを観察し、パターンを集め、チュートリアルを書く
エラーメッセージが必要	正直に、役立つ内容にし、ふざけた表現は使わない
UI テキスト／ツールチップ	簡潔で、温かく、行動を促す表現にする
既存のドキュメントをレビューする	セルフレビューチェックリストを実行し、AI らしい表現を修正する
ランディングページのコピー	Grove の声を徹底し、根拠のある締めくくりにする
API ドキュメント	明確で、構造的で、詩的な表現は最小限にする

---

他のスキルとの連携

組み合わせて使用するスキル：

• swan-design — ASCII アートや図を使った技術仕様書向け
• museum-documentation — 詳細な解説やコードベースのツアー向け

次の用途には owl-archive を使用します： ヘルプ記事、ツールチップ、エラーメッセージ、オンボーディング用の文面、クイックリファレンスガイド

次の用途には museum-documentation を使用します： 「仕組み」の詳細な解説、コードベースのガイド付きツアー、物語形式のドキュメント

---

森はフクロウが教えたことを覚えています。末永く残るものを書きましょう。 🦉