@orbitant/brain-marketing 1.10.0 → 1.12.0

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

@@ -8,7 +8,7 @@ description: |
   wants editorial feedback on a draft, needs SEO analysis for an article, or requests
   writing improvements for the Orbitant blog — even if they don't explicitly mention "review".
 license: MIT
-version: "1.2.0"
+version: "1.2.2"
 metadata:
   author: orbitant
   tags: marketing, blog, editorial, seo, content-review, writing
@@ -102,7 +102,7 @@ Review against the following expected structure:
 When reviewing an article generated from a multi-participant input, check:
 
 - [ ] **Single signer**: The article is written in first person singular. "Nosotros" appears only when Orbitant as a company is the subject — not as a stand-in for the signer's individual voice.
-- [ ] **Correct signer**: The person signing is the conversation initiator or most senior participant. Flag if the signer appears to be misidentified.
+- [ ] **Correct signer**: The person signing is the one the request named, when it named one; otherwise the one `blog-post-create` Step 3 picks (most presence, then most valuable contribution, then the initiator). Flag if the signer appears to be misidentified, and flag an article written in institutional "nosotros" when the request named a signer.
 - [ ] **Prose attribution**: Other participants' contributions appear in running prose — not as a series of isolated blockquotes. Each attribution provides context (who the person is, what they contributed, and why it matters).
 - [ ] **Functional role in attributions**: Attribution lines identify participants by functional role (software engineer, software architect, DevOps engineer, engineering manager), not by seniority level (Senior Engineer, Junior Developer).
 - [ ] **Pull quotes as reinforcement only**: Blockquotes used as pull quotes must echo content already stated in prose above. Flag any blockquote that introduces information for the first time.
@@ -110,6 +110,24 @@ When reviewing an article generated from a multi-participant input, check:
 
 ---
 
+## Signer tone checklist (when the signer has a tone file)
+
+Some signers have their own tone file in `../blog-post-create/references/tones/` (today: Felipe Polo, `felipe-polo.md`, and Matteo di Paolantonio, `matteo-di-paolantonio.md`; for Matteo, run section 8 of his file as the checklist). When the article is signed by one of them, **load that file and review the article against it**, on top of the general guidelines above. Where the two disagree, the tone file wins, following its own precedence section. In particular, do not ask a signer with a business voice to make the piece more technical.
+
+For Felipe Polo, check at least:
+
+- [ ] **One business idea per H2**: each H2 title and its bolded phrase state a business idea (cost, risk, value, options, speed). Flag any H2 built around a mechanism (a hash, a PR, an ADR, a lockfile).
+- [ ] **At most two technical specifics per H2**, each one translated into a business consequence in the same or the next sentence. Flag the H2 and list its specifics if it has more.
+- [ ] **No negate-then-assert**: flag every sentence that negates one framing and then asserts another ("no es X, es Y", "la diferencia no está en X, sino en Y", "lo primero no es X: es Y"). Felipe treats one occurrence as invalidating the draft.
+- [ ] **No unbacked first-person decisions**: flag every "decidí / tomé la decisión / exijo" that the source material does not attribute to Felipe. What the team did or decided stays in plural or attributed by name.
+- [ ] **No open gaps**: flag any `[PENDIENTE FELIPE: …]` still in the text.
+- [ ] **Closing**: ends on a decision rule the reader can apply or on what comes next, not on a summary.
+- [ ] Run the tone file's own pre-delivery check (section 8) and report any item that fails.
+
+Report these findings under *3. Tono y voz*, ranked above generic tone remarks, and include any failure among the top suggestions in *5. Sugerencias accionables*.
+
+---
+
 ## SEO Review Checklist
 
 ### Metadata
@@ -170,6 +188,7 @@ Produce feedback with these sections:
 - If the article originates from a multi-voice source: apply the multi-voice checklist above.
 
 ### 3. Tono y voz
+- If the signer has a tone file: apply the signer tone checklist above and report its findings first.
 - Does it sound like a person, not a consultancy brochure?
 - Is Orbitant referenced naturally and contextually, not promotionally?
 - Flag any generic consultant phrases found (quote them exactly).

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

@@ -52,6 +52,7 @@ Maintain the same tone as the original:
 If the signer has a tone file, load it again for the translation, so the English version keeps that voice and its English-specific rules:
 
 - Felipe Polo: [../blog-post-create/references/tones/felipe-polo.md](../blog-post-create/references/tones/felipe-polo.md)
+- Matteo di Paolantonio: [../blog-post-create/references/tones/matteo-di-paolantonio.md](../blog-post-create/references/tones/matteo-di-paolantonio.md)
 
 ### Technical terms
 Most technical terms are already in English in the Spanish original (e.g., *framework*, *pipeline*, *deployment*, *token*, *clean code*). Keep them as-is — they are the standard English terms and require no translation. Do not over-translate industry-standard terminology.

package/skills/tone/SKILL.md

@@ -8,7 +8,7 @@ description: |
   or editorial guidelines. Also trigger when reviewing blog content for consistency,
   checking if text "sounds like Orbitant", or when creating/editing marketing content
   — even if they don't explicitly mention tone or voice.
-version: "1.1.0"
+version: "1.2.0"
 license: MIT
 metadata:
   author: orbitant
@@ -44,7 +44,7 @@ Many Orbitant articles originate from group conversations — a Slack thread tha
 
 **The rule**: one article, one signer, first person singular.
 
-The signer is the person who initiated the conversation or the most senior participant. Everyone else's contribution lives in the article as prose attribution — not as a series of isolated quotes.
+The signer is the person the request names, when it names one. Otherwise the channel skill says how to choose (for the blog, `blog-post-create` Step 3), and where it says nothing, the person who initiated the conversation or the most senior participant. Everyone else's contribution lives in the article as prose attribution — not as a series of isolated quotes.
 
 The prose pattern is: context sentence → attribution phrase (name + functional role) → the person's actual point, paraphrased or quoted depending on whether the phrasing itself is what matters.
 
@@ -135,6 +135,7 @@ Good technical writing acknowledges what did not work, what could be better, and
 - **Not a brochure**: We do not write to sell Orbitant. We write to share what we know. If the content is genuinely useful, it speaks for itself.
 - **Not neutral**: We have opinions. We explain why we prefer certain approaches, tools, or patterns. We do not hedge every sentence to avoid taking a position.
 - **Not formal**: We do not use "usted", corporate passive voice, or expressions like "cabe destacar que", "en el contexto actual", "es de vital importancia". We write like we talk — clearly and directly.
+- **Not translated**: When the material is in another language, usually English notes, we write from its ideas, not from its sentences. No sentence should read as a sentence of the material put into Spanish. The calques this guide lists are examples, not the boundary: any phrase a Spanish editor would not write (English word order, "lo que importa más", a passive with nobody acting like "pasaron a descubrirse") is rewritten the way a native writer would say it. Ordinary Spanish editing applies without being listed: no word repeated within a sentence unless it is the term under discussion, and no sentence that says nothing ("la diferencia entre ambas cosas es la diferencia").
 - **Not theoretical**: We do not write about how things should work in an ideal world. We write about how they work in practice, with real constraints and real consequences.
 
 ---