reviewer

AI エージェントが書いた Markdown などの文書に、GitHub の PR レビューのような行コメントとプロジェクト全体へのコメントを付け、フィードバックをファイルとしてエージェントに返すためのツールです。仕様は SPEC.md を参照してください。

ビルド

Go 1.25 以降と Node.js が必要です。

make build        # web/ をビルドして bin/reviewer を作る
make dist         # dist/<os>-<arch>/reviewer にクロスコンパイル
make test

make dist の対象は、既定では linux-amd64、linux-arm64、darwin-arm64、darwin-amd64 です。make dist DIST_TARGETS="linux-amd64" のように絞り込めます。Linux 向けは静的リンクです。

Web UI はバイナリに埋め込まれるので、リモートマシンにはバイナリを1つ置けば動きます。

scp dist/linux-amd64/reviewer devbox:~/bin/

macOSでHomebrewを使う

brew install ymotongpoo/macos/reviewer
brew services start reviewer
reviewer url

Homebrewのサービスはログイン時に自 10BC8 動起動します。停止は brew services stop reviewer、再起動は brew services restart reviewer です。sudo は不要です。reviewer service はLinuxのsystemd用なので、macOSでは brew services を使います。

設定は ~/.config/reviewer/config.toml を読み込みます。このMacからだけ接続する場合は、サービスの起動前に bind = "127.0.0.1" を設定してください。既定では全インターフェースで待ち受けます。ログは $(brew --prefix)/var/log/reviewer.log に保存します。エージェントのコマンドが見つからない場合は、グローバル設定にコマンドの絶対パスを指定してください。

使い方

サーバーを起動する

devbox$ reviewer serve            # ディレクトリの選択画面から始める
devbox$ reviewer serve ./docs     # ./docs を開いた状態で始める
reviewer dev
  Open: http://devbox.local:7777/?token=3f9a...
        http://192.168.1.10:7777/?token=3f9a...

表示された URL を手元のブラウザで開きます。mDNS（Bonjour / Avahi）が使える環境では、ホスト名でアクセスできます。既定では全インターフェースの IPv4 と IPv6 の両方で待ち受けます（--bind all）。このマシンからだけ開けるようにしたいときは --bind 127.0.0.1 を指定します。

トークンは初回起動時に ~/.local/state/reviewer/token に保存され、再起動しても変わりません。URL は reviewer url でいつでも表示できます。

常駐させる（systemd）

reviewer service install        # ~/.config/systemd/user/reviewer.service を作って起動する
reviewer service status | restart | uninstall
reviewer url                    # アクセス用の URL を表示する

ログアウト後やマシンの再起動後も動かし続けるには、sudo loginctl enable-linger $USER が必要です。未設定の場合は install のときに案内が出ます。

ディレクトリを開いて切り替える

トップページ（/）でレビューするディレクトリを選びます。

最近開いたディレクトリ：セッションごとに、ラウンドの状況とエージェントの送信先を一緒に表示します。
パス入力：~/ から始められ、Tab で補完できます。
ブラウズ：ディレクトリをたどって選べます。

開いたディレクトリは /p/<id>/ で表示されます。ブラウザのタブを分ければ、複数のディレクトリを同時に開けます。ヘッダーのディレクトリ名から、最近のディレクトリに切り替えることもできます。

ラウンドの履歴、コメント、エージェントの送信先は、そのディレクトリの .reviewer/ に保存されます。サーバーを入れ直しても、同じディレクトリを開けばそのまま続きから使えます。サーバーの外に持つのは、最近開いたディレクトリの一覧（~/.local/state/reviewer/projects.json）とトークンだけです。

開けるディレクトリは、既定ではホームディレクトリの中に限られます。変更するには、グローバル設定に roots = ["~/repos", "~/writing"] のように書きます。

1つのディレクトリで複数のレビューを進める（セッション）

zenn.dev.draft や event-talk-prep のように、1つのリポジトリに複数の本や登壇資料が入っていることがあります。それぞれを別のエージェントのスレッドで書いていると、レビューも別々に進めたくなります。そこで reviewer では、1つのディレクトリに複数のレビューセッションを作れます。

