@tech-writerADR, runbooks, design docs — format précis pour chaque type
Maifady est un plugin Claude Code 100% gratuit avec 30 agents IA — @tech-writer rédige les docs techniques que tu repousses depuis 6 mois : ADR pour justifier un choix, runbook pour la prochaine alerte PagerDuty, design doc pour une feature, onboarding pour le prochain dev. Format précis par type, pas de marketing fluff.
Le problème qu'il résout
Tu choisis Postgres plutôt que MongoDB. Tout le monde te demande "pourquoi pas Mongo ?". Tu dois écrire un ADR mais tu n'as ni le format en tête ni l'envie. Ou pire : tu reçois une alerte PagerDuty et tu n'as pas de runbook pour l'incident — tu débugges à 3h du matin sans assistance.
@tech-writer connaît le format de chaque type de doc et te demande juste les infos métier.
Comment il bosse
- Tu lui dis le type : ADR, runbook, design doc, onboarding.
- Tu lui donnes les inputs métier (le choix, les options considérées, l'incident, etc.).
- Il structure selon le format standard du type :
- ADR : Context, Options, Decision, Consequences, Revisit if
- Runbook : Symptoms, Severity, Diagnosis steps, Common root causes, Mitigation, Resolution, Post-incident
- Design doc : Goals, Non-goals, Background, Proposal, Alternatives, Risks, Migration
- Onboarding : Day 1, First week, Resources
- Concrete, active voice, daté.
Exemple concret
Tu tapes
›@tech-writer ADR : on choisit Postgres plutôt que MongoDB pour SaaS B2B. Raisons : - 80% relations 1-N et M-N (ACID critique) - Équipe a 8 ans de Postgres, 0 mois de Mongo - Reporting SQL nécessaire - < 100M docs (10k tenants max)
Tu obtiens (extrait)
# ADR-007: Choose Postgres over MongoDB - **Status**: Accepted - **Date**: 2026-05-26 - **Deciders**: Tech team ## Context Nous démarrons un SaaS B2B multi-tenant. Volume cible 10k tenants (soit ~10M rows max sur les tables principales). 80% du modèle est relationnel (users ↔ projects ↔ tasks). Reporting SQL exigé... ## Options considered 1. Postgres — relationnel, ACID, équipe à l'aise 2. MongoDB — flexibilité schéma, scaling natif horizontal 3. Sqlite — trop limité au-delà de 1 user concurrent ## Decision Postgres 16, hébergé Supabase. Schéma normalisé 3NF. ## Consequences - ✅ ACID critique pour les workflows de tâches - ✅ Reporting SQL direct, pas d'ETL - ⚠️ Scaling horizontal demande Citus ou sharding manuel - 🔄 Revisit si on dépasse 100M rows / 1k QPS
Pourquoi tu vas l'aimer
Format pro
ADR Nygard, runbook structuré, design doc Google-style. Tu rends du standard.
Tradeoffs honnêtes
Pas "Postgres est mieux". Mais "✅ X, ⚠️ Y, à revisiter si Z".
Tout est daté
Pas d'ADR sans date. Une décision peut devenir fausse — la date te permet de juger sa fraîcheur.
No fluff
"Leverages", "best-in-class", "world-class" → bannis. Active voice, concrete.
Quand l'utiliser
✅ Idéal pour
- Décision archi non-évidente → ADR
- Après une alerte PagerDuty → runbook (pour la prochaine)
- Proposer une feature complexe → design doc
- Onboarder un nouveau dev → guide d'arrivée
⚠️ Pas adapté quand
- README → @readme-generator
- Référence API → @api-doc-generator
- Marketing copy — ce n'est pas son but
Combine avec ces agents
Questions fréquentes
Quels formats de doc sait-il ?
ADR (Architecture Decision Records, format Nygard), runbooks d'incident, design docs (format Google), onboarding guides, RFC internes.
Et le marketing copy ?
Pas son domaine — il refuse explicitement le "marketing fluff". Il est conçu pour la doc tech interne.