Compétence de transformation d'un sujet vague en plan d'article

Transformez un sujet large ou à moitié formé en un plan d'article distinctif et exploitable, sans rédiger l'article pour l'utilisateur. Partez du travail existant et de la base de connaissances de l'utilisateur, identifiez les questions récurrentes dans les communautés pertinentes, sélectionnez une question de lecteur ciblée et créez un échafaudage de recherche section par section.

Quand l'utiliser

À utiliser lorsque l'utilisateur :

donne un sujet vague et souhaite de l'aide pour le transformer en article ;
demande des questions de recherche, un plan ou un point de vue ;
veut écrire manuellement et demande à l'agent d'affiner le travail ultérieurement ;
demande à relier un nouveau sujet à des pages wiki, des projets ou des travaux d'implémentation existants.

Ne pas utiliser pour :

rédiger immédiatement l'article fini ;
un brainstorming générique sans recherche ni travail sur les sources ;
éditer un brouillon existant dont la thèse et la structure sont déjà claires.

Modèle mental principal

Utilisez cette séquence :

Sujet vague
  ↓
Travail et connaissances existants
  ↓
Questions externes récurrentes
  ↓
Problème d'un lecteur ciblé
  ↓
Thèse distinctive
  ↓
Mécanisme ou objet de conception concret
  ↓
Affirmations et questions de recherche par section
  ↓
Contre-arguments et lacunes dans les preuves
  ↓
Plan réutilisable dans l'espace de travail demandé

L'objectif n'est pas de prédire l'avenir ou de résumer un domaine. L'objectif est de trouver l'intersection la plus forte entre :

ce que l'utilisateur a réellement construit, observé ou pensé ;
ce qu'un lecteur technique spécifique a besoin de comprendre ou de décider ;
ce que les praticiens actuels débattent activement ;
ce qui peut être étayé par des sources primaires et des exemples concrets.

Utilisez la séquence de planification de [[outlining-an-article|Planifier un article]] :

sujet → remue-méninges → regrouper → façonner → une phrase par section → brouillon

Pour un article technique Substack, ajoutez la couche de recherche avant la rédaction :

sujet → travail existant → questions récurrentes → angle ciblé
→ remue-méninges → regrouper → structure narrative → affirmations par section → recherche → brouillon

Procédure

1. Définir la contrainte d'écriture

Avant de rechercher, établissez :

le lecteur visé ;
le type d'article : essai technique, guide de terrain, note d'architecture, argumentaire dissident ou étude de cas ;
si l'utilisateur souhaite un plan ou un texte fini ;
où le plan doit être sauvegardé ;
le contexte du projet, de l'implémentation ou du wiki de l'utilisateur.

Par défaut : public technique, recherche et rédaction manuelles, plan uniquement, puis affinement ultérieur.

Vérification d'achèvement : rédigez une phrase décrivant le lecteur et le travail de l'article.

2. Inspecter d'abord le travail existant de l'utilisateur

Lisez les fichiers référencés suffisamment complètement pour identifier :

les thèses explicites ;
les parcours ou exemples concrets ;
les limites de l'architecture ;
les cas d'échec ;
les critères d'évaluation ;
les compromis ;
les questions non résolues ;
le langage déjà utilisé par l'utilisateur.

Si l'utilisateur référence un wiki ou un dossier, cherchez-y des concepts qui se chevauchent avant d'inventer un nouveau cadrage. Lisez les pages de concepts, sources, thèmes, notes et projets les plus pertinents.

Privilégiez les idées ancrées dans le travail propre de l'utilisateur. Une implémentation concrète, une évaluation échouée, une décision de conception ou un compromis non résolu est généralement plus précieux qu'une affirmation de tendance générique.

Vérification d'achèvement : listez 3 à 8 principes réutilisables issus du matériel de l'utilisateur.

3. Rechercher les questions récurrentes des praticiens

Utilisez la recherche web pour les discussions actuelles dans les communautés d'ingénierie et les sources techniques primaires. Cherchez sur plusieurs surfaces selon le cas :

les dépôts de protocole et les issues/discussions GitHub ;
les exemples officiels d'implémentation ;
les blogs d'ingénierie et la documentation ;
Reddit ou d'autres communautés de praticiens ;
les forums techniques ou le matériel de conférence.

Cherchez des questions, pas seulement des noms de sujets. Exemples :

[sujet] GitHub issue authority
[sujet] problème d'implémentation
[sujet] discussion d'ingénierie échec
[sujet] limitations du protocole
[sujet] leçons de production

Enregistrez les questions récurrentes sous des catégories telles que :

identité et autorité ;
état et transactions ;
interopérabilité ;
limites des données et du contexte ;
sécurité et abus ;
évaluation et observabilité ;
produit et modèle opérationnel.

