diff --git a/.claude/skills/openseo-release-notes/SKILL.md b/.claude/skills/openseo-release-notes/SKILL.md index 90a9741..e6df91f 100644 --- a/.claude/skills/openseo-release-notes/SKILL.md +++ b/.claude/skills/openseo-release-notes/SKILL.md @@ -15,37 +15,41 @@ Cut a release for this repo end to end. The deliverables are a version bump in ` ## 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 generated skeleton. -- For each commit, fetch the PR body and author (`gh pr view --repo every-app/open-seo --json title,body,author`) — squash-commit subjects can be stale. The `(#NN)` in commit subjects references the **public** repo (`every-app/open-seo`), so look authors up there, not on `origin`. Verify claims against the final code when a PR body and commit subject disagree (features get reverted before merge). +- 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` matching the style of the 2–3 most recent files in `release-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. -- 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. -- Imperative bullets ("Add…", "Improve…", "Cut…"), concise, user-facing. -- **Credit the contributor.** End each bullet with `— thanks @handle`, using the PR author's GitHub handle, for the feature or fix they contributed. When a bullet has sub-bullets, put the credit at the end of the top-level bullet (the feature), not on the sub-bullet. Skip the credit for the repo maintainer's own PRs (`bensenescu`) — only credit outside contributors. If one bullet folds in work from multiple contributors, thank each (`— thanks @a, @b`). -- **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. +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` -Content guidelines: +Curation — this is where the work is. Cut aggressively; the Full Changelog link covers the long tail: -- 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. +- 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** — 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). -- 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. + - **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. +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. diff --git a/.dockerignore b/.dockerignore index 75a4d69..91049e2 100644 --- a/.dockerignore +++ b/.dockerignore @@ -1,10 +1,11 @@ .git .github +.claude .logs -.wrangler -node_modules -dist -coverage +**/.wrangler +**/node_modules +**/dist +**/coverage *.log Dockerfile .env diff --git a/package.json b/package.json index 5aff29c..6d40648 100644 --- a/package.json +++ b/package.json @@ -2,7 +2,7 @@ "name": "open-seo", "private": true, "sideEffects": false, - "version": "0.0.23", + "version": "0.0.24", "type": "module", "packageManager": "pnpm@10.30.1", "scripts": { diff --git a/release-notes/v0.0.24.md b/release-notes/v0.0.24.md new file mode 100644 index 0000000..1f06301 --- /dev/null +++ b/release-notes/v0.0.24.md @@ -0,0 +1,17 @@ +GSC UI, improved app layout and beta in app agent. + +## What's new +- Get GSC Insights inside the app — thanks @mattmacrocket + - See queries in "striking distance" of ranking +- (Beta) In app agent - MCP is still recommended, but we'll be working to improve this during the summer. + - Requires `OPENROUTER_API_KEY` +- Redesigned the app layout + +## Fixed + +- A wrong or mis-formatted DataForSEO API key now shows a clear message telling you how to fix it, instead of "an unexpected error occurred". — thanks @mattmacrocket +- Local business searches with invalid input now show an error instead of quietly returning nothing. +- Claude answers in AI search work again. +- Site audits no longer occasionally crash near the end of a run. + +Full Changelog: https://github.com/every-app/open-seo/compare/v0.0.23...v0.0.24