tavern-card-builder

Tavern Card Builder

共有コミュニケーション

ユーザー向けの作業には、TW plain-language and guidance rulesを適用してください。用語は文脈に沿って説明し、ユーザーが選んだ新人／入门／熟练／老手のレベルを、推測で変更せずに維持してください。新人と入门には詳しい説明を行い、範囲を明示的に免除された場合を除き、すべてのレベルで必要事項とバグについて説明してください。Soul モードと prose モードでも、この基本ルールは無効になりません。タスクへの着手、レベル管理、説明に関する判断では、共通リファレンスを読み込んでください。

カードは明示的な契約の集合として設計してください。作成に関する判断はここで行い、エンジニアリング作業は担当の専門家に引き継いでください。

書き込みを伴う設計の前に、tavern-card-builder ルートを使って $consult-tavernweave-library を実行し、A0 と該当する最小限の ST ガイドが実際に読まれていることを確認してください。ルートの受領記録はプロジェクトの権威ある記録と一緒に保管してください。ルートを通じて読み込まれていないバンドル済みデータベースは、根拠になりません。

新規カードまたは長期運用するカードでは、大量の本文を作成する前に、creative-authority.mdで再開可能な創作上の権威情報を確立してください。原作小説、メモ、チャット、調査資料については、material-provenance.mdで来歴の連鎖を追加してください。永続的な知識、状態、物語の想起、または作成者プロフィールに関する依頼では、memory-architecture.mdを使って4つのストアを分離してください。

対象から始める

「接手一张卡 / 二创 / 继续更新别人留下的卡」では、retrofit-and-text-cards.mdの既存カード引き継ぎ手順から始めてください。変更を提案する前に、実際のカードについて説明してください。続きを作ることと派生作品を作ることを区別し、ユーザーが選んだ要点を維持して、最初の変更と2回目の反復を計画してください。PNG／JSON のエクスポートがあっても、維持管理された作成元ファイルが存在する証拠にはなりません。既存の確定済み判断を再開し、再検討はしないでください。

1. リポジトリの指示を読み、設計を提案する前に既存のカードを調べてください。
2. 挙動がバージョンに依存する場合は、対象となる SillyTavern、Tavern Helper、プロンプトテンプレート、MVU の実装またはバージョンを特定してください。
3. 実際のカードと維持管理されたソースから、主要なカードタイプを1つと機能フラグを特定してください。ユーザーがインストールするもの、カードに埋め込むもの、リモートから読み込むものを決める前に、ランタイム依存関係の台帳を作成してください。card-types-and-runtime-dependencies.mdを読んでください。
4. 結果に実質的な影響を与える判断だけを尋ねてください。小規模な編集に、定型の聞き取り手順を押し付けないでください。
5. カードに専用の CoT が必要か、再利用可能なメインの CoT がプリセットにすでにあるか、カード固有の追加要素として何が必要か、どのモジュールを条件付きで有効にするかを、それぞれ独立して判断してください。この判断を、カードが MVU を使っているかどうかに依存させないでください。
6. MVU カードでは、更新がプロット生成と同じ生成処理を共有するのか、追加の更新モデル処理を使うのかを特定してください。ランタイムがエントリールーティングをサポートする新規の MVU zod カードでは、デュアル互換レイアウトを優先してください。移行が明示的に許可されていない限り、既存カードの現在のモードを維持してください。
7. バージョンに左右される未解決の主張は仮定として記録し、実際のランタイムでの受け入れ確認を必須にしてください。

作成手順の全体については、authoring-workflow.mdを読んでください。

プロットより先に契約を定める

各システムについて、次の項目を書き出します。

• 信頼できる情報源
• フィールドとデフォルト値
• 書き込み元、読み取り元、レンダラー、クリーンアップの担当者
• 初期化と移行の動作
• モデルに表示される指示
• 実行時の依存クラス、提供方法、有効化ポリシー、障害時の動作
• 検証の証拠

カスタム CoT では、次の項目を追跡します。

main CoT phases -> card increments -> conditional modules -> recipient model
                -> assembled prompt -> output boundary -> fallback -> acceptance

作成元では、安定したフェーズ ID とルール ID を使用します。ID だけでなく、意味による重複排除も行います。カードの追加分では、プリセットの CoT 全体をコピーするのではなく、そのカード固有の条件、例外、またはより限定的な制約を追加します。

MVU の状態については、すべてのフィールドを次の項目に沿って追跡します。

schema -> initialization -> update rules -> model projection -> runtime reader
       -> renderer -> write-back -> cleanup/migration -> examples/tests

消費側もライフサイクルもないフィールドは追加しないでください。スキーマ、更新ルール、または MVU のモデルルーティングプレフィックスを書く前に、variable-systems.md を読んでください。

開始方法を選択する

すべての開始方法を一つのプロトコルとして扱わないでください。

• 最初のメッセージが固定されている場合や、別のあいさつ分岐がある場合は、共通の初期化とあいさつごとの初期化を使用します。
• 通常のプロット／更新チェーンをトリガーする必要がある自由形式または複数ステップのセットアップでは、実際のユーザー開始メッセージを使用します。
• 開始時の初期化を実現するためだけに、ヘルパースクリプトで MVU の初期化イベントを偽装してはいけません。

<initvar>、<UpdateVariable>、または開始ウィザードの動作を追加または削除する前に、opening-strategies.md を読んでください。

作成レイヤーを分離する

