lark-hirono

Lark Hirono — Feishu ドキュメントツールキット

Markdown をスタイル付きの Feishu ドキュメントとしてアップロードし、既存のページを最適化し、取得・分析・ハイライト・検証します。

スキルファイルの場所

このスキルの関連ファイルは、この SKILL.md からの相対パスにあります。

• references/optimization-guide.md — ドキュメント変換の品質基準と参考パターン
• references/mermaid-guide.md — mermaid 図を生成するタイミングと方法、および一般的なパターンの例

CLI の実行

各セッションの開始時に、以下の手順を順番に試して、適切な呼び出し方法を一度だけ確認してください。

1. グローバルインストール — lark-hirono が PATH にあるか確認します。

   command -v lark-hirono
   

   見つかった場合は、すべてのコマンドで lark-hirono <action> [options] を使用します。 見つからない場合は、npm install -g lark-hirono でインストールし、npm update -g lark-hirono で最新バージョンに更新します。

2. ローカルの開発リポジトリ — クローンした lark-hirono リポジトリ内（"name": "lark-hirono" を含む package.json があるディレクトリ）で作業している場合に限り、依存関係がインストールされていることを確認し（npm install）、次を実行します。

   npx tsx bin/lark-hirono.ts <action> [options]
   

以下の例では lark-hirono を省略形として使用しています。確認したコマンドに置き換えてください。

初回セットアップ

初めて使用する前に、以下の手順を一度実行してください。各手順は、次の手順に進むための前提条件です。

1. lark-hirono をインストールする

npm install -g lark-hirono

2. lark-cli をインストールする

lark-hirono は、すべての Feishu API 操作で lark-cli バイナリ（>= 1.0.9）をサブプロセスとして呼び出します。まだインストールされていない場合は、次を実行します。

mkdir -p /tmp/larkcli && cd /tmp/larkcli
npm init -y && npm install @larksuite/cli
node node_modules/@larksuite/cli/scripts/install.js

または、既存の lark-cli バイナリを指すように LARK_CLI 環境変数を設定します。

インストールを確認します。

lark-cli --version   # should print >= 1.0.9

3. lark-cli を設定する

lark-cli が Feishu API の呼び出しに使用するアプリの認証情報を初期化します。

lark-cli config init

対話形式のセットアップが始まります。プロンプトに従って、Feishu アプリの ID とシークレットを入力してください。アプリのセットアップとスコープの詳細については、lark-shared スキル（lark-cli config init / lark-cli auth login）を参照してください。

4. 認証する

lark-hirono auth login --domain docs
# or equivalently: lark-cli auth login --domain docs

Feishu OAuth のためにブラウザーが開きます。ログイン後、トークンは lark-cli によってキャッシュされます（通常は ~/.config/lark/ 内）。

認証を確認します。

lark-hirono auth status

トークンの有効期限が切れている場合は、auth login を再実行してください。

5. オプションの設定ファイル

プロジェクトディレクトリに lark-hirono.json を作成すると、Wiki スペース、ノード、バックグラウンドモードのデフォルト値を設定できます。このファイルは任意です。すべての値は CLI フラグでも指定できます。

前提条件の概要

• Node.js 20+
• lark-cli >= 1.0.9（インストールおよび認証済み）
• lark-hirono.json 設定ファイル（任意。Wiki スペース／Wiki ノードのデフォルト値に使用）

データの保存場所

• 設定ファイル：現在のディレクトリまたは親ディレクトリにある lark-hirono.json
• トークンキャッシュ：lark-cli が管理（通常は ~/.config/lark/ 内）
• キーワードのバッチ：highlight extract によって生成される <input.md>.keywords_batch_N.json
• 選択済みキーワード：highlight extract によって生成される <input.md>.selected_keywords.json（LLM の出力で、パイプラインで使用）

引数

$ARGUMENTS は ACTION [ARGS...] の形式にしてください。

ユーザーの意図からアクションを判断します。

