twitter-post

Twitter 投稿

単発のツイート作業は、独立した対等なピアとして担当します。twitter-automation は有効化せず、依存もしないでください。このピアからこちらへルーティングされることはありますが、事前確認と投稿ワークフロー全体はこのスキルが担当します。

モードを1つ選択する

ユーザーがトピック、方向性、希望する結果、下書きの依頼、または 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 を有効化します。このスキル名、選択したモード、変更していない依頼内容、必要な機能ファミリーを渡します。これは、このタスクに関するスキルの更新を確認してから、通常の 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 の不変条件チェックを繰り返したり、受け入れられた結果を契約の不整合と解釈し直したりしてはいけません。
• ワークフローを続行するため、返された読み取り専用の next コマンドを実行します。レビュー、再開、キャンセル、または X への変更を伴うコマンドは選択肢として提示し、ユーザーが許可した正確なコマンドのみを実行します。
• ok=false の場合は、返された error.code、error.message、error.retryable を報告し、安全な next の選択肢のみを提示します。CLI エラーをモデルが作り出した診断に置き換えてはいけません。
• ワークフローの失敗段階は、CLI が failure_stage を返した場合に限り報告します。source_status、draft_status、タイミング、またはエラーコードから段階を推測してはいけません。このフィールドがない場合は、返された失敗情報のみを報告します。
• コマンドが完全なエンベロープを返さずに終了した場合は、task_dispatch_unconfirmed として停止します。この転送エラーは、ホスト側で確認する唯一の結果であり、タスクの重複実行を許可するものではありません。

タスクモード

1. 有界のタスクを1つ作成する

指示はデータとして扱い、シェル構文として扱わないでください。

• 真の引数配列を使った子プロセス API を備えるホストでは、変更していない指示を --direction 経由で一度だけ渡すことができます。
• Codex およびシェル／PTY コマンド文字列しか公開しないホストでは、プライベートな一時ディレクトリを1つ作成し、シェルによる補間ではなくファイルシステムツールを使って、変更していない指示を UTF-8 で書き込み、--direction-file 経由では安全なファイルパスのみを渡してください。ホストが権限をサポートしている場合は、一時ディレクトリ／ファイルへのアクセスを現在のユーザーに制限してください。
• コマンドが終端結果に達するまで、たとえ実行環境が session_id を返した場合でも、そのファイルを保持し、その後に一時ディレクトリを削除してください。指示をヒアドキュメント、シェル変数、手動で引用符を付けたコマンド、または PTY の write_stdin シーケンスに含めないでください。

次と意味的に同等のコマンドを実行してください。

tw task create --surface tweet --direction-file <private_utf8_path> --count <1..5> --json

--direction と --direction-file は相互に排他的で、どちらも同じトリミング済みの 1..4000 文字の値に正規化されます。task_direction_input_invalid が返された場合は、返された理由をすぐに提示してください。デーモン／バックエンドのタスクは受け付けられていないため、インラインのシェルテキストに切り替えて再試行しないでください。

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

2. 自動のソース取得と下書き生成に従う

受け付けられたエンベロープの next にあるコマンドに正確に従ってください。読み取り専用のタスク確認コマンドと下書き確認コマンドは、直接実行してください。同じタスクの表示を繰り返し続ける場合は、固定の15分の期限を設定し、読み取りの間隔を min(15 seconds, remaining time) にしてください。全体のリストや最新のレコードで代用しないでください。

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

3. 下書きとスケジュール済みの変更をレビューする

受け付けられた CLI エンベロープの next にあるコマンドのみを使用してください。読み取り専用の確認を続けるコマンドは、直接実行してください。承認、却下、スキップ、再開、キャンセル、および X 変更のコマンドを選択肢として提示し、明示的な判断を受けた後に、該当するコマンドを正確に一度だけ実行してください。未提示のレビューは保留のままにしてください。

次にレビューする項目、成果物、対象、またはスケジュール済みタスクを推測しないでください。複数の下書きレビューを「すべて承認」にまとめないでください。各コンテンツの承認で許可されるのは、正確に1つのスケジュール済み X 変更のみです。

4. 変更と不足への対応

• 方向性／ソース／角度の変更：対象範囲を正確に示したうえで、tw task retask --task または --batch のいずれかを明示的に1回だけリクエストします。
• 同じ系統内での文言変更：正確なフィードバックを添えて tw draft redraft を使用し、その後、新たなコンテンツレビューを必須とします。
• 有効な出力が依頼数に満たない場合：実際の有効件数を報告します。項目を捏造したり重複させたりしてはいけません。
• 固定のタスク確認期限を過ぎてもタスクが停滞している場合：正確な task_blueprint_ref を提示し、ユーザーに明示的な選択肢を1つ提示します。tw task restart <task_blueprint_ref> --json を1回実行して再起動する（ok=true と返された新しい実行状態を確認し、その後、同じ ref に対して固定のタスク確認期限を再開する。再起動は変更前の新たな実行であり、タスクの重複作成でも、以前のディスカバリーがキャンセルされたという主張でもありません）、または停止して正確なブロッカーを報告します。再起動の呼び出しが失敗した場合、または ref が引き続き停滞する場合は、失敗ラウンド1回として数えます。同じセッションで失敗ラウンドが2回に達したら、停止してブロッカーを報告します。
• スケジューラーまたは変更の証拠が不明な場合：再試行せず停止します。正確な ref とその永続的な分類を提示し、ユーザーに明示的な判断を1つ求めて停止します。選択肢は、監視を続ける、スキップする（outcome unknown を了承して監視を終了する。再試行や代替を許可するものではありません）、ユーザーが指定した正確な scheduled_task_ref を tw scheduler cancel で1回キャンセルし、返されたステータスを確認する、またはサニタイズ済みの問題報告を依頼する、のいずれかです。