1つのカードにまとめて同梱する場合でも、次のレイヤーは分けて管理してください。

• カードのアイデンティティと物語の文章
• カスタム CoT とカード固有の CoT 追加分
• ロアブックとプロンプトのルーティング
• 永続変数プロトコル
• 正規表現による変換
• 実行時スクリプトと API
• 埋め込み UI
• モジュール式ソースライブラリ
• ビルドとリリースの成果物

作成の範囲をまたぐタスクでは、対象を絞ったスキルを使用してください。

• $sillytavern-card-components：安全な分解、レジストリ／レシピ作業、ソースの往復変換
• $sillytavern-card-pipeline：組み立て、検証、JSON／PNG のパッケージ化、リリースゲート
• $sillytavern-api-reference：正確なシグネチャ、イベント、マクロ、バージョン依存の実行時情報
• $sillytavern-runtime-debug：実際の SillyTavern セッションから得られる証拠
• $sillytavern-embedded-ui：開始ページ、ステータスバー、コントロールセンター、ダイアログ
• $rolecard-workshop-ops：公開インフラストラクチャ
• $rewrite-natural-prose：文章の改善が依頼された場合、またはすでに文章の書き換えモードが有効になっている場合に使用します。そのモード内で創作上の引き継ぎ文を改善しつつ、正史と保護対象の技術フィールドを維持します。通常のカード作成では、文章の書き換え設定は有効にならず、保持もされません。
• $code-quality-workflow：カードの構成とソフトウェア上の連携について、明示的な全体レビュー／アーキテクチャレビューが必要な場合に使用します。作成上の変更は、既存のゲートの内側に留めてください。

最小限で完全な設計を作成する

タスクに必要な参照資料だけを読みます。

• card-writing.md：識別情報のフィールド、文章、挨拶、例、プロットの指針。
• cot-design-and-authoring.md：独立したカスタム CoT の定義、デプロイ、モジュール式の作成、プリセットとカードの結合、モデルのルーティング、テンプレート、予算、スクリプトの境界、受け入れ基準。
• lorebook-and-prompts.md：エントリの境界、ルーティング、モデルに表示されるテキスト、プロンプトの予算。
• variable-systems.md：スキーマ、初期化、更新、射影、クリーンアップ、移行。
• opening-strategies.md：固定の挨拶と動的なセットアップフロー。
• card-types-and-runtime-dependencies.md：タイプの検出、依存関係の分類、リージョン別ローダー、ユーザーへの通知。
• regex-and-runtime-requirements.md：API を作り上げずに、変換とスクリプトの要件を確認します。
• retrofit-and-text-cards.md：既存のカードの維持、または MVU を完全に使わない方法。
• 引き渡しの前に validation.md を確認します。

変わらないルール

• ソースと生成された成果物は分けて管理します。ソースを修正してから、成果物を再ビルドします。
• 根拠と移行の承認がない限り、既存カードで実証済みのプロトコルを維持します。
• コマンドの構文とランタイムの動作は、普遍的な常識ではなく、バージョンに依存する機能として扱います。
• MVU Zod は、API 識別子だけで判断せず、カードのスキーマ、登録経路、同梱ローダースクリプトから検出します。埋め込みスキーマ、埋め込みの国内版／グローバル版 MVU Zod スクリプト、それぞれの Git／CDN の取得先、必要なホスト拡張機能は、個別にたどって確認します。カードにすでにローダースクリプトが含まれている場合、Zod の単独インストール手順を追加しません。
• 拡張機能やリモートランタイムを、ユーザーに知らせずインストールしません。埋め込み、ホスト、リモート、リージョン別、オプション、開発専用の依存関係を個別に報告します。
• モデルに表示されるテキストには、インシデントの履歴、開発時のコメント、モデルにとって目的のない Markdown の装飾、コピーして使えるハードコード済みの出力を含めません。
• カスタム CoT は、作成者が記述した意思決定プロトコルとして扱い、モデルの隠れた内部推論にアクセスする手段とは見なしません。推論全体の出力を要求するのではなく、観察可能な動作とルーティングを検証します。
• 基本は、プリセットのメイン CoT にカード固有の追加項目と条件付きモジュールを加える形にします。プロットモデルの CoT、更新モデルのプロンプト、決定論的なスクリプト計算は、それぞれの役割に応じて分離します。
• 多言語または複数行の本文を書き込む場合は、UTF-8 に対応したガード付き書き込みを使用します。変更の前後に、構造的な一致を検証します。
• 新しい抽象化を導入するより、プロジェクトで実証済みの構造を優先します。
• 影響の大きさに応じて検証します。ランタイムに影響する変更は、実際の SillyTavern で受け入れられるまで完了とは見なしません。
• 作成計画が完了したというだけの理由で、ユーザーのカードをパッケージ化、公開、デプロイ、または上書きしません。

引き渡し形式

次の項目を返します。

1. 対象カードのタイプ、検出された機能、根拠。
2. 合意したシステムと対象外の項目。
3. ランタイム依存関係の一覧、およびユーザー向けのインストール／埋め込み／リモート読み込みに関する通知。
4. フィールド／ロアブック／コンポーネントの契約、および CoT のデプロイ／結合契約。
5. 作成または変更するファイルやカードのセクション。
6. 次に必要となる専門スキル。
7. 得られた検証の証拠。
8. 実際のランタイムでの確認、またはユーザーによる受け入れで、まだ必要なもの。