ユーザーの意図	アクション
ローカルの Markdown を Feishu にアップロードする	upload <input.md>
既存の Feishu ドキュメントを最適化する	スキルのワークフロー（取得 → 編集 → アップロード）
ローカルファイルから Feishu ドキュメントを更新する	optimize --doc <id> --input <file>
Feishu ドキュメントを Markdown として取得する	fetch --doc <id>
ドキュメントの構造を分析する	analyze <input.md>
LLM 用に表のタイトルを抽出する	highlight extract <input.md>
キーワードのハイライトを適用する	highlight apply <input.md> <keywords.json>
Feishu ドキュメントの品質を検証する	verify --doc <id>
認証を管理する	auth <subcommand>

---

Action: upload

ローカルの Markdown ファイルを、スタイル設定された Feishu ドキュメントとしてアップロードします。

lark-hirono upload <input.md> [title] [options]

オプション:

• --title <title> — ドキュメントのタイトル（デフォルト：最初の H1）
• --wiki-space <id> — Wiki スペース ID
• --wiki-node <id> — 親ノード ID
• --bg-mode <mode> — 見出しの背景：light | dark
• --image-dir <dir> — ダウンロードした画像のディレクトリ
• --strip-title — 最初の H1 見出しを削除
• --no-highlight — キーワードのハイライトをスキップ
• --frontmatter-as-callout — YAML frontmatter を Meta コールアウトに変換（blockquote → Feishu コールアウト）。このフラグを指定しない場合、frontmatter は変更されずにそのまま渡されます。
• --mention-map <path> — ドキュメント URL をキーとする JSON マップ：{ "<url>": { "obj_token": "…", "obj_type"?: 22, "title"?: "…" } }。アップロード後、キーに一致する text_run リンクはネイティブの mention_doc 要素に書き換えられ、Feishu のバックリンクパネルとグラフビューに反映されます。
• --verify — アップロード後に取得して検証
• --dry-run — 前処理のみを実行し、Markdown を標準出力に表示
• -v, --verbose — 詳細ログ

入力形式に関する注意:

• [^name] のインライン脚注参照と [^name]: body の定義は自動検出され、Unicode の上付き文字（⁽¹⁾…）と末尾の ## Footnotes セクションに書き換えられます。冪等であり、脚注の定義がない入力には何も行いません。フェンス付きコードブロック内の内容は変更されません。

catalog_table ドキュメントの場合（Code/Title 列を持つテーブル）：

1. 最初に highlight extract input.md を実行します
2. JSON を LLM に送信し、.selected_keywords.json として保存します
3. ファイルが存在する場合、アップロード時にキーワードが自動的に適用されます

例:

lark-hirono upload my-doc.md "My Document" --wiki-space 123456

---

Action: optimize

Feishu Wiki ドキュメントを控えめに最適化します。作成者の口調、文体、意図を保ちながら、誤りの修正、破損の修復、書式の改善を行います。

基本原則：元のドキュメントを最優先します。参照ドキュメントは書式構造の指針としてのみ使用します。大幅な書き換えや再構成は決して行いません。

出力：最適化したバージョンを含む新しい Wiki サブページを、参照ドキュメントの下に作成します。

仕組み：このスキルは CLI コマンド（fetch、upload、analyze）をツールとして使用し、破損の検出、強調の判断、品質監査には LLM の判断を適用します。

引数

• SOURCE_URL：最適化する Feishu Wiki の URL。例：https://my.feishu.cn/wiki/Abc123
• DEST_URL（任意）：書式が適切な参照ドキュメントの URL。親ノードの下に新しいページが作成されます

URL からの ID の抽出:

• Wiki URL https://my.feishu.cn/wiki/Abc123XYZ → ドキュメント／ノード ID は Abc123XYZ（/wiki/ の後のパスセグメント）
• この ID を --doc、--wiki-node CLI フラグに使用します

ワークフロー

以下のタスクを順番に実行します。

1. ソースを読む — ソースドキュメントを取得して内容を理解します
2. 参照を読む — 参照ドキュメントを取得して書式を分析します
3. 書式を分析する — 構造を比較し、書式の不足箇所を特定します
4. 内容を確認する — 事実誤認、不完全な説明、軽微な問題を特定します
5. 最適化したバージョンを生成する — 控えめな改善を適用します 5.5. 内容保持の監査 — 内容が削除または短縮されていないことを確認します 5.6. 強調の監査 — 色や太字の密度が適切であることを確認します 5.7. レンダリングレイアウトのリグレッションチェック — 視覚的なリグレッションがないことを確認します
6. Feishu に書き込む — 最適化した内容で新しいサブページを作成します

