@profile-as-code/cli 0.3.0 → 0.3.5

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@profile-as-code/cli",
-  "version": "0.3.0",
-  "description": "pasco — the profile-as-code CLI: init, validate, build, diff, status + partial refine (task template), check (offline rules M6–M8; catalog ships M3/M4), skills:install (prints the projection command). Consumes @profile-as-code/core; never re-implements load/drift/geo/compile.",
+  "version": "0.3.5",
+  "description": "pasco — the profile-as-code CLI: init, validate, build, diff, status + partial refine (task template), check (offline rules M6–M8; catalog ships M3/M4), skills:export (copies the platform skills this package ships). Consumes @profile-as-code/core; never re-implements load/drift/geo/compile.",
   "type": "module",
   "license": "MIT",
   "bin": {
@@ -26,13 +26,15 @@
     "json-schema"
   ],
   "files": [
-    "dist"
+    "dist",
+    "skills"
   ],
   "scripts": {
-    "build": "pnpm --filter \"@profile-as-code/cli^...\" build && tsup && node -e \"process.platform !== 'win32' && require('node:fs').chmodSync('dist/index.js', 0o755)\"",
+    "build": "pnpm --filter \"@profile-as-code/cli^...\" build && tsup && node scripts/bundle-skills.mjs && node -e \"process.platform !== 'win32' && require('node:fs').chmodSync('dist/index.js', 0o755)\"",
     "verify:pack": "node scripts/verify-pack.mjs",
     "guard:release": "node scripts/release-guard.mjs",
     "prepublishOnly": "publint",
+    "prepack": "node scripts/bundle-skills.mjs",
     "typecheck": "tsc -p tsconfig.test.json",
     "test": "pnpm build && vitest run",
     "test:watch": "vitest"
@@ -42,10 +44,13 @@
   },
   "dependencies": {
     "yaml": "^2.9.1",
-    "zod": "^4.6.5"
+    "zod": "^4.6.7"
   },
   "devDependencies": {
+    "@profile-as-code/artifact": "workspace:*",
     "@profile-as-code/core": "workspace:*",
+    "@profile-as-code/github": "workspace:*",
+    "@profile-as-code/paste": "workspace:*",
     "@profile-as-code/renderers-buymeacoffee": "workspace:*",
     "@profile-as-code/renderers-github-org": "workspace:*",
     "@profile-as-code/renderers-github-readme": "workspace:*",
@@ -54,9 +59,9 @@
     "@profile-as-code/renderers-kofi": "workspace:*",
     "@profile-as-code/renderers-liberapay": "workspace:*",
     "@profile-as-code/renderers-payhip": "workspace:*",
-    "@types/node": "^26.6.4",
+    "@types/node": "^26.6.5",
     "tsup": "^8.5.1",
     "typescript": "^7.0.2",
-    "vitest": "^5.0.3"
+    "vitest": "^5.0.5"
   }
 }

package/skills/README.md

