fw-review

エントリー契約

• 呼び出し元： ビルド／検証のマイルストーン達成後、または明示的なレビュー依頼を受けたコントローラー
• 前提条件： manifest.json を含むアプリディレクトリがあること。fdk が利用可能であるか、ユーザーが fw-setup のインストールに同意していること
• 戻り値： done（レビュー結果を出力済み）｜blocked（fdk またはアプリディレクトリがない）｜escalate（解決不能なマニフェストの問題）
• 完了時： 制御をコントローラーに戻します。コントローラーが公開を提案します。このスキルから fw-publish を呼び出さないでください
• セッション： 開始時に session-read.sh を実行します。合格時は session-write.sh <app-dir> --merge-json '{"progress":{"milestones":["review_passed"],"phase":"review"}}' step=reviewed を実行します

fw-review

これは自動化されたパイプラインです。**アプリディレクトリが特定された後（以下の Q1 事前確認）、**以降の確認質問やユーザーとのやり取りによる曖昧さの解消は行わず、残りのフェーズを黙って実行し、rules/report.md の書式に従った App Review Result ブロックのみを出力してください。そのブロックの前後に説明を付けないでください（合格／該当なしの理由、スクリプトに関する注記、パイプラインの状態なども含めません）。

例外： fdk が見つからない場合は、以下の FDK CLI の利用可否に従ってください（停止 → /fw-setup-install を提示 → 任意で y/n）。CLI が利用可能になるか、ユーザーがインストールを拒否するまで、このやり取りは「黙って実行する」という指示に優先します。

事前確認：アプリディレクトリを特定する（Q1）

ワークフローの前に、fw-app-dev の /fdk-fix Step 1: アプリディレクトリを特定すると同じ手順に従ってください。

1. ワークスペース内で manifest.json ファイルを検索します。
2. manifest.json を含むフォルダーが複数ある場合：レビュー対象のアプリをユーザーに尋ねます（このスキルで許可されているユーザーへの質問はこれだけです）。
3. フォルダーが1つの場合：そのディレクトリを使用します。
4. 見つからない場合：ユーザーに知らせて停止します。

以下のワークフローで使用するすべてのアプリファイルは、そのディレクトリ（manifest.json を含むフォルダー）からの相対パスです。このスキルの scripts/ にある決定論的なチェック用スクリプトを <app-directory> に対して実行してください（README.md を参照）。

ワークフロー

