twitter-agent

Twitter Agent

通常の日次の、レビュー承認を経る成長ループを実行します。ThreadWave は、戦略、計画、タスク、下書き、スケジューラー、エビデンス、復旧に関する契約を提供します。

対象範囲

次の場合にこのスキルを使用します。

• 有効な戦略が存在しない場合の、初回戦略の初期化；
• 有効な戦略に基づく日次計画の作成；
• 戦略、計画、タスク／ソース、下書きのレビュー提示；
• スケジューラーの確認と、指定されたスケジュール済みタスクの管理；
• 成果の要約と、範囲を限定した改善；
• 新しい作業を作成する前に、既存の保留中レビューを再開する場合。

即時に投稿または返信する内容が1件だけの場合は、このワークフローを使用しないでください。その場合は twitter-post と twitter-reply を使用します。

言語

threadwave-preflight を通じて、明示されたユーザーの希望、最新のメッセージ、会話の言語、英語の順に、en または zh-CN を選択します。

コマンド、JSON キー、参照値、レビュー状態、安定したエラーコードは英語のままにします。レビュー内容全体は元の言語で提示し、承認済みの内容を黙って翻訳しないでください。

必須の事前確認と初期化フロー

新しい日次エージェントタスクを開始するたびに、スキル名で threadwave-preflight を有効化します。呼び出し元のスキル名、変更していない日次エージェントの意図、必要な機能ファミリーを渡します。タスクに必要なスキルの更新を確認した後、通常の CLI 事前確認を実行します。この確認では、12 時間操作がない状態になるまで準備状態を再利用し、古くなった場合または無効化された場合にのみ完全な確認を実行します。レビューの判断だけを理由に事前確認を再実行しないでください。すべての名簿上のスキルバージョンがサポート対象と確認され、最新バージョンの状態が判明しているか、事前確認の契約にある未確認インデックスの選択肢に基づいて明示的に続行した状態の、最新の ready 結果がない限り、tw コマンドを実行しないでください。

選択された機能ゲートでは、context、strategy、plan、task、draft、scheduler が必要です。threadwave-preflight が利用できない場合、またはスキル、CLI、拡張モジュールに不足、非互換、未確認があると報告された場合は、このリクエストを維持し、承認後に事前確認から https://www.threadwave.xyz/cli/setup/agent.md を実行させてください。サポート対象の古いスキルまたは CLI については、事前確認に従って、ブロックせずに続行するか更新するかを選択します。

セットアップの準備が整ったら、元の日次エージェントの意図を再開します。セットアップの準備が整ったことは、コンテンツの承認を意味しません。

コンテキストの再開

次を1回実行します。

tw context resume --format json

返された選択済みアカウントバインディング、アクティブな実行、進行中の作業サイクル、保留中のレビュー、保留中の復旧、主要な次のアクションを使用します。返された主要な次のアクションは、対応する 你可以 / You can の選択肢とともに、必ずユーザーに提示してください。選択済みのバインディングがないまま複数のアカウントバインディングが存在する場合は、セットアップを通じて対象のアカウントをユーザーに明示してもらいます。アカウントを推測してはいけません。

新しい戦略／計画の作業を作成する前に、「保留中の復旧」セクションを通じて保留中の復旧を提示します。重複する提案を作成する前に、保留中のレビューを提示します。

保留中の復旧

保留中の復旧は、ユーザーが明示的な判断を下すまで、新しい戦略や計画の作業のみをブロックします。セッションごとに pending_recovery セット全体を、各正確な recovery_ref、ステータス、安全な作業サイクルのコンテキストを含む番号付きリストとして一度だけ提示してください。ターゲット、内容、非公開の参照情報は決して公開しないでください。

番号付きの項目ごとの判断マップ、または表示された変更のない正確なセットに対する明示的な「すべてスキップ」を受け付けます。

• 調査：リンクされたスケジューラー参照を tw scheduler show <scheduled_task_ref> --json と tw scheduler evidence <scheduled_task_ref> --json で調査し、永続的な記録が裏付ける内容のみを報告してください。
• スキップ：スケジューラーの該当ステータスを一覧表示し、tw scheduler show <scheduled_task_ref> --json で参照を照合して、表示された各正確な recovery_ref を recovery_required ステータスのスケジュール済みタスク1件に特定してください。その後、tw scheduler skip <scheduled_task_ref> --json を1回呼び出し、data.outcome_acknowledged=true を必須条件として確認してください。明示的な「すべてスキップ」の場合は、変更のない正確な表示項目ごとにこれを実行してください。いずれかの参照を一意に特定できない場合、その項目については停止し、成功したスキップを再実行しないでください。この確認は永続的で、今後の保留中セットから復旧項目を削除します。結果は「不明」のままで、「未送信」にはなりません。また、スキップによって再試行、置き換え、キャンセル、変更が許可されることはありません。
• 報告：サニタイズ済みメタデータを使用して、Issue Report の引き継ぎを行ってください。

キャンセルは別の、より限定的な操作です。ユーザーが復旧に関連付けられた正確な scheduled_task_ref を1つ明示し、それをキャンセルするよう依頼した場合に限り、tw scheduler cancel <scheduled_task_ref> --json を1回呼び出し、返されたステータスを確認して、返された再確認の指示に従ってください。キャンセルによってそのスケジューラー記録は終端状態になりますが、別個の pending_recovery 項目は削除されません。これらには上記の判断が引き続き必要です。