セッションごとに別々に持つもの：

ラウンドの履歴、コメント、返信
AI確認依頼と AI指摘
エージェントの送信先（バインドしたスレッド）と、その作業ログ
Git でコミットする変更（下記）

ディレクトリで共有するもの：

ファイルの表示と編集、Git のブランチとプッシュ
プリセット（.reviewer/presets.toml）と Git の設定（.reviewer/git.toml）

ヘッダーの「⎇ ブランチ名」から開く Git のダイアログには、そのセッションで変更したファイルだけを出します。セッションを始めたときから内容が変わっていて、次のどれかに当たるファイルが、そのセッションの変更です。

そのセッションでコメントを付けた
そのセッションのエディタで保存した
そのセッションのエージェントがラウンドに取り組んでいる間（提出してから返答を取り込むまでと、エージェントの実行中）に変わった

ほかの変更（別のセッションやツールによる変更、セッションを始める前からある変更）は一覧に出さず、コミットもしません。ダイアログには、その件数だけを示します。コミットに入るのは一覧のファイルの今の内容だけで、ほかにステージ済みの変更があっても、ステージしたまま残します。一覧が長いときは一覧の中をスクロールして見ます。

ヘッダーのディレクトリ名の右にある「📑 セッション名」から、セッションを切り替えたり、新しく作ったりします。新しいセッションは /p/<id>/s/<セッション>/ で開くので、ブラウザのタブを分ければ同時に進められます。セッションの名前の変更とアーカイブも同じメニューから行います。アーカイブしたセッションは一覧から隠れるだけで、データは残ります。メニューの「アーカイブ済み」から開いて「元に戻す」を押せば戻せます。

最初からあるセッションは「メイン」です。データは従来どおり .reviewer/ の直下に置くので、セッション機能より前のレビューはメインセッションとしてそのまま続けられます。追加したセッションのデータは .reviewer/sessions/<セッション>/ に置きます。エージェントに渡すフィードバックのパスもセッションごとに分かれるので、複数のエージェントが同時に返答を書いても混ざりません。

レビューの流れ

左のツリーからファイルを開き、行番号をクリックしてコメントします。Shift+クリックかドラッグで範囲を選べます。入力内容は自動で下書き保存されます。
Markdown ファイルでは、ファイルヘッダーの「プレビュー」を押すと右側にレンダリング結果を並べて表示します。オンオフの状態はブラウザに保存されます。
- ソースとプレビューは、上端に同じ行が来るように互いのスクロールに追従します。ソースのコメント欄はプレビューにはないので、ソースでコメント欄を通り過ぎる間はプレビューが止まって待ちます。そのため、コメントが多いほどプレビューのほうが先まで見えます。
- コメントと AI 指摘がある箇所は、プレビューでも本文をハイライトし、左端に縦線を表示します。縦線を押すと、ソース側のそのコメントへ移動します。プレビューで本文を見つけられない行（数式や HTML を含む行など）は、その段落全体を囲んで示します。
- frontmatter に emoji と type / topics があるファイル（Zenn の記事）と books/ 以下のファイルは、zenn-editor の zenn-markdown-html でレンダリングします。:::message、:::details、ファイル名付きコードブロック、数式、脚注などの Zenn 記法に対応しています。それ以外のファイルは GFM としてレンダリングします。どちらを使うかはプレビュー上部のメニューで切り替えられます。
- 数式は同梱の KaTeX で描画します。YouTube やツイートなどの埋め込みは読み込まず、リンクだけを表示します。
「± 修正案を挿入」で suggestion ブロックを挿入すると、選択範囲の置き換え案として扱われます。
プロジェクト全体へのコメントは「概要・全体コメント」に、ファイル全体へのコメントはファイルヘッダーの「ファイルにコメント」から書きます。
「レビューを提出」を押すと、.reviewer/rounds/<N>/feedback.md と feedback.json が書き出され、エージェント用の指示文がコピーされます。これをエージェントに貼り付けます。
エージェントがファイルを直して response.json を書くと、UI は自動で更新されます。エージェントの返答は各スレッドに表示されます。ファイル表示は常に現在の内容です。そのラウンドで何が直されたかは、概要ページのラウンド履歴にある「差分を見る」で確認できます。差分ページには、そのラウンドのコメントが提出時点の行位置に表示されます。解決済みにしたコメントはファイル表示から消え、差分ページでだけ見られます。
納得したコメントは「解決」に、そうでないものには「返信」します。コメントや返信を書くと次のラウンドが自動で始まり、解決していないコメントは次の提出に持ち越されます。