正確なアクションモード

最終投稿は正確に1つだけとします。改善、翻訳、短縮、拡張、空白の正規化、スペルの修正、ハッシュタグの追加、句読点の変更をしてはいけません。

1. 安全な argv／stdin 処理を通じて tw action tweet --text <exact_text> --dry-run --json を実行します。
2. 正確な全文、dry-run の結果、意味上の操作を提示し、明示的な承認を求めます。
3. 文字を1つでも変更した場合は、新たなペイロードとして新しい dry-run と承認を必須とします。
4. 承認後、現在の ready 結果を再利用し、tw action tweet --text <same_exact_text> --json を1回実行します。
5. 受理された CLI の結果を正式なものとして扱います。完了を返した場合に限り、完了として報告します。それ以外の場合は、その状態、エラー、安全な選択肢を示します。結果が不明な場合は、決して再試行したり、確認のために2件目の投稿を送信したりしてはいけません。

境界

ローカルメディアを使った厳密アクションモード

ローカルメディアがサポートされるのは、手動のオリジナル投稿を1件作成する場合のみです。内容が空でない正確なテキストと、順序を指定したPNG/JPEGファイル1～4点（各5 MiB以下）、またはMP4ファイル1点（512 MiB以下）を使用できます。ファイルは読み取り可能な絶対パスの通常ファイルである必要があり、シンボリックリンクは使用できません。このフローでは、メディアをタスク／下書き／スケジューラのペイロードや、返信／引用アクションに含めないでください。URLからのダウンロード、生成、編集、画像と動画の混在、トランスコード、未対応のGIF/MOVファイルへの置き換えは行わないでください。

1. 通常の事前確認の後、tw capabilities --format json を確認します。data.browser_relay.local_media_upload=true と、action ファミリーに属する両方のメディアコマンドが必要です。満たさない場合は停止し、次の選択肢としてセットアップ／更新を提示してください。CLIのバージョンだけからメディアのサポートを推測しないでください。
2. テキストとパスは別々のargv値として渡します。tw action tweet --text <exact_text> --media <absolute_paths...> --dry-run --json を実行します。これはXを開いたり、アクション記録を書き込んだりせずにファイルを検証します。
3. 正確なテキスト、ホストで表示できる場合は順序どおりのメディアプレビュー、返された data.media_manifest（ベース名、種類、サイズ、SHA-256）と data.artifact_hash を表示します。URLやファイル名だけでは、メディアを確認した証拠になりません。プレビューを表示できない場合はその旨を伝え、ユーザーにファイルを確認してもらってください。該当する正確なテキストと順序どおりのファイルについて、明示的な承認を求めます。
4. 承認後、tw action tweet --text <same_exact_text> --media <same_absolute_paths...> --expected-artifact-hash <reviewed_artifact_hash> --json を1回だけ実行します。CLIが返したハッシュを変更せずに使用してください。自分で計算、推測、置換してはいけません。テキスト、バイト列、画像の順序、モード、点数を変更する場合は、新たにdry-runを行い、承認を得る必要があります。同一のバイト列のファイル名変更だけでは、同一性は変わりません。
5. data.status=confirmed であり、返された data.status_url と、期待されるメディアの種類／点数が観測されたものと一致する場合にのみ、送信済みと報告します。証拠が不明な場合、または最終エンベロープがない場合は、2回目のアップロードや送信をしてはいけません。ユーザーが明示的に復旧方法を決定するまでは、読み取り専用の確認方法のみを使用してください。

中文：本流程仅支持一条手动原创推文：准确原文加 1–4 张有序 PNG/JPEG（每张最多 5 MiB），或一个 MP4（最多 512 MiB）。先检查媒体能力，再 dry-run；展示原文、可用预览、文件顺序和返回的哈希，获得明确批准后带同一哈希发送一次。文字、文件内容、顺序或数量变化须重新审核；结果未知时不得重传或重发。任务、定时、回复、引用、远程链接和转码不在本流程内。

共通の境界

• タスクモードでは、実体化された手動タスクを1件作成し、投稿下書きを 1..5 件作成できる可能性があります。タスク提案やソース選択のレビューは作成されず、一括変更の承認も付与されません。
• 厳密アクションモードで操作できる投稿は1件のみで、タスク／プランの系譜には含まれません。
• 返信、引用、いいね、保存、フォローを行ったり、ブラウザーUIを直接操作したりしないでください。
• 診断情報にユーザーコンテンツ、生のペイロード、プライベート参照、ローカルパスを含めないでください。

問題の報告

明示的な報告依頼、CLIから返されたエラー、解消されないセットアップの繰り返し、または証拠が不明な場合は、サニタイズ済みのメタデータを使い、問題報告専用モードで threadwave-preflight を有効にしてください。投稿テキストとタスクの指示は除外します。何も送信されていないことを伝えてください。

返却形式

State: <invoking | discovering | generating | needs content approval | scheduled | complete | blocked | unknown>
Mode: <task | exact action>
Count: <requested / valid / approved / scheduled>
Reviews: <current content reviews with exact review_ref; none before drafts or for exact action>
Waiting for you: <matching per-item content decisions; one exact-action approval; 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: の行には、現在のゲートで実際に選べる選択肢のみを記載します。具体的には、番号付きの決定事項、表示済みの参照、またはタスクテンプレートです。ユーザーがそのまま返信できる表現にし、選択された言語に合わせてください。現在のゲートで許可された範囲を超えるアクションを提示してはいけません。