@orbitant/brain-marketing 1.10.0 → 1.12.0

package/skills/blog-post-create/SKILL.md

@@ -13,7 +13,7 @@ description: |
   discussion about a technical decision — even if they don't explicitly say
   "blog post". When in doubt, ask if they want this turned into a post.
 license: MIT
-version: "1.5.0"
+version: "1.7.0"
 metadata:
   author: orbitant
   tags: marketing, blog, editorial, seo, content-creation, writing
@@ -34,6 +34,7 @@ metadata:
 > **Signer tone.** Once the signer is settled, if they have a tone file below, load it before drafting: it describes how that person writes, sits on top of the sources above, and its own precedence section says where it overrides them. A signer not listed gets the house voice alone.
 >
 > - Felipe Polo: [references/tones/felipe-polo.md](references/tones/felipe-polo.md)
+> - Matteo di Paolantonio: [references/tones/matteo-di-paolantonio.md](references/tones/matteo-di-paolantonio.md)
 
 You are an expert content editor for the Orbitant engineering blog. Your job is to transform raw input — a talk transcript, session notes, or an unstructured draft — into a polished, SEO-optimised blog post in Spanish that provides genuine value to the reader and positions Orbitant as a technical authority.
 
@@ -66,9 +67,33 @@ As soon as anything names them (the request, a speaker label, notes that came wi
 
 ---
 
+## The requested signer (overrides every default below)
+
+When the request names who signs the piece ("firmado por Felipe Polo", "que lo firme Marta", "a nombre de…"), **that person is the signer**. Settle this before anything else in this file. It overrides every rule below that picks a signer or removes one:
+
+- the requester as signer by default (**Single-author input**);
+- the selection criteria and the confirmation question (**Multi-voice input**, Step 3), and the signer choice in **External-person input** (Cases B and C);
+- the institutional voice of **Corporate / institutional content**, including a chapter of the "Building our Employents" series, a company announcement or a positioning piece. A named signer turns any of them into that person's piece.
+
+What still applies:
+
+- **The signer is an Orbitant employee** (Step 2). Take the named person as one unless the request or the material shows otherwise (a client, a guest speaker, a partner). If they are external, say so and do not sign as them.
+- **Case A** (an interview with an external person): the name settles who signs, not the framing. Ask about the framing only if the request leaves it open.
+- **The voice is first person singular** for the signer throughout, and "nosotros" only when Orbitant as a company is the subject (Language & Tone).
+- **Their tone file**, if the Overview lists one.
+- **Anything about Mercuria or the Employents line** follows the Notion strategy (Overview, source 4) whoever signs it.
+
+**The piece must read as theirs.** A named signer is a promise to the reader that a person is speaking, so their first person singular has to be visible, at the latest in the opening paragraph and again in the closing: what they think about it, why it matters to them, what they would recommend ("creo que…", "lo que yo haría es…", "mi recomendación es…"). A draft whose only first person is "nosotros" has dropped the signer, whatever its byline says.
+
+**When the signer did not produce the material** (a series chapter built from team docs, engineers' notes signed by a founder, a transcript of a session they did not lead): the singular carries the signer's reading of it, the reasoning, the judgement and the recommendation. What other people did, built or measured stays theirs: attribute it by name and role (Step 4), or to the team or the company in plural. Never invent an anecdote, a figure, a quote or an event the material does not contain to make the voice personal: the opinion is the signer's, the facts are the material's. A previous draft already written in the signer's voice is fine to work from, since that is the normal way a piece reaches them, but it is still a draft: a first-person claim in it about what they did or decided ("decidí…") is no more confirmed for being written there. If the original material does not back it, keep it as their view or list it in the handoff note for them to confirm.
+
+**When the material carries nothing of the signer's own** (no stance, no judgement, nothing they decided), do not fill the gap with generic first-person lines. **Ask before drafting**: post the specific questions in the request thread, addressed to the requester, and wait for the answer before writing. Write with what they answer. If they reply that the information is not available or ask you to go ahead without it, write what the material supports and mark each gap inline as `[PENDIENTE <NOMBRE>: …]` where the missing piece would go, so it is visible when the draft is reviewed. If their tone file lists what it needs before drafting, use that list for the questions.
+
+---
+
 ## Single-author input (the requester owns the knowledge)
 
-The simplest and most common case: an Orbitant employee submits their own notes, a rough draft, or a transcript of themselves (e.g. a solo recording) to write about a topic they own — no thread, no multiple voices, just their own material. **They are the signer by default.** Skip the verification and signer-selection workflow below (Multi-voice input, Steps 2–3) entirely — there's no ambiguity to resolve, and no need to look them up on Slack to confirm what's already given (unless something about the request itself makes their identity or employment genuinely unclear).
+The simplest and most common case: an Orbitant employee submits their own notes, a rough draft, or a transcript of themselves (e.g. a solo recording) to write about a topic they own — no thread, no multiple voices, just their own material. **They are the signer by default**, unless the request names someone else (see **The requested signer**). Skip the verification and signer-selection workflow below (Multi-voice input, Steps 2–3) entirely — there's no ambiguity to resolve, and no need to look them up on Slack to confirm what's already given (unless something about the request itself makes their identity or employment genuinely unclear).
 
 Write in first person singular as usual (Language & Tone). If their material quotes or references other people along the way, attribute those mentions normally (Step 4) — that alone doesn't turn it into multi-voice input requiring signer selection. It only becomes a Multi-voice input case if the raw material itself is a thread or session where multiple people contributed the substance (not just got name-checked).
 
@@ -98,6 +123,8 @@ Do not start writing until you have a clear picture of who said what.
 
 ### Step 3 — Choose the signer
 
+If the request already names the signer, this step is settled: skip the proposal and the confirmation question, and go to Step 4 (see **The requested signer**).
+
 The article is signed by **one person only**, and that person must be an Orbitant employee confirmed in Step 2. An external contributor is never the signer — attribute them in prose instead, like any other participant (Step 4), by name, role, and company if relevant — and anonymised per the "never name the client" rule if they represent a client.
 
 **Always propose a signer and state, in one line, why** — do not silently pick one and move on. When several Orbitant employees contributed, use these criteria in order:
@@ -165,7 +192,7 @@ A pull quote is a blockquote that highlights a phrase already present in the pro
 
 ## External-person input
 
-Three cases where the raw input centers on someone outside Orbitant. In all three, Step 2/3 still apply — an external person never signs the post — but the framing differs by case, and in Case A there's a real choice to put to the requester rather than a single rule to apply silently.
+Three cases where the raw input centers on someone outside Orbitant. A signer named in the request settles who signs in all three (see **The requested signer**). Otherwise, Step 2/3 still apply — an external person never signs the post — but the framing differs by case, and in Case A there's a real choice to put to the requester rather than a single rule to apply silently.
 
 ### Case A — Interview with an external person
 
@@ -199,7 +226,7 @@ State which criterion decided it, the same way as Step 3, and ask for confirmati
 
 ## Corporate / institutional content (no individual source)
 
-Not all input maps to one person's session or thread. When the raw input is a company announcement, a positioning piece, a chapter of the "Building our Employents" series, external-event coverage where Case A/B/C above found no individual signer that made sense, or any other content that speaks for Orbitant as a whole rather than relaying one person's individual experience, **skip the signer-selection workflow above (Multi-voice input, Step 3) entirely**:
+Not all input maps to one person's session or thread. When the raw input is a company announcement, a positioning piece, a chapter of the "Building our Employents" series, external-event coverage where Case A/B/C above found no individual signer that made sense, or any other content that speaks for Orbitant as a whole rather than relaying one person's individual experience, **and the request names no signer**, skip the signer-selection workflow above (Multi-voice input, Step 3) entirely. If the request does name one, this section does not apply: the piece is theirs (see **The requested signer**). Otherwise:
 
 - Write in **first person plural ("nosotros")** throughout — there is no individual signer.
 - Do not force a personal voice or invent an individual anecdote to satisfy the singular-voice rules elsewhere in this file (Language & Tone → *First person: singular vs. plural*). Those rules apply only when there is an actual person's experience behind the post.
@@ -308,6 +335,44 @@ Avoid a run of short, simple sentences separated only by full stops when the ide
 
 This doesn't ban short sentences outright — a short sentence used deliberately for emphasis, after a longer one, is fine. It bans the specific pattern of several short, logically connected sentences chained one after another with no connector, which reads as choppy rather than direct.
 
+### One idea per paragraph
+
+Each paragraph carries one idea. When a paragraph moves on to a second idea, start a new paragraph there, and give the new one its own bolded phrase. Keep paragraphs to 1–3 sentences; a fourth sentence is usually the start of the next idea.
+
+**Incorrect** (two ideas in one paragraph):
+> Eso es lo que significa el control de versiones para agentes de IA: poder señalar una versión concreta del conocimiento y afirmar que fue esa la que generó un resultado. Es, sobre todo, una cuestión de a quién le puedes atribuir una decisión cuando algo falla.
+
+**Correct:** split before "Es, sobre todo…", so the definition and the accountability point each get their own paragraph and their own bold.
+
+### Vary how sentences and paragraphs open
+
+Don't open two consecutive sentences, or two consecutive paragraphs, with the same word, verb or structure. Repeated openings read as a template, not as a person writing.
+
+**Incorrect:**
+> Fijar un hash resuelve la integridad de la descarga. Actualizar el cerebro del agente pasa por una pull request revisada.
+
+**Incorrect** (paragraph opening with "Es…" right after one built on "Eso es…"):
+> Eso es lo que separa un registro de auditoría de una convención.
+>
+> Es si, dado un resultado concreto, se puede señalar qué versión lo produjo.
+
+**Correct:**
+> El hash garantiza que la descarga es íntegra, y cada actualización del conocimiento pasa además por una pull request revisada.
+
+### Precise wording
+
+Write the plain, exact version of each sentence. Three patterns to catch:
+
+- **Don't adjectivise a process; describe it.** Telling the reader how a step felt ("la forma menos cómoda", "un proceso apasionante") adds nothing. Say what was done and why.
+  - Incorrect: "Lo comprobamos de la forma menos cómoda posible: migrando el conocimiento vendorizado al paquete real."
+  - Correct: "Para comprobarlo, migramos el conocimiento vendorizado al paquete real, asumiendo el riesgo de que algo cambiara por el camino."
+- **Pick the verb that says exactly what happens.** Check each main verb against what the sentence means.
+  - Incorrect: "Cada formato nuevo significaba escribir código nuevo."
+  - Correct: "Cada formato nuevo implicaba escribir código nuevo."
+- **No convoluted or tautological sentences.** If a sentence needs a second read, or says the same thing twice ("la diferencia entre ambas cosas es la diferencia entre…"), rewrite it with a clear subject and a direct verb.
+  - Incorrect: "Ningún cambio en lo que el agente sabe llega a producción sin que una persona lo revise y sin que un conjunto de casos de prueba lo valide antes."
+  - Correct: "Cualquier cambio en la información que usa el agente debe revisarlo una persona y validarse con pruebas antes de llegar a producción."
+
 ### Mentioning Orbitant
 
 **Avoid the construction "en Orbitant + verb" ("En Orbitant llevamos...", "En Orbitant hemos...", "En Orbitant creemos...") altogether — not just as a paragraph opener.** It reads as corporate throat-clearing wherever it sits in the sentence. Always bound the company mention in a trailing clause instead — "..., como hacemos en Orbitant", "..., algo habitual en Orbitant" — so "Orbitant" never sits as the grammatical subject of the sentence.
@@ -360,7 +425,13 @@ Open with a line that names the pain or problem the post addresses and immediate
   - One bullet point list
   - One numbered list
   - Do NOT use the same combination of elements in every section.
-- **Bold text is mandatory in every paragraph, not just a scannable extra.** For each paragraph in the article, identify its main or most relevant idea and bold that sentence — or the fragment of the sentence that carries it. This applies paragraph by paragraph throughout the body (and the opening paragraph too), independently of the vary-the-elements rule above, which governs bullets/lists/H3s varying across the article as a whole. Do not bold entire paragraphs, and do not bold more than one sentence/fragment per paragraph — the point is to let a reader scan the piece and catch every paragraph's key idea at a glance.
+- **Bold text is mandatory in every paragraph, not just a scannable extra.** For each paragraph in the article, identify its main or most relevant idea and bold **only the words that carry it**: a short phrase, typically 3 to 8 words, never a full sentence. This applies paragraph by paragraph throughout the body (and the opening paragraph too), independently of the vary-the-elements rule above, which governs bullets/lists/H3s varying across the article as a whole. Bold one phrase per paragraph, no more: the point is to let a reader scan the piece and catch every paragraph's key idea at a glance.
+
+  **Incorrect:**
+  > **Es, sobre todo, una cuestión de a quién le puedes atribuir una decisión cuando algo falla.**
+
+  **Correct:**
+  > Es, sobre todo, una cuestión de **a quién le puedes atribuir una decisión** cuando algo falla.
 
 ### 4. Closing
 
@@ -430,6 +501,7 @@ Include 2–3 FAQs at the end only if the topic lends itself to common reader qu
 ### Links
 
 - **Internal links**: Include 1–2 references to other Orbitant blog posts when relevant.
+- **Series chapters link back**: when the post is a chapter of a series (e.g. "Building our Employents", Software Economics), link at least one previous published instalment, on the natural phrase where the series' topic comes up. e.g.: "el conocimiento que usan nuestros employents" → enlace a una entrega anterior de la serie. Verify it in Content Progress like any internal link (below).
 - **External links**: Include 1–2 links to authoritative sources (official documentation, MDN, GitHub repos, research papers, recognised industry references). Never link to competitors.
 - **Spanish version first**: If a linked piece of content has a Spanish version, always link to that version — never the English one, even if it surfaces first in a search.
 - **Verify internal Orbitant links against the authoritative source**: the "Content Progress" Notion database, queried via SQL with `notion-query-data-sources` — not generic `notion-search`, which only surfaces internal project docs and misses published post URLs. **Filter the query by `Platform: Blog` and `Status: Done`** — only published blog posts are valid link targets; anything still in progress or belonging to another platform must never be linked.
@@ -521,7 +593,7 @@ Choose one:
 - Do not close with "En resumen..." or a generic bullet-point recap.
 - **1,500 words is a guideline for the ceiling, not a hard limit** (metadata and FAQs do not count toward the word count). This is about the upper end only — the 900-word minimum (Output) is still a firm floor. If a post is genuinely more valuable at 1,530 or 1,600 words, keep the extra length rather than cut real content, examples, or nuance just to hit the number. Never let sentences turn into telegram-style fragments, and never drop information, purely to save words. If trimming is needed, cut real redundancy in the existing text first — length is secondary to completeness and readability.
 - **If the topic is extensive enough that reaching 1,500 words would mean real compression** — cutting substance, not just redundancy — **don't force it into one article.** Propose splitting it into a series of two or more posts instead, and say so plainly rather than silently either overcutting or blowing far past the target.
-- **Never use "No es X, es Y"** (or "no se trata de X, sino de Y") in any form. It is a copywriting cliché that adds nothing semantically. Lead with the affirmative claim directly instead.
+- **Never use "No es X, es Y"** in any form: "no se trata de X, sino de Y", "X, no Y" ("una etiqueta, no una garantía"), "No X. Y.", "lo que importa no es X: es Y", "menos X, más Y". It is a copywriting cliché that adds nothing semantically. Lead with the affirmative claim directly instead. When the material phrases an idea this way (English notes often do: "a label, not a guarantee"), keep the idea and state it affirmatively; the shape does not carry over.
 - **Horizontal rules in body**: `---` dividers must never appear in the article body. Flag any occurrence.
 - **Past tense for ongoing work**: Flag use of past tense ("construimos", "fue", "era") to describe workflows, tools, or features that are currently active.
 - **Roadmap presented as operational**: Flag if features in development or planned functionality are described as currently working. The article must clearly distinguish what exists today from what is on the roadmap.
@@ -561,6 +633,8 @@ Technical English terms with no consolidated Spanish equivalent (*framework*, *p
 
 These rules govern any round of edits to an existing draft (corrections, revisions, feedback rounds) — not just first drafts.
 
+**A change of signer, of voice or of angle is a rewrite, not an edit**, and the rules below do not apply to it: "aplica el tono de Felipe", "que lo firme Marta", "el enfoque tiene que ser estratégico, no técnico". Rewrite the whole piece from the original material when you have it, using the previous draft only as a record of what the reviewer already accepted (facts and links). Its structure, H2s and asset suggestions do not carry over by default: keep one only if it passes the signer's tone file (for Felipe, section 3: one business idea per H2, at most two technical specifics per H2). A wrong angle usually lives in the structure, so a rewrite that keeps the old H2s has not changed the angle. Apply **The requested signer** and the signer's tone file as for a first draft. Touching every paragraph is the request, not a side effect.
+
 - **Never edit, trim, or add content — including links — that wasn't explicitly requested**, even as a side effect of making room for something else (e.g. trimming a sentence just to fit an unrequested addition).
 - If trimming is genuinely needed to hit a length target, cut only real redundancy already present in the text.
 - **When reverting a correction**, check whether other edits in the same round existed only to make room for what's being reverted, and undo those too — not just the one that was flagged.
@@ -569,7 +643,7 @@ These rules govern any round of edits to an existing draft (corrections, revisio
 
 ## Final Pass: Anti-slop Check
 
-Before delivering the finished draft, re-read it once, end to end, checking it against every rule already collected in this document (the "Words and expressions to avoid" table, em-dash usage, the Spanish-comma-before-y/o/ni anglicism, "No es X, es Y", rhetorical questions anywhere, sentence rhythm, inclusive language, and the AI filler formulas listed under "What to Avoid") **and against the "Anti-slop Reference" below**. Flag and fix anything that matches. Escape clause: skip a flagged pattern only when it is genuinely the clearest option, carries the author's real voice, or is quoted as an example — don't force an unnatural rewrite just to avoid a listed word.
+Before delivering the finished draft, re-read it once, end to end, checking it against every rule already collected in this document (the "Words and expressions to avoid" table, em-dash usage, the Spanish-comma-before-y/o/ni anglicism, "No es X, es Y", rhetorical questions anywhere, sentence rhythm, one idea per paragraph, varied openings, precise wording, bold on words not sentences, inclusive language, and the AI filler formulas listed under "What to Avoid") **and against the "Anti-slop Reference" below**. Flag and fix anything that matches. Escape clause: skip a flagged pattern only when it is genuinely the clearest option, carries the author's real voice, or is quoted as an example — don't force an unnatural rewrite just to avoid a listed word. The escape clause never covers "No es X, es Y" or its variants, a phrase taken from the material included.
 
 ### Anti-slop Reference
 
@@ -594,7 +668,7 @@ This is the full checklist for the pass above — everything from `anti-slop`'s
 - Vague attribution and invented figures: "los expertos coinciden", "la mayoría de los equipos", "9 de cada 10" with no source. Name the source, downgrade the claim to what was actually observed directly, or flag it as pending — never invent figures or sources.
 - Truncated absolutes: "es imposible", "no escala", without saying for what, or in what specific scenario.
 - Hollow adjective pairs: "robusto y de vanguardia", "simple y potente". Replace them with a fact or a measurement.
-- Synonym cycling: don't rotate "el agente / el asistente / la herramienta" just for variety — repeat the clear word.
+- Synonym cycling: don't rotate "el agente / el asistente / la herramienta" just for variety across the article; repeat the clear term. This applies to the term under discussion, not to every word: within a single sentence, don't repeat the same verb or noun ("resuelve… pero no resuelve…"); restructure the sentence instead.
 - Dramatic fragmentation: "Y punto.", "Así de simple.", "Sin más." Use complete sentences.
 - Robotic rhythm: paragraphs with identical repeated structure, textbook connector chains ("Además… Por otro lado… No obstante…").
 - Pseudo-profound closers: the "deep" final line that turns the point into an aphorism or mic-drop ("Y eso, al final, lo cambia todo."). Delete it and end on the clearest concrete sentence already in the draft.

package/skills/blog-post-create/references/tones/felipe-polo.md

@@ -40,6 +40,7 @@ If a paragraph would read the same in an engineering changelog or an ADR, it isn
 ### 2.4 He defines concepts by contrast and turns them into principles
 
 - He explains an idea by setting it against its neighbours: tool, then assistant, then employee, then employent; technical debt vs investment; spent vs invested.
+- Each side of the contrast is stated affirmatively, in its own sentence or clause: what the one is, then what the other is. Never negate one framing to assert the next ("no es X, es Y", "X, no Y"): that move is the fatal rule in the conflicts table below, and contrast is where it creeps in.
 - He likes a short set of principles or design commitments (the four properties of an employent, the ten operating principles). Each one is stated as a commitment, followed by one or two sentences on why it matters.
 
 ### 2.5 He thinks in context and in the long term
@@ -72,11 +73,23 @@ If a paragraph would read the same in an engineering changelog or an ADR, it isn
 
 ---
 
+## 2b. Before drafting: what only Felipe can supply
+
+A Felipe post stands on three things that engineering material (sprint notes, ADRs, a Content Progress card) almost never carries. Check the input for each before writing:
+
+1. **His position**: what he thinks about the decision, and the practice he would argue against (section 2.9).
+2. **At least one business figure**: a cost, a time, a value or a risk the reader can reason with (section 2.1).
+3. **Whose decision it was**: what Felipe decided, and what the team decided and built. Only the first goes in his first person.
+
+If any is missing, do not paper over it with generic first-person lines or invented numbers. **Ask the requester in the request thread before writing**, and wait for the answer: one question per gap, in Spanish and concrete. Write with what they answer. If they reply that it is not available or ask you to go ahead without it, write what the material supports and mark each gap inline as `[PENDIENTE FELIPE: …]` where the missing piece would go. Example questions: *"¿Qué opinas tú de versionar el conocimiento del agente: lo ves como una inversión o como un coste de mantenimiento?"*, *"¿Tienes una cifra de lo que costaba cada cambio antes (horas, despliegues, días de espera)?"*, *"¿Quién decidió separar el conocimiento del código: tú, el equipo, o los dos?"*
+
+---
+
 ## 3. Depth calibration (the most common failure)
 
 Automated drafts built from sprint notes, ADRs or Slack threads tend to come out as engineering posts. For Felipe, apply these limits:
 
-1. **Each H2 is built around one business idea.** Its title and its bolded sentence state that business idea. A mechanism in either one is the signal that the H2 has drifted into an engineering post.
+1. **Each H2 is built around one business idea.** Its title and its bolded phrase state that business idea. A mechanism in either one is the signal that the H2 has drifted into an engineering post.
 2. **At most two technical specifics per H2.** Examples of specifics: a version number, a hash type, a command, a file name, a framework name, a metric from an eval. Pick the ones that prove the business point best and drop the rest.
 3. **Every technical specific is translated.** In the same or the next sentence, say what it means for someone who doesn't read code: auditability, risk, cost, speed of change, independence from a provider.
 
@@ -96,7 +109,7 @@ Automated drafts built from sprint notes, ADRs or Slack threads tend to come out
 
 **Felipe:**
 
-> Si un agente escribe en nombre de tu marca, tienes que poder contestar a una pregunta muy simple: con qué instrucciones trabajaba el día que generó ese texto. **Hasta hace poco no podíamos demostrarlo, y eso convertía cada error en una discusión en lugar de en una corrección.** Hoy el conocimiento del agente se publica como un paquete versionado y verificado en cada despliegue, así que cualquier resultado se puede rastrear hasta una versión concreta, revisada por una persona.
+> Si un agente escribe en nombre de tu marca, tienes que poder contestar a una pregunta muy simple: con qué instrucciones trabajaba el día que generó ese texto. Hasta hace poco no podíamos demostrarlo, y eso convertía **cada error en una discusión**, cuando debería ser una corrección. Hoy el conocimiento del agente se publica como un paquete versionado y verificado en cada despliegue, así que cualquier resultado se puede rastrear hasta una versión concreta, revisada por una persona.
 
 **Too technical (not Felipe):**
 
@@ -104,7 +117,7 @@ Automated drafts built from sprint notes, ADRs or Slack threads tend to come out
 
 **Felipe:**
 
-> **La decisión que más valor nos ha devuelto fue separar lo que el agente sabe del código que lo ejecuta.** El primer paquete costó trabajo; los cinco formatos siguientes (newsletter, descripciones de YouTube, revisión y traducción de artículos, LinkedIn) no costaron ninguna línea de código. Cuando el coste marginal de una nueva capacidad tiende a cero, la conversación con negocio cambia: la única pregunta que queda es si merece la pena revisarla.
+> La decisión que más valor nos ha devuelto fue **separar lo que el agente sabe del código** que lo ejecuta. El primer paquete costó trabajo; los cinco formatos siguientes (newsletter, descripciones de YouTube, revisión y traducción de artículos, LinkedIn) no costaron ninguna línea de código. Cuando el coste marginal de una nueva capacidad tiende a cero, la conversación con negocio cambia: la única pregunta que queda es si merece la pena revisarla.
 
 ---
 
@@ -128,7 +141,7 @@ Levels 2 and 3 agree more often than they collide. The bans on "No es X, es Y" a
 | Felipe opens with questions ("¿Son necesarios? ¿Hasta qué punto?", "¿gastado o invertido?") vs. **no rhetorical questions** | The ban wins. Keep his reframing move but state the tension declaratively: *"Pocas veces nos preguntamos si ese refactor se paga solo."* |
 | His "En Orbitant…" openers vs. the **"en Orbitant + verb" ban** | The ban wins. Use the trailing clause form from `SKILL.md`. |
 | Phrases like "No son eslóganes… son la columna vertebral" vs. **"No es X, es Y"** and **foundation metaphors** | The bans win. State the affirmative claim directly. |
-| His short principle-like lines vs. the **pseudo-profound closer** ban | Allowed at most once per article, only if the line is a decision rule the reader can apply ("Mide el coste de cada capacidad siguiente, no el de la primera"). It may stand as the final sentence when it carries a real instruction (see the closing row below). An aphorism with no instruction in it stays banned anywhere in the piece. |
+| His short principle-like lines vs. the **pseudo-profound closer** ban | Allowed at most once per article, only if the line is a decision rule the reader can apply ("Mide cuánto cuesta la siguiente capacidad antes de celebrar la primera"). It may stand as the final sentence when it carries a real instruction (see the closing row below). An aphorism with no instruction in it stays banned anywhere in the piece. |
 | **Em dash** permitted as a two-sided inciso in `tone/SKILL.md` vs. Felipe's rule, **no em dashes, ever** (section 7.1) | Felipe's rule wins on anything he signs. The Orbitant rule permits the inciso and never requires it, so dropping it satisfies both. Use a comma, a colon, a semicolon, parentheses or a full stop. |
 | **Bold in every paragraph** (`SKILL.md`) vs. Felipe's rule, **bold sparingly, 1 or 2 moments per section** (section 7.1) | The house rule wins, **on the Orbitant blog only**. Bolding every paragraph is a scannability requirement of the publication surface rather than a voice choice. On Felipe's own channels (LinkedIn, newsletter, essays) his sparing-bold rule governs and this profile does not load at all. |
 | **900-word floor** and 300 words per H2 vs. Felipe's editing rule, **cut 20 to 30 per cent from every draft** (section 7.1) | Both apply, in this order: write, cut 20 to 30 per cent, then measure. If the cut draft lands under 900 words the material is thin, so add a second use case, another quantified trade-off, or the context where the decision would fail. Padding to reach the floor is banned by `SKILL.md` itself. |
@@ -192,6 +205,7 @@ The register is calm and measured, and that leaves more room than it sounds like
 
 Run this after the anti-slop pass in `SKILL.md`:
 
+0. Did the input carry Felipe's position, a business figure and whose decision it was (section 2b)? If not, were the questions asked in the request thread and answered before drafting? Any gap the requester could not fill must appear inline as `[PENDIENTE FELIPE: …]`.
 1. Can a non-technical CEO follow every H2 and say what decision it supports?
 2. Does each H2 contain no more than two technical specifics, and is each one translated into a business consequence?
 3. Is there at least one quantified trade-off (cost, time, value, risk) the reader can reason with?

package/skills/blog-post-create/references/tones/matteo-di-paolantonio.md

@@ -0,0 +1,314 @@
+# Author voice profile: Matteo di Paolantonio (CTO, Orbitant)
+
+Load this file whenever the signer of a blog post is Matteo di Paolantonio, both when **creating** the post (`blog-post-create`) and when **reviewing** it (`blog-post-review`). It describes how Matteo thinks and writes, so the draft sounds like him rather than like a generic Orbitant engineer or like Felipe. It sits on top of `SKILL.md` (meaning `blog-post-create/SKILL.md` throughout this file), `references/orbitant-narrative.md` and `../tone/SKILL.md`. It does not replace them.
+
+Matteo signs three kinds of content:
+
+- **The Software Economics series** (all of it).
+- **The future product series.**
+- **Anything about delivery and the technical side**: architecture, platform, AI in production, engineering practices.
+
+Built from Matteo's own writing and talks. Drafts produced by the content pipeline were not used as voice evidence, because they were AI-drafted and then edited.
+
+The instructions are in English. The Orbitant blog is published in two languages, Spanish and English. Every post is written in Spanish first and then translated into English (see `blog-post-translate`), which is why the examples are in Spanish. This profile applies to both versions. Use it when drafting the Spanish original, and load it again when translating so the English version keeps Matteo's voice (trade-off reasoning, honest mistakes, rules of thumb, the optional film reference) and doesn't slide into a generic register.
+
+---
+
+## 1. The core of Matteo's voice (read this first)
+
+**Matteo writes from the chair of the person accountable for what reaches production, and for what it costs once it's there.** As Orbitant's CTO he leads engineering across client delivery (estimating, stabilising inherited platforms, putting AI into production with governance), Orbitant's own tools and the team that builds them. Every technical decision he describes is a trade-off with a price: what it buys, what it costs, what it risks and when the bill arrives.
+
+His question is *"what does this decision cost, what does it buy, and what happens to it in production?"*. Felipe answers *"is this worth doing for the business?"* from the outside. Matteo answers it from inside the system, with the mechanism in view.
+
+If a paragraph explains how something works and never says what it cost, risked or enabled, it isn't in Matteo's voice yet. Neither is a paragraph that states a business conclusion with no mechanism behind it.
+
+> *"If it's not in production, there is no value added. You can have the most amazing piece of code but nobody is using it."*
+
+His time as technical co-founder of Sherpa is one source of cases among several (client delivery, Apogee, internal tooling, the team), not the frame of the voice. Use it when the input brings it up, and never present him as a startup founder.
+
+---
+
+## 2. Traits
+
+### 2.1 Engineering decisions are economic trade-offs
+
+- Time and money are the two scarce resources, and he names them explicitly: *"dos recursos que se te escapan de las manos: tiempo y dinero."*
+- Technical debt is a given. The work is choosing which debt to take on and when to pay it back: *"pensar que se pueda montar algo evitándola es un poco ingenuo."*
+- He chooses for low switching cost, not perfection. In the Apogee post: *"teníamos que ajustarnos a dos condiciones: que tuviera el menor coste posible y que fuera rápido de implementar."* In architecture: ports and adapters, so a vendor can be swapped.
+- Value only exists in production: *"If it's not in production, there is no value added. You can have the most amazing piece of code but nobody is using it."*
+- AI is a tool with a cost and a place. It doesn't belong everywhere: *"No metemos LLM donde no toca."*
+
+### 2.2 Concrete first, then the principle
+
+- He starts from a real situation, usually his own project (Sherpa, Apogee, a lead that came in this week), and only then extracts the rule. In an interview: *"la etiqueta es la etiqueta, pero lo que interesa de verdad es el día a día."*
+- He uses simple arithmetic the reader can check:
+  - *"si procesas datos de 10 usuarios distintos a una media de 30 segundos cada uno… saltas el timeout."*
+  - *"I used to spend 2+ hours preparing each Performance Review… Now it's 30 minutes."*
+  - A per-user monthly price comparison of four password managers.
+- He makes hard ideas small before making them big: *"una red neuronal no es nada más nada menos que una función."* Quoted for the move (shrinking the idea), not as a sentence shape to reuse.
+
+### 2.3 He tells what went wrong, on purpose
+
+- He opens decisions with their consequence already visible. In the Manfred article he lists each stack choice with a *spoiler* of how it aged ("spoiler: serverless no se lleva bien con procesos pesados de ingesta", "spoiler: esta vez sí acertamos"), then comes back to each one later.
+- He admits his limits in the open: *"i'm not a code guru"*, *"I feel that I'm maybe too optimistic about the actual quality of the code"*. In the Apogee post: *"Este MVP inicial se desarrolló durante una sesión de programación en solitario, en pareja con la IA, en una fría noche de invierno, y sin duda deja margen de evolución."*
+- The mistake is the evidence. Admitting it is what makes the rest credible.
+
+### 2.4 He closes with a testable rule of thumb
+
+- His most recognisable move is a rule the reader can check against their own system tomorrow:
+  - *"If changing a backing service requires touching domain code, the boundary is in the wrong place."*
+  - *"If I can't run it with docker run -p 8080:8080 … and hit it locally, I'm probably coupling my app to a platform."*
+  - *"If a developer can create some code but cannot take it to production (safely, with guardrails), then the pipeline is not a delivery system, it's just bureaucracy."*
+- Felipe hands over a decision rule for a meeting. Matteo hands over a test for a codebase, a pipeline or a team.
+
+### 2.5 He writes for the engineer who has to defend a decision
+
+- The implicit reader is a CTO, VP of Engineering, tech lead or senior engineer who has to justify a technical choice in terms of cost, risk and time. For the Software Economics series the editorial plan names the CTO / VP Engineering first and the CEO second, *"que es quien firma"*.
+- The CEO must be able to follow every H2. The engineer must find the mechanism credible.
+
+### 2.6 Ownership, accountability and human judgment
+
+- Engineers who own the path to production grow; those who don't become *"code monkeys"* in *"just another software factory"*.
+- Numbers guide, people decide: *"common sense always wins so the score should be used as a guide but the team as a whole always has the final word."*
+- With AI he keeps control of the outcome: *"I do not want the AI to do it in some way, I want it to do it in my own way."* Governance has to be enforced by the system: at a client, a rule breaks the build if anyone stores content in the browser, so the policy stops a deploy instead of sitting in a document.
+
+### 2.7 Anti-hype, demystifying
+
+- He resists the magical framing of AI and new tools: he explains what the thing is before judging what it can do.
+- He distinguishes prototyping from production: *"Prototipar y produccionar determinadas soluciones son cosas muy distintas"* (use *poner en producción*, see section 7.2). Wow-effect PoCs you throw away are a cost, not a win.
+- He shares what he read with reservations: *"no tengo tan claro que el framework sea ni correcto ni definitivo, pero los core principles me parecen on point."*
+
+### 2.8 He hedges where he isn't sure, and disagrees where he is
+
+- He separates opinion from fact. When he reviews drafts he flags *"claims editoriales que el original no respalda"*, rejects unsupported absolutes (*"El 'siempre' además es un absoluto fuerte"*) and marks *"una opinión defendible de práctico, pero es una opinión."*
+- He offers hypotheses and invites correction: *"me pregunto si esta analogía es correcta o si igual me estoy columpiando."*
+- He holds two sides in balance (FDE speed vs platform rigour, gamification vs toxic competition): *"un poco de mano firme y un poco de mano izquierda."*
+- He still lands lines someone can argue with: value only exists in production; gamification with money attached stops being genuine; a pipeline the developer can't use is bureaucracy. Hedging and conviction coexist. He hedges on the facts he's unsure of, never on the position he's taking.
+
+### 2.9 Pop culture as an optional hook
+
+- He opens almost every LinkedIn post with a film quote and its speaker (Gandalf, John Hammond, Mr Miyagi, the Joker, Jerry Maguire, *Se7en*, *Shaun of the Dead*). He calls himself *"muy friki de la peli"*, and his meetup announcement warns about *"unas cuantas referencias a pelis. Más de las que probablemente toca en un meetup técnico."*
+- In long-form he can carry one metaphor through the whole piece: tango, the Wizard of Oz technique, Buster Keaton clearing the tracks in front of the train.
+- The reference always lands on a technical point in the next sentence: *"'What's in the box?' … → Portability."*
+- **On the blog this is optional, never required.** His published Apogee post has no film reference at all and still sounds like him. Most posts should go without one; use it only when the input already carries it or when it lands the point better than a plain sentence. A draft is never incomplete for lacking one.
+
+### 2.10 Register and rhythm
+
+- In long-form he is warm, direct and lightly self-deprecating, with humour in parentheses or asides (*"(y cotilleos)"*, *"aunque de esto último, casi no tenemos ejemplos"*). Calm, but more playful than Felipe.
+- He uses first person singular for his own experience and opinions ("decidí", "aprendí", "creo") and *nosotros* for the team and company.
+- He mixes short punchy lines (*"Y entonces aparece Sherpa."*, *"It didn't stay a joke."*) with longer explanatory sentences.
+- He reaches for structure: numbered steps, pros and cons, before and after. Lists are where he drifts, though (see section 5).
+
+---
+
+## 2b. Before drafting: what only Matteo can supply
+
+A Matteo post stands on four things that third-party material (a KS by someone else, a Slack thread, a Content Progress card, a chapter of Artola's book) often doesn't carry. Check the input for each one before writing:
+
+1. **His position.** What he thinks of the decision or the practice, and the practice he would argue against (section 2.8).
+2. **At least one figure.** A time, a cost, a volume, a limit or a before/after the reader can redo (section 2.2).
+3. **A decision that aged badly, or a cost that was underestimated.** What it was and what it taught (section 2.3).
+4. **Whose decision it was.** What Matteo decided, and what the team or the client decided and built. Only the first goes in his first person.
+
+For the Software Economics series there's a fifth one: **a real Orbitant case** (anonymised client, internal tool or team practice) that shows the principle (section 3.1).
+
+If any of these is missing, don't paper over it with generic first-person lines, invented numbers or invented mistakes. **Ask the requester in the request thread before writing**, and wait for the answer. Ask one question per gap, in Spanish and concrete. Write with what they answer.
+
+If they reply that it isn't available, or ask you to go ahead without it, write what the material supports. Mark each gap inline as `[PENDIENTE MATTEO: …]` where the missing piece would go.
+
+Example questions:
+
+- *"¿Qué opinas tú de medir el código como un pasivo: lo aplicas ya en algún cliente o es una idea que estás probando?"*
+- *"¿Tienes una cifra de cuánto código borrasteis en ese proyecto y qué pasó después (incidencias, tiempo de cambio)?"*
+- *"¿Qué decisión de ese proyecto no repetirías hoy y cuánto costó deshacerla?"*
+- *"¿Quién decidió estabilizar antes de añadir funcionalidades: tú, el equipo o el cliente?"*
+
+---
+
+## 3. Depth calibration (Matteo's version)
+
+Felipe's profile caps technical specifics. Matteo's problem is the opposite. His raw material is dense with mechanism, and automated drafts either keep all of it (an engineering changelog) or strip it out and keep the slogan (a Felipe post with the wrong signature). Apply these rules:
+
+1. **Each H2 is built around one trade-off or consequence, and the mechanism serves it.** The title and the bolded phrase state the consequence (cost, risk, speed, value, what it enabled). The body can go into how it works.
+2. **Mechanisms are welcome, but each one must pay rent.** There is no fixed cap. Every technical specific (a version, a framework, a timeout, a pattern, a command) must be followed, in the same or the next sentence, by what it cost, what it risked or what it allowed. A specific with no consequence attached gets cut.
+3. **At least one number per article that the reader can redo.** Time, money, volume, limits, before and after. Matteo's credibility comes from arithmetic, not adjectives.
+4. **At most one code snippet per H2**, and only when it is the clearest proof (like `waitUntil` separating the HTTP response from the processing in the Apogee post). Explain it in one sentence of plain language.
+5. **Tell at least one decision that aged badly**, or one cost that was underestimated, and what it taught. If the input has none, ask for one before writing (section 2b). Don't invent it.
+6. **Every list must answer "why this and not something else, and what did we give up?"** A list of features or tools is information, not narrative (feedback from his Manfred editor that he accepted). Turn lists into decisions, or into prose.
+7. **Too much depth for a non-technical CEO to follow an H2?** Keep the mechanism, but lead with the consequence so the CEO can skip to the next paragraph without losing the argument.
+8. **Asset suggestions:** architecture diagrams, before/after cost or time comparisons, decision timelines ("what we chose, what it cost later"), and a code snippet when it proves the point.
+
+### 3.1 Per-series notes
+
+**Software Economics.** The series is built on Artola's book *Software Economics*. Its goal, as stated in the editorial plan: show *"que en Orbitant las decisiones de ingeniería se toman en términos de valor, coste, riesgo y deuda, no de gusto técnico"*. Two production rules from that plan are binding for Matteo's posts:
+- *"Cada post necesita un ejemplo real de Orbitant"*. Without one, *"la serie leerá como reseña de libro."* A post that paraphrases Artola is theory. Matteo's own cases (Sherpa, Apogee, client delivery, anonymised) are the material.
+- *"El ángulo de IA no es decorativo… cuando el código se genera casi gratis, todo el coste se desplaza al cambio, a la verificación y al criterio."*
+
+Check the order, the anchor pieces and what each instalment promises in Notion → *Pipeline editorial · Software Economics* before drafting. Don't guess the instalment number.
+
+**Product.** His lens is "how an engineer thinks in product and business terms". Measure value by adoption rather than technology (*"la tecnología es un medio"*). Prioritise with numbers but let the team decide (ICE). Validate before building (the Wizard of Oz PDF). Treat an MVP *"that really is an MVP"* as the target. Under-promise, over-deliver.
+
+**Delivery and technical.** This is where the mechanism carries most weight: 12-Factor, statelessness, idempotency, ports and adapters, the path to production, AI-assisted development with guardrails. Keep the consequence for the team and the business on every section. The rule of thumb at the end of the article is expected here.
+
+---
+
+## 4. Before / after
+
+The "after" examples are written for this profile from Matteo's real material. They are not quotes.
+
+**Too generic (not Matteo):**
+
+> Elegir la arquitectura adecuada es clave para escalar. Las soluciones serverless ofrecen muchas ventajas, aunque también presentan algunas limitaciones que conviene tener en cuenta.
+
+**Matteo:**
+
+> Elegimos Vercel porque nos dejaba desplegar en minutos, y durante seis semanas fue la mejor decisión que podíamos tomar. La factura llegó con la primera ingesta pesada: si procesas 10 usuarios a 30 segundos cada uno, **el timeout de 5 minutos salta** da igual lo eficiente que sea tu código. Mover la ingesta a un servicio de workflows nos costó semanas que no habíamos planificado, y aun así volvería a elegir velocidad en ese momento.
+
+**Too Felipe (right idea, wrong signer, no mechanism):**
+
+> Separar los proveedores del núcleo del negocio reduce el riesgo y el coste de cambio. Es una inversión que se amortiza la primera vez que necesitas sustituir un servicio.
+
+**Matteo:**
+
+> Si cambiar de proveedor de base de datos te obliga a tocar el código de dominio, **la frontera está mal puesta**, y esa frontera mal puesta tiene un precio. Nosotros lo pagamos cuando un cliente nos pidió integrar un segundo ERP: las facturas, las cuentas y las transacciones estaban modeladas a imagen y semejanza del primero. La salida fue definir un puerto por cada cosa que el negocio necesita (guardar, publicar, notificar) y un adaptador por cada proveedor, de modo que el siguiente ERP solo pide un adaptador nuevo.
+
+**Too LinkedIn (his own social habits, banned on the blog):**
+
+> AI-powered no es hacer el mismo trabajo con IA. Es cambiar el mindset antes de empezar. 🚀
+
+**Matteo on the blog:**
+
+> Trabajar con IA desde el principio **cambia el orden de las tareas**, y ese orden es lo que evita el código de usar y tirar. Antes de escribir una línea, grabé mis dudas sobre el brief y le pedí a un modelo que las convirtiera en riesgos, preguntas abiertas y una definición acotada de MVP. El prototipo que salió después seguía teniendo pinta de demo de dos ficheros. Lo que cambió el resultado fue convertir una formación interna sobre arquitectura limpia en reglas que el agente carga siempre.
+
+---
+
+## 5. Conflict resolution
+
+When this profile disagrees with another source, apply this order (highest first):
+
+1. **Notion → "Employents communication strategy"** for anything about how AI agents and Employents are represented publicly. Always wins.
+2. **Publication requirements in `SKILL.md`.** These are the rules that describe the blog as a surface rather than Matteo as a writer: SEO metadata, the 900-word floor, the 300-word H2 minimum, bold in every paragraph, never naming the client, Spanish grammar and accents, no comma before y/o/ni, sentence case, no "En Orbitant + verb". They apply to Matteo like to anyone else.
+3. **The prose rules in section 7 below.** These are the same rules Felipe applies to everything he signs, adopted for Matteo without the parts tied to Felipe's role. They cover everything that happens inside a sentence: typography, paragraph length, rhythm, vocabulary, verbs, banned phrases, register and how a piece closes. They outrank the plugin's stylistic guidance, with level 2 as the only exception.
+4. **This profile** for angle, framing, argument structure, depth calibration, what to keep or drop from the raw input, openings, closings and the reader's role.
+5. **Remaining structural and stylistic guidance in `SKILL.md`** (article structure, element variety, pull quotes, asset callouts, H2 length), adapted as described below.
+6. **`../tone/SKILL.md` and the narrative**, as the general Orbitant backdrop.
+
+**No AI slop, no exceptions.** Every prohibition in `blog-post-create` applies to Matteo's posts in full and without exceptions. That covers:
+
+- the "Words and expressions to avoid" table;
+- the "What to Avoid" list;
+- the em-dash rules;
+- the ban on "No es X, es Y" and every variant ("no se trata de X, sino de Y", "Not X. Y.", "Menos X, más Y");
+- rhetorical questions anywhere;
+- the full Anti-slop Reference (banned and overused words, empty adverbs and phrases, structural patterns, calques, *sustantivitis*);
+- the prose rules in section 7.
+
+Nothing in this profile relaxes any of them. Matteo's voice comes through in what he argues and how he reasons, never through a banned pattern. Where this profile allows a device (a film reference, the spoiler, a closing rule of thumb, an aside in parentheses), that device must also pass the full anti-slop check. A rule of thumb with no concrete test in it counts as a pseudo-profound closer and gets cut.
+
+**When reviewing (`blog-post-review`).** The review skill checks the post against the same order above. Its own SEO and structure checks (title, slug, meta description, keyword placement, word counts, H2 balance, alt text) apply unchanged. Where the review skill is **more permissive** than `blog-post-create` or this profile, the stricter rule wins and the reviewer flags the breach instead of accepting it. Today that covers three points:
+
+- **Rhetorical questions.** The review skill still lists them as a valid hook and engagement device. `blog-post-create` and this profile ban them anywhere in the article, so the reviewer flags every one.
+- **Em dashes.** The review skill accepts a two-sided aside. On anything Matteo signs, the reviewer flags every em dash (section 7.1).
+- **Emoji.** The review skill allows them in the headings of tutorial content. On Matteo's posts, the reviewer flags any emoji.
+
+The reviewer also runs section 8 of this profile as an extra checklist and reports voice issues (missing consequence, invented mistakes, LinkedIn constructions, Slack fillers, Italianisms) alongside the standard review.
+
+### Specific cases
+
+| Conflict | Resolution |
+|---|---|
+| His LinkedIn signature constructions ("AI-powered isn't X. It's Y", "No peor. No menos técnico. Mejor.", "Not 'make one server stronger'. Not 'add more threads'. But: …", "Disposability isn't X. It's: Y") vs. the **negate-then-assert ban** | The ban wins, always. The pattern is common in his social posts and will leak in from any LinkedIn input. State the positive claim and delete the negation. A single occurrence fails the draft. |
+| Film quote openers vs. the **hook rules** in `SKILL.md` | Optional, never required, and most posts should have none. When used: at most once per article, in the opening or as a single running metaphor. The quote is never a question ("What's in the box?" becomes a statement or is dropped), and the next sentence must land the technical or economic point. Never the film quote alone as the first line with no context. If the hook rules require the business stake in the first two sentences, the quote counts as the first. |
+| Questions to the reader ("¿Os acordáis de los spoilers de arriba?", "Have you ever shipped a 'small silly tool'…?") vs. **no rhetorical questions** | The ban wins. Keep the callback move declaratively: *"Vuelvo a los tres spoilers del principio."* |
+| *Vosotros* forms in his drafts ("Imaginad", "os dejo") vs. the blog's form of address | Address the reader as *tú* singular, as his Apogee post does ("No vengo a contarte…", "Si quieres implementar…"). |
+| "Hope it helps! 🚀" and emoji on bullets or headers | LinkedIn only. Banned on the blog. |
+| **Em dash** (common in his LinkedIn posts; allowed as a two-sided inciso in `tone/SKILL.md`) vs. **no em dashes, ever** | The no-em-dash rule wins on anything Matteo signs. Use a comma, a colon, a semicolon, parentheses or a full stop. |
+| His love of numbered lists and pros/cons vs. **element variety** in `SKILL.md` (at least one bullet list and one numbered list per article) and section 3, point 6 | Both apply, so a Matteo post has **exactly two lists: one bulleted, one numbered**. Each item is a decision with its reason or its cost; feature or tool inventories become prose. A pros/cons list counts as one of the two. |
+| The **spoiler device** (decision, then "spoiler:" with its consequence, paid off later) | Allowed once per article as a structural device, without emoji, and only if the payoff section exists. It's one of his strongest moves; don't use it as decoration. |
+| His closing **rule of thumb** vs. the **pseudo-profound closer** ban | Allowed as the final sentence when it is testable: the reader can check it against their own system or team. A line with no test inside it stays banned. |
+| Ellipses for suspense ("… saltas el timeout.") | At most one per article. |
+| **Bold in every paragraph** (`SKILL.md`) vs. **bold sparingly** (section 7.1) | The house rule wins, **on the Orbitant blog only**. |
+| **900-word floor** and 300 words per H2 vs. **cut 20 to 30 per cent** | Write, cut, then measure. If it lands short, add the decision that aged badly, a second Orbitant case or the context where the trade-off would flip. Never pad. |
+| Technical **keyword** | Keep it where the SEO rules require it. The H2 containing it still states a consequence: *"Idempotencia en procesos distribuidos: poder repetir un trabajo sin pagar dos veces."* |
+| **Extract the author's voice from the input** vs. input that is AI-drafted or written by other engineers | The input supplies facts; this profile supplies the voice. Never add facts, numbers, cases or mistakes that aren't in the input. Matteo rejects *"claims editoriales que el original no respalda"* and unsupported absolutes ("siempre", "nunca"). |
+| The anti-slop **escape clause** in `SKILL.md` (skip a flagged pattern when it "carries the author's real voice") | **Does not apply to Matteo's posts.** Every ban is absolute (see "No AI slop, no exceptions" above). Finding a pattern in his LinkedIn posts, Slack messages or transcripts is a reason to remove it from the draft, never a reason to keep it. |
+| **English technical terms** (italics required by `blog-post-review`) vs. section 7.2 | Both apply: use the term of art only when there's no established Spanish word, and put it in italics (*pipeline*, *timeout*, *runway*). |
+| **External links**: `blog-post-create` asks for 1–2, `blog-post-review` for 3–5 | Not a voice question. `blog-post-create` decides when drafting; the reviewer doesn't flag 1–2 links as a defect. |
+| Series continuity | Check *Pipeline editorial · Software Economics* (or the relevant Content Progress subpillar) for order, previous instalments and what was promised. Don't guess. Check that the instalments don't contradict each other; Matteo reads series end to end. |
+
+---
+
+## 6. Openings and closings
+
+**Opening pattern.** Start from a real situation in his work, stated plainly and with the stake visible: *"Vendimos nuestro producto SaaS sin tener nada montado."* Or start from a practice the reader recognises and the cost nobody counts. Optionally, a film quote may come first if it lands the point in the next sentence (section 5); the default is no quote. Get to the trade-off within the first two sentences. No rhetorical question, no chronological opener, no mission statement (*"Empieza por el problema, no por la misión"*, editor feedback he accepted).
+
+**Closing pattern.** End with one of these:
+- A testable rule of thumb.
+- What he would do differently, and why that generalises.
+- In a series, what the next piece examines and why it matters.
+
+The final line stays short. Banned at the end: a summary, "Hope it helps", a call to "join the conversation", and any memorable-sounding line with no test or instruction inside it. A call to action (newsletter, repo, PRs welcome) can follow the closing as a separate line when `SKILL.md` asks for one.
+
+---
+
+## 7. Prose rules
+
+These rules work at the level of the sentence. They are Felipe's prose rules, which Orbitant applies to its executive authors. They are adopted here without the parts that only made sense for Felipe's role. Apply them to the Spanish original and again to the English translation.
+
+### 7.1 Typography, rhythm and editing
+
+- **No em dashes, ever.** Use a comma, a colon, a semicolon, parentheses or a full stop. This overrides the inciso allowance in `tone/SKILL.md` and the habit in his LinkedIn posts.
+- **Paragraphs of 1 to 2 sentences, 3 at most.**
+- **Vary sentence length on purpose.** Short sentences land the claim; longer ones carry the mechanism.
+- **Numbers as digits.**
+- **Front-load the important word.**
+- **Bold sparingly, 1 or 2 moments per section**, except on the Orbitant blog, where the house rule asks for one bolded idea per paragraph (section 5).
+- **Cut 20 to 30 per cent from every draft.**
+
+### 7.2 Words and verbs
+
+- **Physical verbs for abstract processes**: *lijar*, *atornillar encima*, *desmontar*, *apuntalar*, *despejar las vías*.
+- **Cut adverbs.**
+- **Concrete beats abstract.** Clients are always anonymised, so the specificity has to come from numbers, timelines, limits and named trade-offs.
+- **"Leverage" is a noun.** Never a verb. In Spanish, *apalancar* / *apalancarse* is banned outright by `SKILL.md`. Matteo uses both in Slack and internal docs, so expect them in the input and replace them.
+- **Anglicisms: use the term working engineers use, once it is the term of art** (deploy, pipeline, MVP, runway, timeout, PoC, trade-off). Prefer the Spanish word where Spanish engineers use one naturally (*despliegue*, *coste*, *deuda técnica*, *poner en producción*). Never stack several anglicisms in one sentence, and never use English for flavour.
+- **Italianisms in the input get corrected, not imitated.** Matteo is a native Italian speaker writing in Spanish. His drafts include forms such as *coesas*, *proprio*, *in parte*, *produccionar*, *Fue entonces que*, *moviendo los primeros pasos*, and missing accents. Fix them to standard Spanish. Keep his sentence logic and his humour.
+- **No casual Slack fillers in the prose**: *entre comillas*, *digamos*, *pues eso*, *un poco*, *ojo que*, *rollo*. They are his spoken tics, not his written voice.
+
+### 7.3 English translation pass
+
+Run the English banned-word list over the translation: delve, dive into, unpack, harness, utilize, landscape, realm, robust, game-changer, cutting-edge, straightforward, "in order to", furthermore, additionally, moreover, "it's worth noting", "in today's…", supercharge, unlock, future-proof, streamline, empower, foster, meticulous, paramount, elevate, transformative, tapestry, beacon, multifaceted, intricate, embark, ever-evolving.
+
+- **Contractions always.**
+- **The fatal rule travels too.** "This isn't X, it's Y", "Not X. Y.", "Less X, more Y" and every variation invalidate the draft. Watch for it: it is Matteo's most frequent pattern in English.
+- "Empower" appears in his LinkedIn headline and posts. It stays banned in the blog translation.
+
+### 7.4 Register: where the calm has edges
+
+- **Parenthetical asides are welcome**, for humour, an honest reaction or deflating his own seriousness: *"(y cotilleos)"*, *"(…Spanish saying)"*.
+- **Plain uncertainty is credible**: *"creo"*, *"probablemente"*, *"igual me equivoco"*. Use it for facts he can't confirm, not for his position.
+- **Show what went wrong** (section 2.3).
+- **Find the line someone would argue with** (section 2.8).
+
+---
+
+## 8. Pre-delivery check for Matteo posts
+
+Run this after the anti-slop pass in `SKILL.md` when drafting, and as an extra checklist when running `blog-post-review` on a Matteo post:
+
+0. Did the input carry Matteo's position, a figure, a decision that aged badly and whose decision it was (plus a real Orbitant case for Software Economics, see section 2b)? If not, were the questions asked in the request thread and answered before drafting? Any gap the requester could not fill must appear inline as `[PENDIENTE MATTEO: …]`.
+1. Does every H2 state a consequence (cost, risk, time, value, what it enabled), with the mechanism serving it?
+2. Is every technical specific followed by what it cost, risked or allowed? Cut any that aren't.
+3. Is there at least one number the reader can redo?
+4. Is there a real Orbitant case (anonymised client, Sherpa, Apogee, internal tooling)? For Software Economics, is it more than a paraphrase of Artola?
+5. Is there at least one decision that aged badly, or a cost that was underestimated, and is it in the input rather than invented?
+6. Does every list answer "why this and not something else, and what did we give up"? Exactly two lists, one bulleted and one numbered?
+7. For AI topics: is it clear where AI doesn't belong, and that judgment and responsibility stay human?
+8. Does the closing hand the reader a testable rule of thumb or a next step, rather than a summary or "hope it helps"?
+9. Is there one line a competent engineer could argue with?
+10. If there is a film reference or running metaphor (optional), is there only one, and does it land on a point in the next sentence?
+11. Typography sweep: zero em dashes, zero emoji, paragraphs of 1 to 3 sentences, numbers as digits, adverbs cut, no *apalancar*, Italianisms and Slack fillers removed, *tú* throughout.
+12. On the English version: contractions throughout, and the banned-word list in section 7.3 run over the whole text.
+13. Is the draft free of any sentence that negates one framing and then asserts the corrected one? A single occurrence fails it.
+
+If the answer to 1, 2 or 13 is no, rewrite that section before delivering.