毎週、Agentにサポート問い合わせの週報を頼む。そのたびに期間、項目、形式を説明し直す。Skillにすれば方法を再利用できる。だが「テンプレートの意味を教えて」でも集計が始まり、入力がないと先週の資料で埋めるなら、誤りまで再利用してしまう。
最初の検証は、必要な場面で動き、不要な場面で止まることだ。 すでに複数回行った仕事を一つ選び、手順より先に境界を整理する。
週報一つの入力条件を決める
架空の例として、サポート週報を「主な問題、要エスカレーション、不足情報、次の担当者」に整理する。報告案を作るだけで、送信や返金、問い合わせ状態の変更はしない。
対象期間、業務キュー、今回のデータファイル、参照テンプレート、出力を指定する。「今週」を固定手順に埋め込まず、毎回の変数にする。サポート対象も製品やキューを明記し、全フォルダを読んでよいとは扱わない。
ファイル不足、日付の不一致、必須項目の欠落があれば先に質問する。先週の数字で今週を推測せず、空欄を正常値に変えない。件数しかなければ解決時間も推定できない。
仕事：指定キューの問い合わせを明示した開始日・終了日で整理する。
入力：期間、今回の問い合わせファイル、テンプレート。
出力：報告案と不足一覧を今回の作業フォルダへ保存。
停止：期間未指定、ファイルなし、対象日付の不一致。
実行しない：送信、状態変更、返金、顧客への回答。
Skill Creatorに方法をまとめてもらう
BudaのAgent会話で「これをSkillにして」と頼む。Skill Creatorは用途、起動する状況、出力、テストを聞き、SKILL.mdを作成する。
入力条件、テンプレート、例を渡す。nameは識別子、descriptionは使う状況、本文は具体的な手順。顧客資料や認証情報、特定週のデータを共有Skillにコピーしない。手順は毎回渡す資料を参照する形にする。
まずBuda AIのMarketplaceで適したSkillを検索・インストールし、方法を読んでからカスタマイズを判断する。汎用手順との差は名称より、期間、出力、停止条件に表れやすい。
似た三つの依頼を区別する
「今週の工単をテンプレートで整理」は起動する。「テンプレートの項目を説明して」は集計しない。「今週のデータはないが改善案を話したい」から週報を作らない。
Creatorには次のような説明案を渡せる。
明示した期間のサポート問い合わせをチームの週報形式に整理する依頼で使う。
テンプレート閲覧、項目説明、戦略相談には使わない。
実行依頼でも必須入力が不足する場合は、不足を示してから待つ。
これは検証する説明であり、分類精度の保証ではない。同僚が自然に言いそうな表現で試す。ツール宣言は承認制度ではなく、「読み取りのみ」と書くだけで実際の動作確認を省略できない。
五つの手順に確認可能な結果を書く
読む：指定期間と今回のファイルを確認し、無関係な顧客資料を走査しない。
照合する：日付、問い合わせID、必須項目を確認。不足と矛盾は別に列挙する。
整理する：テンプレートに沿い、根拠のIDを残す。原因が記録されていなければ未確認とする。
点検する：件数を入力へ戻して照合し、重複とエスカレーション担当を確認する。
渡す：報告案と不足一覧を保存し、パスを示して終了。送信を追加しない。
「丁寧に分析する」より、各段階の入力と結果を書く方が検証しやすい。事実と推測を分け、未記録の原因を断定しない。
正例3、反例3、入力不足2を用意する
以下は推奨する検証例で、実測結果ではない。
| 例 | 期待する動作 |
|---|---|
| 期間・ファイル・形式がそろう | 実行して報告案を出す |
| 同じ仕事を口語で依頼 | 範囲を変えず認識する |
| 別キュー・別期間 | 新しい入力を使う |
| テンプレートだけ見る | 集計を始めない |
| 項目の意味を聞く | 説明だけを返す |
| 改善方針を相談 | 週報処理を始めない |
| データファイルなし | 不足を聞いて止まる |
| ファイル日付が違う | 不一致を示し旧資料で埋めない |
依頼、実際の起動、成果物、ずれ、修正を記録する。起動漏れと誤起動は別に評価する。書式が合っていても資料が違えば失敗だ。八例の合格を全業務への保証にはしない。
共有前に、今の版を確認する
Apps & Skillsでmanifest全文を読める。Local Skillの編集後はRefreshで再走査し、修正した手順を確認してから該当例を再実行する。Refreshはテスト合格でもMarketplace公開でもない。
まずagent scopeで一つの専門Agentに試す。チームが出力と停止条件を受け入れてからspace scopeを検討する。SpaceのSkillはそのSpaceのAgentから見えるため、機密資料と特定顧客の事情を共有手順に入れない。
版の説明、変更した挙動、影響する例を残す。descriptionの変更は起動範囲を、出力項目の変更は後工程を変える。正例、反例、入力不足を回帰確認する。定期実行はその後で、毎回の期間と資料を別に指定する。スケジュールがあるだけで方法の品質は保証されない。
AgentとSkillはどう違う？
Agentは会話、資料、タスクを持ち、Skillは読み込んで使う方法を提供する。説明を繰り返さずに済むが、今回の期間とファイルは必要だ。
編集後にRefreshする理由は？
Apps & Skillsが作業場所を再走査して変更を取り込むためだ。LocalのSKILL.mdを編集し、Refresh後にmanifestと手順を確認し、関連例を再実行する。
どの反例を残すべき？
「この週報テンプレートだけ説明して」のように実タスクに近いが実行すべきでない依頼を残す。説明が広すぎる問題が見える。日付不一致の例も残し、古い入力の流用を防ぐ。
繰り返したSOPを一つ選び、停止条件と八つの例をCreatorに渡そう。再利用できる方法は、始めやすさと同時に、止める判断を明確にする。