エージェントからの返答形式

{
  "round": 1,
  "responses": [
    { "id": "C-1", "status": "addressed", "message": "削除しました" },
    { "id": "C-2", "status": "wontfix", "message": "理由…" },
    { "id": "C-3", "status": "question", "message": "質問…" }
  ],
  "summary": "変更の概要"
}

形式は feedback.md の末尾にも書かれているので、エージェントには指示文を渡すだけで足ります。

その他のコマンド

reviewer status [DIR]                         # ラウンドと未解決コメントの件数
reviewer export [DIR] [--round N] [--format md|json]

モバイル（Android Chrome）で使う

モバイル対応は未完了（実機ゲート未実施）です。実機ゲート記録の項目は未検証で、自動テストは実機の代わりになりません。最終受け入れ E2E と実装後の性能評価も未実施です。

接続と公開 URL

Android からの接続には、Tailscale の MagicDNS と HTTPS を推奨します。同じ tailnet にサーバーと Android を接続し、Tailscale Serve でローカルの reviewer を公開する構成です。次のコマンドは設定例です。この実装作業では実行していません。

# サーバー側の例。Serve は別のターミナルで実行します。
reviewer serve --bind 127.0.0.1 --port 7777
tailscale serve --bg http://127.0.0.1:7777

Serve が表示する HTTPS URL を、グローバル設定の public_url に指定して reviewer を起動します。以下のホスト名は例なので、実際の URL に置き換えてください。

# ~/.config/reviewer/config.toml（[agent] などのテーブルより前に記述）
bind = "127.0.0.1"
port = 7777
public_url = "https://devbox.example.ts.net"

public_url には、トークン、クエリ、フラグメント、/p/<id>/ を含めず、サーバーのルート URL を指定します。末尾の / は除かれます。この設定は表示と通知に使う URL を指定するもので、HTTPS の設定や待ち受けアドレスの変更は行いません。

reviewer serve --public-url https://devbox.example.ts.net
reviewer url

--public-url は設定ファイルより優先します。--public-url= で、その起動だけ公開 URL の設定を無効にできます。起動表示と reviewer url は公開 URL を先頭に出し、従来の直接接続用 URL も続けて表示します。reviewer url はグローバル設定を読むため、起動時だけ渡した --public-url や別の --config の値は反映しません。両方の表示をそろえるにはグローバル設定に記述してください。未設定時の URL の順序と通知先は従来どおりです。

Android Chrome で、先頭に表示されたトークン付き URL を開いて認証します。通知のプロジェクト URL は公開 URL を基点に生成され、トークンを含みません。

接続項目	注意と確認状況
Tailscale の MagicDNS と HTTPS	Android からの到達性と、この経路での SSE は未検証（実機ゲート未実施）。D-NET-04、05 が対象です。
Discord などの通知リンク	Cookie は SameSite=Strict のため、別サイトから開いた最初の表示が 401 になることがあります。そのページの URL をもう一度開くか、Chrome のアドレスバーから直接開いてください。S-08 では別サイトからの遷移が 401、続く直接アクセスが 200 でした。Discord 内ブラウザーと Android Chrome での結果は未検証（実機ゲート未実施、D-NET-01）。
オリジンと認証	ホスト名、HTTP か HTTPS か、ポートを変えたら、新しい入口のトークン付き URL を開き直してください。Cookie が引き継がれない場合があります。Cookie 自体はオリジン単位の保存ではありませんが、ホスト名が変われば別の Cookie になり、reviewer の待ち受けポートを変えると Cookie 名も変わります。Chrome 再起動後の保持を含め、未検証（実機ゲート未実施、D-NET-05、06）。
トークン付き URL	認証情報なのでチャットに貼らないでください。認証後は URL からトークンを除くリダイレクトを行いますが、履歴や共有先に残らない保証はありません。実機でどこに残るかは未検証（実機ゲート未実施、D-NET-07）。
mDNS と LAN	Android の `.local` の名前解決は環境によって不安定なため、標準の入口には推奨しません。mDNS と LAN の IP による HTTP 接続は未検証（実機ゲート未実施、D-NET-02、03）。