タスク 1：ソースドキュメントを読む

lark-hirono fetch --doc <source-doc-id>

出力全体を保存します。これが最適化するドキュメントです。

注意深く分析します： トピック、目的、文体／口調、見出し構造、内容の流れ、書式のパターン、および保持しなければならない技術的な内容（数値、数式、システム、デプロイに関する事実、実験設定、引用、但し書き）。タスク 5 に向けて、分析結果を記録します。

タスク 2：参照ドキュメントを読む

lark-hirono fetch --doc <reference-doc-id>

出力全体を保存します。これは書式の参照用であり、内容の情報源ではありません。

書式のみを分析します： 見出しの階層、セクション構成、書式の規則（太字、リスト）、内容の密度、構造要素（区切り線、引用、コードブロック）。

タスク 3：フォーマット分析

詳細な比較フレームワークと既知のフォーマット規則については、[references/optimization-guide.md](/references/optimization-guide.md) をお読みください。

参照ガイドの適用方針：

• 最適化ガイドはスタイルの参考資料であり、ドキュメント全体のスタイルを一新する許可ではありません
• 明らかなフォーマット上の欠陥がない限り、ソースドキュメントの大枠の構成を維持してください
• ソースに一貫した見出し階層がある場合、参考パターンに合わせるためだけに見出しの番号を振り直したり、階層を深くしたりしないでください
• 冒頭のブロック、メタデータブロック、概要のレイアウトがすでに機能している場合は、再設計よりも軽微な整理を優先してください

ソースドキュメントを、以下の具体的なフォーマット規則に照らして確認してください。

規則	想定されるパターン
冒頭のコールアウト	[!callout] に説明と論文／リポジトリへのリンクを含める
番号付き見出し	## 1 标题／### 1.1 子标题
見出しグループ	ドキュメント全体を通して番号を連続させる
見出しレベルの競合	グループ／章のタイトルと下位項目を適切なレベルにする
コールアウト／引用	全体を通して |>／[!callout]／> 📌 を自由に使用する
コードブロックのタグ	すべてのコードブロックに言語タグを付ける
重要用語の太字	重要な技術用語は初出時に太字にする
インライン強調	重要なポイントには {red:...}、重要な用語には {green:...} を使う

厳守事項：

• ソースに一貫した階層構成がある場合、番号付き見出しが必須だと決めつけないでください
• 例外：中国語の序数を使った見出しは常に欠陥です：## 一、、## 二、、## 三、…は、ツールの青色番号表示の対象にならない漢字を使用しています。必ず ## 1 Title、## 2 Title…の形式に変換してください。これは任意ではありません。
• 参考資料の方が細分化されているという理由だけで、サブセクションを追加しないでください
• 同じ見出しレベルの兄弟見出しは、すべて番号付きにするか、すべて番号なしにする必要があります。 番号付きの兄弟見出しの中に番号なしの見出しが1つだけある場合（例：## Cheatsheet）、次の連番を付けてください。
• 冒頭のレイアウト、メタデータのレイアウト、文書冒頭の概要レイアウトは、過剰な編集によって後退が生じやすい重要な領域です

重要：フォーマット上の違いのみを指摘してください。内容のトピックは比較しないでください。

タスク 4：内容のレビュー（最小限の修正）

フォーマットにかかわらず修正すべき問題がないか、ソースドキュメントを確認してください。

修正する項目：

• 事実誤認：技術情報の誤り、バージョン番号の誤り、リンク切れ
• 説明の不備：途中で終わっている文、説明の欠落、TODO／プレースホルダーテキスト
• 明らかな誤り：スペルミス、意味を変えてしまう文法上の誤り
• フォーマットの破損：閉じられていない Markdown、箇条書きのインデントの不統一
• Feishu エクスポートによる破損：段落が見出しになっている、見出し階層の破損、内容の結合