判断されていない保留中の復旧は新しい戦略や計画の作業を引き続きブロックします。スキップ済みの復旧はブロックしません。

戦略の初期化

確認してください：

tw strategy status --json
tw strategy review list --json

次のように振り分けます。

• 有効な戦略があり、保留中の戦略レビューがない場合：日次実行に進みます。
• 保留中の戦略レビューがある場合：そのレビュー全体をそのまま表示し、判断を求めて停止します。
• 有効な戦略がなく、保留中のレビューもない場合：tw strategy create --mode blank --json を実行し、返されたレビュー全体を表示して停止します。
• 古い戦略に明示的な改善ルートがある場合：結果を要約し、改善提案を作成します。有効な戦略を直接変更してはなりません。

表示された正確な戦略が明示的に承認された場合：

tw strategy review approve <review_ref> --json
tw strategy activate --review <review_ref> --json

承認によって同じレビュー範囲の証明が返された場合にのみ、有効化を実行してください。却下、スキップ、編集は、ユーザーがその判断を明示的に選んだ場合にのみ行ってください。

日次実行

有効な戦略が存在したら、references/daily-run.md を最後まで読み、内容に従ってください。表示される承認境界を一度に1つずつ処理します。

通常の順序は次のとおりです。

1. 保留中の復旧（永続的に確認済みの参照はブロックしません）；
2. 保留中の戦略レビュー；
3. 保留中の計画レビュー；
4. 保留中のタスク／ソースレビュー；
5. 保留中のドラフト／コンテンツレビュー；
6. 既存のスケジューラー状態；
7. 未解決の作業と競合しない場合に限り、新しい日次計画を作成します。

保留中のレビューを避けるために、2つ目の計画を決して作成しないでください。

承認モデル

ユーザーが対応する実行を依頼した場合、事前確認、コンテキストの再開、読み取り専用のステータス／一覧／表示コマンド、戦略提案の作成、計画提案の作成、範囲を限定した結果の要約は自動的に実行してください。

次の各操作の前には必ず一時停止してください。

• 戦略の承認／却下／スキップ／編集；
• 計画の承認／却下／スキップ／編集；
• タスク／ソースの承認／却下／スキップ／編集；
• ドラフト／コンテンツの承認／却下／スキップ／編集；
• 保留中の復旧に関する調査／スキップ／報告の判断（復旧の「すべてスキップ」も含む）；
• ユーザーが明示的に指定していない手動のスケジューラー実行またはスケジュール変更。

承認が適用されるのは、表示された正確な review_ref、コンテンツのハッシュ／範囲、ターゲット、テキストに限られます。範囲が変更された場合、以前の承認は無効になります。

スケジューラーの状態

実際のスケジューラーの状態を報告するには、tw scheduler list --json、show、status を使用してください。返された結果に正確な scheduled_task_ref と予約が含まれている場合に限り、「スケジュール済み」と伝えてください。提案または承認がすでにスケジュール済みだと主張してはいけません。

tw scheduler execute <scheduled_task_ref> --json には、明示的な参照先とユーザーからの依頼が必要です。レビュー、リスク、クールダウン、ペーシング、エビデンスの各ゲートを回避することはできません。

イシューレポート

明示的なレポート依頼があった場合、またはレポート対象となる失敗が発生した場合は、サニタイズ済みの診断メタデータを使い、イシューレポート専用モードで threadwave-preflight を有効にしてください。この引き継ぎ中にワークフローを再実行したり、確認を更新したりしてはいけません。

スイート／CLI の不整合、ユーザーに起因しないセットアップ失敗の繰り返し、予期しないワークフロー契約違反、または変更エビデンスが不明もしくは結論不明の場合は、レポートを作成してください。レビュー待ち、ペーシング、Chrome／認証／決済／X ログイン、またはその他の想定されるユーザーゲートについては、レポートを作成しないでください。

コピー＆ペーストできるよう、サニタイズ済みの Markdown を必ず提示し、何も送信されていないことを明記してください。

返却形式

ローカライズされたラベルを使用し、該当する行のみを含めてください。

State: <ready | waiting for you | needs approval | blocked | scheduled | complete>
Completed: <verified records or transitions>
Preflight: <suite / CLI / setup / agent capability>
Review: <full exact proposal or draft plus its scope>
Problem: <stable code and localized meaning>
Waiting for you: <one exact decision>
你可以 / You can: <two to four verbatim-sayable options valid at the current gate>
Next: <one next workflow step>
If you approve, I will run: <exact decision command>
Issue report: <generated for copy/paste; nothing sent>

你可以 / You can: の行には、現在のゲートで実行可能な選択肢のみを記載してください。具体的には、番号付きの決定事項、表示された参照先、または返された主な次のアクションに限ります。ユーザーがそのまま返信できる表現とし、選択された言語にローカライズしてください。現在のゲートで許可されている範囲を超えるアクションを提示してはいけません。

生のエンベロープ、決定に関係のない非公開の参照先、非公開パス、ハンドル（デフォルトでは非表示）、生のプロンプトを公開しないでください。