@@ -0,0 +1,62 @@
+# Skills por plataforma
+
+Cada plataforma tiene UNA skill: el conocimiento operacional SOTA de esa red,
+versionado y contribuible. Las skills son la capa de *juicio* que complementa
+al renderer (capa determinista de código).
+
+## Estructura de una skill
+
+```
+skills/<plataforma>/
+├── SKILL.md              # frontmatter (nombre, descripción, modelo sugerido) + flujo
+├── research/             # investigación versionada, con fuentes fechadas
+│   └── SOTA-<año>.md
+├── playbook.md           # pasos de deploy manual + verificación post-pega
+└── checks.yaml           # criterios machine-readable que ejecuta `pasco check`
+```
+
+## División de responsabilidades
+
+| Capa | Qué garantiza |
+|---|---|
+| **Renderer** (`packages/renderers/<plataforma>`) | Consistencia: el mismo hecho nunca se contradice entre redes. Determinista, snapshot-tested. |
+| **Skill** (`skills/<plataforma>/`) | Juicio y actualidad: límites oficiales, ranking/SEO, ángulos por audiencia, trampas, checks. |
+
+## Reglas
+
+1. **Evidencia:** toda afirmación cuantitativa lleva fuente + fecha. Sin fuente → no entra.
+2. **Distinción de fuentes:** `[OFICIAL]` docs de la plataforma · `[EXPERTO]` artículo de autor reconocido ·
+   `[BENCHMARK]` patrón observado en perfiles reales · `[?]` sin confirmar.
+3. **Frontmatter con modelo sugerido:** las skills declaran qué nivel de modelo requieren
+   (mecánico = modelo pequeño; juicio = modelo grande) para el refinamiento vía `pasco refine`.
+4. **GEO obligatorio por skill:** además de SEO, cada skill documenta cómo los LLM leen/citan
+   esa plataforma (p. ej. LinkedIn vía agentes, X vía citas, GitHub README como contexto de agente)
+   y qué checks de consistencia factual aplican.
+5. **i18n por skill:** la política de idioma de cada plataforma (qué `lang` prioriza y por qué).
+6. **Contribución:** PR de skills para plataformas que no cubrimos. Toda skill pasa por
+   sanitización + security scan + test de comportamiento antes de aceptarse.
+7. **No optimizar engagement vacío:** la prioridad es credibilidad + conversión real
+   (reclutador, cliente), no métricas superficiales.
+
+## Plataformas objetivo (orden de prioridad)
+
+1. `github-readme` — la única superficie 100% automatizable (git/API)
+2. `linkedin` — trayectoria profesional
+3. `upwork` — servicio/cliente
+4. `x` — visibilidad
+5. `researchgate` — ciencia
+6. `substack` — newsletter/audiencia propia (superficie de contenido + perfil)
+
+## Brand flavor (M6, §17)
+
+`github-org` — README del GitHub **org** para workspaces `flavor: brand`: voz de
+marca (≠ voz personal), handle-matrix checks (`handle-claimed`/`handle-consistent`,
+offline en `pasco check`), trademark/impersonación. Ver `skills/github-org/`.
+
+## Post skills (MVP, #264)
+
+The week-1 post experiment uses a **different shape** from the profile skills:
+`skills/<platform>/post.md` (judgment) + `skills/<platform>/posting.yaml`
+(machine-readable limits/settings). `pasco post` reads them; `pasco refine` keeps
+reading `SKILL.md`. They cover two channels only (`linkedin`, `x`) and are not
+projected to harnesses yet — see `docs/post-mvp.md`.