タッチ操作

操作	手順	実機の確認状況
ファイルと補助操作	狭い画面では ☰ でファイル一覧を開き、ファイルをタップします。設定や AI 確認などはヘッダーの ⋯ から開きます。	未検証（実機ゲート未実施）。
行範囲コメント	開始行の行番号をタップし、終了行をタップして、画面下の選択バーで「コメント」を押します。1 行なら最初のタップ後に「この行にコメント」を押します。「解除」で選択を外せます。	未検証（実機ゲート未実施）。
行の編集	行の ✎、または 1 行を選んだときの「この行を編集」を押します。本文のダブルタップでは編集を開始しません。変更した行も ✎ から編集できますが、未保存の変更行へのコメントはできません。	Gboard の入力と確定後の操作は未検証（実機ゲート未実施、D-IME）。
文字範囲コメント	本文を長押しして選択し、ハンドルで範囲を調整して、画面下の選択バーで「コメント」を押します。ファイルが更新されると選択は解除されます。	Android 標準の選択メニューとの重なりを含め、未検証（実機ゲート未実施、D-SEL）。
プレビュー	幅 600px 未満では「プレビュー」を有効にすると「ソース」「プレビュー」のタブが表示されます。タブを切り替えても、上端に表示していた行がそのまま上端に来ます。600px 以上では左右分割です。	回転時を含め、未検証（実機ゲート未実施）。

下書きと既知の制限

コメントの保存に失敗したら、コメント欄の「再試行」「端末に保存して閉じる」「編集を続ける」から選びます。保存結果が不明なときは自動で再送しません。編集で「サーバーを確認」が出た場合は、その操作で内容を確認してください。提出前にはコメントの保存を待ちますが、返信は「下書き保存」を押す必要があります。キーボード表示中に各ボタンを押せるかは未検証（実機ゲート未実施、D-CMP）。

レビューコメントには PNG、JPEG、GIF の画像を添付できます。「画像を添付」から選ぶか、画像をコメント本文欄に貼り付けてください。1枚10 MiB、1件5枚かつ合計20 MiBまでです。添付画像は提出時にエージェントへ渡すフィードバックにも含まれます。

PWA、Service Worker、Web Push は未対応です。オフラインでのレビューや、オフライン中の変更を復帰後に自動送信する機能も未対応です。
端末に保存したコメントや編集の下書きは、その端末とブラウザーの同じオリジンでだけ復元できます。別端末や別の入口には移りません。ブラウザーのサイトデータを消すと失われます。Android のプロセス終了後の保持は未検証（実機ゲート未実施、D-LC-04）。
IndexedDB を利用できない場合はメモリーに保存し、端末への保存が使えない旨を表示します。この場合、再読み込み後には下書きを復元できません。
Gboard の日本語フリック入力、ローマ字入力、再変換、音声入力、変換中の別行移動や Undo は未検証（実機ゲート未実施、D-IME）。現在は行単位の編集を維持し、限定ブロック編集は導入していません。
縦横の切り替え、safe-area、画面分割、候補欄、フローティングキーボード、文字拡大は未検証（実機ゲート未実施、D-VP）。
バックグラウンドからの復帰、画面ロック解除、Wi-Fi とモバイル回線の切り替え後の SSE 再接続は未検証（実機ゲート未実施、D-LC-01〜03）。

エージェントへの直接送信

提出したフィードバックを、reviewer から直接エージェントの会話（セッション、スレッド）に送れます。送り先は、文書を書いたときの会話です。対応しているのは T3 Code と Hermes Agent です。既定（kind = "auto"）では、T3 Code が入っていれば T3 Code を、入っていなければ Hermes Agent を使います。