変更しない項目：

• 著者の文体：くだけた文体の場合は、くだけた文体を維持してください
• 内容の重点：特定のトピックが強調されている場合は、その重点を尊重してください
• 技術的な意見：ツールやアプローチが推奨されている場合は、その推奨を維持してください
• 元の構成：参考フォーマットと明らかに矛盾する場合に限り、構成を調整してください
• 詳細度：あるトピックの説明が簡潔でも、それには理由がある場合があります

タスク 4.5：Mermaid 図（可能な範囲で対応）

パターン、ルール、配置例については、[references/mermaid-guide.md](/references/mermaid-guide.md) をお読みください。

判断：このドキュメントに図が役立つかどうかを判断してください。複数段階のパイプライン、システムアーキテクチャ、分岐アルゴリズム、またはプロセスフローについて説明している場合は、Mermaid ブロックを1つ作成し、冒頭のコールアウトの後、最初の見出しの前に配置してください。参照用の表、FAQ、カタログ、またはフロー構造のないドキュメントでは省略してください。判断に迷う場合は省略してください。不適切な図を追加するより、図を追加しない方が適切です。

すべての視覚的なスタイル設定はパイプラインが自動的に処理します。記述するのは構造だけです。

---

タスク 5：最適化版の生成

重要：執筆を始める前に、このセクションを注意深くお読みください。

80/20 ルール

最適化後のドキュメントは、原文と80％以上同一である必要があります。変更は書き換えではなく、さりげない改善にとどめてください。

変更する内容：

1. 冒頭のコールアウト — 物語性のあるドキュメント（文章が中心で、表が少ないもの）では必須です。catalog_table または data_table のドキュメントでは省略してください。

   • 見出しより前の最初のブロックとして記述します。
   • 書式：<callout emoji="ICON" background-color="light-blue" border-color="light-blue"> — アイコンを選びます（例：gift、bulb、bookmark、pushpin、rocket、star）。
   • ドキュメントの導入文／概要説明を中に入れ、</callout> で閉じます。
   • 原文にドキュメントを説明する導入段落、引用ブロック、概要セクションがある場合は、その内容をコールアウト本文として再利用するか、軽く最適化してください。新しい概要文を作成しないでください。
   • 該当する内容がない場合は、ドキュメントの主題と対象範囲から1～3文の概要を作成します。
   • パイプラインの安全策：パイプラインは代替手段として最初の段落から自動挿入します。内容と絵文字を制御できるよう、必ず明示的に記述してください。

2. 見出しの再構成 — 必要に応じて番号付けと階層を修正します。

   • 連続した通し番号を適用します。最上位は ## 1、## 2…、第2階層は ### 1.1、### 1.2…とします。
   • 入力形式：## 1 Title のように記述します（番号の後にスペース、その後にタイトル — Markdown にはピリオドを付けません）。パイプラインは単一レベルの番号にピリオドを自動追加します。## 1 Title → 青色の番号付きで 1. Title と表示されます。複数レベルの番号（### 1.1 Sub）にはピリオドは追加されません。
   • 中国語の序数を修正します。## 一、标题 → ## 1 标题
   • 破損を修正：見出しになってしまった段落は、段落に戻します。
   • 階層を維持：構造に問題がない限り、見出しのレベルを追加または削除しないでください。