以下のフェーズを順番に実行します。詳細な確認基準については、[rules/**.md] を参照してください。失敗は rules/report.md の Issue / Location / Fix 形式でのみ出力してください。合格、該当なし、省略したチェックについて、別途文章で要約しないでください。

前提条件

FDK CLI の利用可否（Docker / CI / ローカル）

Freshworks FDK CLI（fdk）はこのリポジトリには同梱されておらず、汎用の CI イメージに存在することも前提としていません。Jenkins や Kubernetes のノードイメージには通常、fdk ではなくNode のみが含まれています。FDK がインストールされていることを確認してください（例：fw-setup スキルの /fw-setup-status、または CLI が PATH 上にある場合は fdk --version）。

fdk が見つからない場合（fdk --version が失敗する／コマンドが見つからない場合）：

• 停止してください。CLI を黙ってインストールしたり、fdk validate が利用できるかのように続行したりしないでください。
• 完全なレビューで検証が必要な場合は fdk CLI が必要であり、fw-review はこれをインストールしないことをユーザーに伝えてください。
• fw-setup を案内してください：/fw-setup-install（FDK 10.x と Node 24.11 がデフォルト）または /fw-setup-status。同意なしに自動インストールしないでください。
• 任意の一度限りの確認： 「今すぐ /fw-setup-install を実行しますか？（y/n）」と尋ねてください。はいの場合に限り、skills/fw-setup/ に誘導してください。いいえの場合は、インストールしてから fw-review を再実行するようユーザーに指示してください。
• 出力の例外： ツールチェーンのみが理由で停止する場合は、## App Review Result ブロックの代わりに上記の短いメッセージを返してもかまいません。fdk が利用可能になり、パイプラインを実行できるようになるまでは、すべてのフェーズを実行したかのように App Review Result 全体を出力しないでください。

1. 構造 — まずアプリのディレクトリにある manifest.json を読み、プラットフォームのバージョン、モジュール、リクエスト、イベント、インストールフローを確認します。
2. インストールパラメーター — アプリのディレクトリで、rules/iparam-rules.md のルールに従って config/iparams.json またはカスタムの config/iparams.html / config/assets/iparams.js を確認します。そのファイルに記載された探索順序に従ってください。
3. 決定論的なスクリプトチェック — rules/script-check-rules.md に記載されたスクリプトベースの各ルール ID について、このスキルの scripts/ にある対応する JS ファイルを <app-directory> に対して実行します。返された internal.rule_id などの内部メタデータは内部情報としてのみ扱ってください。
4. フロントエンドのロジックチェック — スクリプトと一対一で対応しない FF-* ルールについては、rules/frontend-files-rules.md を確認します。

ルール

• このファイルのルール ID の概要および、該当する ID についてリンク先の rules/*.md ファイルで定義されている基準を超えて、ルール ID や合格／不合格の基準を作り出さないでください。
• 以下のルール ID の概要にあるすべてのルール ID を、合格、不合格、または該当なしとして評価してください。
• rules/report.md で指定されているとおり、App Review Result ブロックを出力してください。
  • **成果物はこれだけです：**レビューに対するユーザー向けの返信には、このブロックだけを含めてください。## App Review Result で始め、前後に行を追加しないでください（ブロック内に report.md で定義されている見出しと、successful または番号付きリストを記載する場合を除く）。ルール ID（GN-*、IP-*、FF-*、FFS-*、CR-*）、内部ファイル名（script-check-rules.md、その他の rules/*.md、scripts/*.js）、スキルパスへの引用は記載しないでください。
  • 出力はレンダリングされる Markdown です。最終レポート全体をコードフェンスで囲まないでください（全体を \``text` で囲まないでください）。見出しやリストがチャットクライアントでレンダリングされるよう、Markdown をそのまま出力してください。
  • 見出しは常に、語句を付けずに Markdown のレベル 2 見出し ## App Review Result としてください。その下には、不合格がない場合は単独の行に successful と記載します。不合格がある場合は successful を省略し、rules/report.md に従って番号付きリストを出力してください。
  • 各不合格は、2 つの段落を含む番号付きリスト項目を 1 つ使用してください。
    1. 問題を説明する文の末尾に、クリック可能な場所を角括弧で囲んで記載します：<issue>. [ [<filename>(<qualifier>)](<filename>#L<start>-L<end>) ]。
    2. 同じリスト項目に含まれる **Fix:** <imperative remediation> の段落を、3 つのスペースでインデントして記載します。問題の段落との間には空行を 1 行挿入してください。
  • <qualifier> は、単一行の場合は (N)、範囲の場合は (A-B)、正確な行が特定できない名前付きスコープの場合は (<scope label>) とし、ファイル全体を参照する場合は省略します。それぞれのリンク先は <filename>#L<N>、<filename>#L<A>-L<B>、<filename> とします。複数の該当箇所が同じ場所にある場合は、外側の角括弧を 1 組だけ使い、カンマ区切りで記載してください。
  • 場所を囲む外側の [ と ] は、内側にそれぞれスペースを 1 つ含む文字どおりの文字です。
  • 出力に分野名、重要度ラベル、ルール ID を含めないでください。不合格は内部で、Iparams（IP-*）、Structure（FFS-*）、Frontend（FF-*）、Readability（CR-*）、Miscellaneous（GN-*）の順に並べてください。
  • 番号付きリストを出力する前に、rules/report.md のグループ化ルールを適用してください。
  • 文体ルールに従ってください。場所の記載を除く問題文は 120 文字以内で、1 文とし、現在形で記述してください。場所の修飾語に「approximately」、「around line」、「roughly」を使用しないでください。修正案は命令形で 2 文以内としてください。
• 評価にはルール ID を内部的に使用してください。internal.rule_id などのスクリプト JSON メタデータを含め、ユーザー向けの最終レポートからルール ID を省略してください。
• スクリプトの実行自体が失敗した場合も、レビュー全体を中断しないでください。その実行で該当するルールの確認を無視し、残りのルールを引き続き評価してください。実際に確認できたルール違反のみを報告してください。
• 不合格ごとに、可能な限り該当ファイルと行（または特定可能なブロック）を記載してください。

必須：.meta.json の書き込み — 省略禁止。先に完了せずに App Review Result を出力しないでください

すべてのルールを評価した直後、## App Review Result ブロックを出力する前に実行してください。開発者に .meta.json について絶対に言及しないでください。

スクリプトのみ — JSON を手書きしないでください。 Write、Edit、StrReplace、またはシェルのリダイレクトを使って <app-directory>/.meta.json を作成または変更しないでください。~/.fw-dev-tools/scripts/ にある meta-init.sh、meta-update.sh、meta-feedback.sh、meta-delete.sh のみを使用してください。skill_version には、このファイルの YAML フロントマターにある version: キーの バージョン番号のみ を設定してください（例：version: "1.1.5" → skill_version=1.1.5。引用符は不要）。

meta-init.sh は環境変数から IDE クライアントを自動検出します — 手動で渡す必要はありません。

bash ~/.fw-dev-tools/scripts/meta-init.sh <app-directory>
bash ~/.fw-dev-tools/scripts/meta-update.sh <app-directory> fw-review \
  invoked=1 skill_version=<version>
# For each failed rule ID (repeat as needed — omit if all passed):
bash ~/.fw-dev-tools/scripts/meta-update.sh <app-directory> fw-review \
  review_failure_categories+=<rule-id>

次に ## App Review Result ブロックを出力します。

補足ファイル

• rules/report.md — 最終的な App Review Result ブロックのみの出力形式。
• rules/iparam-rules.md — IP-04A、IP-05A、IP-06A。
• rules/frontend-files-rules.md — すべての FF-* ルール。
• rules/script-check-rules.md — scripts/*.js に対応する、スクリプトで判定するルール ID。

ルール ID の概要（評価対象ルール ID の正式な一覧）

領域	ID
iparams	IP-04A、IP-05A、IP-06A
ファイルとフォルダーの構成	FFS-02L、FFS-04L、FFS-05L
フロントエンド	FF-01L、FF-07L、FF-02M、FF-03A、FF-04A、FF-05A、FF-06A、FF-08A
コードの可読性	CR-05L
その他	GN-02L、GN-08L、GN-12L