送信先はレビューセッションごとに選びます。1つのディレクトリで本ごとにセッションを分ければ、それぞれの本を書いているスレッドにフィードバックを送れます。

T3 Code

同じマシンで T3 Code のサーバーが動いていれば、準備は要りません。reviewer は ~/.t3/userdata/server-runtime.json からサーバーのアドレスを読み、T3 Code の MCP エンドポイント（/mcp）に接続します。

ヘッダーの「🤖 T3 Code: 送信先を選ぶ」を押すと、T3 Code のスレッドが新しい順に並びます。候補になるのは、レビューしているディレクトリと同じディレクトリ、その親、またはその中を作業ディレクトリにしている T3 Code プロジェクトのスレッドです。たとえば ~/repos/zenn.dev.draft を開くと、zenn.dev.draft のプロジェクトと、books/tinygo-otel-esp32 などの本ごとのプロジェクトのスレッドが並びます。サブエージェントのスレッドは並びません。
- 使えるスレッドがない場合や、新しいスレッドで始めたい場合は、「＋新しいスレッドを作る」から作って、そのまま送信先にできます。候補のスレッドが1つもないときは、この作成欄が最初から開いています。名前とモデルを選べます。名前を空欄にすると reviewer: <ディレクトリ名>（メイン以外のセッションでは後ろに ［<セッション名>］）になります。モデルは T3 Code の作成画面と同じ一覧から選び、初期値はこのディレクトリで最近使われたスレッドのモデルです。推論レベル（Reasoning）があるモデルでは、その値も選べます。選べる値はモデルごとに違い、初期値はモデルの既定値です。作ったスレッドは空なので、最初に提出したフィードバックが最初のメッセージになります。
「レビューを提出」のダイアログで「T3 Code に送信する」にチェックを入れたまま提出すると、そのスレッドにメッセージとして送ります。スレッドが作業中なら、作業が終わってから始まるように順番待ちにします。
概要ページの「🤖 T3 Code」パネルに、エージェントの返答と作業ログ（ツールの実行）が流れます。「停止」を押すと、T3 Code の実行を中断します。
T3 Code が承認や質問への回答を待っているときは、パネルにその旨を表示します。回答は T3 Code の画面でしてください。MCP からは承認に答えられないためです。
AI確認依頼で「新規セッション」を選ぶと、T3 Code に新しいスレッドを作ります。モデルと推論レベルは送信先と同じように選べます。

新しいスレッドを作る先は、レビューしているディレクトリを含む T3 Code プロジェクトのうち、いちばん内側のものです。そのようなプロジェクトがなければ作れないので、T3 Code でプロジェクトとして追加してください。推論レベル以外のモデルごとの設定（Codex のサービスティア、Claude の高速モードなど）は選べず、モデルの既定値になります。新しいスレッドの権限モードは、reviewer のトークンの上限（既定は full-access）です。

最初に接続するとき、reviewer は T3 Code の認可を自分で取得します。t3 auth pairing create で5分間有効なペアリングコードを発行し、それを T3 Code の OAuth 承認に使って、MCP クライアント用のトークン（有効期間30日）を受け取ります。ブラウザでの操作は要りません。トークンは ~/.local/state/reviewer/t3-token.json（パーミッション 600）に保存し、期限の1日前や T3 Code に拒否されたときに取り直します。発行したトークンは、t3 auth session list に「reviewer」というラベルで表示されます。

既定では、トークンの権限の上限を full-access にします。T3 Code では、上限より広い権限モードのスレッドにはメッセージを送れないためです。access を狭めると、それより広い権限モードのスレッドには送れなくなります。

開始と完了の通知は送りません。T3 Code のスレッドにそのまま実行が表示されるからです。Discord に通知したい場合は notify = "discord-webhook" を使います。

Hermes Agent

同じマシンで Hermes Agent の gateway が動いていれば、Hermes のセッション（Discord のスレッドなど）に送れます。T3 Code も入っているマシンでは、kind = "hermes" を指定します。

Hermes 側の準備（1回だけ）

~/.hermes/.env に次を追記して、gateway を再起動します。

API_SERVER_ENABLED=true
API_SERVER_KEY=<openssl rand -hex 32 で作った値>   # 16文字以上。短いと gateway が起動を拒否する

