@profile-as-code/cli 0.3.5 → 0.3.7

package/package.json

@@ -1,9 +1,23 @@
 {
   "name": "@profile-as-code/cli",
-  "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.",
+  "version": "0.3.7",
+  "description": "pasco \u2014 the profile-as-code CLI: init, validate, build, diff, edit (read / preview / write one contract field, comment-preserving), status + partial refine (task template), check (offline rules M6\u2013M8; catalog ships M3/M4), audit (offline findings projection), entity (the schema.org projection + paste-ready JSON-LD for surfaces the engine does not render), cite-check (deterministic citation matching over saved answer-engine answers, no network), export ai-policy (robots.txt + llms.txt + AI-POLICY.md: retrieval allowed, AI training blocked by default), export profile (the normalized, versioned profile object for programmatic consumers), preview (one self-contained HTML page of the rendered surfaces, written locally and never published), 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",
+  "funding": [
+    {
+      "type": "github",
+      "url": "https://github.com/sponsors/ChristianLuciani"
+    },
+    {
+      "type": "kofi",
+      "url": "https://ko-fi.com/christianluciani"
+    },
+    {
+      "type": "patreon",
+      "url": "https://www.patreon.com/cluciani"
+    }
+  ],
   "bin": {
     "pasco": "dist/index.js"
   },
@@ -43,6 +57,7 @@
     "node": ">=22"
   },
   "dependencies": {
+    "marked": "^18.1.1",
     "yaml": "^2.9.1",
     "zod": "^4.6.7"
   },

package/skills/README.md

@@ -53,10 +53,44 @@ skills/<plataforma>/
 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)
