ThreadWave — Suite d'automatisation Twitter/X

Publication Twitter

Gérez les tweets ad-hoc de manière indépendante et plane. N'activez jamais et ne dépendez pas de twitter-automation ; ce pair peut vous rediriger ici, mais cette skill possède le pré-vol et l'ensemble du flux de publication.

Choisir un mode

Sélectionnez le mode tâche lorsque l'utilisateur fournit un sujet, une direction, un résultat souhaité, une demande de rédaction ou un nombre de 1 à 5. Tout nombre supérieur à un sélectionne le mode tâche.

Sélectionnez le mode action exacte uniquement lorsque l'utilisateur fournit un post final complet et souhaite explicitement que ce texte exact soit publié maintenant.

• Par défaut, un nombre de tâches manquant est fixé à 1.
• N'acceptez qu'un nombre entier de 1 à 5.
• Pour un nombre supérieur à 5, demandez à l'utilisateur de le diviser explicitement ; ne créez jamais plusieurs propositions automatiquement.
• Pour plusieurs textes finaux exacts, demandez si l'utilisateur souhaite une tâche basée sur une direction ou des actions exactes séparées. Ne transformez jamais des payloads exacts en directions génératives.
• Si la distinction entre exactitude et direction n'est pas claire, posez une question concise avant d'invoquer tw.

Modèle de tâche

En entrant en mode tâche — et lorsque la demande est trop vague pour former une direction — proposez un modèle de remplissage localisé au lieu de questions ouvertes :

Modèle de tâche :
Sujet/direction : <quoi écrire>, nombre <1–5>
Optionnel : ton, audience, points à inclure ou à éviter
Exemple : Sujet : pourquoi les petites équipes devraient automatiser les notes de version, nombre 3

发推任务模板：
主题/方向：<要写什么>，条数 <1–5>
可选：语气、受众、必须包含/避开的点
示例：主题：为什么小团队应该自动化 release notes，3 条

Réutilisez le même modèle en cas de manque ou après une proposition rejetée lorsque l'utilisateur souhaite reformuler.

Langue

Répondez en anglais ou en chinois simplifié selon la préférence explicite, le dernier message, la langue de la conversation, puis l'anglais. Ne traduisez et ne normalisez jamais le texte exact du post. Préservez la direction de la tâche sans ajouter d'exigences.

Pré-vol obligatoire

Activez threadwave-preflight par son nom au début de chaque nouvelle tâche de post ou session d'agent, et après toute invalidation de l'état de préparation définie par son contrat. Passez le nom de cette skill, le mode sélectionné, la demande inchangée et les familles de capacités requises. Réutilisez ce résultat réussi pour les décisions de révision inchangées et la poursuite du flux de travail dans la même session ; ne relancez pas le pré-vol pour une simple décision de révision. N'invoquez pas tw sans un résultat prêt, actuel ou réutilisable.

Exigez la CLI 1.0.21 ainsi que les familles de commandes task, draft, plan, scheduler et action. Un état manquant (skill, CLI ou extension) redirige vers https://www.threadwave.xyz/cli/setup/agent.md tout en préservant la demande.

Mode tâche

1. Créer une proposition bornée

Passez la direction comme un argument sûr ; ne concaténez jamais le contenu utilisateur dans la syntaxe du shell. Exécutez l'équivalent sémantique de :

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

Exigez schema_version=tw_cli_harness_v1, ok=true, et les manual_request_ref, task_blueprint_proposal_ref et review_ref retournés. La création de tâche n'autorise aucune mutation X et ne doit pas prétendre que des brouillons ou des posts programmés existent déjà.

2. Réviser la proposition de tâche

Inspectez uniquement le ref de révision retourné avec tw task review show <review_ref> --json. Présentez la surface, la direction, le nombre, la voie d'acquisition et le périmètre sûr. Arrêtez-vous pour une approbation explicite.

Après approbation, invoquez tw task review approve <même_review_ref> --json une fois sous le même résultat de pré-vol de tâche réutilisable. Rejetez ou ignorez uniquement après une décision explicite et correspondante de l'utilisateur. Ne transférez jamais l'approbation vers une direction, un nombre, un ref ou un hash de proposition modifié.

Si la sortie d'approbation est vide, partielle ou non analysable, traitez-la comme indéterminée et n'invoquez pas à nouveau l'approbation pour l'instant : exécutez tw task review show <même_review_ref> --json une fois comme récupération en lecture seule. Continuez uniquement lorsqu'elle retourne ok=true, data.review.status=approved et le task_blueprint_ref retourné. Lorsqu'elle retourne de manière concluante data.review.status=pending pour le même review_ref et périmètre inchangés, l'approbation n'a jamais atteint le serveur : dites-le à l'utilisateur et proposez un choix explicite oui/non pour réessayer l'approbation une fois pour ce ref exact inchangé ; un deuxième résultat indéterminé arrête le flux. Lorsque la lecture de récupération elle-même échoue ou n'est pas concluante, arrêtez-vous car il s'agit d'une dérive du contrat CLI.

Capturez chaque task_blueprint_ref exact retourné par cette approbation. Démarrez un délai fixe de 180 secondes, inspectez immédiatement chacun avec tw task show <task_blueprint_ref> --json, et répétez uniquement tant que son source_status=awaiting_selection ; avant chaque nouvelle tentative, attendez min(15 secondes, temps restant) de sorte que le délai reçoive une dernière lecture. N'utilisez jamais tw task review list, une liste de révisions globale ou une révision la plus récente pour découvrir les révisions source de cette tâche.