hermes gateway restart   # PATH に無ければ ~/hermes/hermes-agent/venv/bin/hermes
curl -s localhost:8642/health

API サーバーは既定で 127.0.0.1:8642 で待ち受けます。reviewer が同じマシンにあるので、LAN に公開する必要はありません。reviewer は ~/.hermes/.env から URL とキーを自動で読むので、reviewer 側の設定は要りません。

使い方

reviewer を起動すると、ヘッダーに「🤖 Hermes Agent: 送信先を選ぶ」と表示されます。クリックして、文書を書いたセッションを選びます。Discord のセッションが新しい順に先頭に並びます。
「レビューを提出」のダイアログで「Hermes Agent に送信する」にチェックを入れたまま提出します。
概要ページの「🤖 Hermes Agent」パネルに、エージェントの返答と作業ログがリアルタイムに流れます。
- 承認が必要な操作では、承認カードが出ます。「今回だけ許可」「拒否」などで答えます。
- 途中で止めたいときは「停止」を押します。
- 送り直したいときは「再送信」を押します。
開始時と完了時には、そのセッションの Discord スレッドに短い通知が投稿されます。Hermes の hermes mcp serve を経由して、gateway のボットが投稿します。
コメントごとの返答は、今までどおりエージェントが書く response.json から取り込みます。

指示文をコピーして手で渡す方法も、そのまま使えます。

設定

[agent]
kind = "auto"          # auto（T3 Code があれば T3 Code、なければ設定済みの Hermes）| t3 | hermes | none
auto_send = true       # 提出ダイアログの「送信する」の初期値
notify = "auto"        # auto（Hermes ならセッションのスレッドに投稿、T3 Code なら送らない）| hermes | discord-webhook | none

[agent.t3]
url = ""               # 空なら ~/.t3/userdata/server-runtime.json のサーバー
access = "full-access" # トークンの権限の上限。approval-required | auto-accept-edits | auto | full-access
token_env = "T3_MCP_TOKEN"  # この環境変数にトークンがあれば、自動の認可をせずに使う
command = ""           # t3 CLI のパス。空なら動いているサーバーのバイナリ、PATH の順に探す
home = ""              # T3 Code のデータディレクトリ。空なら $T3CODE_HOME か ~/.t3

[agent.hermes]
url = ""               # 空なら ~/.hermes/.env から自動検出
api_key_env = "HERMES_API_KEY"
profile = ""           # 指定すると /p/<profile>/ を使う
command = ""           # hermes CLI のパス。空なら PATH と ~/hermes/hermes-agent/venv/bin を探す

[agent.discord_webhook]
url = ""               # notify = "discord-webhook" のときに使う

注意

reviewer は既定で LAN から開けます。トークン付きの URL を知っている人は、エージェントに作業を依頼できます。T3 Code では、既定の full-access の権限で依頼できることになります。
T3 Code のトークンと Hermes の API キーはサーバー側だけで使い、ブラウザには渡しません。
reviewer の T3 Code のトークンが不要になったら、t3 auth session list で「reviewer」のセッション ID を調べて t3 auth session revoke <ID> で取り消し、~/.local/state/reviewer/t3-token.json を削除します。
API から送ったターンでは、危険と判定されたコマンドが Hermes の approvals.unattended_mode（既定は deny）によって自動的に拒否されます。reviewer の承認カードで答えられるのは、Hermes が承認を求めてきた操作だけです。

Hermes なしで試す

go build -o bin/fakehermes ./cmd/fakehermes
HERMES_HOME=/tmp/fh ./bin/fakehermes &          # 偽の API を 127.0.0.1:8642 で起動し、/tmp/fh/.env を書く
HERMES_HOME=/tmp/fh ./bin/reviewer serve ./docs

偽の Hermes は、途中で承認を1回求めます。その後、すべてのコメントに「対応済み」と返す response.json を書きます。

