tsubaiso ti-howto — 使い方・可否・仕様の問いに、ナレッジを引いて答える
ベータとして先行提供している機能です。 記述が変わることがあります。扱いは ti-core の
references/beta-status.mdを参照してください。
利用者が「これはできますか」「どうやりますか」「これは仕様ですか」と聞いたときの入口。答えの中身はすべて製品ナレッジにあり、本スキルは持たない。本スキルが持つのは「引く → 出典を添えて答える → 引けなければ未確認と書いて残す」の順序だけで、製品の仕様を一行も書かない（ナレッジが更新されても追随しないため。ti-core references/knowledge-lookup.md と同じ規律）。
なぜ入口が要るか
可否・手順・理由を書く瞬間の作法は ti-core references/knowledge-lookup.md が持ち、各能力スキルは自分の手順の途中でそこへ到達する。しかし会話が問いから始まるとき——「〜はできますか」だけを投げられたとき——はどの能力スキルの手順にも入っておらず、作法へ到達しないまま答える経路が開く。本スキルはその問いを受け止めて、作法へ確実に渡すためにある。
答える対象と、答えの出どころ。
| 問い | 出どころ |
|---|---|
| この機能はできるか・対応しているか | ナレッジ（ヘルプ記事） |
| この画面で何をどの順に押すか・設定はどこで行うか | ナレッジ |
| この挙動は仕様か・なぜこうなるか・不具合か | ナレッジ（＋実測値の意味は意味定義） |
| その画面はメニューのどこにあるか | 本スキルではなく ti-navigate（組織から実行時に引く） |
| このデータは業務的に何を意味するか・どう集計するか | 本スキルではなく ti-reference（意味定義） |
発火点（いつ・何を読む/呼ぶ）
| チェックポイント | 読む／呼ぶ |
|---|---|
| そのセッションで最初に TI のスキルを使う瞬間（依頼の内容を問わず・1 セッション 1 回） | ti-core references/version-freshness.md（同梱の版と公開されている最新版を照合） |
| 本スキルが発火した瞬間（答えを書き始める前）[REQUIRED] | ti-core references/knowledge-lookup.md（引き方・立て直し・出典・未確認・接続が無いときのふるまい） |
| 実測した値が期待と違う、と持ち込まれた瞬間 | knowledge-lookup §意味定義とナレッジの使い分け（両方引いてから「仕様と違う」と言う） |
| ナレッジの検索の道具が見えない | ti-rollout（接続の案内へ渡す。未接続を理由に推測しない） |
| 立て直しても引けなかった | ti-core references/feedback.md（knowledge_gap として残す） |
| 利用者が当面の解決を要し、一次解決で片づかない | ti-core references/support-escalation.md |
答え方の順序 [REQUIRED]
- 問いを、製品と機能の呼び名に直す。 利用者の言い方のまま投げない。製品（PSA か IMA か）を先に決める。
- ナレッジを引く。 引き方（業務の対象＋機能名の 2〜3 語・語を減らす・総論から個別へ降りる）は
knowledge-lookup.mdのとおり。1 回の検索で「無い」と結論しない。 - 読んだ記事を根拠に、業務の言葉で答える。 どの記事で確かめたかを添える（公開ヘルプセンターの記事は URL を出してよい）。記事に書かれている強さを超えて断定しない——記事が「できる」と書いていないことを「できる」と書かない。
- 引けなかったことは「未確認」と書く。 引いた結果のように書かない。「無い」と「対応していない」の書き分けは
capability-preflight.mdに従う。そのうえで、利用者が自分で探せるよう製品と機能の呼び名を伝え、feedback.mdの作法で残す。 - 問いの続きが別のスキルの領域に入ったら渡す。 「では、その画面はどこですか」→
ti-navigate、「では、登録してください」→ti-update、「では、項目を足してください」→ti-metadata。本スキルは答えるところまで。
やらないこと
- コード・フロー・項目ヘルプ・パッケージのメタデータを開いて、そこから可否・手順・理由を組み立てない。 読めたものは「何がどうなっているか」を示すが、「そうあるべきか」は示さない。
- 同じ回答の中に、根拠のある部分と無い部分を混ぜない。 混ざると読み手には境目が見えない。根拠が無い部分は「未確認」と分けて書く。
- 利用者へ出す選択肢・作業計画・段取りの前提に、引いていない仕様を置かない。
出力規律
ti-reference §出力規律（最上位原則）に従う。利用者向けの説明文は業務言語だけで書き、内部の識別子・問い合わせ文を出さない。ヘルプ記事の公開 URL は同規律の対象外で、出してよい。
原則
- 答えはナレッジにある。本スキルは順序だけを持つ。 仕様の例を本文に書かない。
- 引けたことと引けなかったことを、同じ強さで書かない。
- 画面の場所は
ti-navigate、データの意味はti-reference、作業は各能力スキル。 本スキルは問いに答えるところまでで、そこから先は渡す。