Ne prétendez pas à une popularité statistique à moins qu'un ensemble de données systématique ne l'étaye. Utilisez des formulations telles que « questions récurrentes dans les discussions échantillonnées » lorsque la recherche est qualitative.

Vérification d'achèvement : produisez 10 à 25 questions récurrentes regroupées par thème, avec des sources représentatives.

4. Sélectionner la meilleure question d'article

Évaluez les questions candidates par rapport à :

Test	Question
Valeur pour le lecteur	Aide-t-elle un lecteur spécifique à prendre une décision de conception ou de produit ?
Autorité de l'utilisateur	L'utilisateur a-t-il un travail de première main ou un point de vue développé ici ?
Preuve	L'affirmation peut-elle être étayée par des sources primaires et des exemples ?
Spécificité	Est-elle plus étroite que le sujet global ?
Originalité	Crée-t-elle un point de vue plutôt qu'un survol ?
Durabilité	Restera-t-elle utile après l'engouement actuel ?
Potentiel de série	Peut-elle mener à des articles de suivi ?

Sélectionnez une question principale et, au maximum, deux alternatives. Expliquez pourquoi la gagnante est plus forte.

Bonne forme de question :

Comment [constructeur spécifique] devrait-il concevoir [système spécifique] lorsqu'il est confronté à [nouvelle condition] ?

Évitez :

Comment [grande technologie] va-t-elle changer [industrie entière] ?

Vérification d'achèvement : énoncez la question de lecteur sélectionnée et pourquoi elle gagne.

5. Dériver la thèse du travail de l'utilisateur

Utilisez ce modèle :

Le point de vue commun est :
Le travail de l'utilisateur suggère :
Ce point de vue est incomplet car :
Le modèle plus utile est :
La conséquence pratique pour les constructeurs est :
L'objection la plus forte est :

La thèse doit être une affirmation argumentable, pas une étiquette de sujet.

Exemples de transformations utiles :

« E-commerce agentique » → « L'agent marchand est un système de résolution de résultats borné, pas un chatbot. »
« Agents d'entreprise » → « L'unité gouvernée est le système d'action, pas le modèle. »
« Mémoire agentique » → « La mémoire est une surface de contrôle au niveau de l'application, pas seulement une fonctionnalité du modèle. »

Vérification d'achèvement : rédigez une thèse en une phrase et une explication de 30 secondes.

6. Nommer ou définir un mécanisme concret

Donnez à l'article un objet de conception qui rend la thèse utile. Exemples :

contrat de parcours ;
frontière d'autorité ;
harnais d'évaluation ;
budget de contexte ;
surface de capacité ;
trace de décision ;
registre de résultats ;
boucle d'intervention.

N'inventez pas de jargon uniquement pour paraître original. Recherchez si le terme existe déjà, identifiez la terminologie adjacente et étiquetez-le comme terme de travail si nécessaire.

Vérification d'achèvement : définissez le mécanisme en 1 à 3 phrases et montrez un petit exemple.

7. Façonner l'article comme une histoire

Ne créez pas un catalogue de sujets. Donnez au lecteur une raison de continuer d'une section à l'autre.

Utilisez ce flux narratif par défaut :

Problème ou scénario d'ouverture — montrez une situation concrète avant d'expliquer le sujet.
Tension — révélez pourquoi la solution évidente échoue ou est incomplète.
Thèse — énoncez clairement l'affirmation principale.
Mécanisme — introduisez le modèle, l'architecture ou l'objet de conception qui explique le problème.
Application — parcourez comment le mécanisme change la pratique.
Garde-fous ou compromis — montrez ce qui peut mal tourner et où se situent les limites.
Preuves et évaluation — expliquez comment un constructeur saurait que l'approche fonctionne.
Implication — montrez ce qui change pour le travail ou l'industrie du lecteur.
Fin ouverte — terminez par une question ou une tension non résolue, pas un résumé.

Pour chaque section, écrivez une phrase avant d'écrire des paragraphes :

Section :
Affirmation que cette section fait :
Exemple ou preuve :
Question que le lecteur a maintenant :
Comment la section suivante y répond :

La section suivante doit généralement répondre à une question créée par la section précédente. Supprimez les sections qui ne font pas avancer l'histoire.

Vérification d'achèvement : le plan peut être lu de haut en bas comme une chaîne de questions et réponses, pas seulement une liste de thèmes.

8. Remue-méninges, regrouper et réduire

Avant de finaliser le plan :