3. 強調を追加 — {red:...} と {green:...} マーカーを適用します。

   • 赤色の強調：重要な結論、結果、重要な主張（長いドキュメントでは10～20箇所）。
     • 太字のフレーズ：{red:**important conclusion**} → 太字＋赤色で表示されます。
     • プレーンテキスト：{red:term} → 赤色で表示されます。
     • インラインコード：{red:`cmd`} → 赤色のコードとして表示されます。
   • 緑色の強調：重要な専門用語の初出（5～10箇所）。
     • プレーンテキスト：{green:term} → 緑色で表示されます。
     • インラインコード：{green:`code`} → 緑色のコードとして表示されます。
   • 重要 — 取得したドキュメントの生の <text color> タグを変換してください：取得したドキュメントに含まれる生の <text color="green">BF16</text> HTML は、アップロードされたドキュメントでは表示されず、プレーンテキストとして表示されます。最適化時に、すべての <text color="COLOR">CONTENT</text> を省略形の {green:CONTENT}、{red:CONTENT} などに変換してください。内容が太字の場合は、太字を内側に配置します（{green:**CONTENT**}）。生の <text color> 形式を最適化後の出力に残さないでください。
   • 既存の強調をすべて維持：原文の {red:...}、{green:...}、**bold** は、すべて最適化後のバージョンに引き継ぐ必要があります。既存の強調を削除せず、新しい強調を追加してください。
   • 重要な表示ルール：太字は色タグの内側に配置します（{red:**text**} とし、**{red:text}** にはしないでください）。見出しに $formula$ を含めないでください。$formula$ の境界を ** で囲まないでください。すべてのパターンについては、optimization-guide の「Rendering Pitfalls」を参照してください。

4. インラインのコールアウトを追加する — ドキュメント本文の重要なポイントに、Markdown の引用ブロックを挿入します。

   • 重要なポイントには > 📌 **标题**: ... を使用します。
   • 背景知識には > 📚 **背景**: ... を使用します。
   • 目安：長いドキュメント全体に 5〜15 個の引用ブロックを挿入します。
   • パイプラインによる自動変換：TL;DR、核心思想、关键结论、一句话总结、核心区别 などに一致する引用ブロックは、自動的に <callout> XML に変換されます。これらに対して <callout> XML を手動で記述しないでください。> TL;DR: ... のように記述し、パイプラインによる変換に任せます。
   • 重要 — <callout> XML の本文に絵文字を付けないでください：<callout> XML ブロックを直接記述する場合、本文を絵文字（📌、💡、📚 など）で始めないでください。開始タグの emoji= 属性がすでにアイコンを指定しているため、本文にも絵文字を付けるとアイコンが重複して表示されます。絵文字を先頭に付ける必要があるのは、パイプラインで自動変換される > 📌 **Title**: ... 形式の引用ブロックだけです。
   • 重要 — <callout> XML を入れ子にしないでください：Lark は、別の <callout> XML ブロック内に入れ子になった <callout> XML ブロックを表示できません。ソースドキュメントにこの形式が含まれている場合、内側の <callout> ブロックを通常の段落に変換してください（開始タグと終了タグを取り除き、テキストはそのまま残します）。<callout> の本文内にある Markdown の引用ブロックは問題ありません。入れ子のコールアウトには該当しません。

5. コードブロックを修正する — 言語タグがない場合は追加します。

6. 事実誤認を修正する — 誤字、リンク切れ、誤った情報を修正します。

7. 画像、表、数式をそのまま保持する — <image token>、<lark-table>、<equation> タグは、元の位置で変更せずにコピーします。<equation> を $...$ に書き換えないでください。|lark-table ...| のようにパイプで囲んだ形式は出力せず、<lark-table> XML または標準の Markdown 表を使用します。正しい形式と誤った形式の詳細については、[references/optimization-guide.md](/references/optimization-guide.md) の「Verified Syntax Reference」を参照してください。

   • 重要 — 数式：_{\text{...}} のような裸の LaTeX 下付き文字を、$...$ または <equation> の区切りの外に書かないでください。裸の _ は斜体として解釈されます。複数の下付き文字に関する不具合：1 つの数式に _{...} が 2 個以上あると、lark-cli が _ を斜体の開始・終了として扱い、表示が壊れます。回避策として、中括弧を使わない 1 文字の下付き文字（_p、_h）を使用してください。数式ごとに _{...} が 1 個だけであれば問題ありません。
   • 重要 — lark-table のセル：下線を含む文字列（例：***sm__throughput***）に ***太字斜体*** を使用すると、lark-cli が *** 内の _ を誤って解釈し、表示が壊れます。下線を含むメトリクス名には、バッククォートのコード形式（`sm__throughput`）を使用してください。

8. <quote-container> の扱い — lark-cli によるアップロードは <quote-container> に対応しておらず、警告なしに削除されます。パイプラインによって自動変換されます：表の外では引用ブロックに、表の中では灰色の <callout> に変換されます。そのまま残すか、手動で変換してください。

