プロンプトライブラリ
ポリシーでは、ログがプロバイダー障害を示す場合、失敗した生成のクレジットはレビュー対象になると書かれています。顧客は自動返金を求めています。
確認済みルール: ログがプロバイダー障害を示す場合、失敗した生成のクレジットはレビュー対象になる。 顧客向け回答: 顧客がタスク ID を提供すれば、チームがそのタスクをレビューできると伝える。 約束してはいけないこと: ログレビュー前に自動返金を約束しない。 エスカレーション要件: ログでプロバイダー障害が確認された場合は、請求責任者にエスカレーションする。 内部メモ: タスク ID とタイムスタンプを記録する。
元の返信: これは返金できません。後でもう一度試してください。ポリシー上できません。
修正版の返信: このメッセージだけでは返金を承認できませんが、失敗したタスクの確認はお手伝いできます。ログを確認できるよう、タスクIDと実行時刻を送ってください。 トーンの変更点: 断定的だが協力的。 取り除いたリスク: 根拠のない包括的なポリシー主張を避けた。 残る注意点: 返金可否はタスク確認に依存する。
マクロ: このようなことが起きて申し訳ありません。失敗した生成は必ず調査し、原因が分かり次第、適切に対応します。
改訂後マクロ: ご連絡ありがとうございます。ログを確認できるよう、失敗した生成のタスクIDとおおよその時刻を共有してください。 必須プレースホルダー: タスクID、タスク時刻、必要な場合はアカウントメール。 ポリシー境界: レビュー前にクレジット調整を約束しない。 担当者メモ: 顧客が生成失敗を報告した場合にのみ使用する。
顧客は、キャンペーン開始が顧客側のクライアント都合で遅れたため、期限切れクレジットの延長を求めています。
ポリシールール: 期限切れクレジットは自動延長されない。 顧客影響: キャンペーン遅延は実際に起きた可能性があるが、Rivya の外部要因だった。 前例リスク: 基準なしに延長すると、一貫しない対応を生む。 エスカレーション経路: 記録されたプロバイダー障害が存在するか、請求責任者に確認する。 返信スタンス: リクエストを受け止め、レビューの制限を説明する。
草案には、成長は力強く、プロダクト品質は改善し、チームは加速のために追加の人員枠が必要だと書かれています。
曖昧な主張：力強い成長には指標と比較期間が必要です。 不足している証拠：プロダクト品質の改善には、欠陥、リテンション、またはタスク成功率のデータが必要です。 防御的なトーン：加速のために人員枠が必要という表現は、根拠が不足しています。 明確な依頼：意思決定、必要なキャパシティ、期待する成果を具体化してください。 書き直し方針：各主張に1つの証拠点を対応させてください。
顧客は、夜間に動画タスクが失敗したことで、Rivya がクライアントの期限を壊したと言っています。
共感: 期限に影響が出たことを受け止めるが、未検証の責任は認めない。 事実: タスク失敗には ID とログが必要。 制限: このメッセージだけでは原因や補償は確認できない。 次のアクション: タスク ID とエスカレーション先の連絡先を依頼する。 内部メモ: 顧客がクライアントの期限に触れているため、優先対応する。
条項には、ベンダーが通知により使用上限を変更でき、紛争中も顧客は支払いを継続しなければならないと書かれている。
平易なリスク：購入後に使用上限が変更される可能性がある。 ビジネス影響：予測していた利用量が信頼しにくくなる可能性がある。 弁護士への質問：どの通知期間と解約権が適用されるか。 交渉ポイント：初回契約期間中の上限を固定する。 判断しない事項：弁護士の確認なしに法的強制力を判断しない。
ブリーフ：ecommerce向けの最適なAI画像ワークフローについて書く。スピード、品質、オールインワンのワークスペースに触れる。
読者像の明確さ：ecommerce運営者なのかクリエイティブチームなのかが指定されていません。 証拠の不足：スピードと品質には、例または比較基準が必要です。 薄い主張：オールインワンのワークスペースは、具体的なワークフロー例がないと広すぎます。 次の一手：商品写真のシナリオを1つ定義し、必要な証拠を決めてください。 リスク：記事が一般的なリスト記事になってしまう可能性があります。
ユーザーが広告キャンペーン向けに、公人の推薦画像を生成したいと依頼しています。
ポリシー適合性：広告における公人の推薦表現はセンシティブで、制限される可能性が高い。 不足している事実：同意またはライセンス済み素材が存在するか。 ユーザー影響：キャンペーンのスケジュールに影響する可能性がある。 エスカレーション推奨：生成前にポリシー責任者へ回す。 安全な返信方針：同意と使用権の確認が必要であることを説明する。
新しいレビュー規則では、公開例に下書き専用リンクではなく、承認済みの出典リンクを使う必要があります。
影響範囲：プロンプト例、モデルカード、ブログカバー、検索用画像、共有用画像。 担当者の対応：素材を承認し、出典リンクを更新し、最終チェックを実行する。 顧客向けメッセージ：URL 変更がアクセスに影響しない限り、表示上の追加約束は不要。 法務確認事項：古い下書きファイルの保持と削除ポリシー。 未解決リスク：下書きリンクが誤ってコンテンツ元に残る可能性がある。
草稿: Rivya を最高のマルチモーダル AI プラットフォームに変えようとしており、全員がもっと速く動く必要があります。
引き締めた主張: チームは今サイクルで、信頼できるマルチモーダルワークフローを優先している。 必要な根拠: 現在のテンプレートカバレッジ、モデルページ、プロンプトから結果までの経路。 トレードオフ: 最終メディアレビューはローンチを遅くするが、信頼性を守る。 依頼事項: 最終リリース前にテンプレートレビューとアセットチェックを完了する。 トーンメモ: 証拠なしに最高プラットフォーム表現を使わない。
アカウントではデザインチームが関心を示し、調達部門はクレジットを懸念し、法務部門はメディア保存について質問している。
ステークホルダー：デザインチーム、調達部門、法務部門。 ユースケース：デザインワークフローと生成メディアのレビュー。 リスク：クレジットパッケージと保存ポリシーの明確さ。 拡張経路：デザインチームのパイロットから始め、その後ワークスペースガバナンスへ広げる。 次回ミーティングの目標：パイロット範囲と法務の保存に関する質問を確認する。
レポートでは、ユーザーが再利用可能な例を見られるため、プロンプトテンプレートはモデルページの信頼を高めると主張しています。
主張の中心: プロンプトテンプレートはモデルページの信頼を高める。 エビデンス: 再利用可能な例がモデルガイダンスの近くに表示される。 弱いリンク: 信頼の向上はまだ測定されていない。 反論: 薄いテンプレートが多すぎると、品質シグナルが下がる可能性がある。 支援される意思決定: 会話例が具体的で有用な場合にのみテンプレートを追加する。
ユーザーは、プロンプトテンプレートがモデルページとStudioにどうつながるかを尋ねている。ドキュメント記事が必要。
ユーザー目標：プロンプトテンプレートがどこに表示され、どのように実行するかを理解する。 前提条件：公開済みテンプレート、推奨モデル、対応モード。 手順：プロンプトを開き、例を確認し、実行またはコピーしてから、Studioで続ける。 エッジケース：利用できないモデル、ドラフトテンプレート、またはメディアがまだ最終承認待ちの場合。 関連リンク：プロンプトライブラリ、モデルページ、メディアチェックリスト。
ボタンには「続行」と書かれています。補助文には「高度なオーケストレーションが出力ジャーニーを最適化します」とあります。ユーザーはモデルを選んでいます。
分かりにくいアクション：「続行」では次に何が起きるか分からない。 詰め込みすぎた補助文：「高度なオーケストレーション」は内部向けの言葉。 欠けている成果：ユーザーは、モデル選択が出力スタイルとコストに影響することを知る必要がある。 推奨ラベル：このモデルを選択。 推奨補助文：画質と編集コントロールのバランスを取りたい場合は、このモデルを使用します。
顧客はプロンプト例を気に入っているが、最終作業ではまだプロンプトを別のツールにコピーしていると言った。
観察：プロンプト例は発見を助けるが、ワークフロー全体を完了させていない可能性がある。 中立的なフォローアップ：何がきっかけでプロンプトを別のツールへ移しますか。 行動質問：前回のプロジェクトでは、それはいつ起きましたか。 避けること：Studioにエクスポート機能が足りないかを尋ねない。 意思決定とのつながり：ツール切り替えの原因が継続作業、信頼、習慣のどれにあるかを知る。
このモジュールはプロンプトテンプレートの互換性、管理画面表示、古いシードエントリを扱っています。1 つの経路を安全に削除する必要があります。
責務: 互換性定義、管理画面での読み取り表示、シード対応。 呼び出し元: プロンプトライブラリ、管理画面のプロンプトページ、検証スクリプト。 データフロー: バージョン管理されたテンプレートが現在の信頼できる情報源で、デフォルト定義は互換性の例です。 危険な前提: デフォルト定義を削除すると、古いスクリプトのラベルが壊れる可能性があります。 安全な最初の変更: 互換性用エクスポートを削除する前に、使用状況の監査を追加します。
ローカルではtypecheckが通りますが、static prompt paramsにlocaleコンテンツのない新しいslugが含まれるとbuildが失敗します。
想定原因：テンプレートソースは存在しますが、対応するlocaleファイルがありません。 再現手順：slugを追加し、buildを実行して、prompt static paramsに到達させます。 最小修正：そのslug用のenとzhのlocaleファイルを追加します。 回帰テスト：build前にprompts:checkを実行します。 変更禁止：localeファイルが有効でない限り、ルート生成は変更しないでください。