確認依頼を送ると、偽の Hermes は AI指摘を annotations.json に書きます。基本の2件に加えて、1行に複数の文がある行があれば、その2文目だけを直す指摘を2件（edits を使うものと、直した文だけを suggestion にしたもの）書きます。1件は行番号をわざとずらしてあり、quote による位置合わせを確かめられます。-modify-annotation-target を付けて起動すると対象ファイルに1行追記するので、確認中にファイルが変更されたときの警告を確かめられます。

エージェントに確認を依頼する（AI指摘）

レビューする前に、エージェントに文書を読ませて、確認が必要な箇所に指摘を付けてもらえます。たとえば、技術的に誤っていそうな箇所を探させ、その指摘を手がかりに自分でレビューします。エージェントが付けた指摘を、reviewer では AI指摘と呼びます。使うには、前節のエージェントとの連携（T3 Code か Hermes Agent）が必要です。

使い方

ヘッダーの「🔍 AIに確認を依頼」を押します。
プリセットを選ぶと確認内容が入るので、必要なら書き換えます。組み込みのプリセットは次の2つです。
- 「技術的な誤りの検出」：事実や技術仕様の誤りを、根拠の URL 付きで指摘するよう求めます。
- 「誤訳の修正」：開いているファイルを翻訳文として、原文と突き合わせて誤訳を指摘するよう求めます。原文は、同じリポジトリの翻訳元のファイル（content/ja/... に対する content/en/... など）か、文書の中の原文から探します。
対象範囲（全体、現在のファイル、選択したファイル）と送信先を選んで送ります。送信先の既定は新しいセッションです。「セッション名（空欄なら自動）」に名前を入力できます。空欄なら reviewer: docs Q-1 技術的な誤りの検出 のような名前を付け、同じ名前があれば末尾に (2) などを付けます。入力した名前がすでに使われている場合は、エラーを確認して別の名前を入力してください。執筆に使ったセッションに自分の文章を点検させたいときは、バインド済みのセッションを選びます。
概要ページの「AI確認依頼」に、作業ログがリアルタイムに流れます。承認カードと停止ボタンは、フィードバックを送ったときと同じように使えます。
完了すると、ファイル表示の行番号の横にマークが付きます。色は重要度（重大、要修正、軽微、確認推奨）、濃さは確信度を表します。マークを押すと、指摘の本文、根拠のリンク、修正案が開きます。
使える指摘は「採用」します。本文、修正案、根拠を含んだ自分の下書きコメントになるので、編集してから通常どおり提出できます。不要な指摘は「却下」します。却下した指摘は「却下済みも表示」から元に戻せます。

エージェントには、対象ファイルを変更しないよう指示しています。それでも確認中にファイルが変わった場合は、その依頼に警告と差分へのリンクが出ます。

確認依頼を何度か送ると、AI指摘は依頼ごとに蓄積されます。概要ページで依頼ごとに表示を切り替えたり、未採用の指摘をまとめて破棄したりできます。

プリセット

確認依頼のダイアログで「プリセットとして保存」を押すと、そのディレクトリの .reviewer/presets.toml に保存されます。どのディレクトリでも使いたいプリセットは、グローバル設定に書きます。

# ~/.config/reviewer/config.toml
[[presets]]
name = "用語の揺れ"
prompt = "同じ概念を指す用語の表記が揺れている箇所を指摘してください。"
scope = "all"          # all | current | selected

同じ名前のプリセットは、組み込み、グローバル、プロジェクトの順に後のものが優先されます。UI から編集や削除ができるのはプロジェクトのプリセットだけです。

エージェントが書く形式

エージェントは .reviewer/requests/<Q-n>/instructions.md を読み、annotations.json を同じディレクトリに書きます。形式は instructions.md に書かれているので、エージェントには reviewer が送る指示文だけで足ります。

{
  "request": "Q-1",
  "annotations": [
    {
      "path": "docs/ch1.md", "startLine": 12, "endLine": 12,
      "quote": ["この API は HTTP GET でデータを作成します。"],
      "severity": "major", "confidence": "high", "label": "must",
      "body": "GET は安全なメソッドとして定義されており、作成には POST を使います。",
      "evidence": [{ "url": "https://www.rfc-editor.org/rfc/rfc9110#section-9.2.1", "quote": "", "note": "" }],
      "suggestion": "この API は HTTP POST でデータを作成します。"
    }
  ],
  "summary": "全体の所見"
}

