Twitter Post
アドホックなツイート作業を独立したフラットなピアとして扱います。twitter-automation を有効化したり依存したりしないでください。そのピアがここにルーティングする可能性はありますが、このスキルがプレフライトと投稿ワークフロー全体を所有します。
モードを選択する
ユーザーがトピック、方向性、望ましい結果、下書きリクエスト、または 1 から 5 のカウントを提供した場合はタスクモードを選択します。1 より大きいカウントはタスクモードを選択します。
ユーザーが 1 つの完全な最終投稿を提供し、そのテキストを今すぐ公開することを明示的に希望する場合にのみ厳密アクションモードを選択します。
- タスクカウントが指定されていない場合はデフォルトで
1に設定します。 1から5の整数のみを受け付けます。5を超えるカウントの場合は、ユーザーに明示的に分割するよう依頼します。複数の提案を自動的に作成しないでください。- 複数の完全な最終テキストがある場合は、ユーザーに方向性ベースのタスクを 1 つ希望するのか、個別の厳密アクションを希望するのかを尋ねます。正確なペイロードを黙って生成的方向に変換しないでください。
- 正確性と方向性が不明確な場合は、
twを呼び出す前に簡潔な質問を 1 つ行います。
タスクテンプレート
タスクモードに入るとき、およびリクエストが方向性を形成するにはあまりにも曖昧な場合は、自由形式の質問の代わりにローカライズされたテンプレートを 1 つ提供します。
Post task template:
Topic/direction: <what to write about>, count <1–5>
Optional: tone, audience, must-include or must-avoid points
Example: Topic: why small teams should automate release notes, count 3
发推任务模板:
主题/方向:<要写什么>,条数 <1–5>
可选:语气、受众、必须包含/避开的点
示例:主题:为什么小团队应该自动化 release notes,3 条
不足が発生した場合や、提案が却下された後にユーザーが言い換えを希望する場合も、同じテンプレートを再利用します。
言語
明示的な好み、最新のメッセージ、会話の言語、次いで英語の優先順位で、英語または簡体字中国語で応答します。正確な投稿テキストを翻訳したり正規化したりしないでください。要件を追加せずにタスクの方向性を維持します。
必須プレフライト
新しい投稿タスクまたはエージェントセッションの開始時、およびそのコントラクトで定義された準備状態の無効化後には、スキル名で threadwave-preflight を起動します。このスキル名、選択されたモード、変更されていないリクエスト、および必要な機能ファミリを渡します。成功した結果は、同じセッション内での変更されていないレビュー決定とワークフロー継続のために再利用します。レビュー決定のためだけにプレフライトを再実行しないでください。現在のまたは再利用可能な準備完了結果なしに tw を呼び出さないでください。
CLI 1.0.21 と、task、draft、plan、scheduler、action の各コマンドファミリが必要です。スキル、CLI、または拡張機能の状態がない場合は、リクエストを保持したまま https://www.threadwave.xyz/cli/setup/agent.md にルーティングします。
タスクモード
1. 1 つの境界付き提案を作成する
方向性を 1 つの安全な引数として渡します。ユーザーコンテンツをシェル構文に連結しないでください。次のセマンティック相当のコマンドを実行します。
tw task create --surface tweet --direction <exact_user_direction> --count <1..5> --json
schema_version=tw_cli_harness_v1、ok=true、および返された manual_request_ref、task_blueprint_proposal_ref、review_ref が必要です。タスク作成は X への変更を許可せず、下書きやスケジュールされた投稿が既に存在すると主張してはいけません。
2. タスク提案をレビューする
返されたレビュー参照のみを tw task review show <review_ref> --json で検査します。表面、方向性、カウント、取得ルート、安全な範囲を提示します。明示的な承認を待ちます。
承認後、再利用可能な同一タスクプレフライト結果の下で、tw task review approve <same_review_ref> --json を 1 回呼び出します。明示的に一致するユーザー決定の後でのみ、拒否またはスキップします。変更された方向性、カウント、参照、または提案ハッシュに承認を移さないでください。
承認出力が空白、部分、または解析不能な場合は、未確定として扱い、まだ承認を再度呼び出さないでください。読み取り専用のリカバリとして tw task review show <same_review_ref> --json を 1 回実行します。ok=true、data.review.status=approved、および返された task_blueprint_ref が返された場合のみ続行します。同じ変更されていない review_ref とスコープに対して決定的に data.review.status=pending が返された場合、承認はサーバーに到達していません。ユーザーに伝え、その変更されていない参照に対する承認の再試行を 1 回、明示的なはい/いいえの選択肢を提供します。2 回目の未確定な結果はフローを停止します。リカバリ読み取り自体が失敗または決定的でない場合、CLI コントラクトのずれとして停止します。
その承認によって返されたすべての正確な task_blueprint_ref をキャプチャします。固定 180 秒の期限を開始し、すぐに各 task_blueprint_ref を tw task show <task_blueprint_ref> --json で検査し、その source_status=awaiting_selection である間のみ繰り返します。各再試行の前に min(15 秒, 残り時間) 待機し、期限が最後の読み取りを受け取るようにします。tw task review list、グローバルレビューリスト、または最新のレビューを使用してこのタスクのソースレビューを発見しないでください。
source_status=source_reviews_created の場合、source_review_refs_by_status.pending のみをフォローします。pending が空で approved または archived が空でない場合、そのタスクに保留中のソース決定はありません。3 つのバケットすべてが空の場合、応答を CLI コントラクトのずれとして扱い、停止します。no_valid_targets_found を不足として扱い、他のターミナルソースステータスについては CLI が返す参照を直接フォローします。
3. 返されたワークフロー参照をフォローする
CLI によって返された参照と次のアクションのみを使用します。
tw task reviewを介して手動のtask_proposalまたはsource_selectionレビューを検査および決定します。tw draft show <artifact_ref> --jsonを介して生成されたアーティファクトを検査します。tw plan review show <review_ref> --jsonを介して各コンテンツレビューを検査します。- 各コンテンツレビューを個別に承認、拒否、またはスキップします。
tw scheduler showおよびtw scheduler evidenceを介して返された各スケジュール済みミューテーションを検査します。
次のレビュー、アーティファクト、ターゲット、またはスケジュールされたタスクを推測しないでください。複数の下書きレビューを「すべて承認」にまとめないでください。各コンテンツ承認は、1 つの正確なスケジュールされた X ミューテーションのみを許可できます。
4. 変更と不足を処理する
- 方向性/ソース/アングルの変更: 正確なスコープを表示した後、1 つの明示的な
tw task retask --taskまたは--batchリクエストを使用します。 - 同じ系統の文言変更: 正確なフィードバックを指定して
tw draft redraftを使用し、新しいコンテンツレビューを要求します。 - 要求より少ない有効な出力: 実際の有効数を報告します。項目を発明したり重複させたりしないでください。
- 承認されたタスクが固定タスク表示期限を過ぎて
source_status=awaiting_selectionで停止した場合: 正確なtask_blueprint_refを提示し、ユーザーに 1 つの明示的な選択肢を提供します。tw task restart <task_blueprint_ref> --jsonを 1 回実行して再起動する(ok=trueと返された新しい実行状態を確認し、同じ参照に対して固定タスク表示期限を再開します。再起動は新しい実行であり、重複タスクや古いディスカバリーがキャンセルされたという主張ではありません)、または停止して正確なブロッカーを報告します。再起動の呼び出しが失敗した場合、または参照が引き続き停止している場合は、1 回の失敗ラウンドとしてカウントします。同じセッションで 2 回の失敗ラウンド後、停止してブロッカーを報告します。 - 不明なスケジューラーまたはミューテーションの証拠: 再試行せずに停止します。正確な参照とその永続的な分類を提示し、1 つの明示的なユーザー決定を待ちます。監視を続ける、スキップする(
outcome unknownを承認し、監視を終了します。再試行や置換を許可しません)、tw scheduler cancelを介してその正確なユーザー指定のscheduled_task_refを 1 回キャンセルし、返されたステータスを確認する、またはサニタイズされた Issue Report を要求する。
厳密アクションモード
1 つの完全な最終投稿が必要です。改善、翻訳、短縮、拡張、空白の正規化、スペル修正、ハッシュタグの追加、または句読点の変更を行わないでください。
- 安全な argv/stdin 処理を通じて
tw action tweet --text <exact_text> --dry-run --jsonを実行します。 - 正確なテキスト全体、ドライラン結果、およびセマンティック操作を表示し、明示的な承認を求めます。
- 文字の変更は新しいペイロードとして扱い、新しいドライランと承認が必要です。
- 承認後、同じタスクのプレフライト結果を再利用し、
tw action tweet --text <same_exact_text> --jsonを 1 回ディスパッチします。 - 完了を報告する前に、
ok=true、action_ref、および決定的な証拠が必要です。不明な結果を再試行したり、確認のために 2 回目の投稿を送信したりしないでください。
境界
- タスクモードは
1..5の独立した可能な下書き項目を持つ 1 つの提案を作成します。バッチミューテーションの承認を許可しません。 - 厳密アクションモードは 1 つの投稿のみを制御し、タスク/プランの系列外にあります。
- 返信、引用、いいね、保存、フォロー、またはブラウザ UI を直接操作しないでください。
- 診断でユーザーコンテンツ、生のペイロード、プライベート参照、またはローカルパスを公開しないでください。
Issue Report
明示的なレポートリクエスト、CLI のずれ、繰り返される未解決のセットアップ、または不明な証拠については、サニタイズされたメタデータを使用して threadwave-preflight を Issue Report のみのモードで起動します。投稿テキストとタスクの方向性を除外します。何も送信されなかったことを明記します。
返却形式
State: <needs task approval | needs source approval | needs content approval | scheduled | complete | blocked | unknown>
Mode: <task | exact action>
Count: <requested / valid / approved / scheduled>
Review: <one exact current review>
Waiting for you: <one decision or setup action>
你可以 / You can: <two to four verbatim-sayable options valid at the current gate>
Next: <one returned ref/action or stop>
Issue report: <copy/paste only; nothing sent>
你可以 / You can: 行は、現在のゲートで実際に有効なオプション(正確な番号付き決定、表示された参照、またはタスクテンプレート)のみをリストし、ユーザーがそのまま返信できるように、選択された言語にローカライズして表現します。現在のゲートの権限を超えるアクションを提供することはありません。