twitter-reply

Twitter Reply

独立したフラットなピアとして、アドホックな返信作業を担当します。twitter-automation を有効化したり、依存したりしないでください。そのピアからこちらにルーティングされることはありますが、このスキルが事前確認から返信ワークフロー全体までを担当します。

まず依頼を簡潔にまとめる

事前確認や tw コマンドを実行する前に、正確なターゲットと最終返信文を保護してください。タスクモードの依頼ごとに、残りのユーザーの文言を、簡潔に整えた1文に書き直してください。文脈全体から明らかな誤字を修正し、冗長な表現や繰り返しを削除しつつ、明示された件数、トピック、文字列そのままの検索語句、アカウントや関係性のフィルター、エンゲージメントのしきい値、その他の制約はすべて保持してください。ユーザーが指定していないトピックや要件を追加しないでください。

タスクの作成と、新しいタスクとして再開する場合は、この簡潔にまとめた依頼をタスクの指示として使用してください。ユーザーの意図を推測せずに簡潔にまとめられない場合は、簡潔な質問を1つして終了してください。正確なターゲットと返信文のペアは、決して書き直さないでください。たとえば、fin 10 let's connect tweets and draft replies は、"let's connect" に一致するツイートを10件見つけて、返信案を作成する を意味し、金融関連のタスクではありません。

いずれか1つのモードを選択する

ユーザーが指示、トピック、文字列そのままの検索語句、アカウントや表示範囲の条件、ターゲットの探索依頼、または 5 から 10 までの探索件数を指定した場合は、タスクモードを選択します。

ユーザーが正確なターゲットを1つ、完成した最終返信文を1つ、そして今すぐ送信する明示的な意図を指定した場合に限り、正確なアクションモードを選択します。

また、ユーザーが現在のタスクにおける、正確で変更のない返信案を明示的に再試行し、その永続的な結果から送信処理が開始されていないことが確実にわかる場合も、正確なアクションモードを選択します。再試行では、新しい正確なアクションフローを開始します。失敗したスケジュール済みの変更を再開、再スケジュール、または実行することはありません。

• 探索タスクの件数が指定されていない場合、5 を既定値にします。
• ターゲットの探索には、5 から 10 までの整数のみを受け付けます。
• 探索件数が 5 未満または 10 を超える場合は、5..10 の範囲から選ぶようユーザーに尋ねてください。自動的に分割したり、正確なアクションモードとして解釈したりしないでください。
• ブラウザーの状態、スクリーンショット、プロフィール URL、または「そのツイート」から、正確なターゲットを推測しないでください。
• 正確なターゲットと文面のペアが複数ある場合は、指示に基づく探索タスクを1つにするか、正確なアクションを個別に行うかを尋ねてください。
• 正確なアクションか探索／指示に基づくタスクかが不明な場合は、tw を呼び出す前に簡潔な質問を1つしてください。
• 以前の返信作業の結果や状況について尋ねられた場合は、どちらのモードも使わず、「以前の作業を確認」を使用してください。

タスクテンプレート

タスクモードに入るとき、またユーザーの依頼が曖昧すぎて推測なしでは簡潔にまとめられない場合は、自由形式の質問ではなく、ローカライズした記入式テンプレートを1つ提示してください。

Reply task template:
Find <5–10> tweets containing "<keyword/phrase>" and draft replies
Optional: only/exclude specific accounts, minimum engagement, language
Example: Find 10 tweets containing "let's connect" and draft replies

回复任务模板：
找 <5–10> 条包含「关键词/短语」的推文并起草回复
可选：只看/排除某账号、最低互动量、语言
示例：找 10 条包含「let's connect」的推文并起草回复

no_valid_targets_found などで探索対象が不足した場合も、方向性を言い換えるための提案として同じテンプレートを再利用してください。

言語

明示的な希望、最新のメッセージ、会話の言語の順に従って、英語または簡体字中国語で応答し、それらがない場合は英語を使用してください。正確なターゲットと返信文のペアは、翻訳も表記の正規化も行わないでください。上記の定義に従って、要件を追加せずにタスクの指示を簡潔にまとめてください。

必須の事前確認

依頼を簡潔にまとめてモードを選択した後、新しい返信タスクを開始するたびに、スキル名を指定して threadwave-preflight を有効化してください。このスキル名、選択したモード、変更していない元の依頼、および必要な機能ファミリーを渡してください。この処理では、このタスク向けのスキル更新を確認してから、通常の CLI 事前確認を実施します。CLI 事前確認では、準備状態は12時間の非アクティブ期間まで再利用され、古くなっているか無効化されている場合にのみ完全な確認が実行されます。レビュー判断だけを理由に事前確認をやり直さないでください。現在有効な準備完了の結果がない状態で tw を呼び出してはいけません。

CLI 1.0.35 と、task、draft、plan、scheduler、action の各コマンドファミリーを必須とします。スキル、CLI、または拡張機能の状態が不足している場合は、依頼を保持したまま https://www.threadwave.xyz/cli/setup/agent.md に誘導してください。

CLI の結果に関する権限

UX はスキルが担います。ユーザーの状況に合った文書化済みのコマンドを選び、安全に引数を渡し、返された対象・内容・選択肢を提示して、承認を得てください。ワークフローの実行、タスク／下書きの系譜、検証、復旧に関する事実、正確な続行方法は CLI が担います。

• 完全で解析可能な tw_cli_harness_v1 エンベロープを 1 つ要求してください。プロセス／セッションハンドルは転送状態であり、結果ではありません。
• ok=true の場合、data、refs、ステータスフィールド、警告、next を信頼できる情報として扱ってください。親タスクと子タスクの参照を比較したり、系譜を再構築したり、CLI の不変条件チェックを繰り返したり、受理された結果を契約の不整合として再解釈したりしないでください。
• 空でないトップレベルの warnings の項目をすべて表示してください。返された下書きデータに generation_warnings が含まれている場合は、該当する下書きの横にすべてのメッセージを表示してください。これらは CLI によってサニタイズされた、顧客向けの人間が理解できるメッセージです。意味を保ち、抑制したり、一般的なゲート失敗のメッセージに置き換えたりしないでください。また、内部ルール ID、プロンプト文、ゲートのコンテキストを追加しないでください。
• ワークフローを続行するため、返された読み取り専用の next コマンドを実行してください。レビュー、再開、キャンセル、X の変更を行うコマンドは選択肢として提示し、ユーザーが承認した正確なコマンドのみ実行してください。
• ok=false の場合、返された error.code、error.message、error.retryable を報告してください。人間向けの失敗を説明する内容であっても、安全な next の選択肢を提示する前に、顧客向けメッセージを表示してください。一般的なブロック状態にまとめたり、モデルが作り出した診断に置き換えたりしないでください。
• ワークフローの失敗ステージは、CLI が failure_stage を返した場合にのみ報告してください。source_status、draft_status、タイミング、エラーコードからステージを推測しないでください。このフィールドがない場合は、返された失敗の事実のみを報告してください。
• コマンドが完全なエンベロープを返さずに終了した場合は、task_dispatch_unconfirmed として停止してください。この転送失敗はホスト側で確認できる唯一の結果であり、タスクの重複実行を許可するものではありません。

承認に関する権限

承認はそれぞれ専用のゲート内で完結させてください。

ゲート	許可される判断	「すべて承認」	承認の結果
コンテンツレビュー	正確なレビューごとに 1 回、明示的に判断する	不可	承認されたレビューごとに、正確な返信変更を 1 回実行する権限を与えます。
正確なアクション	ドライラン後の、変更されていない対象／テキストのペアを 1 つ選ぶ	不可	そのペアを 1 回ディスパッチします。

プランを使わない手動のタスク作成では、ユーザーの依頼が、情報の特定と下書きの生成を行う権限の根拠になります。タスク提案やソース選択のレビューは作成されません。決定論的なソース選択はユーザーの承認ではなく、X の変更を許可するものでもありません。「すべて承認」「続行」「再試行」などの表現によって、残りのゲート間で権限が移ることはありません。

タスクモード

1. 範囲を限定したタスクを 1 つ作成する

指示は安全な引数として 1 つ渡してください。ユーザーの内容をシェル構文に連結してはいけません。意味的に同等の処理を実行してください。

パッケージ化された Windows 版では、threadwave-preflight から保持した構造化された後続形式を使用してください。各 CLI トークンと、完全に要約した指示を、それぞれ個別に ProcessStartInfo.ArgumentList に追加します。PowerShell の & とスプラッティングの組み合わせ、Start-Process -ArgumentList、ProcessStartInfo.Arguments、または文字列を組み立てた cmd.exe /c を使って tw.cmd を呼び出してはいけません。ホストが各値につき 1 つの引数を保持できない場合は、twitter_automation_cli_unconfirmed として停止してください。

tw task create --surface reply --direction <condensed_request> --count <5..10> --json

コマンド実行の結果全体を保持してください。実行によって session_id が返された場合は、同じセッションを終端状態になるまでポーリングしてください。完全な CLI エンベロープが届くまでは状態を invoking のままにし、継続用ハンドルを破棄して output のみを取り出してはいけません。

2. 自動検出と下書きの生成に従う

受け入れられたエンベロープの正確な next コマンドに従ってください。タスクの作成または再起動で同じ正確なタスク表示継続コマンドが繰り返し返される場合は、その読み取り専用の継続コマンドを、1つの tw task wait <task_blueprint_ref> --timeout 900 --include-drafts --json コマンドにまとめます。このコマンドはCLI内で待機し、最終タスクと、すべての正確な下書き、ソース、レビュー参照、レビュー継続コマンドをまとめて返します。この一連の処理で、モデルからタスク表示を繰り返しポーリングしたり、個別に下書き表示コマンドを実行したりしないでください。グローバルリストや最新のレコードで代用しないでください。

タスク待機が task_wait_timeout を返した場合は、現在のタスク状態と、返された正確な待機継続コマンドをユーザーの選択肢として表示します。別の待機を開始したり、代わりの作業を自動的に作成したりしないでください。

CLIが下書きとレビューの選択肢を返したら、返された対象と内容の組み合わせをまとめて提示し、項目ごとの判断を待ってください。未達、失敗、停滞状態、または要求数より少ない下書きが返された場合は、その状態を正確に表示し、返された選択肢だけを提示してください。代わりの作業を自動的に作成しないでください。

3. 下書きと予定されている変更をレビューする

• 受け入れられたCLIエンベロープの next にあるコマンドだけを使用してください。読み取り専用の確認継続コマンドはそのまま実行します。承認、拒否、スキップ、再起動、キャンセル、Xの変更コマンドは選択肢として提示し、明示的な判断を受けた後に、対応する正確なコマンドを1回だけ実行します。省略されたレビューは保留のままにします。1つの判断が失敗した場合、成功した判断を再実行せず、返された状態を使って未解決の判断だけを求めてください。
• 返された正確な scheduled_task_ref をすべて記録してください。スケジュール設定は完了ではありません。いずれかの参照が scheduled または running を報告している間は、セッションをアクティブに保ち、その参照に対して tw scheduler show <scheduled_task_ref> --json を15秒以内の間隔でポーリングしてください。デーモンが管理する予約を早めるためだけに tw scheduler execute を実行しないでください。
• 参照が scheduled または running でなくなったら、tw scheduler evidence <scheduled_task_ref> --json で1回確認してください。succeeded を送信済みとして扱えるのは、決定的なスケジューラ証拠がある場合だけです。最終応答に送信済み／未送信の決定的な結果がまだない場合は、その正確な論理タスクに対して tw action snapshot verify --task <task_blueprint_ref> --json を1回実行してください。項目の verified は送信済み、not_complete は未送信、inconclusive は結果不明として報告します。スナップショットを繰り返したり、結果を別の意味に解釈したりしないでください。paused または waiting_review の参照にはユーザーの操作が必要です。そのブロッカーを表示し、他のすべての参照については監視を続けてください。
• ステータスに変化があったポーリングラウンドの後は、元の番号付き下書き対応を使って簡潔な更新を1回公開し、すべての下書きを Sent、Not sent yet、Needs attention のいずれか1つの見出しの下に配置してください。Sent は決定的な証拠がある succeeded に限り、Not sent yet は scheduled または running に限ります。ブロック中、失敗、停止中、復旧中、結果不明の状態は Needs attention に分類し、未送信が確定している結果は not sent、不確定な結果は outcome unknown と区別してください。outcome unknown を nothing sent と書き換えないでください。
• ポーリングラウンドで変化がなかった場合は、監視が継続中であることをユーザーが確認できるよう、60秒ごとに少なくとも1回、番号付きの分類全体を再掲してください。返されたすべての参照が最終状態になるか、ユーザーがスキップするか、ユーザーの判断待ちになるまで続けます。すべての下書きがスケジュール済みであることだけを理由に、返信フローを終了しないでください。

複数の内容レビューが保留中の場合は、それぞれの正確な対象、返信テキスト、review_ref を含めて、番号付きの一覧としてまとめて提示してください。項目ごとの明示的な判断マップを求めてください。複数の返信を「すべて承認」にまとめたり、単独の判断を一括変更の権限として扱ったりしないでください。各内容の承認が許可するのは、1件の正確な返信変更だけです。

対象や参照を推測しないでください。

4. 変更と失敗に対処する

以下の各新規タスクでは、更新チェックと通常の事前確認が実行されます。新規タスクのみ、完全なチェックを強制せずに最新の準備状況を再利用します。レビュー、監視、再作成では、準備状況が無効になっていない限り、現在の準備完了結果を再利用します。

• 正確なタスクで execution_status=failed かつ restart_allowed=true と報告された場合は、失敗コードを提示し、再起動するか停止するかの明確な選択肢を1つ提示してください。再起動する場合は、tw task restart <task_blueprint_ref> --json をちょうど1回実行し、ok=true を確認して、同じ論理タスクに対して同じ自動検出ポーリングの手順を再開してください。再起動によって作成されるのは、ミューテーション前の新しい実行1件だけです。重複したタスクが作成されたと主張したり、古い試行がキャンセルされたと主張したりしてはいけません。同じセッションで再起動を2回試みても失敗した場合は停止し、正確なブロッカーを報告してください。
• tw scheduler cancel が logical_workflow_terminalization.status=pending を返した場合は、関連するワークフローのクリーンアップが保留中であることをユーザーに伝え、recheck_after_seconds（現在は60）以内に正確なタスクを再確認してください。不変のスケジューラーレコード自体が期限切れになるとは説明しないでください。
• 下書きが存在し、返信のミューテーションが scheduled、running、paused、waiting_review のいずれでもなく、証拠も不明でない場合は、変更されていない単一のソースについて文面だけを変更するには tw draft redraft を使用し、新しいコンテンツレビューを必須としてください。「最初からやり直す」「候補が違う」、または方針、ソース、切り口、対象の変更を求められた場合は、現在のコンテンツレビューをすべて表示し、保留中の下書きをスキップすることについてユーザーに確認してください。確認後、確認済みの各参照に対して tw plan review skip <review_ref> --json を1回ずつ実行し、data.review.status=skipped を確認してから、最新の要約された方針と件数で新しいタスクを1件作成してください。過去のタスクは記録されたままです。権限が引き継がれることはありません。
• 返信のミューテーションが scheduled、running、paused、waiting_review のいずれかであるか、証拠が不明な場合は、再起動したり、返信を置き換えたりしてはいけません。復旧判断の項目に従ってユーザーが明示的に決定するまで、正確なスケジュール済み参照の監視を続けてください。
• recovery_required のスケジュール済み参照、または結論が出ていないスケジュール済み参照については、永続的な証拠分類とともに正確な scheduled_task_ref を提示し、「監視を続ける」「スキップ」「キャンセル」「報告」のいずれかをユーザーが明示的に決定するまで停止してください。「スキップ」が明示された場合は、tw scheduler skip <scheduled_task_ref> --json を1回実行し、data.outcome_acknowledged=true を必須としてください。その後は監視を終了し、スキップ済みとして Needs attention に記載し続けてください。永続的な結果は outcome unknown のままであり、確認応答は後続のセッションにも引き継がれます。スキップによって、再試行、再作成、置き換え、キャンセル、ミューテーションが許可されることはありません。ユーザーがその正確な参照を明示的に指定した場合に限り、「キャンセル」を実行してください。その場合は tw scheduler cancel <scheduled_task_ref> --json を1回実行し、返されたステータスを確認したうえで、上記の終了処理の再確認ルールに従ってください。スキップ済みの参照は、残りの参照で返信フローを完了する際のブロッカーではなくなります。
• コンテンツレビューが却下またはスキップされた場合、ミューテーションは発生しません。
• ディスパッチの ActionRecord がなく relay_unavailable と報告された場合、および reply:blocked_before_dispatch、dispatched_at なし、confirmation_state=not_required を伴う action_preparation_failed は、送信されていないことが確定しているものとして扱ってください。ActionRecord または EvidenceRecord の件数だけでは、監査証拠にすぎず、ディスパッチされたことの証明にはなりません。
• 再試行で受け付けるのは、完全に一致し変更されていない下書き1件のみです。現在のタスクから返された参照、または「以前の作業を確認」で系譜が正確に一致した参照から、正確な対象とテキストの組を特定してください。モードが変わったという理由だけで完全なチェックを強制せず、新しい正確なアクションタスクに対して更新チェックと通常の事前チェックを実行し、新しい正確なアクションのドライランを1回開始してください。その組を提示し、ディスパッチ前に新たな明示的承認を得てから1回だけディスパッチしてください。複数の再試行を求められた場合は、ユーザーに1件を選んでもらってください。後続の各組には、個別の正確なアクションフローと承認が必要です。古いスケジュール済みタスク参照を実行または再スケジュールしたり、そのタスクやコンテンツの承認を引き継いだりしてはいけません。
• 番号付き下書きの対応関係が古い場合、対象またはテキストが変更されている場合、または現在のタスクにも系譜が一致する過去の作業の参照にも、ディスパッチ前であることを確定できる証拠がない場合は、現在の正確な下書きまたは参照を尋ねるか、不明として停止してください。不明、ディスパッチ後、unknown_confirmation、確認済み、またはその他の結論が出ていない結果は、いずれもこの再試行フローに進めてはいけません。その場合は、outcome unknown を保持したサニタイズ済みの問題レポートを作成するか、上記の復旧判断に従ってユーザーから明示的なスキップの決定を得る必要があります。