行番号がずれていても、quote を手がかりに位置を合わせます。

suggestion は、採用すると quote の行全体を置き換えます。行の一部（1行の中の1文など）だけを直す場合、エージェントは suggestion の代わりに edits を書きます。reviewer はそれを quote に当てはめ、行全体の置換案を作ります。

"edits": [{ "find": "3種類のシグナルの1つ", "replace": "3種類のシグナルのうちの1つ" }]

エージェントが suggestion に直した文だけを書いてきた場合も、そのまま採用すると同じ行のほかの文が消えてしまいます。そこで reviewer は取り込み時にこれを検出し、quote の中でいちばん近い文だけを差し替えて、行全体の置換案に補完します。補完できない場合は置換案にせず、本文に「修正案（該当部分のみ）」として残します。どちらの場合も、AI指摘のカードに注意書きが表示されます。

設定

~/.config/reviewer/config.toml（グローバル）と DIR/.reviewer/config.toml（プロジェクト）を読み込みます。port、bind、public_url、roots、agent はサーバー全体の設定なので、グローバル設定にだけ書きます。labels、exclude、prompt_template、anchor、data_dir は、プロジェクトの設定で上書きできます。

# ~/.config/reviewer/config.toml（サーバー全体の設定）
roots = ["~"]               # 開けるディレクトリ
port = 7777
bind = "all"                # 既定。"127.0.0.1" にするとこのマシンからのみ
public_url = ""             # 公開 URL。空なら従来の直接接続用 URL を使う
exclude = ["drafts/", "*.bak"]
prompt_template = "{{.FeedbackPath}} を読んで対応し、{{.ResponsePath}} に返答してください。"

[[labels]]
name = "must"
description = "必須"

[anchor]
fuzzy_threshold = 0.7

prompt_template では .Round .FeedbackPath .FeedbackJSONPath .ResponsePath .Project を使えます。

セキュリティ

既定では全インターフェースで待ち受けるので、同じネットワークの他のマシンから届きます。通信は HTTP の平文なので、信頼できる LAN か Tailscale などの内側で使ってください。このマシンからだけ開けるようにするには --bind 127.0.0.1 を指定します。起動のたびにランダムなトークンを発行し、トークン付き URL で認証します。固定したい場合は --token か REVIEWER_TOKEN を使います。
変更系の API には X-Reviewer ヘッダーを必須にしています（CSRF 対策）。
対象ディレクトリの外にあるパス、.git/、データディレクトリは読めないようにしています。

開発

reviewer serve ./sample --token dev     # API サーバー
cd web && npm run dev                   # Vite の開発サーバー（/api は 7777 番に中継する）

リリースを作る

make package VERSION=0.1.0

dist/release/ にWeb UIを埋め込んだ各OS・アーキテクチャ向けのアーカイブとSHA-256チェックサムを作ります。VERSION はバイナリの reviewer version にも反映されます。GitHub Releaseにアーカイブを添付し、Homebrew tap の Formula/reviewer.rb のURLとチェックサムを更新します。

Name		Name	Last commit message	Last commit date
cmd		cmd
docs		docs
internal		internal
web		web
.gitignore		.gitignore
Makefile		Makefile
README.md		README.md
SPEC.md		SPEC.md
go.mod		go.mod
go.sum		go.sum

Latest commit

History

Folders and files

Repository files navigation

reviewer

ビルド

macOSでHomebrewを使う

使い方

サーバーを起動する

常駐させる（systemd）

ディレクトリを開いて切り替える

1つのディレクトリで複数のレビューを進める（セッション）

レビューの流れ

エージェントからの返答形式

その他のコマンド

モバイル（Android Chrome）で使う

接続と公開 URL

タッチ操作

下書きと既知の制限

エージェントへの直接送信

T3 Code

Hermes Agent

Hermes 側の準備（1回だけ）

使い方

設定

注意

Hermes なしで試す

エージェントに確認を依頼する（AI指摘）

使い方

プリセット

エージェントが書く形式

設定

セキュリティ

開発

リリースを作る

About

Resources

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages