SKILLKnowledge Workautomation

prompt-review

プラグイン: Synthflow
ソース: GitHub で見る ↗

説明

AI音声エージェント（音声で対応するAIシステム）のプロンプト、特にSynthflow Single-Promptについて、以下の点をチェック・改善します： - 矛盾や不整合がないか - 必要な背景情報が漏れていないか - ツールや動作の安全性に問題がないか - 問題が深刻化した場合の対応が用意されているか - コンプライアンス（法令遵守）上のリスク - 過去のバージョンから悪化していないか **次のような場合に使用：** ユーザーがプロンプトをデプロイ（本番環境へ投入）する前に、レビュー・監査・検証・改善、または複数のプロンプト比較を依頼したとき

原文を表示

Review AI voice-agent prompts, especially Synthflow Single-Prompt, for contradictions, missing context, unsafe tool/action behavior, escalation gaps, compliance risk, and regression risk. Use this when the user asks to review, audit, validate, improve, or compare a prompt before deployment.

ユースケース

プロンプトをデプロイする前にレビュー
矛盾や不整合がないかチェック
安全性とコンプライアンスを検証
複数のプロンプトを比較・評価

本文（日本語訳）

プロンプト審査スキル

目的

AIエージェント（自動応答システム）のプロンプト（指示文）を、テスト前・本番環境への展開前・本番環境での編集前に審査します。プロンプトが信頼できるか、具体的か、安全か、利用可能なツール・機能と一致しているか、実際の顧客との会話に適切かを重点的に確認します。

特に以下で有用です：Synthflow音声エージェント、シングルプロンプト型エージェント、フロー設計ノードのプロンプト、転送フロー、エスカレーション（問題の段階的な引き上げ）ロジック、サポート・営業・適格性判定・予約エージェント、通話動作を制御するすべてのプロンプト。

素材の取得方法（MCP経由）

プロンプトがSynthflowワークスペース内にある場合は、Synthflow MCP ツールで取得します：

現在のプロンプトと設定は get_agent
プロンプトが従うべきアクション説明は get_agent_actions / get_action
編集を比較する際の変更リスク確認は list_agent_versions / get_agent_version_diff

Synthflowの機能の実装方法を確認するには、公式ドキュメントで search_docs を使うか、ワークスペース連携がまだ済んでいない場合は synthflow-docs サーバーの searchDocs ツールを使用してください。

審査の基本的な考え方

優れたプロンプトは、背景知識がない人間オペレーターでも理解できるものです。

「別の人が読むテスト」（OpenAIが推奨）：プロンプトを同僚に声に出して読みます。同僚が「このエージェントが何をすべきか」を平易な言葉で言い直せなければ、LLM（大規模言語モデル）も確実には実行できません。

文脈のない18歳の若者でも、同じやり方を2回実行できる ように書きます。ぼんやりした性格指示より、具体的な行動指示を優先します。

悪い例：「親切で専門的に対応してください」 改善例：「1ターンに1～2文。1度に1つの質問をする。電話の相手が価格について聞いたら、承認された価格帯を伝えて、相談の予約希望があるか質問する」

ぼんやりした動詞を、テスト可能な具体的な行動に置き換えます：

❌ ぼんやり	✅ 具体的
「相手に専門的に対応する」	「1文1ターン、相手のトーン（調子）に合わせる、スラングは使わない」
「適切なバッテリーを見つけるのを手伝う」	「年式・メーカー・モデル・グレードを質問し、在庫ある2商品をSKU（商品コード）・価格・保証期間付きで提示する」
「顧客を認証する」	「名前・電話・注文番号を集める。各項目を読み上げて確認させる。『正しいですね、はい or いいえ?』と聞く」
「親切にする」	（削除 — 実行不可能）

背景・行動・出力の構造

Synthflowプロンプトは、この순序で・見出し付きで 3セクションに分かれるべきです：

セクション	内容
背景（Background）	エージェントの身元、企業、状況、支店・アカウント情報、ポリシー、役割、目標、相手の背景、変数、顧客固有の制限
行動（Behavior）	条件判定ロジック、フロー、「もし X なら Y」、ツール・アクション実行のトリガー、予約・転送・エスカレーション・フォールバック・通話終了ルール、異議対応とエラーハンドリング
出力（Output）	文の長さ、形式、言語、数字・日付・金額の読み上げ方 — 書式のみ

よくある誤配置：出力セクション内の条件ルール（「企業顧客なら転送する」）、上部に混在した「重要ルール」ブロック。フロー内の「出力」がツール呼び出しの場合は、出力ではなく行動セクション に属します。

注釈 — 決まった手順のフロー：多くの企業顧客が「ステップ1、2、7」形式のプロンプトを書きます。区分はなお有効ですが、出力は書式・スタイルのみに絞られます。再構成を強要せず、この前提を述べます。

機械的なチェックを先に実施

これらは客観的でほぼ自動化可能です。失敗は全てフラグを立てます。

ツール予算：エージェントあたり ≤ 20 ツール呼び出し
トークン長（語数）：< 180k は合格 · 180k–200k は注意 · > 200k は 不合格、リリースを阻止
変数・キャッシュの規律：固定内容を先に記載。変数は 名前だけで参照、本文に波括弧 {} は付けない；後ろの専用ブロックで解決。本文の早期インライン {vars} はプロンプトキャッシング（中程度の後退）を破壊
ルール配置：太った「重要ルール — 最初に読む」ブロックなし。各ルールは制御する行動の隣に配置。最後に最重要2～3個だけ繰り返すのはOK
物理的に不可能な指示：LLMには時計がない、ターン間でカウントできない、ターン間で「思考」できない。「ナレッジベースを使え」と指示してはいけない（Synthflowが自動で実行する並列プロセス）。トーン指示も LLM に書いてはいけない（トーンは音声指示に属する）

詳細と修正テーブル：references/mechanical-checks.md。

審査範囲

これらのカテゴリですべてのプロンプトを審査します。カテゴリごとの詳細チェックリスト：references/review-checklists.md で、調査結果を進める際に参照してください。

矛盾・重複指示 — プロンプト全体で両立しない指示
ビジネス背景不足・役割境界不明確 — エージェントは安全で一貫した仕事をするのに十分な情報を持っているか？
ツール・アクション・転送・ナレッジベース指示 — トリガー、正確な名前、引数・列挙値、戻り値・空・エラーハンドリング、兄弟関係の解消、書き込み前の確認。プロンプトと Synthflow UI のアクション説明が一致する必要があります。 ツール・説明が提供されない場合、審査に「利用可能ツールの文脈が必要」とマークし、不完全とします — 発明しない。アクション説明の作成ルール：references/action-descriptions.md
転送・エスカレーション・フォールバック・通話終了 — すべてのパスにトリガーと安全な確認ポイントが必要。「必要に応じて通話を終了」を厳格なゲート（実行条件）で置き換える
コンプライアンス・安全・顧客固有リスク — 規制対象のアドバイス、機密データ、同意、保証、AI身元開示。長い禁止事項リストより、3～5個の強い運用ガードレール（安全措置）を優先
変更に伴う後退リスク（編集を比較する場合） — 削除されたコンテキスト・トリガー・ガードレール、変更された閾値、行動が出力に移動、弱まった例、キャッシング損傷の変数変更

重要度レベル

致命的 — 安全でない行動、コンプライアンス露出、無断データ収集、誤った転送、存在しないツール呼び出し、本番環境破損。（例：カード番号を集める、不許可な規制対象アドバイス、コアワークフロー内の存在しないツール、確認なし予約、矛盾したコアワークフロー指示、重要ツール失敗時フォールバックなし、完了前に通話終了可能、> 200k トークン）
高 — 一般的に矛盾または失敗の可能性。（予約営業時間不明、トリガー曖昧、転送パス不明確、必須フィールド未定義、プロンプト・説明の矛盾、異議対応なし、空結果の回復方法なし）
中 — 機能するが信頼性・保守性・UX 問題。（ぼんやり指示、重複ルール、長いトーン説明、ルール誤配置、行動が出力に、読み上げ書式欠落、本文内早期 {vars}、物理的に不可能な指示）
低 — 軽微な修正

審査方法

エージェント型を特定 （シングルプロンプト、フローノード、転送ノード、ツール指示、ナレッジベース活用重視、予約、適格判定、サポート、営業、受付、内部QA）。不明なら前提を述べる
意図したワークフローを平易な英語で抽出 。できなければ背景情報不足とフラグ
コンテンツをマッピング → 背景・行動・出力・ガードレール・変数・例・ツール説明。誤配置をフラグ
機械的なチェック実行 （上記）
具体性チェック — ぼんやり指示ごと：エージェントは2通りでできないか？トリガー・成功条件・失敗パスはあるか？具体的な行動に書き直し
ツール・アクション整合性チェック 利用可能ツールと UI 説明の照合。プロンプト vs 説明の矛盾をフラグ。説明なしは不完全
転送・通話終了ゲートをチェック
コンプライアンス・安全チェック 業界別；不明なら一般サポートガードレール適用、業界コンプライアンスは不足とフラグ
例をチェック — 成功パス、エッジケース、エラー回復；指示と矛盾する例をフラグ
変更リスク確認 旧・新バージョン提供時；シミュレーション推奨

出力形式

references/output-template.md の構造を使い、審査を作成します（経営層向け要約 → 調査結果 → 不足情報 → 変更に伴う後退リスク → 推奨テスト → オプション：改善されたプロンプト）。そのファイルにはスコアリング規準と実例の調査結果も含まれます。

調査結果は実行可能に — すべての調査結果に具体的な推奨を含める（「もっと明確にしろ」ではなく）。

特別ルール

ビジネスロジックを発明しない — 発明された価格、ポリシー、法的要件、転送先、ツールなし。不足情報をフラグし、安全なプレースホルダー提供
過剰な書き直しをしない — デフォルトは審査。ユーザーが要求した場合、または修正が小さく局所的でポリシー発明が不要な場合のみ書き直し
意図を保存 — ビジネス目標、エージェント身元、トーン、ワークフロー、ツール名、コンプライアンス制約、有効な例
テスト可能な小さな変更を優先 — 1行動ずつ；本番環境プロンプト展開前にシミュレーション・テスト通話を推奨

最終確認事項

審査が完全なのは、(1) 実際の通話で何が起こりうるか、(2) プロンプトのどこに基づくか、(3) プロンプトをどう変えるべきか、(4) 展開前に何をテストするかに答えた場合のみです。

改善提案は 最大5個 とします。最終レポートの後、ユーザーに変更を適用するか確認してください。

原文（English）を表示

Prompt Review Skill

Purpose

Review an AI agent prompt before it is tested, deployed, or edited in production. Focus on whether the prompt is reliable, specific, safe, aligned with available tools/actions, and suitable for real customer conversations.

Especially useful for Synthflow voice agents, Single-Prompt agents, Flow Designer node prompts, transfer flows, escalation logic, support/sales/qualification/booking agents, and any prompt that controls call behavior.

Getting the material over MCP

When the prompt lives in a Synthflow workspace rather than in the conversation, pull it with the Synthflow MCP tools: get_agent for the live prompt and settings, get_agent_actions / get_action for the action descriptions the prompt must agree with, and list_agent_versions / get_agent_version_diff when comparing an edit for regression risk. To check how a Synthflow feature actually works, search the official docs with search_docs, or with the searchDocs tool on the synthflow-docs server if the workspace tools aren't connected yet.

Core Review Philosophy

A good prompt is understandable by a human operator with no hidden context.

The "another human" test (OpenAI's recommended check): read the prompt aloud to a teammate. If they can't restate what the agent should do in plain English, the LLM won't reliably do it either.

Write so an 18-year-old with zero context could execute it the same way twice. Prefer concrete behavioral instructions over vague personality instructions.

Bad: Be helpful and professional.
Better: Use one or two sentences per turn. Ask one question at a time. If the caller asks about pricing, give the approved price range and ask whether they want to book a consultation.

Replace vague verbs with specific, testable behavior:

❌ Vague	✅ Specific
"Handle the caller professionally"	"One sentence per turn, mirror their tone, no slang"
"Help them find the right battery"	"Ask year/make/model/trim, then present 2 in-stock SKUs with price + warranty"
"Verify the customer"	"Collect name, phone, order ref. Read each back. Ask 'is that correct, yes or no?'"
"Be helpful"	(delete — not actionable)

Background / Behavior / Output structure

A Synthflow prompt should split cleanly into three sections, in this order, with headers:

Section	Contains
Background	Who the agent is, company, situation, store/account context, policies, role, goal, caller context, variables, customer-specific restrictions
Behavior	Conditional logic, flows, "if X then Y", tool/action triggers, booking/transfer/escalation/fallback/end-call rules, objection and error handling
Output	Sentence length, format, language, spoken forms for numbers/dates/money — formatting only

Common misplacements to flag: conditional rules inside Output ("if commercial caller, transfer"); a "Critical Rules" block at the top mixing all three. If a flow's "output" is a tool call, that lives in Behavior, not Output.

Caveat — deterministic step-by-step flows: many enterprise customers write "step 1, 2, 7" prompts. The split still applies, but Output collapses to formatting/styling only. State this assumption rather than forcing a restructure.

Run the mechanical checks first

These are objective and near-automatable. Flag any failure.

Tool budget: ≤ 20 tool calls per agent.
Token length: < 180k pass · 180k–200k warning · > 200k fail, block release.
Variable / cache discipline: fixed content first; reference variables by name only, no curly braces in the body; resolve them in a trailing block. Early inline {vars} break prompt caching (Medium regression).
Rules placement: no fat "CRITICAL RULES — READ FIRST" block; put each rule next to the behavior it governs; repeating only the 2–3 most critical at the end is fine.
Physically-impossible instructions: the LLM has no clock, can't count across turns, can't "think" between turns, and shouldn't be told to "use the knowledge base" (it's a parallel process Synthflow runs automatically) or to adopt a tone (tone lives in speech instructions, not the system prompt).

