admin/metatron-open-seo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

release: v0.0.21 (#293)

Browse Source
This commit is contained in:
Ben Senescu 2026-06-24 15:22:17 -04:00 committed by GitHub
parent 2087d0d614
commit 770005e2b9
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 24 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
.claude/skills/openseo-release-notes/SKILL.md
View File

@ -22,17 +22,23 @@ Cut a release for this repo end to end. The deliverables are a version bump in `
Write `release-notes/v<version>.md` matching the style of the 2–3 most recent files in `release-notes/`: Write `release-notes/v<version>.md` matching the style of the 2–3 most recent files in `release-notes/`:
- One-sentence summary line at the top (no heading). - One-sentence summary line at the top (no heading). Lead with the biggest user-facing win, stated as the outcome.
- `## What's new`, `## Improved`, `## Fixed` — include a section only when it has content. - `## What's new`, `## Improved`, `## Fixed` — include a section only when it has content.
- Imperative bullets ("Add…", "Improve…", "Cut…"), concise, user-facing. - Imperative bullets ("Add…", "Improve…", "Cut…"), concise, user-facing.
- **Be punchy — lead with the impact, not the mechanism.** The top-level bullet is the outcome the user gets ("Reduce rank tracking costs by ~3x"); push the how into one brief sub-bullet beneath it. Don't open a bullet with the implementation ("Run scheduled checks through DataForSEO's task queue and…") — that buries the lead.
- End with: `Full Changelog: https://github.com/every-app/open-seo/compare/v<prev>...v<version>` - End with: `Full Changelog: https://github.com/every-app/open-seo/compare/v<prev>...v<version>`
Content guidelines: Content guidelines:
- Only include changes relevant to users of the product (hosted users and self-hosters). - Only include changes to the **product itself** — the app, the MCP tools, the SEO data/features that someone running OpenSEO actually uses. The litmus test for every bullet: **would a self-hoster running OpenSEO care about this?** If it only affects the hosted commercial offering, the marketing site, or the first-run signup experience, drop it.
- Do NOT mention: marketing-website (`web/`) changes, hosted-app internals (billing infrastructure, Autumn config, directory/Smithery scores, analytics), specs/ADRs, CI, refactors. - Do NOT mention:
- Include bug fixes and improvements when notable and not part of a larger refactor (fold minor fixes into the related bullet or drop them). - **Marketing-website (`web/`) changes** — landing pages, copy, positioning, blog.
- **Pricing / plans / subscription / billing** — price changes, paywalls, free-trial changes, money-back guarantees, grandfathering, Autumn config, billing-status syncs. These are hosted-commercial concerns, irrelevant to self-hosters.
- **Onboarding-flow-only changes** — the signup/onboarding chat, profiling steps, upgrade rails, email-verification UX, and other first-run-only flows. A change buried in onboarding is not a product capability the broader user base gains; leave it out even if it's a sizable feature.
- **Hosted-app internals & meta** — directory/Smithery scores, analytics, specs/ADRs, CI, refactors.
- Include bug fixes and improvements when notable, user-facing, and not part of a larger refactor (fold minor fixes into the related bullet or drop them). A fix only qualifies if it changes behavior a user would notice in the product or MCP tools — not in onboarding or billing.
- Never invent features — every claim must trace to a commit. State user-visible limitations that set expectations (e.g. a feature unavailable for some countries). - Never invent features — every claim must trace to a commit. State user-visible limitations that set expectations (e.g. a feature unavailable for some countries).
- For headline numbers, quote the **conservative, typical figure**, not the cherry-picked best case. A PR's biggest number is often scoped to an ideal condition (e.g. "~83% cheaper for a page-1-ranking domain at default depth") — round down to a defensible blended claim ("~3x cheaper") so the headline never overstates the everyday result.
- Name specific MCP tools/params when an umbrella phrase would over- or understate which tools support a feature. - Name specific MCP tools/params when an umbrella phrase would over- or understate which tools support a feature.
## 4. Review and verify ## 4. Review and verify

2
package.json
View File

@ -2,7 +2,7 @@
"name": "open-seo", "name": "open-seo",
"private": true, "private": true,
"sideEffects": false, "sideEffects": false,
"version": "0.0.20", "version": "0.0.21",
"type": "module", "type": "module",
"packageManager": "pnpm@10.30.1", "packageManager": "pnpm@10.30.1",
"scripts": { "scripts": {

13
release-notes/v0.0.21.md Normal file
View File

@ -0,0 +1,13 @@
This release cuts rank tracking costs by ~3x, plus fixes for MCP tool output and project lookups.
## Improved
- Reduce rank tracking costs by ~3x.
- Scheduled checks now run through DataForSEO's task queue, and every check stops crawling SERP pages once your domain is found.
## Fixed
- Fix MCP tool output validation so results are no longer rejected after credits are spent, and report tool errors more clearly.
- Avoid an internal error during project access lookups.
Full Changelog: https://github.com/every-app/open-seo/compare/v0.0.20...v0.0.21