tsubaiso ti-poc — PoC・商談（トライアル体験）
契約前の PoC・商談・社内検証で、見込み客に「導入が簡単・速い」を実感させる進行スキル。4体験（理解・可視化 → サンプルデータでの多軸集計 → 自社マスタ取込 → 自社文書からの取引作成）を1本のナラティブで束ねる。能力は再実装せず、各体験で層2スキルを体験順に呼び、実装形態の判断は ti-lifecycle を参照する。契約が成立したら ti-onboarding へモードを遷移して引き継ぐ。
本書は薄い索引に徹する（詳細は必要な reference だけを読む方式）。体験の順序づけ・デモデータ／実演台本・モード設定の実体は各 reference にある。
このスキルが持つもの・持たないもの
| 持つ（進行＝順序づけ・段取り） | 持たない（能力・判断＝委譲先） |
|---|---|
| 4体験（理解→集計→マスタ→文書）の順序づけと1本のナラティブ | 参照・集計の実行＝ ti-reference／可視化＝ ti-spec-view |
| 驚きの源泉（AI 固有性）の演出規律・poc モードの挙動設定 | データ投入・移行・デモデータ生成の機構＝ ti-data-load／帳票資産＝ ti-report |
| デモデータ作成のワークフロー設定（何を何件どの順で＝ ti-data-load を呼ぶ） | 文書→取引作成・入力支援＝ ti-update／メタデータ配備の機構＝ ti-metadata |
| ti-onboarding への引き継ぎ渡し・ロール別の見せ方の出し分け | 実装形態の判断（宣言的/Apex/外部/製品機能化・Anonymous Apex 可否・運用移行）＝ ti-lifecycle |
| — | 契約後の本番導入プロジェクトの工程進行＝ ti-onboarding |
進行はこのスキル、能力は層2、判断は ti-lifecycle。この主従を崩さない。単一の能力で完結する作業（集計を1本・マスタを1件・可視化を1枚・受注を1件）は層2へ直接落とし、本スキルを経由しない。
モードと未判定既定（発火時にまず確認）
本スキル（契約前寄り）と ti-onboarding（契約後寄り）は同じ層2能力を違う局面モードで束ねる連続体で、相互排他ではない。契約状態が判明した時点で poc→onboarding へモードが遷移する。契約状態・環境が読めないときは、フェーズを確定せず、参照・可視化のみで応答し、書込・環境前提を要する段に入る前に契約状態と環境（トライアル／Sandbox／本番）を能動的に確認する。poc モード（サンプル・破棄前提・少量）を本番顧客に誤適用すると本番 org への害につながるため、「疑わしきは poc」を既定にしない。
発火点（いつ・どの reference を読むか）
| チェックポイント | 読む／呼ぶ | 渡す・確認するもの |
|---|---|---|
| そのセッションで最初に TI のスキルを使う瞬間（依頼の内容を問わず・1 セッション 1 回） | ti-core references/version-freshness.md |
同梱 .claude-plugin/plugin.json の版 |
| 製品の操作手順・可否・理由を書こうとした瞬間／製品そのもの（コード・フロー・項目ヘルプ・パッケージのメタデータ）を読もうとした瞬間／実測と期待の食い違いを不具合と書こうとした瞬間／作業の対象範囲を自分で数え上げようとした瞬間 | ti-core references/knowledge-lookup.md |
引きたい製品・機能と、利用者の言い方 |
| どの体験を・どの順で見せるか段取りする瞬間 | references/experience-flow.md |
買い手の業務・現在の体験・環境（トライアル） |
| デモデータを用意する・多軸集計の実演台本を組む瞬間 | references/demo-data-and-scenario.md |
業種プロファイル・見せる集計軸・台本のテンポ |
| poc モードの挙動・onboarding への引き継ぎ・ロール別出し分けを決める瞬間 | references/mode-and-handoff.md |
契約状態・データ規模・ロール |
| 体験1の理解可視化・体験2の多軸集計を出す瞬間 | ti-reference の該当 reference（experience-flow.md が案内） |
対象プロセス・意味定義の参照点・見せる軸 |
| 業務プロセスフロー図・データのつながり図・業務モデル図を描く直前 | ti-reference SKILL.md §業務プロセスの図・順番を描くとき（references/experience-flow.md が案内） |
正準シーケンス（レコードができる順番）。記憶や受領資料の日付順で順番を振らない |
| 現状のカスタマイズを把握・可視化する瞬間 | ti-spec-view の該当 reference | 対象 org・可視化の範囲 |
| デモデータ準備・体験3の自社マスタ取込で投入が要る瞬間 | ti-data-load の該当 reference（大量 I/O はスクリプト経路） | 投入シナリオ・dry-run→突合の前提 |
| デモデータを投入し終えた瞬間（見せる前・指示を待たない） | references/demo-data-and-scenario.md §投入後の答え合わせ（見せる前の関門）（機構は ti-data-load references/import-errors.md §投入後の答え合わせ（3層・完了条件）） |
正解表・L1〜L3 の結果・見せる画面に⚠️ が残っていないか |
| 体験4の自社文書→取引作成が要る瞬間 | ti-update の該当 reference（レイアウト解析資産は ti-report 側） | 対象文書・意味定義マッピング |
| トライアル構築で「どの実装形態で作るか」の判断が要る瞬間 | ti-lifecycle の該当 reference（Anonymous Apex はトライアル限定で可） | 要件の性質・破棄前提かどうか |
| org へ書き込む直前（体験3のマスタ取込・体験4の取引作成） | ti-core references/safety-gate.md |
対象・承認ドラフト・dry-run→突合 |
| 現状仕様を往復で詰める瞬間（体験1の業務理解・Fit 確認） | ti-core references/spec-roundtrip.md |
現状仕様・買い手の業務説明 |
| トライアルで繰り返し詰まる／ナレッジが不足した瞬間 | ti-core references/feedback.md |
匿名化した摩擦シグナル |
| 一次解決で解けず利用者が未解決のまま／繰り返し詰まると判定した瞬間 | ti-core references/support-escalation.md |
本人の許可・再現手順（PII・業務データ本体・認証情報は載せない） |
本文中の能力スキル名（ti-reference・ti-update・ti-report・ti-metadata・ti-spec-view・ti-lifecycle・ti-core・ti-data-load）は配置済みで、フォルダ名＝正準名として辿れる（ti-data-load は
tsubaiso-data-migrationからの改称先）。未配置の機構・スキルに当たったら機構を捏造せず人へ引き継ぐ（または ti-core Knowledge で代替する）。
reference 索引
| reference | 何を定義するか |
|---|---|
references/experience-flow.md |
4体験マップ（各体験で呼ぶ層2能力・理解→集計→マスタ→文書のナラティブ）＋体験連続性（トライアル→PoC→導入→稼働後）＋驚きの源泉＝AI 固有性の設計原則（語り口の規律）＋図を描く直前に正準シーケンスを引く発火点（手順の正本は ti-reference） |
references/demo-data-and-scenario.md |
デモデータ作成ワークフロー（ti-data-load をワークフロー設定で呼ぶ・業種プロファイル・山と谷の型・予算側を必ず埋める）＋投入後の答え合わせ（見せる前の関門・正解表→L1〜L3→手順への帰属）＋多軸集計の軸セットの型＋実演台本の型（軸切替のテンポ・待ち時間ゼロ・ROI 対比） |
references/mode-and-handoff.md |
poc モードの挙動軸・poc⇄onboarding の引き継ぎ（契約成立でのモード遷移・未判定既定）・ロール別の出し分け・段階導入と二層モデル・安全ゲート ≠ ライセンス制御の区別 |
原則
- 進行はここ、能力は層2、判断は ti-lifecycle。体験の順序づけ・段取り・モード設定は本スキルが持ち、各体験の実作業と実装形態の判断は委譲先で行う。
- 驚きの源泉＝AI 固有性。「その場で・準備なしで・速く」を驚きの核に据え、人力で事前準備できてしまうもの（事前受領して集計を作り込む等）は驚きに数えない。
- AI が下書き、人が判断。体験3・4で買い手の実データを操作する局面でも、下書き（取込案・マッピング案・dry-run 結果）を示し、確認・承認を得てから書き込む。
- 本書は薄く保つ。体験の手順・デモデータ・台本・モード設定は reference に置き、SKILL.md は索引に徹する。
- 出力に内部識別子（API 名・SOQL・レコード ID）を利用者向けに出さない（ti-core
references/output-discipline.mdに従う）。