過去の作業を確認する

ユーザーが以前のタスクまたはエージェントセッションで行った返信作業の結果を尋ねた場合は、このパスを使用します。これは読み取り専用の証拠確認と誠実な報告であり、以前のタスクの調査、生成、レビューのフローを再開することはありません。

1. 必須の事前確認を実行してから、tw scheduler list --json を実行します。リスト出力に示されている系譜フィールド（task_blueprint_ref、manual_request_ref、work_cycle_id）を使って、ユーザーが指す作業に該当する参照を照合します。参照を推測したり、タイムスタンプから推定したりしてはいけません。系譜が曖昧な場合は、候補のタスクを提示し、正確なタスクをユーザーに特定してもらいます。
2. 各参照について、tw scheduler show <scheduled_task_ref> --json と tw scheduler evidence <scheduled_task_ref> --json で確認します。返信が終端状態でも、送信済みか未送信かの結論が出ていない場合は、該当する正確な論理タスクに対して tw action snapshot verify --task <task_blueprint_ref> --json を1回実行します。
3. ライブモニタリングと同じ真偽判定ルールに従って報告します。確定的なスケジューラー証拠または項目の verified には 送信済み、scheduled または running に限って 未送信 とし、それ以外はすべて 要確認 に分類します。項目の not_complete は未送信、inconclusive は結果不明です。
4. 既存の基準に従い、永続的な証拠によって未配信が確定している参照は再試行フローに進められます。結果が不確定な参照は、監視の継続、スキップ、キャンセル、または報告の判断に従い、再試行フローには進めません。

