mcpField
C
check-approve

check-approve

github.com/rheinmir開発10239 回インストール2 週間前に更新
リポジトリ

check-approve について

check-approve は、DMS の承認リクエストがバックエンドに届いたかを調べるスキルです。リクエスト ID から BE・FE のログ確認コマンドを生成し、スクリプトに保存して表示します。製品サーバーへの接続やコマンド実行は行いません。

主な機能

  1. 01BE・FE のログ確認コマンド生成
  2. 02時間範囲によるログ絞り込み
  3. 03不明なコンテナやユーザーのプレースホルダー
  4. 04スクリプト保存とコピー用コマンド表示
  5. 05製品サーバーへの接続・操作なし

活用シーン

  1. 01DMS 承認リクエストの BE 到達確認
  2. 02FE またはプロキシでの承認リクエスト停滞の確認
  3. 03特定リクエスト用の製品サーバー確認コマンド作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rheinmir/setup --skill check-approve

インストール後、Claude Code で/check-approveを入力して読み込まれたか確認します。

詳細

スキル：check-approve

WHAT

目的とコンテキスト
  • 目的： DMS リクエストで「approve を押したら処理が止まった」／承認コマンドが BE に届いたか不明な場合、ユーザーが 1 行のコマンドを プロダクトサーバー（ubuntu@hcm-bonbon-sv03）に貼り付けて実行できるようにします。エージェントはプロダクトサーバーに SSH 接続できないため、自分では実行せず、コマンドを生成するだけです（[[feedback_product_server_debug]]）。このスキルでは、BE と FE のコマンドを生成し、コピー時の改行エラーを避けるため .sh ファイルに書き出すとともに、インラインでも出力します。
  • トリガー（使用するタイミング）：
    • /check-approve <REQ-CODE> [--since 120m]
    • ユーザー：「approve／承認の確認コマンドを書いて」「リクエスト の approve が止まっている」「ログに承認コマンドが見当たらない」「BE／FE で承認を確認して」
  • 対象外： プロダクトサーバーへの SSH 接続／コマンド実行、approve のバグ修正（再現／修正が必要な問題には /orca-issue）、デフォルトでのローカル環境のトレース。
メンタルモデル

REQ-CODE（＋SUM-ID、since、container、user）→ BE + FE のテンプレート → 1 行コマンド → .sh ファイルへの書き込み＋インライン出力 → ユーザーがプロダクトサーバーで実行 → 結果を確認（POST approve があるかどうか）。

入力と出力の契約
フィールド必須？意味
入力<REQ-CODE>はいリクエストコード。例：BAF-CTD-26050043。指定がない場合はユーザーに確認します
入力--sinceいいえdocker logs の対象期間。デフォルトは 120m
入力--be-container / --userいいえ指定がない場合はプレースホルダー <BE_CONTAINER> / <FE_USER> を使用します
入力SUM-IDいいえさらに絞り込むための値。必要に応じてユーザーに確認します
出力scratchpad/check-approve-<REQ-CODE>.shはいBE + FE の 2 つの 1 行コマンド（またはユーザー指定のパス）
出力回答内のインラインコマンドはいユーザーがすばやくコピーできるようにします。「完了」とは、ユーザーが実行可能なコマンドを受け取ったことを指し、エージェントが実行したという意味ではありません
ルールと機能
  • RULE-01（必須）：プロダクトサーバーに SSH 接続／コマンド実行をしないでください。コマンドの生成のみ行います（[[feedback_product_server_debug]]）。
  • RULE-02（必須）：デフォルトではローカルではなく、プロダクト（hcm-bonbon-sv03）をトレースします。
  • RULE-03（必須）：各コマンドは 1 行のままにしてください（改行しない）。
  • RULE-04（必須）：ユーザーが「wiki のログフォルダーに書いて」と言った場合は .sh / .txt に書き込み、.md は使わないでください（OKF frontmatter hook を避けるため）。
  • 機能：ローカルのコマンドファイルへの書き込み。サーバーへのアクセス、ネットワークアクセスはできません。
失敗時の境界
  • <REQ-CODE> がない場合 → 確認し、推測したコードでコマンドを生成しないでください。
  • container／user が不明な場合 → 部分的な対応で問題ありません。プレースホルダー付きのコマンドを生成し、docker ps で確認して置き換えるようユーザーに伝えてください。
  • ユーザーがエージェント自身によるプロダクトサーバーでの実行を求めた場合 → RULE-01 に従って 対応不可とし、コマンドだけを提示してください。

HOW

メインワークフロー
StepTypeInputsActionOutputs/exitFailure/next
W01判断ユーザーの発言パラメーターを解決し、残りはプレースホルダーにしますパラメーター一式REQ-CODE がない場合 → 確認
W02決定的パラメーターテンプレートに従って BE + FE の 1 行コマンドを 2 つ生成します2 つのコマンド—
W03副作用コマンドscratchpad/check-approve-<REQ-CODE>.sh（またはユーザー指定のパス）に書き込みます.sh ファイル—
W04決定的コマンドインラインで表示します。自分では実行しませんユーザーがコマンドを取得—

