Menu
Writing rules for clear, powerful, incarnated blog posts.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | 10xblogger |
| description | Writing rules for clear, powerful, incarnated blog posts. |
Rules for writing with clarity, conviction, and an incarnated voice.
Goal: Say one true thing well. Everything else is noise.
State your claims directly. Hedging words dilute your authority.
Kill: "it seems", "one could argue", "in some ways", "might potentially", "sort of".
Pick a specific reader. Write as if only they are reading. This produces warmth, directness, and a sense of occasion. A reader who feels addressed stays. One who feels lectured leaves.
When using a loaded term — art, craft, intuition, velocity — define it first in your own words.
Every claim needs a concrete anchor: an example, a name, a number, a scene.
Long sentences carry ideas forward. Short sentences land them.
The relentless pursuit of quarterly metrics forces teams into tactical reactivity, optimizing for local maxima while ignoring the strategic landscape that determines survival. This is a trap.
Short = conclusion, punchline, turn. Long = argument, evidence, nuance.
First sentence: your sharpest claim or most arresting image
Last sentence: a question, an image, a thought that extends beyond the post
Never end with "In conclusion..." or "I hope this was useful"
Bad: In summary, we've discussed why observability matters for modern systems.
Good: The tools change, but the principle is timeless: build systems a stranger can debug. What are you building today that a future you could understand?
After writing, cut. Then cut again.
Inspired by Hemingway and Strunk & White.
Omit needless words.
It is absolutely essential that you make an effort to write more clearly. → Write clearly.
Use active voice.
A decision was made to refactor the legacy service. → The team decided to refactor it.
Let verbs do the work. Replace weak verb + adverb with a single strong verb.
walked quickly → strode. spoke loudly → boomed.
Show, don't tell (Iceberg Principle). Omit what the reader can infer. Don't write "the codebase is complex." Describe the tangled dependencies, the conflicting protocols, the six-hour onboarding session. Trust readers to feel the complexity. The 90% below the waterline is what gives the 10% above its weight.
Issu de la tradition éditoriale française.
Voltaire : « Le secret d'ennuyer est de tout dire. » Ne pas épuiser votre sujet. Trois arguments forts valent mieux que dix faibles. Donnez de l'espace au lecteur pour penser.
Éviter la nominalisation. Transformez les substantifs en verbes.
La réalisation d'une revue de l'implémentation a été nécessaire. → L'équipe a réalisé qu'il fallait revoir l'implémentation.
Voix active. Nommez l'agent.
Des erreurs ont été commises. → J'ai fait une erreur. La clarté, c'est la responsabilité.
Une idée par phrase. En français, la tentation est la subordonnée dans la relative dans la proposition. Résistez. Coupez.
Mots courts d'abord. utiliser avant employer. mais avant cependant. parce que avant en raison du fait que.
Task and project management in .claude/global-project/. Use when user ask for a new task.
Thinking guidelines to reduce common coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
TypeScript and Angular coding best practices. Use when working with TypeScript, Angular, or Node.js files: implementation, testing, refactoring, RxJS Observables, type system, strict mode, generics, and async patterns.
Docker and docker-compose best practices. Use for any Docker task: Dockerfiles (multi-stage builds, alpine, non-root), docker compose services (Go API, frontend, MariaDB, Oracle), healthchecks, volumes, networks, and K8S-compatible configurations.
Rules for writing and updating documentation. Use for any non-trivial documentation task in README.md, markdown files, text files, and code comments.
Best practices for Go project Makefiles. Use when creating or modifying a Go project Makefile: adding/reviewing targets, PHONY declarations, tab indentation, docker compose v2 targets.