Full detail and the fix-it table: references/mechanical-checks.md.

Review scope

Review every prompt for these categories. Detailed checklists per category are in references/review-checklists.md — read it when working through findings.

Contradictions / duplicated instructions — instructions that can't both be true, across the whole prompt.
Missing business context / unclear role boundaries — does the agent know enough to do the job safely and consistently?
Tool, action, transfer, knowledge instructions — trigger, exact name, arguments/enums, return/empty/error handling, sibling disambiguation, confirmation before writes. Prompt and the Synthflow UI action-description must agree. If tools/descriptions aren't provided, mark the review Needs available-tool context and incomplete — do not invent them. Action-description authoring rules: see references/action-descriptions.md.
Transfer / escalation / fallback / call-ending — every such path needs a trigger and a safe confirmation point. Replace "end the call when appropriate" with a hard gate.
Compliance, safety, customer-specific risk — regulated advice, sensitive data, consent, guarantees, AI-identity disclosure. Prefer 3–5 strong operational guardrails over long negative lists.
Regression risk (when comparing an edit) — removed context/triggers/guardrails, changed thresholds, behavior moved into Output, weakened examples, variable changes that hurt caching.

Severity levels

Critical — unsafe behavior, compliance exposure, unauthorized data collection, wrong transfers, hallucinated tool calls, production-breaking. (e.g. collects card numbers; regulated advice when disallowed; non-existent tool in core workflow; books without confirmation; contradictory core-workflow instructions; no fallback for a failed critical tool; can end call before completion; > 200k tokens.)
High — likely inconsistent or fails in common scenarios. (missing business hours for booking; ambiguous trigger; unclear transfer path; undefined required fields; prompt/description conflict; missing objection handling; no recovery for empty results.)
Medium — works but reliability/maintainability/UX issues. (vague instructions; duplicated rules; long tone descriptions; misplaced rules; behavior in Output; missing spoken-formatting; early inline {vars}; physically-impossible instruction.)
Low — minor polish.

Review method

Identify the agent type (Single-Prompt, Flow node, transfer node, tool instruction, KB-heavy, booking, qualification, support, sales, receptionist, internal QA). State assumptions if unclear.
Extract the intended workflow in plain English. If you can't, flag missing context.
Map content into Background / Behavior / Output / Guardrails / Variables / Examples / Tool descriptions. Flag misplacements.
Run the mechanical checks (above).
Check specificity — for each vague instruction: could the agent do it two ways? Is there a trigger, a success condition, a failure path? Rewrite into concrete behavior.
Check tool/action alignment against available tools and their UI descriptions. Flag prompt-vs-description conflicts. Incomplete without descriptions.
Check transfer and end-call gates.
Check compliance and safety for the industry; if unknown, apply general support guardrails and flag industry compliance as missing.
Check examples — happy path, edge case, error recovery; flag examples that contradict instructions.
Check regression risk if old and new versions are provided; recommend simulations.

Output format

Produce the review using the structure in references/output-template.md (executive summary → findings → missing information → regression risks → recommended tests → optional improved prompt). That file also contains the scoring rubric and a worked example finding.

Keep findings actionable — every finding includes a concrete recommendation, not "make this clearer."

Special rules

Do not invent business logic — no invented pricing, policies, legal requirements, transfer targets, or tools. Flag missing info and give a safe placeholder.
Do not over-rewrite — default is review, not rewrite. Only rewrite if the user asks, or the fix is small and local and doesn't require inventing policy.
Preserve intent — business goal, agent identity, tone, workflow, tool names, compliance constraints, still-valid examples.
Prefer small, testable changes — one behavior at a time; recommend simulations/test calls before deploying production prompts.

Final reminder

A review is complete only when it answers: (1) what could go wrong in a real call, (2) why, based on the prompt, (3) how the prompt should change, (4) what to test before deployment.

Give a maximum of 5 improvement suggestions. After the final report, ask the user whether they want you to apply the changes.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。