Remue-méninges sur chaque idée, exemple, source, objection et observation personnelle pertinents.
Recherchez le matériel existant dans le wiki, les notes, les surlignages et les fichiers de projet.
Regroupez les idées connexes et supprimez le matériel qui ne soutient pas l'angle choisi.
Choisissez une structure parmi le flux narratif ci-dessus ou une autre structure appropriée.
Écrivez une phrase par section et vérifiez les transitions.
Conservez les idées non résolues dans une liste de côté plutôt que de les forcer dans l'article.

Ne passez pas directement du sujet à la prose. Le plan est le pont entre la pensée brute et le brouillon.

Vérification d'achèvement : chaque idée conservée appartient à une section, et chaque section a une affirmation principale.

9. Ajouter des questions de recherche et des lacunes dans les preuves

Pour chaque section conservée, fournissez :

les questions de recherche auxquelles l'utilisateur doit répondre ;
les preuves à trouver ;
le contre-argument probable ;
ce qui changerait la thèse ;
un exemple concret, diagramme ou cas.

N'écrivez pas de questions qui sont simplement intéressantes. Chaque question doit aider à établir, contester ou qualifier l'affirmation de la section.

Vérification d'achèvement : chaque section a 2 à 5 questions de recherche auxquelles on peut répondre et au moins une cible de preuve.

10. Ajouter des contre-arguments et des lacunes dans les preuves

Ne produisez pas un récit de tendance unilatéral. Ajoutez 4 à 8 objections sérieuses. Pour chacune, créez :

Affirmation :
Preuves pour :
Preuves contre :
Ce qui me ferait changer d'avis :
Implication pour la thèse :

Marquez les affirmations comme fait, prévision, interprétation ou opinion. Identifiez les affirmations qui nécessitent des preuves primaires avant publication.

Vérification d'achèvement : listez l'affirmation non étayée la plus faible de l'article et la source nécessaire pour la tester.

11. Créer l'artefact du plan

Si l'utilisateur demande un fichier, créez-le à l'emplacement demandé. Pour les brouillons Substack, utilisez :

substack/drafts/<titre-descriptif>.md

Utilisez le frontmatter :

---
type: substack-draft
created: AAAA-MM-JJ
updated: AAAA-MM-JJ
status: outline
working_title: "..."
---

Le fichier doit contenir la thèse de travail, le lecteur, la question sélectionnée, la discipline de recherche, le plan des sections, les questions, les contre-arguments et la liste des sources. N'écrivez pas de prose d'article fini sauf demande explicite.

Ne mettez pas à jour wiki/index.md ou wiki/log.md pour un brouillon Substack sauf si l'utilisateur le demande explicitement. Ne modifiez pas raw/.

Vérification d'achèvement : le fichier existe, contient le plan complet et indique clairement à l'utilisateur ce qu'il doit rechercher ensuite.

12. Rapporter le résultat

Donnez un court rapport contenant :

le cadrage choisi ;
pourquoi il a été choisi ;
la plus forte intersection avec le travail existant de l'utilisateur ;
où le plan a été sauvegardé ;
ce que l'utilisateur doit rechercher et écrire ensuite ;
toute limitation de la recherche, surtout si « le plus courant » a été déduit d'un échantillon qualitatif.

Discipline de recherche et de source

Utilisez la documentation technique primaire pour les revendications de protocole et d'implémentation.
Utilisez les discussions communautaires pour découvrir des questions et des modes de défaillance, pas comme preuve incontestée d'un comportement à l'échelle du marché.
Séparez la capacité du protocole, le comportement d'implémentation, la confiance de l'utilisateur et l'adoption sur le marché.
Privilégiez les exemples concrets, les traces, les cas d'évaluation et les rapports d'échec plutôt que les prévisions génériques.
Citez les affirmations factuelles dérivées d'Internet dans la réponse finale lorsque la recherche web a été utilisée.
Ne présentez pas les résultats de recherche qualitative comme statistiquement représentatifs.

Modes de défaillance courants

Commencer par le sujet de l'industrie au lieu de la preuve la plus forte de l'utilisateur.
Produire un tour d'horizon du protocole sans argument.
Traiter un agent comme l'unité d'analyse alors que la véritable unité est un parcours, un flux de travail ou un système d'action.
Rédiger l'article avant de définir la question du lecteur.
Confondre une capacité de modèle avec une garantie de production.
Traiter une API ou un protocole comme une preuve d'interopérabilité sûre.
Poser des questions de recherche qui ne peuvent pas changer la conclusion de l'article.
Cacher l'incertitude derrière des phrases telles que « le marché évolue vers ».
Créer une terminologie impressionnante sans vérifier la littérature adjacente.
Rédiger une prose soignée alors que l'utilisateur a demandé à rechercher et écrire manuellement.

aman-sharma-nine/agent-skills

Qu'est-ce que agent-skills ?

Demander à votre IA préférée

Documentation