package/skills/github-org/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: github-org-readme
+description: >
+  Transforma los HECHOS del SSOT de un workspace brand (flavor: brand —
+  profile-data-topia/content/*.yaml) en el README del GitHub ORG con estrategia
+  comunicativa de marca — NO un CV ni un dump de surfaces. Patrón: editorial
+  press / high-epistemic (research/SOTA-2026.md). El agente ejecutante produce N
+  variantes en prosa; el humano elige; la elegida se registra como variante
+  activa (content/active.yaml). La voz de marca NO es la voz personal.
+model: juicio (frontier) — la voz de marca y la estrategia editorial no son delegables
+applies_to: github-org
+projection: agent-agnostic (AionUi, OpenHands, Claude Code, Cursor, pi…)
+version: 0.1.0
+status: draft (M6)
+sources: skills/github-org/research/SOTA-2026.md
+---
+
+# GitHub Org README — skill de marca (flavor brand, §17)
+
+## Misión
+
+Convertir los HECHOS del workspace brand (SSOT) en la página de aterrizaje del
+org de GitHub: quién es la marca, qué publica, dónde vive (handle matrix), y
+POR QUÉ importa. El dump determinista ya lo produce el renderer
+(`pasco build github-org`) — esta skill es la capa de **juicio y voz** (D4/D5).
+
+## Regla de oro
+
+> Los HECHOS son sagrados (byte-idénticos al SSOT); solo la VOZ varía. La voz de
+> marca ≠ voz personal: no escribas como persona, escribí como la marca.
+
+- Nombres, fechas, URLs, handles, estados: **idénticos** a `content/*.yaml`.
+- URLs SOLO de `identity.links` + `socialHandles[].url` (regla drift / §17.1).
+- **Impersonación/trademark:** si un dominio o handle homónimo pertenece a una
+  empresa viva NO relacionada (p. ej. `topia.com` es una empresa real no
+  relacionada con Topia Press), la marca SIEMPRE firma como su nombre completo
+  ("Topia Press") y nunca usa el nombre a secas que podría confundirse.
+
+## Fuente de datos (workspace brand)
+
+```
+content/flavor.yaml          → flavor: brand (obligatorio para esta skill)
+content/identity.yaml        → name, orgName, mission, tagline, brandVoice, established, links
+content/socialHandles.yaml   → la handle matrix (status: claimed|pending) — SEED
+content/newsletter.yaml      → Substack/Ghost
+content/podcast.yaml         → Spotify/RSS
+content/press.yaml           → menciones de prensa (fechadas, resolubles)
+content/audiences.yaml       → perfiles de lector (no reclutador)
+content/keywords.yaml        → SEO + GEO
+```
+
+## Estrategia comunicativa (editorial press — SOTA-2026 §3)
+
+1. **¿Quién lee?** Lectores de alta exigencia epistémica, suscriptores, prensa,
+   LLMs que citan (GEO).
+2. **¿Qué quiero que hagan?** Suscribirse al newsletter, seguir la marca en sus
+   plataformas, citar los ensayos.
+3. **¿Cuál es mi señal más fuerte?** La consistencia: mismo nombre, misma
+   misión, mismos handles en todas las superficies — la marca ES su coherencia
+   (handle-claimed / handle-consistent).
+
+Liderá con #3: una marca dispersa (handles sin claim, URLs contradictorias) no
+se cita, se ignora.
+
+## Voice matrix (brandVoice → secciones)
+
+| Contexto | Voz | Trampa a evitar |
+|---|---|---|
+| Header/misión | editorial, riguroso, esperanzado | doom-scrolling, hype |
+| Newsletter | concreto, de alta señal | prometer "todo sobre X" |
+| Press | factual, modesto | autobombo |
+| Footers/CTAs | UN llamado claro | múltiples CTAs |
+
+## Checklist de deploy (manual + git)
+
+1. `pasco validate` — schema OK y 0 drift warnings en la handle matrix.
+2. `pasco check` — handle-claimed / handle-consistent OK (offline) + `url-live` de
+   cada handle claimed (network, verificación manual).
+3. `pasco build github-org --lang en` → `profiles/github-org/README.md`.
+4. Copiar el README al repo del org (deploySpec: git; el humano mergea —
+   repo-governance).
+5. Verificación post-deploy: cada badge/link del README resuelve; los handles
+   pending NO figuran como surfaces vivas.
+
+## GEO
+
+`schema.org/Organization` JSON-LD con `@id` = el link con `role: identity` (ausente si
+ninguno lo declara) y `sameAs` = los links con `role: realization` + claimed handles
+(v1.6/#103; antes de v1.6 era identity.links completo). El email de contacto
+(`identity.email`, v1.5/#71) sale como propiedad `email`, nunca dentro de `sameAs`. Un LLM que triangule la marca debe encontrar el mismo nombre,
+misión y set de handles en GitHub, X, Bluesky y el newsletter — esa consistencia
+ES la citabilidad.

package/skills/github-org/checks.yaml

@@ -0,0 +1,40 @@
+# checks.yaml — criterios machine-readable para `pasco check github-org`
+# (unión con content/checks.yaml del workspace; misma rule catalog que el schema).
+# v1.1/§17: handle-claimed y handle-consistent se EJECUTAN offline en pasco check
+# (drift codes); url-live es la verificación de red (skill, no drift).
+
+- id: org-handle-claimed
+  platform: github-org
+  rule: handle-claimed
+  value: true
+  note: "Todo handle claimed debe resolver a una URL (offline: drift/handle-claimed-not-linked; live: url-live)."
+
+- id: org-handle-consistent
+  platform: github-org
+  rule: handle-consistent
+  value: true
+  note: "La handle matrix es el SSOT: una fila por plataforma, hosts correctos (offline: drift/duplicate-handle, drift/handle-host-mismatch)."
+
+- id: org-mission-identity
+  platform: github-org
+  rule: fact-present
+  value: true
+  note: "name/mission/tagline del README byte-idénticos al SSOT (D4)."
+
+- id: org-links-identity
+  platform: github-org
+  rule: link-in-identity
+  value: true
+  note: "Toda URL del README vive en identity.links o socialHandles[].url (regla drift, §17.1)."
+
+- id: org-jsonld-org
+  platform: github-org
+  rule: geo-consistent
+  value: true
+  note: "JSON-LD schema.org/Organization: @id = el link con role: identity (ausente si no hay ninguno), sameAs = links con role: realization + claimed handles (GEO, v1.6/#103, §15.4)."
+
+- id: org-cta-one
+  platform: github-org
+  rule: lang-present
+  value: en
+  note: "EN requerido (D8/§11); un CTA primario por variante (suscribirse al newsletter)."

package/skills/github-org/playbook.md

@@ -0,0 +1,30 @@
+# Playbook — deploy del GitHub Org README (flavor brand, deploySpec: git)
+
+## Pre-requisitos
+
+- Workspace brand (`pasco init --flavor brand`) con `content/` lleno y
+  `pasco validate` en verde.
+- Org de GitHub creado (privado hasta pasar el checklist de public-readiness —
+  repo-governance).
+
+## Pasos
+
+1. **Handle matrix** — `pasco check` (offline):
+   - Cada fila `claimed` tiene `url` o match en `identity.links`.
+   - Sin `drift/duplicate-handle`, sin `drift/handle-host-mismatch`.
+2. **Live check (manual, red):** abrí cada URL `claimed` — debe resolver al
+   perfil correcto (verificación `url-live` que el engine no automatiza).
+3. **Build:** `pasco build github-org --lang en` →
+   `profiles/github-org/README.md`.
+4. **Deploy:** copiá el README al repo `org/org` del GitHub org y commiteá en tu
+   branch + PR — el humano mergea (repo-governance §3).
+5. **Verificación post-deploy:** cada badge y link del README resuelve; los
+   handles `pending` NO figuran como surfaces vivas; el JSON-LD `Organization`
+   está embebido (GEO §17.1).
+
+## Nota de marca (impersonación)
+
+Si un dominio/handle homónimo pertenece a una empresa viva NO relacionada
+(p. ej. `topia.com`), la marca siempre firma con su nombre completo
+("Topia Press") — nunca el nombre a secas. Checks: `org-mission-identity`,
+`org-cta-one`.

package/skills/github-org/research/SOTA-2026.md

@@ -0,0 +1,39 @@
+# SOTA-2026 — GitHub org README / brand landing (brand flavor, M6)
+
+Dated, evidence-tagged sources for the `github-org` skill. Claims without a
+source + date do not enter (regla de evidencia).
+
+## Sources
+
+- **[OFICIAL] GitHub docs — "Creating a default community health file" / org
+  profiles** (2026, github.com/orgs/community). Org READMEs render on the org
+  landing page; they are the first page a visitor (human or LLM agent) sees.
+- **[OFICIAL] schema.org — Organization type** (2026, schema.org/Organization):
+  `sameAs`, `logo`, `foundingDate`, `slogan`, `description` are the machine-
+  readable fields an LLM triangulates across surfaces.
+- **[BENCHMARK] Handle-consistency pattern** (observado 2026-08-18 en el sweep
+  de disponibilidad de handles de Topia Press, operador): la marca vive en 10+
+  superficies (X, Bluesky, GitHub org, Substack, Instagram, TikTok, YouTube,
+  Reddit, Mastodon, SoundCloud + dominio canónico); el drift manual de esa
+  matrix es el problema que el engine resuelve (issue #25).
+- **[EXPERTO] Brand voice vs personal voice** (2026, práctica de agencias de
+  marca): una org no "habla como persona" — misión/tagline estables, un CTA
+  primario, consistencia sobre autobombo. La voz de marca es la coherencia.
+
+## Implicaciones para el renderer y la skill
+
+1. El README del org es la **primera superficie GEO** de la marca: el JSON-LD
+   `Organization` con `sameAs` = links + claimed handles es lo que un LLM cita.
+2. La **handle matrix es el SSOT** de superficies (más fiable que adivinar de
+   `identity.links`): filas `claimed` son surfaces vivas; `pending` no se
+   despliegan.
+3. **Consistencia = citabilidad** (SPEC §8): mismo nombre, misma misión, mismos
+   handles en todas las superficies.
+4. **Impersonación:** homónimos vivos no relacionados (p. ej. `topia.com`) →
+   firmar siempre con el nombre completo de la marca.
+
+## Open questions (skill-level)
+
+- ¿El org README debe listar repos públicos del org (proyectos de la marca) en
+  M6? El renderer v1 no lo hace (los repos del org son surfaces secundarias; el
+  newsletter/podcast/prensa son las primarias).

package/skills/github-readme/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: github-readme-profile
+description: >
+  Transforma los hechos del SSOT (profile-data/content/*.yaml) en un GitHub profile
+  README con estrategia comunicativa y estética deliberada — NO un dump de CV.
+  Patrón: OSS Maintainer / minimalista senior (research/SOTA-2026.md). El agente
+  ejecutante produce N variantes en prosa; el humano elige; la elegida se registra
+  como variante activa (content/active.yaml).
+model: juicio (frontier) — la estrategia narrativa no es delegable a modelos pequeños
+applies_to: github-readme
+projection: agent-agnostic (AionUi, OpenHands, Claude Code, Cursor, pi…)
+version: 0.1.0
+status: draft (M3)
+sources: skills/github-readme/research/SOTA-2026.md
+---
+
+# GitHub Profile README — skill de comunicación
+
+## Misión
+
+Convertir los HECHOS del workspace (SSOT) en una página de perfil que se lea en
+**30 segundos** con una impresión fuerte: quién sos, qué estás construyendo AHORA,
+por qué importa, y UNA acción posible. El dump exhaustivo ya lo produce el renderer
+determinista (`pasco build`) — esta skill es la capa de **juicio y narrativa** (D4/D5).
+
+## Regla de oro
+
+> Los HECHOS son sagrados (byte-idénticos al SSOT); solo la HISTORIA varía.
+
+- Nombres, fechas, DOIs, números, URLs: **idénticos** a `content/*.yaml`. Prohibido
+  inventar, redondear o reordenar hechos.
+- URLs SOLO de `identity.links` (regla drift). No inventes links.
+- Claims cuantitativos SOLO de `projects[].evidence` o `keywords.geo.claims`.
+
+## Fuente de datos
+
+Lee el workspace (ruta del `.pascorc` o `--workspace`):
+
+```
+content/identity.yaml      → nombre, ubicación, links canónicos (TU fuente de URLs)
+content/positioning.yaml   → statement + ángulos por audiencia + anclas GEO
+content/projects.yaml      → qué construís (status + evidence verificable)
+content/publications.yaml  → papers/preprints con DOI
+content/skills.yaml        → stack con pesos por plataforma
+content/bios.yaml          → textos base por plataforma (punto de partida)
+content/keywords.yaml      → SEO + GEO (associations/claims)
+```
+
+## Estrategia comunicativa (framework de 3 preguntas — SOTA-2026 §3)
+
+1. **¿Quién lee?** Contribuidores OSS, sponsors, reclutadores técnicos, pares.
+2. **¿Qué quiero que hagan?** Explorar los proyectos, sponsor (Patreon/GitHub Sponsors),
+   contactar para colaborar/contratar.
+3. **¿Cuál es mi señal más fuerte?** Para un perfil open-source/soberanía: el trabajo
+   público con evidencia (upstream PRs merged, papers con DOI, deployments probados).
+
+Liderá con #3 filtrado por #1: **stewardship** (proyectos vivos con proof), no branding.
+
+## Estructura del README (prosa, no dump)
+
+1. **Header**: nombre + one-liner que responde "qué construís" (de `statement`/headlines,
+   reescrito en prosa si mejora) + badges canónicas (identity.links) centradas.
+2. **Hook** (2–3 líneas): quién sos y por qué lo que hacés importa — conectá física +
+   sistemas complejos + IA soberana como UNA historia, no como lista. Weave de las
+   anclas GEO (`positioning.geo.semanticAssociations`) de forma natural, sin stuffing.
+3. **Qué estoy construyendo AHORA** (2–3 proyectos con narrativa): nombre, una frase de
+   valor (de `description`), UNA evidencia verificable (de `evidence[]`). Prosa corta,
+   no bullets de 4 items. Prioridad por `skills[].platformWeights[github-readme]`.
+4. **Evidencia de stewardship** (una sección corta): upstream PRs (merged/open) y
+   papers con DOI — woven como "every merged PR is infrastructure that belongs to
+   everyone". Tabla compacta si son varios.
+5. **Stack como señal**: 4–6 tecnologías reales de `skills` (los keywords de mayor peso),
+   no todos los que tocaste. Badges shields.io máximo ~8.
+6. **UN CTA**: Patreon (soporte al trabajo) + UN link más (CV o contacto). No cinco.
+7. **Footer**: firma visual (one-liner o ASCII art sutil, coherente con la identidad) +
+   `<!-- generated by profile-as-code pasco refine github-readme · variant <id> -->`.
+
+## Estética (SOTA-2026 §6)
+
+- **Dark-first**: assets y badges que funcionen en dark mode (GitHub sigue el tema del
+  sistema). Nada de fondos claros forzados.
+- **Restraint**: máximo un widget de stats (o ninguno si los repos hablan solos);
+  cero typing-animations, cero visitor counters, cero snake games.
+- **Jerarquía visual**: headers claros, whitespace, una sola columna. `<details>`
+  accordions para material secundario si hace falta.
+- **Centrado HTML div** para el header/badges en pantallas anchas.
+- Tipografía: sin emojis decorativos; símbolos funcionales (✓ mergeado, ↗ link) como
+  máximo.
+
+## Variantes (flujo refine)
+
+- Producí **N variantes** (`--variants N`, default 3) con ángulos distintos:
+  1. **Stewardship** (por defecto): lidera con open source + evidencia.
+  2. **Soberanía**: lidera con la tesis (IA soberana, economía agéntica), proyectos como prueba.
+  3. **Investigador**: lidera con publicaciones/DOI, proyectos como aplicación.
+- Cada variante: `variantId` = `gh-<lang>-<n>` (ej. `gh-en-1`).
+- El humano elige; se registra con `pasco refine github-readme --choose <id>` →
+  escribe `content/active.yaml`.
+
+## Verificación (checks)
+
+- `pasco validate` exit 0 (schema + drift 0 + geo).
+- Facts byte-idénticos: cruzá cada hecho del README contra el YAML.
+- Links ⊆ `identity.links` (más el hecho de contacto: fila `- [Email](mailto:…)` derivada
+  de `identity.email`, v1.5/#71 — primero en `## Links`, output-only, nunca en `sameAs`).
+- Length: el README se lee en 30s (SOTA-2026 §1) — si hay más de ~40 líneas, recortá.
+- CTA: exactamente una acción primaria.
+
+## GEO (consistencia = citabilidad)
+
+- Los hechos del README deben coincidir byte a byte con el CV y LinkedIn (fechas,
+  roles, papers) — un LLM que triangula y encuentra contradicción te descarta.
+- Los anchors semánticos se refuerzan naturalmente en la prosa (no keyword stuffing:
+  los LLM lo descuentan, SPEC §8 anti-patterns).

package/skills/github-readme/checks.yaml

@@ -0,0 +1,32 @@
+# checks.yaml — criterios machine-readable para `pasco check github-readme`
+# (unión con content/checks.yaml del workspace; misma rule catalog que el schema).
+
+- id: gh-bio-max
+  platform: github-readme
+  rule: max-chars
+  value: 280
+  note: "Bio corta (one-liner) — el README se lee en ~30s (SOTA-2026 §1)."
+
+- id: gh-facts-identity
+  platform: github-readme
+  rule: fact-present
+  value: true
+  note: "Los hechos del README deben estar byte-idénticos al SSOT (D4)."
+
+- id: gh-links-identity
+  platform: github-readme
+  rule: link-in-identity
+  value: true
+  note: "Toda URL del README vive en identity.links (regla drift)."
+
+- id: gh-geo-consistent
+  platform: github-readme
+  rule: geo-consistent
+  value: true
+  note: "Hechos consistentes con las otras superficies (CV, LinkedIn) = citabilidad."
+
+- id: gh-cta-one
+  platform: github-readme
+  rule: lang-present
+  value: en
+  note: "EN requerido (D8/§11); un CTA primario por variante."

package/skills/github-readme/playbook.md

@@ -0,0 +1,36 @@
+# GitHub Profile README — deploy playbook
+
+Deploy = git (D9): el README generado se commitea en el repo-perfil
+(`<user>/<user>`, p.ej. `ChristianLuciani/ChristianLuciani`) y GitHub lo muestra.
+Sin pegar a mano, sin API.
+
+## Flujo
+
+1. **Refine**: `pasco refine github-readme --variants 3` → el agente (esta skill)
+   produce 3 variantes en prosa. Elegí una:
+   `pasco refine github-readme --choose gh-en-2`.
+2. **Build**: `pasco build github-readme` → si hay una variante activa con cuerpo,
+   escribe ese README completo VERBATIM en `profiles/github-readme/README.md`;
+   sin variante, regenera el snapshot determinista del SSOT (control de verdad).
+3. **Deploy**: copiá el artefacto al repo-perfil y commit:
+   ```sh
+   cp profiles/github-readme/README.md ../<usuario>/README.md
+   cd ../<usuario> && git commit -am "docs: profile README (variante activa, desde profile-data)"
+   ```
+4. **Verificar en GitHub**: perfil → se ve el README en dark/light, links clicables,
+   facts consistentes con el CV.
+
+## Verificación post-deploy (CHECKLIST)
+
+- [ ] README visible en el perfil (repo público con el nombre del usuario)
+- [ ] Dark mode OK (badges y assets legibles)
+- [ ] Todos los links → identity.links (clicables, sin 404)
+- [ ] Facts byte-idénticos al CV (fechas, roles, papers, DOIs)
+- [ ] UN CTA primario (Patreon + un link más)
+- [ ] Se lee en ~30 segundos
+- [ ] `pasco validate` exit 0 con la variante activa registrada
+
+## Rollback
+
+Git: `git revert` del último commit del repo-perfil. El SSOT nunca se ve afectado
+(el deploy es un commit normal).

package/skills/github-readme/research/SOTA-2026.md

@@ -0,0 +1,105 @@
+# SOTA 2026 — GitHub Profile README
+
+> Research fechada para la skill `github-readme` (SPEC §16, M3). Regla de evidencia:
+> toda afirmación cuantitativa lleva fuente + fecha; `[OFICIAL]` docs de la plataforma,
+> `[EXPERTO]` autor reconocido, `[BENCHMARK]` patrón observado en perfiles reales, `[?]` sin confirmar.
+
+## 1. El problema central: señal, no ruido
+
+El error N°1 es tratar el README como un **resumen de CV**: listas largas de tecnologías,
+paredes de badges, GIFs animados. Los reclutadores piden "signal, not noise"
+[EXPERTO — Codeboards.io, "GitHub Profile README Guide 2026", 2026].
+
+- Un visitante decide en **~6 segundos** si explora más [EXPERTO — Igor Braz, dev.to,
+  "Top 10 Hacks... 2026", 2026-08-06].
+- Reclutadores técnicos pasan **30–90 segundos** en un perfil de GitHub; la meta es
+  **comprensión en 30 segundos, no completitud** [EXPERTO — Quillly/devbio.me,
+  "GitHub Profile README: What to Include in 2026", updated 2026-06].
+- El 82% de las contribuciones ocurren en repos privados [OFICIAL — GitHub Octoverse 2025]
+  → el perfil público muestra <20% del output real; el README debe **dirigir a la mejor
+  evidencia pública**, no intentar listar todo.
+
+## 2. Los 8 elementos que funcionan (2026)
+
+[EXPERTO — Quillly/devbio.me, 2026-06]
+
+1. **Bio de una línea** que responde "qué construís", no el cargo ("passionate developer"
+   no funciona).
+2. **Stack como señal, no como lista**: 3–5 tecnologías en las que sos genuinamente
+   experto. TS es #1 en GitHub desde ago 2025 (+66.6% YoY, Octoverse 2025) — decirlo
+   explícito si aplica.
+3. **Un widget de stats** (dark-themed, que matchee el perfil). Ojo: los contadores de
+   contribuciones se están inflando por herramientas de IA (1M+ PRs generados por IA
+   entre may–sep 2025 [OFICIAL — Octoverse 2025]) → volumen es señal más débil.
+4. **Heatmap de contribuciones** (consistencia > estallido).
+5. **Repos pineados con contexto**: una frase de qué hace, no solo el nombre.
+6. **Qué estás construyendo AHORA** (momentum — da razón concreta para contactar).
+7. **UN link** deliberado (el que cuente la historia completa más rápido).
+8. **UN número honesto** (stars, usuarios, deployments) — más credibilidad que prosa.
+
+### Qué NO incluir
+
+- Texto animado de typing ("I'm a developer who loves to code…") — el equivalente de un
+  spinner; todo generador lo produce [EXPERTO — Quillly, 2026-06].
+- Contadores de visitas (se inflan, no dicen nada).
+- "Currently learning X, Y, Z" (señal de que no estás haciendo bien ninguno).
+- Párrafos largos de bio (nadie los lee).
+- Skills en prosa ("team player") — cero señal.
+
+## 3. El framework de las 3 preguntas (antes de escribir)
+
+[EXPERTO — Quillly, "10 Templates (2026)", 2026-06]
+
+1. ¿Quién lee esto? (reclutador, contribuidor OSS, cliente, co-founder)
+2. ¿Qué quiero que hagan? (contratar, abrir un PR, bookear una llamada, sponsor)
+3. ¿Cuál es mi señal más fuerte? (años, repos con stars, revenue, papers)
+
+El README lidera con la respuesta a #3, filtrada por #1. No se puede hablar a 180M de
+desarrolladores a la vez — **un patrón, una audiencia**.
+
+## 4. Patrón recomendado: The OSS Maintainer (stewardship)
+
+Para un perfil alineado a **open source + soberanía tecnológica**, el patrón OSS
+Maintainer es el correcto [EXPERTO — Quillly, Pattern 2, 2026-06]:
+
+- Señal de **stewardship**, no branding personal: contribuidores potenciales revisan el
+  perfil ANTES del código.
+- Elementos: proyectos activos con descripción de una frase + evidencia; widget de stats
+  o heatmap; **CTA de sponsorship** (GitHub Sponsors / Patreon / Polar); links de
+  comunidad.
+- "One founder documented how consistent public proof of project activity was the
+  turning point from zero to five-figure MRR — the README is the most visible piece of
+  that proof" [EXPERTO — Indie Hackers, citado en Quillly, 2026-06].
+
+Variante "minimalista senior" [EXPERTO — Quillly, Pattern 5]: tres cosas claras > veinte
+vagas; cada palabra gana su lugar; funciona cuando los repos pineados son fuertes.
+
+## 5. GEO — cómo leen los LLM el perfil de GitHub
+
+- El README del perfil es **contexto de agente**: un LLM que triangula una identidad
+  cruza GitHub ↔ LinkedIn ↔ web. Hechos inconsistentes = auto-descarte [INF — SPEC §8].
+- La consistencia factual entre superficies ES citabilidad: fechas/roles/papers idénticos.
+- Structured data: el JSON-LD `Person` (sameAs = links canónicos) ayuda a la resolución
+  [INF — schema/README.md, geoCheck structured-data readiness].
+
+## 6. Estética (2026, lo que funciona)
+
+- **Dark-first**: el widget de stats y los assets deben matchear dark mode
+  [EXPERTO — dev.to Igor Braz, hack #9: SVG con media queries de prefers-color-scheme].
+- **Centrado HTML div** para header/badges en pantallas anchas [EXPERTO — dev.to, hack #10].
+- **Accordions `<details>`** para material secundario (setup, certificaciones) — mantiene
+  limpio el primer scroll [EXPERTO — dev.to, hack #6].
+- **Restraint**: un solo widget de stats; paredes de badges = señal de optimización en
+  vez de construcción [EXPERTO — Quillly, 2026-06].
+- **ASCII art / one-liner** como firma visual funciona si es parte de la identidad
+  (perfil senior), no un decorado [BENCHMARK — patrón observado en perfiles técnicos].
+
+## 7. Fuentes
+
+| Fuente | Tipo | Fecha |
+|---|---|---|
+| GitHub Octoverse 2025 (82% privado, 1M+ PRs IA, TS #1, 36.2M nuevos) | [OFICIAL] | 2025 |
+| Quillly/devbio.me — "GitHub Profile README: What to Include in 2026" | [EXPERTO] | 2026-06 |
+| Quillly/devbio.me — "10 Patterns (2026)" (framework 3 preguntas, OSS Maintainer) | [EXPERTO] | 2026-06 |
+| Codeboards.io — "Complete Guide 2026" (signal not noise) | [EXPERTO] | 2026 |
+| Igor Braz — dev.to "Top 10 Hacks 2026" (6s, dark-mode, accordions) | [EXPERTO] | 2026-08-06 |