+## Post skills (MVP, #264/#266/#361)
 
 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`.
+`skills/<platform>/post.md` (judgment) + a machine-readable rule file.
+`pasco post` reads them; `pasco refine` keeps reading `SKILL.md`.
+
+- **Short** (`posting.yaml`): `linkedin`, `x` — char limits, hashtags.
+- **Long-form** (`longform.yaml`, #266): `substack`, `ghost`, `medium`, `devto`,
+  `hashnode`, `wordpress`, `listmonk` — required fields (`title`/`dek`), an
+  editorial word band, and `export: api | paste` (Substack/Ghost are paste
+  surfaces). The word band is house style, not a platform limit: cite a source
+  before encoding a hard cap.
+
+Every long-form channel also carries its judgment layer (#361): the `post.md` the
+short channels already have, plus a `SKILL.md` that they do not ship.
+
+- `post.md` — what a piece on that channel is for, its shape, its voice, and its
+  GEO and i18n policy, plus what `export: api | paste` means for the writing.
+- `SKILL.md` — the channel skill document: mission, when the skill runs, the
+  flow, the pointers to the contract, and the suggested model in its frontmatter.
+  It is a strategy reference, not a bundle input: `pasco post task` carries the
+  contract and `post.md`, never this file.
+
+**Do not use `pasco refine <channel>` on a post channel.** Refine is the
+profile-refinement command; with a `SKILL.md` present it now resolves the file (it
+used to answer "no skill yet") and emits a **profile** task that saves to
+`profiles/<channel>/variants/<id>.md` — not a post workflow. The path for these
+channels is `pasco post` with `longform.yaml`. Teaching the engine to tell a
+profile skill from a post skill is a separate engine matter, not something a
+skill can fix. (`checks.yaml` is not the cause: `pasco check` reads that catalog
+and reports "no catalog" without failing when it is missing.)
+
+`longform.yaml` stays the contract: required/optional fields, the word band and
+`export` are declared there, and the prose explains them instead of restating
+their numbers. A channel's *dated* platform sources live in the contract's
+`sources[]`; a claim the contract does not already carry needs its own source
+(URL + date + tier) before it enters either file. The post shape is Markdown
+beside the rule file — not the `research/` + `playbook.md` + `checks.yaml` trio,
+which belongs to the profile skills above.
+
+Neither shape is projected to harnesses yet — see `docs/post-mvp.md`.

package/skills/devto/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: devto-post
+description: >
+  Long-form post skill for DEV (Forem). Says what a DEV article is for and how
+  the agent writes one; the machine contract is skills/devto/longform.yaml
+  (required/optional fields, editorial word band, export: api). The judgment
+  layer — shape, voice, GEO, i18n — lives in post.md. The agent writes N
+  variants, the operator picks one, and the choice is recorded with
+  `pasco post choose`.
+model: juicio (frontier) — choosing the technical claim and its trade-off is
+  judgment; the mechanical parts (markdown, front matter) are not
+applies_to: devto
+projection: agent-agnostic (any harness that reads Markdown and can run the CLI)
+version: 0.1.0
+status: draft (#361)
+sources: skills/devto/longform.yaml
+---
+
+# DEV (Forem) long-form — skill
+
+## Mission
+
+Turn one canonical seed into a DEV article that a developer can act on: one
+claim, the smallest example that proves it, and the caveat that keeps it honest.
+The skill is the judgment layer (D5); the deterministic part is the contract plus
+`pasco post check`.
+
+## When it runs
+
+`pasco post task <seed> --format longform --channel devto` emits a task bundle
+that points at the contract (`longform.yaml`) and the judgment file (`post.md`);
+it does **not** carry this `SKILL.md`. This file is the channel's strategy
+reference for whoever opens it directly: read the contract for the fields and the
+band, then `post.md` for how to write.
+
+Do **not** run `pasco refine devto` for this channel. Refine is the profile
+command: with a `SKILL.md` now present it resolves this file instead of answering
+"no skill for devto yet", and emits a **profile** task ("write N variants of the
+devto profile") that saves to `profiles/devto/variants/<id>.md` — not a post
+workflow. Telling a profile skill from a post skill is an engine decision, not
+something this skill can fix.
+
+## Flow
+
+1. Read `longform.yaml` + `post.md`. Do not re-derive the limits: the contract
+   owns them.
+2. Write N variants as YAML front matter + markdown body, at
+   `posts/<seed>/devto/devto-<n>.md`.
+3. The operator picks one; record it with `pasco post choose`.
+4. `pasco post check` — fix what it reports instead of explaining it away.
+5. `pasco post export <seed> --target postiz` for the API draft payload.
+6. Publish manually, then verify on the live page that the front matter landed.
+
+## Contract pointers (single source each)
+
+| Question | Home |
+|---|---|
+| required / optional fields | `longform.yaml` `fields` |
+| editorial word band | `longform.yaml` `limits.words` (not a platform cap) |
+| api vs paste | `longform.yaml` `export` |
+| link policy | `longform.yaml` `links.policy` (`identity-ssot-only`) |
+| dated platform sources | `longform.yaml` `sources[]` |
+| how to write the piece | `post.md` |
+
+## GEO and i18n
+
+Public, indexed article page: the citation unit is the code block plus the
+sentence that states what it proves. Write `en` by default; a Spanish piece is a
+separate seed for that audience, never a duplicate of the English one. The
+crawler stance is the repo's global `ai.policy` (`platforms/registry.yaml`, v1,
+2026-10-27) — no per-channel rule is invented here.
+
+## Verification
+
+- `pasco post check` exit 0 (no `missing-field`, `word-count` or
+  `url-not-in-ssot` errors).
+- Facts byte-identical to the SSOT; every URL from the identity SSOT.
+- On the live page: title, tags and canonical URL arrived; the dek shows up as
+  the subtitle the channel renders, or not at all — never as a repeat of the
+  body's first line.
+- Report any contract gap as a finding — the engine is not extended from a
+  skill (#361).

package/skills/devto/longform.yaml

@@ -0,0 +1,33 @@
+# devto long-form rules — machine-readable (#266)
+#
+# Read by `pasco post task|check|export` when the seed is `format: longform`.
+# The word range is an EDITORIAL default (the operator's house style), NOT a
+# platform limit: cite a platform source before encoding a hard cap here.
+
+platform: devto
+format: longform
+export: api
+settings:
+  __type: devto
+fields:
+  required:
+    - title
+    - dek
+  optional:
+    - tags
+    - canonical
+    - publication
+limits:
+  words:
+    min: 600
+    max: 3000
+links:
+  policy: identity-ssot-only
+structure:
+  - title
+  - dek
+  - sections
+sources:
+  - url: https://developers.forem.com/api
+    date: 2026-10-29
+    note: "The Forem/DEV articles API takes title, tags and canonical_url; the body is markdown."

package/skills/devto/post.md

@@ -0,0 +1,96 @@
+# DEV (Forem) long-form post — skill (MVP)
+
+> Long-form post skill. The contract is `longform.yaml`: required/optional
+> fields, the editorial word band and `export` live there and are **not**
+> restated here — this file is the judgment layer the agent reads before
+> writing. The contract's `sources[]` carries the dated URL for every platform
+> claim; re-verify before making a hard one, and cite a source (date + tier)
+> before calling anything a limit.
+
+## What a DEV piece is for
+
+A technical piece for developers who will judge it by whether the code and the
+claim hold up. The reader arrives from a tag feed, from search, or from a
+cross-post on another channel — so the piece must stand alone: one technique,
+one result, or one decision with its trade-off. It is not a career update and
+not a newsletter issue.
+
+## Shape
+
+1. **Title** — the outcome the reader gets, in concrete verbs. No numbers you
+   cannot source, no curiosity gap the body does not pay off.
+2. **Dek** — one line of scope: what the piece assumes and what it delivers.
+   The contract requires it as a field, and the engine's task bundle is explicit
+   that title and dek are fields, never the first lines of the body — so the dek
+   is delivered in the front matter, not repeated as the body's opening line. No
+   platform mapping is declared; confirm on the first publish whether DEV renders
+   it as a subtitle [?].
+3. **Sections** — one H2 per step or idea. Show the smallest example that
+   proves the point, then the caveat. The contract fixes the three-part
+   structure; how many sections that takes is editorial.
+
+## Rules
+
+- **Front matter is the field contract.** Supply the fields `longform.yaml`
+  declares. A field the channel does not declare is not exported (`pasco post
+  check` warns `unknown-field`) — never smuggle it into the body instead.
+- **Length:** the band in `limits.words` is the operator's editorial default,
+  not a DEV limit (the contract says so in its own header). Treat it as the
+  budget for a piece a developer finishes in one sitting, not as a ceiling to
+  fill.
+- **Links:** `links.policy` is `identity-ssot-only` — every URL comes from the
+  identity SSOT. DEV syndicates, so `canonical` must point at the canonical
+  home from the SSOT, never at a second syndication copy.
+- **Facts:** every number, date, version and URL is cited with
+  `{{fact:<pointer>}}`; the engine renders it and fails on a dangling pointer.
+- **Voice:** first person, technical, no hype. Match `brandVoice`; the piece
+  should sound like an engineer explaining a decision, not a growth account.
+
+## Export: `api`
+
+The contract declares `export: api`: the body is markdown that the Forem/DEV
+articles API receives, with the title, tags and canonical URL carried as payload
+fields [OFICIAL — the contract's source, `sources[]` in `longform.yaml`, dated
+2026-10-29]. Consequences for the writing:
+
+- Markdown only. No raw HTML, no embeds that only an editor understands.
+- `canonical` is a payload field, not a body line — do not paste the URL into
+  the text as a substitute.
+- The export produces a Postiz draft payload; publishing stays manual (no
+  scheduler, no OAuth — `docs/post-mvp.md`).
+
+## GEO (how this channel is read and cited)
+
+DEV article pages are public and indexed, and the quotable unit is the snippet
+plus the sentence that says what it proves. Keep the version and the date inside
+the code block or the sentence around it; a table of unsourced benchmarks is not
+citable. The crawler stance is the repo's global `ai.policy`
+(`platforms/registry.yaml`, v1, 2026-10-27) — do not invent a per-channel rule.
+Consistency check: every version, date and number matches the SSOT byte for
+byte, exactly as on the profile surfaces.
+
+## i18n
+
+DEV's audience and tag vocabulary are English-first: write `en` by default. A
+Spanish piece is its own seed for the hispano dev community, not a translation
+of the English one. Do not publish the same text twice in two languages: two
+canonical URLs of one text split the citation.
+
+## Anti-patterns
+
+- "X is dead" / "N tools you must know" listicles with no artifact behind them.
+- An intro that restates the title for three paragraphs.
+- A code block that cannot run, or a version pin that is never stated.
+- Cross-posting without `canonical` — two copies then compete for one query.
+- A benchmark number with no method, date or source.
+
+## Output contract
+
+Save each variant as YAML front matter + a markdown body at
+`posts/<seed>/devto/devto-<n>.md`, then record the choice and check it:
+
+```
+pasco post choose <seed> --channel devto --variant devto-1
+pasco post check <seed>     # missing-field · word-count · url-not-in-ssot · unknown-field
+pasco post export <seed> --target postiz
+```

package/skills/ghost/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: ghost-post
+description: >
+  Long-form post skill for Ghost. Says what a Ghost essay/newsletter issue is for
+  and how the agent writes it; the machine contract is
+  skills/ghost/longform.yaml (required/optional fields, editorial word band,
+  export: paste). The judgment layer — shape, voice, GEO, i18n — lives in
+  post.md. The agent writes N variants, the operator picks one, and the choice is
+  recorded with `pasco post choose`; the deploy is a manual paste driven by the
+  generated checklist.
+model: juicio (frontier) — the argument and the opening are judgment; the
+  mechanical parts (markdown, front matter, paste checklist) are not
+applies_to: ghost
+projection: agent-agnostic (any harness that reads Markdown and can run the CLI)
+version: 0.1.0
+status: draft (#361)
+sources: skills/ghost/longform.yaml
+---
+
+# Ghost long-form — skill
+
+## Mission
+
+Turn one canonical seed into an essay worth a subscription: one argument, the
+evidence that carries it, and an opening that earns the first scroll in an
+inbox. Ghost is the surface the operator owns end to end (publication, domain,
+archive), so the piece is written to be the citable copy — while every URL it
+claims still comes from the identity SSOT.
+
+## When it runs
+
+`pasco post task <seed> --format longform --channel ghost` emits a task bundle
+that points at the contract (`longform.yaml`) and the judgment file (`post.md`);
+it does **not** carry this `SKILL.md`. This file is the channel's strategy
+reference for whoever opens it directly: read the contract for the fields and the
+band, then `post.md` for how to write.
+
+Do **not** run `pasco refine ghost` for this channel. Refine is the profile
+command: with a `SKILL.md` now present it resolves this file instead of answering
+"no skill for ghost yet", and emits a **profile** task ("write N variants of the
+ghost profile") that saves to `profiles/ghost/variants/<id>.md` — not a post
+workflow. Telling a profile skill from a post skill is an engine decision, not
+something this skill can fix.
+
+## Flow
+
+1. Read `longform.yaml` + `post.md`; the contract owns every limit.
+2. Write N variants as YAML front matter + markdown body, at
+   `posts/<seed>/ghost/ghost-<n>.md`.
+3. The operator picks one; record it with `pasco post choose`.
+4. `pasco post check` — fix the findings.
+5. `pasco post export <seed>` → `paste-checklist.md` (no body API in v1).
+6. Paste the body and each field into the publication editor, tick the checklist,
+   and verify the live page before calling it published.
+
+## Contract pointers (single source each)
+
+| Question | Home |
+|---|---|
+| required / optional fields | `longform.yaml` `fields` |
+| editorial word band | `longform.yaml` `limits.words` (not a platform cap) |
+| api vs paste | `longform.yaml` `export: paste` (decision #266) |
+| link policy | `longform.yaml` `links.policy` (`identity-ssot-only`) |
+| dated platform sources | `longform.yaml` `sources[]` |
+| how to write the piece | `post.md` |
+
+## GEO and i18n
+
+The publication's domain is the citable address; its archive is public, the email
+copy is not. State the claim next to a heading so the section is extractable, and
+keep every fact byte-identical to the profile. One publication, one language:
+write `en` by default and treat a Spanish publication as a separate surface with
+its own domain. The crawler stance is the repo's global `ai.policy`
+(`platforms/registry.yaml`, v1, 2026-10-27).
+
+## Verification
+
+- `pasco post check` exit 0 (no `missing-field`, `word-count` or
+  `url-not-in-ssot` errors).
+- The pasted body kept its heading levels, code fences and links; nothing was
+  flattened by the editor.
+- Front matter fields arrived on the live page (title + dek where the theme
+  renders it); canonical, if set, matches the SSOT.
+- Report any contract gap as a finding — the engine is not extended from a
+  skill (#361).

package/skills/ghost/longform.yaml

@@ -0,0 +1,36 @@
+# ghost long-form rules — machine-readable (#266)
+#
+# Read by `pasco post task|check|export` when the seed is `format: longform`.
+# The word range is an EDITORIAL default (the operator's house style), NOT a
+# platform limit: cite a platform source before encoding a hard cap here.
+# `export: paste` in v1 even though Ghost has an Admin API: the issue defers the
+# API channel and keeps Ghost a paste surface like Substack (#266 decision).
+
+platform: ghost
+format: longform
+export: paste
+settings:
+  __type: ghost
+fields:
+  required:
+    - title
+    - dek
+  optional:
+    - preview
+    - tags
+    - canonical
+    - list
+limits:
+  words:
+    min: 600
+    max: 3000
+links:
+  policy: identity-ssot-only
+structure:
+  - title
+  - dek
+  - sections
+sources:
+  - url: https://ghost.org/docs/admin-api/
+    date: 2026-10-29
+    note: "Ghost ships an Admin API; v1 keeps Ghost a paste surface (paste checklist) per #266, not an API channel."

package/skills/ghost/post.md

@@ -0,0 +1,98 @@
+# Ghost long-form post — skill (MVP)
+
+> Long-form post skill. The contract is `longform.yaml`: required/optional
+> fields, the editorial word band and `export` live there and are **not**
+> restated here — this file is the judgment layer the agent reads before
+> writing. The contract's `sources[]` carries the dated URL for every platform
+> claim; re-verify before making a hard one, and cite a source (date + tier)
+> before calling anything a limit.
+
+## What a Ghost piece is for
+
+An essay or newsletter issue that lives on a publication the operator controls,
+with its own domain and archive. That makes it the surface where the canonical
+URL of a piece can exist: other channels point their `canonical` here *when the
+SSOT already carries that URL* — never a URL the agent typed. The reader is
+either a subscriber reading an email or someone who arrived from search; write
+for both without writing twice.
+
+## Shape
+
+1. **Title** — the one claim the piece makes, stated so it still reads well in
+   an inbox list and in a search result.
+2. **Dek** — the line that earns the next scroll: context, stake, or the
+   question the piece answers. The contract requires it; how the theme renders
+   it (subtitle, excerpt, nothing) varies per publication theme [?] — verify on
+   the first publish and record what you saw.
+3. **Sections** — an essay argues, so give each section one move: the situation,
+   the tension, the evidence, the conclusion. H2 headings are the anchors a
+   reader (and an extractor) navigates by.
+
+## Rules
+
+- **Front matter is the field contract.** The fields `longform.yaml` declares are
+  the ones the channel consumes; anything else is dropped (`unknown-field`
+  warning) — do not re-add it in the body.
+- **Length:** the band in `limits.words` is the operator's editorial default
+  (the contract says so). Aim for the piece the argument needs; the band is a
+  guardrail, not a quota.
+- **Links:** `links.policy` is `identity-ssot-only`. A Ghost publication is a
+  URL surface like any other: every URL in the piece comes from the identity
+  SSOT, and `canonical` is only set when the SSOT already carries the target.
+- **Facts:** `{{fact:<pointer>}}` for every number, date and URL; a dangling
+  pointer fails the check.
+- **Voice:** first person, essayistic, no hype. Match `brandVoice`; a newsletter
+  issue is the one surface where a longer voice can breathe — do not turn that
+  into padding.
+
+## Export: `paste`
+
+The contract declares `export: paste` even though Ghost ships an Admin API: v1
+keeps Ghost a paste surface like Substack, by decision (#266), and the contract's
+`sources[]` records the Admin API docs [OFICIAL, dated 2026-10-29]. Consequences
+for the writing and the deploy:
+
+- The body is **pasted into the publication editor**; formatting must survive a
+  paste. Keep markdown simple: headings, paragraphs, lists, code fences, block
+  quotes. No raw HTML, no footnotes the editor may flatten, no tables unless you
+  re-check them after pasting.
+- `pasco post export` writes a paste checklist, not a publish: the deploy is
+  manual and the checklist is the record of what was pasted.
+- Fields are pasted one by one — treat the checklist as the field contract's
+  human-readable form and tick each line.
+
+## GEO (how this channel is read and cited)
+
+The publication's own domain is the citable address: its archive pages are
+public and indexable, while the email copy is not. That is why the canonical URL
+matters here more than on a network — the citation unit is a section heading
+plus the claim under it, and it resolves to a URL the operator owns. The crawler
+stance is the repo's global `ai.policy` (`platforms/registry.yaml`, v1,
+2026-10-27); no per-channel rule is invented here. Consistency check: the piece's
+facts are byte-identical to the profile and to every other channel's projection.
+
+## i18n
+
+A Ghost publication is per language: one publication, one audience language.
+Write `en` by default; a Spanish publication is a separate publication with its
+own domain and archive, and the piece belongs to exactly one of them. Do not
+publish a machine translation of the same text under the same canonical.
+
+## Anti-patterns
+
+- An essay whose first two paragraphs are a table of contents.
+- A `canonical` invented for the occasion — it must come from the SSOT.
+- Rich HTML that the editor flattens on paste, discovered after publishing.
+- Email-only framing in a piece that is also the public archive page.
+- A newsletter issue that is a link dump with no argument.
+
+## Output contract
+
+Save each variant as YAML front matter + a markdown body at
+`posts/<seed>/ghost/ghost-<n>.md`, then record the choice and check it:
+
+```
+pasco post choose <seed> --channel ghost --variant ghost-1
+pasco post check <seed>     # missing-field · word-count · url-not-in-ssot · unknown-field
+pasco post export <seed>    # paste: writes posts/<seed>/ghost/paste-checklist.md
+```

package/skills/github-org/SKILL.md

@@ -77,8 +77,7 @@ se cita, se ignora.
 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).
+4. Copiar el README al repo del org (deploySpec: git; el humano mergea).
 5. Verificación post-deploy: cada badge/link del README resuelve; los handles
    pending NO figuran como surfaces vivas.
 

package/skills/github-org/checks.yaml

@@ -19,7 +19,7 @@
   platform: github-org
   rule: fact-present
   value: true
-  note: "name/mission/tagline del README byte-idénticos al SSOT (D4)."
+  note: "El README que escribió `pasco build` se compara contra el render actual del SSOT en los dos sentidos — URL, fecha o número agregado u omitido, y texto sin token que lo explique (WARN, D12; `pasco audit` lo gradúa). `link-in-identity` es una premisa aparte."
 
 - id: org-links-identity
   platform: github-org

package/skills/github-org/playbook.md

@@ -4,8 +4,7 @@
 
 - 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).
+- Org de GitHub creado (privado hasta pasar el checklist de public-readiness).
 
 ## Pasos
 
@@ -17,7 +16,7 @@
 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).
+   branch + PR — el humano mergea.
 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).

package/skills/github-readme/checks.yaml

@@ -11,7 +11,7 @@
   platform: github-readme
   rule: fact-present
   value: true
-  note: "Los hechos del README deben estar byte-idénticos al SSOT (D4)."
+  note: "El README que escribió `pasco build` se compara contra el render actual del SSOT en los dos sentidos: URL, fecha o número que la superficie agrega u omite, y texto que ningún token explica (WARN, D12; `pasco audit` lo gradúa). `link-in-identity` es una premisa aparte."
 
 - id: gh-links-identity
   platform: github-readme

package/skills/github-repo-meta/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: github-repo-meta
+description: >
+  Superficie de presencia `github-repo-meta` (D23, #262): la metadata del
+  artefacto de código — descripción del repo, topics, social preview, release
+  notes y la página npm derivada. Convierte un release en presencia visible
+  sobre el repo, sin inventar hechos: la descripción y las notas salen del
+  release plan (`pasco release plan`) y del SSOT, nunca de la memoria del agente.
+model: mecánico (la copy es corta y acotada; el juicio de posicionamiento vive en
+  la skill de la README del perfil)
+applies_to: github-repo-meta
+projection: agent-agnostic (AionUi, OpenHands, Claude Code, Cursor, pi…)
+version: 0.1.0
+status: draft (D23, #262)
+sources: "platforms/registry.yaml (kind: repo-meta) · docs/SPEC.md §22"
+---
+
+# GitHub repo metadata — skill de superficie repo-meta (D23)
+
+## Misión
+
+Que un release exista como **presencia**: el repo se encuentra, se entiende y se
+comparte. El motor no renderiza esta superficie (no hay renderer: es HTML/API de
+GitHub); lo que el motor SÍ da es el **plan**: `pasco release plan <id>` nombra la
+superficie, su estado derivado del ledger y la **espina factual** del release. Esta
+skill es la capa de juicio que convierte esa espina en metadata publicable.
+
+## Regla de oro
+
+> La metadata del repo describe el **artefacto**, no a la persona. El perfil
+> (github-readme) es la voz; `github-repo-meta` es la ficha: qué es esto, para
+> quién, y qué cambió.
+
+- La descripción NO repite el positioning personal: dice qué hace el repo.
+- Los facts (versión, fecha, link) salen del release row y del SSOT; si un dato
+  no está, no se escribe.
+- Un release = una pasada. No optimices metadata sin release: sin evento, la
+  superficie queda `never` en el plan (y eso es correcto, D23).
+
+## Flujo
+
+1. **Plan**: `pasco release plan <release-id> --json` → la fila
+   `github-repo-meta` (estado) + `baseText[kind=repo-meta]` (la espina factual).
+   Sin `releases[]` en el workspace, el comando falla con la razón: agregá el
+   release primero (schema v1.15).
+2. **Composición** (juicio, esta skill):
+   - `description` ≤350 chars, la promesa del artefacto + una señal de para quién.
+   - `topics` ≤20, minúsculas, guiones; genéricos primero, específicos después.
+   - release notes: `baseText` como primer párrafo + `changedUnits` como bullets
+     verificables; nada de métricas sin fuente.
+   - social preview 1280×640 (el preview se sube a mano: no hay API).
+3. **Deploy** (API de GitHub, D9):
+   ```sh
+   gh repo edit --description "<description>" --add-topic <topic> …
+   gh release edit <tag> --notes-file <notas.md>
+   ```
+4. **Verificación** (playbook.md, sección "Verificación post-deploy"): la
+   lectura de vuelta con `gh repo view --json description,repositoryTopics` y la
+   inspección visual del social preview.
+5. **Cierre del loop**: en v1 el ledger solo direcciona las superficies del enum
+   de perfiles; `github-repo-meta` no tiene record y el plan la lee `never`. Es
+   un límite declarado (D23): el plan nombra lo que falta tocar; extender la
+   clave de superficie del ledger es un cambio de contrato aparte.
+
+## Límites y trampas
+
+- **Descripción duplicada**: si el repo y la página npm dicen lo mismo, es señal
+  de que el release no cambió nada relevante; no reescribas por inercia.
+- **Topics como hashtags**: no son keywords de marketing; son el índice por el
+  que un desconocido encuentra el artefacto.
+- **Notas = changelog completo**: el release note es la parte que le importa a
+  quien evalúa adoptar; el detalle vive en CHANGELOG.
+- **Social preview desactualizado**: es la única pieza sin API; verificala a
+  mano o no cuenta como publicada.
+
+## Checks
+
+`checks.yaml` declara los criterios con la misma forma que el resto de las skills
+(`rule` del catálogo, `platform: github-repo-meta`). En v1 `pasco check` no
+ejecuta una superficie fuera del enum de perfiles: el catálogo queda declarado
+para cuando la superficie tenga renderer, y hoy la verificación es la del
+playbook.