変更してはいけないこと：

• 文体を整えるために段落を書き換えないでください。
• セクションを追加したり、既存のセクションを削除したりしないでください。
• 技術的な詳細や推奨事項を変更しないでください。
• ドキュメントの論旨の流れを組み替えないでください。

タスク 5.5：コンテンツ保持の監査

重要：Feishu に書き込む前に、コンテンツが失われていないことを確認してください。

最適化後のバージョンをソースと比較します。

• すべてのセクションが含まれている（セクションが削除されていない）
• すべての段落が含まれている（段落が抜けていない）
• すべてのコードブロックが含まれている（コードが削除されていない）
• すべての表が含まれている（データが失われていない）
• すべてのリンクが保持されている（リンクが削除されていない）
• 技術的な詳細がそのまま保持されている（数値、数式、コマンド）
• すべての <image token="..."> タグが含まれている（ソースと出力の数を比較し、欠落がないことを確認）
• すべての <equation> ブロックが含まれ、変更されていない（数式を書き換えたり、分割したりしない）

コンテンツが欠落している場合：元に戻してください。最適化後のバージョンには、元のコンテンツが 100％含まれている必要があります。

タスク 5.6：強調の監査

強調の密度が適切であることを確認します。

• 赤色の強調：長いドキュメントでは10～20箇所（または文書の長さに比例した数）
• 緑色の強調：初出の専門用語に5～10箇所
• 強調しすぎていない：1段落あたりの強調項目が3つ以下
• 強調が不足していない：重要な結論が強調されている

タスク 5.7：レンダリングレイアウトのリグレッションチェック

最適化したドキュメントで視覚的なリグレッションが発生しないことを確認します。

• 見出しが正しくレンダリングされる（階層が適切）
• コードブロックに言語タグが設定されている
• 表がレンダリングされる（Markdown の表構文が適切）
• コールアウトがレンダリングされる（引用構文が適切）
• 閉じられていない Markdown 構文がない

タスク 6：Feishu への書き込み

ソースがローカルファイルの場合（例：report.md）：最適化した内容を report_upload.md（同じディレクトリ内、_upload サフィックス）に書き込みます。元のファイルは絶対に変更しないでください。/tmp/ パスは絶対に使用しないでください。

ソースを Feishu から取得した場合：任意の使いやすい一時ファイルに書き込みます（例：カレントディレクトリ内の <title>_upload.md）。

# Step 1: Write optimized content to upload file
# For local source report.md → use report_upload.md
cat > report_upload.md << 'OPTIMIZED_CONTENT_END'
[optimized markdown content here]
OPTIMIZED_CONTENT_END

# Step 2: Upload — default is always to create a new sibling page
lark-hirono optimize --doc <doc-id> --input report_upload.md --new \
  --title "Optimized: [Original Title]"

# Only update in place if the user explicitly asked to overwrite the original:
# lark-hirono optimize --doc <doc-id> --input report_upload.md

--new フラグを指定すると、同じ親ノードの下に兄弟ページが作成されます。下記の検証手順で使うため、返された URL／doc-id を記録してください。

タスク 7：アップロード後の検証（必須）

アップロード後、ユーザーに報告する前に、レンダリングされたドキュメントにリグレッションがないことを確認してください。

lark-hirono verify --doc <new-doc-id>

次の項目を確認します。

• コールアウトがある（説明文書の場合）
• 見出し番号が連番で、中国語の序数がない
• \# のアーティファクトがない（エスケープされたハッシュがテキストに漏れていないこと。パイプラインでは ZWSP を使用）
• <text color> のプレーンテキストタグがコンテンツに表示されていない
• コンテンツ量が妥当である（ソースより大幅に短くなっていない）

問題が見つかった場合 → ローカルのアップロードファイルを修正し、--new を指定して再アップロードするか（作成済みページの ID があればそのページを上書きし）、再度検証します。最大 合計3回 まで繰り返します。

検証に合格した後（または3回の試行を使い切った後）、次の内容をユーザーに報告します。