各ステップの詳細（W01～W04 の正本）：

  1. 解決 — <REQ-CODE>、--since、ユーザーが指定した場合は container／user を取得します。指定がない項目は、ユーザーが入力できるようプレースホルダーにします。
  2. 生成 — 以下のテンプレートに従って、BE + FE の 1 行コマンドを 2 つ組み立てます。1 行のままにしてください（改行しない）。
  3. 書き込み — scratchpad/check-approve-<REQ-CODE>.sh（またはユーザー指定のパス）に書き込みます。ユーザーが「wiki のログフォルダーに書いて」と言った場合は .sh / .txt に書き込み、.md は使わないでください（OKF frontmatter hook を避けるため）。
  4. 表示 — ユーザーがすばやくコピーできるよう、回答内に両方のコマンドをインラインで出力します。プロダクトサーバーで自分では実行しないでください。
入力
パラメーター意味デフォルト
<REQ-CODE>リクエストコード。例：BAF-CTD-26050043必須
--sincedocker logs の対象期間120m
--be-containerバックエンドのコンテナー（ユーザーが把握している場合）プレースホルダー <BE_CONTAINER>
--userプロキシログの絞り込みに使う FE のユーザー名プレースホルダー <FE_USER>（例：trangntt）

<REQ-CODE> には通常 SUM-ID が紐づいています（例：1010228）。さらに絞り込む必要がある場合は、ユーザーに確認してください。

分岐
ID種類条件動作スキップ／失敗再合流
B01user_optionalユーザーが「wikiのログフォルダーに書き込んで」と言うscratchpad/ ではなく、そのフォルダーに .sh／.txt を書き込み、.md は作成しません指定がない → デフォルトのパスW04
B02user_optionalユーザーがリクエストコードでの絞り込みだけを必要としている統合版ではなく簡易版 BE を使用します—W03
検証と停止

目視で確認します。各コマンドが1行であること、リクエストコードが正しい位置に置き換えられていること、残りのプレースホルダーが明記されていることを確認します。W04 の後で停止します。ログを読む手順はユーザーが行います（「結果の読み方」の項目は、ユーザーがログを貼り付けたときに使用します）。

例
  • 成功例： /check-approve BAF-CTD-26050043 --since 6h → scratchpad/check-approve-BAF-CTD-26050043.sh に --since 6h を付けた BE + FE コマンドを記録し、コンテナーは <BE_CONTAINER>／<FE_CONTAINER> のままにして、インラインで出力します。実行はしません。
  • 境界／失敗例： 「check approveが止まっているので、SSHで入って確認して」ではリクエストコードがないため、リクエストコードを尋ねます。SSH は拒否し、コマンドの生成のみ行います。
参考 — コマンドテンプレート

BE（product 上の docker logs）— approve の全エンドポイントをまとめたコマンド：

docker logs <BE_CONTAINER> --since 120m 2>&1 | grep -i -B2 -A2 -e BAF-CTD-26050043 -e <SUM_ID> | grep -i -e POST -e Action -e Approve -e Reject -e Return -e UpdateGenTask -e GetGenTaskById -e UpdateTask -e "ApproveSummary/Approve" -e QuickApprove -e UpdateRequestByApproveGroup

BE — 簡易版（リクエストコードでのみ絞り込み）：

docker logs <BE_CONTAINER> --since 120m 2>&1 | grep -i -e POST -e approve -e UpdateGenTask -e ApproveSummary -e UpdateRequestByApproveGroup -e BAF-CTD-26050043

FE（dms-proxy log）— user + request で絞り込み：

docker logs <FE_CONTAINER> --since 120m 2>&1 | grep -i -e "dms-proxy" -e BAF-CTD-26050043 -e <FE_USER> -e Approve -e Action

<BE_CONTAINER>／<FE_CONTAINER> を実際のコンテナー（docker ps）に置き換えます。承認から時間が経っている場合は --since を変更します（例：6h）。BAF-CTD-26050043 は確認するリクエストコードに置き換えます。

参考 — 結果の読み方
  • POST /api/ApproveSummary/Approve（または UpdateGenTask、UpdateRequestByApproveGroup）にリクエストコードが含まれている → 承認コマンドは BE に到達しています。
  • FE でボタンを押したと表示されているのに POST の行がない → リクエストは FE／プロキシで止まっており、BE は呼び出されていません → 続けて [[concepts/approve-action-flow]] とプロキシを確認します。
  • モジュールごとのエンドポイントは [[entities/dms-modules]] を参照してください（BAF／VEN01／CashAdv…で異なります）。
参考 — 制限事項
  • product 上で SSH やコマンドを実行しないでください。コマンドを生成するだけです（[[feedback_product_server_debug]]）。
  • デフォルトでは product（hcm-bonbon-sv03）をトレースします。local ではありません。

起源

  • 元データ： セッション 6902c846 / c2f1149e から抽出（2026-06-25、BAF-CTD-26050043/30/26060030 の承認停止をデバッグ）
  • 生成元： /orca-eval finding #3（250626-eval-report）

コメント

Markdown 対応