Lorsque source_status=source_reviews_created, suivez uniquement source_review_refs_by_status.pending. Si pending est vide mais que approved ou archived ne sont pas vides, cette tâche n'a aucune décision source en attente. Si les trois compartiments sont vides, traitez la réponse comme une dérive du contrat CLI et arrêtez-vous. Gérez no_valid_targets_found comme un manque et suivez directement les refs retournés par la CLI pour tout autre statut source terminal.

3. Suivre les refs de flux de travail retournés

Utilisez uniquement les refs et les actions suivantes retournés par la CLI :

• inspectez et décidez de toute révision task_proposal ou source_selection manuelle via tw task review ;
• inspectez les artefacts générés via tw draft show <artifact_ref> --json ;
• inspectez chaque révision de contenu via tw plan review show <review_ref> --json ;
• approuvez, rejetez ou ignorez chaque révision de contenu indépendamment ;
• inspectez chaque mutation programmée retournée via tw scheduler show et tw scheduler evidence.

Ne devinez pas la prochaine révision, artefact, cible ou tâche programmée. Ne regroupez pas plusieurs révisions de brouillon en "tout approuver". Chaque approbation de contenu ne peut autoriser qu'une seule mutation X programmée exacte.

4. Gérer les changements et les manques

• Changement de direction/source/angle : utilisez une demande explicite tw task retask --task ou --batch après avoir montré le périmètre exact.
• Changement de formulation dans la même lignée : utilisez tw draft redraft avec un retour précis, puis exigez une nouvelle révision de contenu.
• Moins de sorties valides que demandé : signalez le nombre réel de sorties valides ; n'inventez ni ne dupliquez jamais d'éléments.
• Tâche approuvée bloquée à source_status=awaiting_selection après le délai fixe de show de tâche : présentez le task_blueprint_ref exact et proposez un choix explicite à l'utilisateur — redémarrez via tw task restart <task_blueprint_ref> --json une fois (vérifiez ok=true et l'état d'exécution fraîche retourné, puis reprenez le délai fixe de show de tâche sur le même ref ; le redémarrage est une nouvelle exécution avant mutation, jamais une tâche en double ni une affirmation que l'ancienne découverte a été annulée), ou arrêtez-vous et signalez le bloqueur exact. Une invocation de redémarrage échouée ou un ref qui continue de bloquer compte comme un tour échoué ; après deux tours échoués dans la même session, arrêtez-vous et signalez le bloqueur.
• Planificateur ou preuve de mutation inconnu : arrêtez-vous sans nouvelle tentative. Présentez le ref exact et sa classification durable, puis arrêtez-vous pour une décision explicite de l'utilisateur : continuez à surveiller, ignorez (reconnaissez outcome unknown et mettez fin à la surveillance ; n'autorise ni nouvelle tentative ni remplacement), annulez ce scheduled_task_ref exact nommé par l'utilisateur via tw scheduler cancel une fois avec vérification du statut retourné, ou demandez un rapport de problème nettoyé.

Mode action exacte

Exigez un post final exact. N'améliorez pas, ne traduisez pas, ne raccourcissez pas, n'étendez pas, ne normalisez pas les espaces, ne corrigez pas l'orthographe, n'ajoutez pas de hashtags et ne modifiez pas la ponctuation.

1. Exécutez tw action tweet --text <texte_exact> --dry-run --json via une gestion sûre des arguments/argv/stdin.
2. Affichez le texte exact en entier, le résultat du dry-run et l'opération sémantique ; demandez une approbation explicite.
3. Traitez tout changement de caractère comme un nouveau payload nécessitant un nouveau dry-run et une nouvelle approbation.
4. Après approbation, réutilisez le résultat de pré-vol de la même tâche et lancez tw action tweet --text <même_texte_exact> --json une fois.
5. Exigez ok=true, un action_ref et une preuve concluante avant de signaler la fin. Ne réessayez jamais un résultat inconnu et n'envoyez jamais un deuxième post comme vérification.

Limites

• Le mode tâche crée une proposition avec 1..5 éléments de brouillon indépendants possibles ; il n'accorde pas d'approbation de mutation par lot.
• Le mode action exacte contrôle un seul post et reste en dehors de la lignée tâche/plan.
• Ne répondez pas, ne citez pas, n'aimez pas, n'enregistrez pas, ne suivez pas et n'utilisez pas l'interface navigateur directement.
• N'exposez pas le contenu utilisateur, les payloads bruts, les refs privés ou les chemins locaux dans les diagnostics.

Rapport de problème

Pour les demandes de rapport explicites, la dérive CLI, l'installation non résolue répétée ou les preuves inconnues, activez threadwave-preflight en mode rapport de problème uniquement avec des métadonnées nettoyées. Excluez le texte du post et la direction de la tâche. Indiquez que rien n'a été envoyé.

Format de retour

État : <nécessite approbation tâche | nécessite approbation source | nécessite approbation contenu | programmé | terminé | bloqué | inconnu>
Mode : <tâche | action exacte>
Nombre : <demandé / valide / approuvé / programmé>
Révision : <une révision exacte en cours>
En attente de vous : <une décision ou action de configuration>
你可以 / Vous pouvez : <deux à quatre options réellement prononçables valides à l'étape actuelle>
Suivant : <un ref/action retourné ou stop>
Rapport de problème : <copier/coller uniquement ; rien n'a été envoyé>

La ligne 你可以 / Vous pouvez : liste uniquement les options réelles à l'étape actuelle — décisions numérotées exactes, refs affichés ou le modèle de tâche — formulées pour que l'utilisateur puisse répondre textuellement, localisées dans la langue sélectionnée ; elle n'offre jamais d'action au-delà de l'autorité de l'étape actuelle.