# Openseo Release Notes > Corta una release de OpenSEO: sube la versión, redacta notas de versión para el usuario desde los commits del último tag, pasa una revisión con verificación por subagentes y abre un PR `release: vX.X.X`. Fuente: https://skillsagentes.com/skills/every-app/open-seo/openseo-release-notes Markdown: https://skillsagentes.com/skills/every-app/open-seo/openseo-release-notes.md Repositorio: https://github.com/every-app/open-seo Autor: every-app Licencia: MIT Actualizado: el mes pasado Coste de contexto: 68 tok instalada, 1.9k tok al activarse, 1.9k tok con todos los archivos del bundle Bundle: 1 archivo, 7 KB Permisos que pide: ninguno declarado ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add every-app/open-seo --skill openseo-release-notes --agent claude-code # Cursor npx -y skills add every-app/open-seo --skill openseo-release-notes --agent cursor # Codex npx -y skills add every-app/open-seo --skill openseo-release-notes --agent codex # Gemini CLI npx -y skills add every-app/open-seo --skill openseo-release-notes --agent gemini # Windsurf npx -y skills add every-app/open-seo --skill openseo-release-notes --agent windsurf # Cline npx -y skills add every-app/open-seo --skill openseo-release-notes --agent cline ``` ## Qué hace - Corta una release de OpenSEO de principio a fin: bump de versión en `package.json`, un nuevo `release-notes/v.md` y un PR contra `origin/main` titulado `release: v`. - Recoge los cambios desde el último tag con `git log`, y por cada commit consulta el cuerpo y el autor del PR en el repo origen o en el público, verificando contra el código final. - Redacta notas como digest escaneable de una pantalla: secciones `## What's new` (nombra la feature, no la vende) y `## Fixed` (3-5 bugs que un usuario reconocería), con `v0.0.24.md` como ejemplar de estilo. - Cura con dureza: solo cambios del producto que un self-hoster notaría; fuera marketing, precios, onboarding e internos invisibles. - Pasa una revisión con subagente y verificación adversarial APPLY/APPLY-MODIFIED/REJECT, y abre el PR sin publicar aún el release de GitHub. ## Cuándo usarla - Se pide preparar una release, subir la versión o escribir notas de versión de OpenSEO. ## Qué la activa - "Prepara la próxima release de OpenSEO" - "Sube la versión y redacta las notas desde el último tag" - "Escribe las release notes de esta versión" ## Antes de instalar - Necesita el repo de OpenSEO, `git`, `gh` autenticado y acceso a los repos origen y público; el release de GitHub se publica tras el merge con `pnpm release:publish`. ## Archivos - SKILL.md — 7 KB ## SKILL.md Reproducido tal cual desde every-app/open-seo bajo MIT. Esta sección es el documento original y está en inglés. # OpenSEO release notes Cut a release for this repo end to end. The deliverables are a version bump in `package.json`, a new `release-notes/v.md`, and a PR against `origin/main` titled `release: v`. ## 1. Bump the version - Read `package.json`. If the branch has already bumped `version`, treat that as the source of truth and do not change it. - Otherwise bump the patch version (e.g. `0.0.19` → `0.0.20`). Only bump minor/major if explicitly asked. ## 2. Collect the changes since the last release - Find the latest tag: `git tag --sort=-creatordate | head -1`. Verify the branch is up to date with `origin/main` (`git fetch origin main && git log HEAD..origin/main --oneline` should be empty; flag it if not). - List commits: `git log ..HEAD --oneline`. You can also run `pnpm release:notes` for a raw commit inventory — use it only as a checklist of candidate changes, never as the draft's structure (its Improved/Changed/Docs sections must not appear in the notes). - For each commit, fetch the PR body and author (`gh pr view --repo --json title,body,author`) — squash-commit subjects can be stale. The `(#NN)` in commit subjects can reference **either** repo: try `bensenescu/open-seo` (origin) first and fall back to `every-app/open-seo` (public) — outside contributors' PRs and their handles live on the public repo. Commits with no `(#NN)` may still be an outside contribution with a public PR (`gh pr list --repo every-app/open-seo --state merged --author `); check `git log --format=%an` for the author. Verify claims against the final code when a PR body and commit subject disagree (features get reverted before merge). - Record the PR author's GitHub handle alongside each change so the bullet can credit them. ## 3. Draft the notes Write `release-notes/v.md`. **`release-notes/v0.0.24.md` is the canonical style exemplar** — match it (v0.0.25 and later follow the same style); v0.0.23 and earlier are the old verbose style, never imitate them. The notes are a scannable digest, not documentation: the whole file fits on one screen (roughly 15 lines including headings), and every line earns its place. Format: - Top line: a fragment naming the release's 2–3 highlights ("GSC UI, improved app layout and beta in app agent."). Not a "This release brings…" sentence. - Sections: `## What's new` and `## Fixed` only. There is no "Improved" section — an improvement is either headline-worthy (What's new) or it's cut. - **What's new bullets name the feature; they don't sell it.** One short line each ("Redesigned the app layout", "Get GSC Insights inside the app") — no em-dash feature tours, no "so you can…" benefit copy, no lists of everything the feature touches. If the name alone is ambiguous, one clause of plain-words context is the maximum. - At most **one sub-bullet per feature**, one short line: the single most useful detail, a requirement ("Requires `OPENROUTER_API_KEY`"), or an expectation-setter. - **Label rough features "(Beta)"** and set expectations honestly, including pointing at the better alternative for now. The expectation-setter rides the top-level line after a dash ("(Beta) In app agent - MCP is still recommended, but we'll be working to improve this during the summer."), keeping the sub-bullet slot free for a requirement or detail. - Fixed: 3–5 bullets, one plain sentence each, only bugs a user plausibly hit and would recognize ("Claude answers in AI search work again."). No error codes, status codes, schema/infra vocabulary, or mechanism. If more than four qualify, keep the ones hit in core flows (searches, audits, tracking, MCP answers) and drop fixes for recovering self-inflicted state (re-adding, un-archiving, refreshing) first. - **Credit the contributor.** End the bullet with `— thanks @handle` for outside contributors only — never for the maintainer's own PRs (`bensenescu`). Credit goes on the top-level bullet, not sub-bullets. Multiple contributors: `— thanks @a, @b`. - End with: `Full Changelog: https://github.com/every-app/open-seo/compare/v...v` Curation — this is where the work is. Cut aggressively; the Full Changelog link covers the long tail: - Only changes to the **product itself** — the app, the MCP tools, the SEO data/features someone running OpenSEO actually uses. Litmus test per bullet: **would a self-hoster notice this while using the product?** Caring in the abstract (a new backend option, a raised cap) is not enough. - Do NOT mention: - **Marketing-website (`web/`) changes** — landing pages, copy, positioning, blog. - **Pricing / plans / subscription / billing** — paywalls, free-trial/plan changes, Autumn config. Hosted-commercial concerns, irrelevant to self-hosters. - **Onboarding-flow-only changes** — signup/onboarding chat, profiling steps, upgrade rails, email-verification UX. Not a product capability, even when sizable. - **Hosted-app internals & meta** — analytics, specs/ADRs, CI, refactors, dependency bumps. - **Invisible-to-the-user work, even when product-relevant** — security hardening, raised caps/limits, stability/memory/perf fixes, database/backend options and migrations. A user reading the notes should recognize every line from using the product; if they'd only notice it in a config file or an incident that no longer happens, cut it. - When torn between including and cutting, cut. A 4-bullet What's new that gets read beats a 10-bullet one that doesn't. - Never invent features — every claim must trace to a commit. - Numbers in bullets are usually selling — cut them; if one is genuinely load-bearing, quote the conservative, typical figure, never a cherry-picked best case. ## 4. Review and verify 1. Spawn a reviewer subagent with: the draft, the guidelines above, the per-commit facts you gathered, and repo access. It returns numbered review comments citing which guideline each violates. Its charge includes **verbosity**: flag any bullet that sells instead of names, any second sub-bullet, any Fixed bullet with mechanism vocabulary, and anything that pushes the file past one screen. 2. For each substantive comment, spawn a verification subagent (in parallel) that adversarially checks the comment against the actual commits/code and verdicts APPLY / APPLY-MODIFIED / REJECT. 3. Apply only verified comments. ## 5. Open the PR - Commit the version bump, release notes, and any skill changes on a branch named `claude/v` (use the current branch if it already follows this pattern). - Push to `origin` and open a PR against `main` titled exactly `release: v`. PR body: the release notes content. - Do not tag or publish the GitHub release — that happens after merge. After merge, run `pnpm release:publish`. It reads the version from `package.json` and publishes the matching `release-notes/v.md` to `every-app/open-seo`. - The equivalent command is: ```sh gh release create v \ --repo every-app/open-seo \ --title v \ --notes-file release-notes/v.md ``` ## Dónde encaja - Categoría: [DevOps e infraestructura](https://skillsagentes.com/categorias/devops-infraestructura.md) — Despliegues, contenedores, IaC y flujos de gestión de incidentes. - Creador: [every-app](https://skillsagentes.com/creators/every-app.md) — 19 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Seo Coach](https://skillsagentes.com/skills/every-app/open-seo/seo-coach.md): Entra en un modo de coach de OpenSEO cercano que explica los flujos, recomienda los siguientes pasos y ayuda a usar bien agentes, búsqueda web, scraping y datos MCP. - [Seo Audit](https://skillsagentes.com/skills/every-app/open-seo/seo-audit.md): Audita un sitio y entrega un informe SEO de una página, en lenguaje llano, que cualquiera puede accionar, centrado en una única acción para esta semana. - [Create Repo Skill](https://skillsagentes.com/skills/every-app/open-seo/create-repo-skill.md): Crea o actualiza una skill en este repositorio de la forma correcta: hogar canónico en `.agents/skills`, marca interna o pública, symlinks en `.claude/skills` y registro en las docs públicas para las skills de producto. - [Seo Project Setup](https://skillsagentes.com/skills/every-app/open-seo/seo-project-setup.md): Rellena el contexto compartido de OpenSEO de un proyecto (alcance del sitio, objetivos, posicionamiento, competidores, páginas clave y preferencias), más comprobaciones de MCP y entrada de Search Console. - [Keyword Research](https://skillsagentes.com/skills/every-app/open-seo/keyword-research.md): Descubre oportunidades de palabras clave, evalúa métricas y SERPs y guarda o etiqueta los términos prometedores usando los datos MCP de OpenSEO. ## Skills relacionadas - [Papercuts](https://skillsagentes.com/skills/every-app/open-seo/papercuts.md): Registra en `.agents/PAPERCUTS.md` la fricción real y recurrente del repositorio (setup confuso, comandos inestables, errores engañosos, archivos generados obsoletos) y también revisa, deduplica y resuelve las entradas existentes. - [Keyword Research](https://skillsagentes.com/skills/every-app/open-seo/keyword-research.md): Descubre oportunidades de palabras clave, evalúa métricas y SERPs y guarda o etiqueta los términos prometedores usando los datos MCP de OpenSEO. - [Webapp Testing](https://skillsagentes.com/skills/every-app/open-seo/webapp-testing.md): Toolkit para interactuar con y probar aplicaciones web locales con Playwright: verificar la funcionalidad del frontend, depurar el comportamiento de la UI, capturar pantallas del navegador y ver sus logs. - [Simple Issue Description](https://skillsagentes.com/skills/every-app/open-seo/simple-issue-description.md): Convierte un reporte de bug tosco, una petición de feature, una nota de soporte o un PR en un issue corto y en lenguaje llano, centrado en el problema y el comportamiento deseado. - [Seo Project Setup](https://skillsagentes.com/skills/every-app/open-seo/seo-project-setup.md): Rellena el contexto compartido de OpenSEO de un proyecto (alcance del sitio, objetivos, posicionamiento, competidores, páginas clave y preferencias), más comprobaciones de MCP y entrada de Search Console. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)