1. 新しいページの URL
2. 変更内容 — 適用した書式改善の簡潔な一覧
3. 信頼度 — 変更内容への確信度。再試行後も未解決の問題があれば記載

---

アクション：fetch

Feishu ドキュメントを Markdown として取得します。

lark-hirono fetch --doc <doc-id> [--output file.md]

オプション：

• --doc <id> — ドキュメント ID（必須）
• --output <file> — ファイルに保存（デフォルト：標準出力）

--output を指定しない場合、Markdown を標準出力に出力します。

---

アクション：analyze

Markdown ドキュメントの構造を分析します。

lark-hirono analyze <input.md>

次の内容を含む JSON を返します。

• document_type — narrative | data_table | catalog_table | mixed
• heading_count — 見出しの数
• table_count — 表の数
• table_rows — 表の合計行数
• suggested_modules — 推奨される変換

---

アクション：highlight

LLM によるキーワード選択用に表のタイトルを抽出するか、Markdown にキーワードを適用します。

抽出

lark-hirono highlight extract <input.md> [--batch-size N]

表から Code／Title 列を抽出し、次のファイルとして保存します。

• input.md.keywords_batch_0.json
• input.md.keywords_batch_1.json（タイトルが200件を超える場合）

次の手順： JSON ファイルを LLM に送信し、応答を input.md.selected_keywords.json として保存します。

適用

lark-hirono highlight apply <input.md> <keywords.json> [--inplace]

表のタイトル内のキーワードを {red:**keyword**} タグで囲みます。

注： .selected_keywords.json が存在する場合、upload と optimize は自動的に適用します。

---

アクション：verify

Feishu ドキュメントを取得し、品質を検証します。

lark-hirono verify --doc <doc-id>
lark-hirono verify <doc-id>          # positional form

オプション：

• --doc <id> — ドキュメント ID（位置引数で渡さない場合は必須）
• -v, --verbose — 詳細出力

次の内容を報告します。

• ブロック／見出し／表の数、見出しの背景色の適用率
• 赤色のハイライトと太字のヘッダーの数
• 残存する HTML タグ（空であること）
• 構造およびコンテンツレベルの期待値に対する合否チェック

すべてのチェックに合格すると終了コード 0、いずれかのチェックに失敗すると 1 を返します。

---

アクション：auth

Feishu 認証の管理（lark-cli へのパススルー）。

lark-hirono auth login
lark-hirono auth status

---

ドキュメントの種類

Narrative — 見出しがある、テキスト中心のドキュメント

• 変換：正規化、見出し、コールアウト
• LLM は不要です

Catalog_table — Code／Title 列があり、50 行以上のテーブル

• 変換：正規化、テーブル、キーワードの強調表示
• キーワードの選定に LLM が必要です

Data_table — 50 行未満のテーブル

• 変換：正規化、テーブル
• LLM は不要です

---

ワークフローの例

Narrative ドキュメントをアップロードする

lark-hirono upload my-article.md

キーワード付きの Catalog_table ドキュメントをアップロードする

lark-hirono highlight extract catalog.md
# Send catalog.md.keywords_batch_0.json to LLM
# Save response as catalog.md.selected_keywords.json
lark-hirono upload catalog.md

既存の Feishu ドキュメントを最適化する

lark-hirono optimize --doc CcKqdWjF2o2UzixXZDecXxvInyc

ローカルファイルから Feishu ドキュメントを更新する

lark-hirono optimize --doc CcKqdWjF2o2UzixXZDecXxvInyc --input local.md

フロントマターとネイティブのバックリンクを含むノートをアップロードする

# mentions.json is a JSON object keyed by doc URL:
# { "https://www.feishu.cn/wiki/<node_token>": { "obj_token": "<obj_token>" } }
lark-hirono upload post.md \
  --frontmatter-as-callout \
  --mention-map mentions.json

アップロード後、mentions.json 内の URL への Markdown リンクはネイティブの Feishu ドキュメントメンションになり、リンク先ドキュメントのバックリンクパネルに表示されます。

---

関連ファイル

• references/optimization-guide.md — 品質基準と参考パターン
• references/mermaid-guide.md — Mermaid ダイアグラムのパターンと例