@orbitant/brain-marketing 1.9.0 → 1.12.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orbitant/brain-marketing",
-  "version": "1.9.0",
+  "version": "1.12.0",
   "description": "Marketing team skills for content creation and review",
   "type": "module",
   "main": "./dist/index.js",

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.4.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.
 
@@ -54,11 +55,45 @@ The raw input may be:
 
 Read it fully before writing. Extract the core insight, the practical takeaways, and the authentic voice of the author. Do not invent technical content that is not present in the input.
 
+### Spoken material whose speaker is not named yet
+
+Sometimes the input is somebody speaking (an interview, a recorded talk, a KS session) and nothing says who they are: no name or speaker label in the transcript, no notes beside it, nobody in the request saying it. Write the post anyway, and write it **about** that person, never **as** them:
+
+- **Third person, always.** Their experience, decisions, team, company and results are theirs: "la persona entrevistada explica que…", "su equipo tardó tres semanas en…", "en su empresa…". Never "yo", "nosotros", "mi equipo" or "nuestro cliente" for what they lived, and never present it as something Orbitant did or learned.
+- **One neutral phrase for them, used the same way throughout.** "La persona entrevistada" for an interview; "la persona que da la charla" for a talk or a session. Do not invent a name, a role, a gender or a company, and do not swap the phrase for a guess the material does not support ("el CTO", "una ingeniera"). A stable phrase is what lets a name replace it later without rewriting the piece.
+- **Whoever signs does not take their story.** The signer workflow below still decides the byline, and the institutional "nosotros" still means Orbitant's own practice. Neither ever covers what the speaker said or lived.
+
+As soon as anything names them (the request, a speaker label, notes that came with the transcript), they are named: attribute them as usual (Step 4).
+
+---
+
+## 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).
 
@@ -88,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:
@@ -155,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
 
@@ -189,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.
@@ -298,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.
@@ -350,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
 
@@ -420,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.
@@ -511,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.
@@ -551,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.
@@ -559,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
 
@@ -584,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?