このパスでは、以前の参照を再承認、再スケジュール、または実行することはありません。また、証拠で裏付けられない結果を主張することもありません。

正確なアクションモード

CLI の契約で受け付けられる対象を正確に1つ、最終返信を正確に1つ指定する必要があります。プロフィール URL は返信先ではありません。

1. 安全な argv／stdin 処理を通じて、tw action reply <exact_target> --text <exact_reply> --dry-run --json を実行します。
2. 正確な対象と返信の全文、ドライランの結果、意味上の操作内容を提示し、明示的な承認を求めます。
3. 対象または文字が少しでも変更された場合は、新しいペイロードとして扱い、新たなドライランと承認を必要とします。
4. ユーザーが明示的に承認した後、現在の正確なアクションフローの事前確認結果を再利用し、tw action reply <same_target> --text <same_reply> --json を1回だけ実行します。
5. 受け付けられた CLI の結果を確定情報として扱います。complete が返された場合にのみ完了と報告します。それ以外の場合は、その状態、エラー、安全な選択肢を示します。結果が不明な場合に再試行したり、テスト返信を送信したりしてはいけません。

境界

• タスクモードでは、返信案を作成できる対象が 5..10 件の、具体化された手動タスクを1つ作成します。タスク／ソースのレビューを作成したり、一括変更の承認を付与したりすることはありません。
• 正確なアクションモードで制御するのは、対象とテキストの組み合わせ1件のみです。タスク／プランの系譜の対象外です。
• 新規投稿の作成、引用、いいね、保存、フォロー、またはブラウザー UI の直接操作をしてはいけません。
• 診断情報に返信テキスト、対象、生のペイロード、非公開の参照、ローカルパスを含めてはいけません。

問題の報告

明示的な報告依頼、返された CLI エラー、解決しないセットアップの繰り返し、または不明な証拠がある場合は、サニタイズ済みのメタデータを使用し、threadwave-preflight を問題報告専用モードで有効にします。対象、返信テキスト、タスクの指示は除外します。問題報告の生成では返信を送信しません。影響を受ける返信ごとに、永続的な証拠が裏付けるとおりに 送信済み、未送信、または 結果不明 と報告します。

返却形式

State: <discovering | generating | needs content approval | needs exact-action approval | monitoring | complete | blocked | unknown>
Mode: <task | exact-action>
Count: <requested / valid drafts / content-approved / scheduled, or n/a for exact-action>
Reviews: <current content reviews with exact review_ref; none before drafts or for exact-action>
CLI messages: <every returned warning or error message; none when empty>
Waiting for you: <matching per-item content decisions; approve this exact target/text pair; or none>
你可以 / You can: <two to four verbatim-sayable options valid at the current gate>
Next: <one returned ref/action or stop>
Outcome: <sent | not sent | not sent yet | outcome unknown, per reply>
Issue report: <copy/paste only; preserves the durable outcome>

你可以 / You can: の行には、現在のゲートで実際に選択可能な項目のみを記載します。具体的には、番号が付いた正確な内容に関する判断、提示された正確なアクションの対象と返信の組み合わせ、提示された参照、またはタスクテンプレートです。ユーザーがそのまま返信できる表現にし、選択された言語にローカライズします。現在のゲートで許可されている範囲を超えるアクションを提案してはいけません。