Recipes v0.5.0 — Creator-onboarding lands

This is the biggest single sprint Recipes has shipped since the public catalog opened. One PR is rarely a story. Nine PRs across three repos, all merged in a 4-hour window, are a story.

Headline numbers:

• 9 new MCP tools (14 → 23)
• 2 new database tables (skill_publish_requests, no-orphan-fleet schema)
• 62 skill rows renamed from cook → pro and operator → pro_plus
• 115 portal pages built; 8 docs pages expanded from stubs to full guides; 2 new docs pages
• 40+ new tests

If you’re an agent author, you probably care about the first three changes. If you’re a portal visitor, you probably care about the last three. If you’re building on the API: the new endpoints are all 100% backward compatible.

What changed for creators

Until today, publishing a skill required either:

1. Building a multipart tarball locally with recipes publish (which silently 422’d on any input mismatch and didn’t surface useful errors), OR
2. Pasting JSON into the WebUI /publish form (which was hardcoded to fail in two different ways).

Both paths needed an ed25519 keypair, a SKILL.md, a tarball, a signature, and the wits to assemble all four correctly. Documentation claimed “24-hour review by the Recipes team” — there was no such thing.

The new path is one MCP call:

recipes_publish_request(
    slug="my-awesome-skill",
    content="<full SKILL.md text>",
    version="1.0.0",
    tier="pro",
    is_public=True,
    references=[{"path": "refs/api.md", "content": "..."}],
)

What happens behind the scenes:

1. The tool runs the same quality gate the multipart /api/skills/_publish route runs. High-severity findings — leaked secrets, AGPL contamination, malformed YAML frontmatter — short-circuit before anyone reviews. You see the findings, not us.
2. If the gate passes, a labelled GitHub issue opens in wisechef-ai/recipes-api with your slug, version, sha256, content preview, and any warnings the gate flagged. We review.
3. When we add the approved label, a GitHub Action takes over. It generates an ephemeral ed25519 keypair, packs the tarball with your content and references, calls the existing multipart _publish route with the platform signing key, and reports back on the issue. The skill goes live.

This mirrors the GitHub-dispatch pattern already used by recipes_feedback, recipes_request_recipe, recipes_report_skill_error, and recipes_propose_skill_patch. Zero new infrastructure — we wrapped an existing helper. CLA, audit trail, no creator-side cryptographic juggling.

The old multipart route still works. recipes publish from the CLI still works. The MCP path is the new default; the rest is fallback.

What changed for cookbook owners

Three new MCP tool families:

Sharing: recipes_share_create / list / revoke / rotate. Mint a cbt_* token scoped to one cookbook, hand it to another agent, revoke when done. Returns ready-to-paste Hermes YAML and Claude Desktop JSON config blocks.

Fleet: recipes_fleet_create / subscribe / sync / list. The Fleet and FleetSubscription tables had been in the schema since Phase E but nothing read them. Now they’re wired. Make a fleet, subscribe cookbooks to channels (stable / beta), send recipes_fleet_sync over an x-fleet-key header to have every agent pull updates atomically. The middleware checks rec_fleet_* prefix, scopes the request to the fleet, runs the same install pipeline as a regular user.

Installation portability: the CLI now respects RECIPES_INSTALL_DIR and a --install-dir flag on install / sync / list / update. Stack-agnostic. Claude Desktop, Codex, Cursor — no more symlink dances.

What changed for portal visitors

Adam, walking the homepage yesterday, found four bugs in twenty minutes.

1. The “Creators” nav link pointed to /creators, which 302-redirected to /referrals. Two hops. Wasted.
2. The /referrals page checked /api/auth/me client-side and flipped one element when you were logged in. The other eight CTAs still said “Sign up for free” to authenticated users.
3. The integration platforms section used emoji as logos. ⚙️ for OpenClaw AND for Zed. 🪟 (a window pane) for Claude Desktop. Whatever 🜲 is for Hermes.
4. The “Pro skills spotlight” was a hardcoded list of four skills. One of them — web-scraper-pro — didn’t exist in the catalog. Click-through returned 404.

All four shipped fixed today:

• Nav points directly at /referrals. /creators keeps the 302 compat-redirect for external link survivors.
• /referrals does a server-side session check at Astro page-render time and shows a real dashboard (referral code, click count, conversion count, MRR earned) to authenticated users. Anonymous visitors still see the signup pitch.
• Ten real SVG logos replace the emoji.
• The spotlight is now a live /api/skills/search?tier=pro&is_public=true&page_size=4&sort=install_count_desc query with a fallback array of verified-existing slugs for offline-build resilience.

Bonus fix in the same sprint: the homepage carousel had been frozen at the moment of the last git push origin main. Astro’s static site generation fetched /api/carousel/today at module-load time and baked the result into the HTML. The cron filled tomorrow’s slate daily, the page never updated. Now the fetch happens client-side on page load, so the carousel reflects today’s slate every time.

What changed for tier semantics

The DB had been carrying four tier labels: free, cook, operator, studio. The portal, Stripe, and all human-facing documentation called them free, pro, pro_plus. Both vocabularies were live simultaneously. Stripe-paying customers saw “Pro” in checkout and “cook” in API responses.

Today:

• A new migration renames cook → pro and operator → pro_plus on every live skill row.
• The recipify default tier for newly-created skills is pro (was cook). No more drift on new inserts.
• TIER_RANK in app/access_routes.py collapses to {'free': 1, 'pro': 2, 'pro_plus': 3} plus a 30-day READ alias for cook / operator / studio so existing integrations keep working through 2026-06-10.

What broke (and got fixed in the same window)

Two regressions surfaced during Phase K verification on production:

1. The /api/skills/search?tier=pro filter returned 0 results despite the DB having 52 pro rows. Three call sites were still mapping pro → cook for the DB query — left over from when the DB column was literally called cook. Inverted to cook → pro (so legacy callers still work). Tests added.

2. The alembic migration test suite had been silently failing for weeks. Investigation revealed three real bugs in the migration chain: a missing bootstrap migration for six tables that were created out-of-band before alembic existed, a try/except CREATE EXTENSION vector that left Postgres transactions in an aborted state on non-pgvector hosts, and a SQLite-only test fixture that couldn’t validate Postgres-only DDL at all. New test suite runs the full chain against real Postgres on every PR. The hidden bugs are now load-bearing tested.

Coverage

Local pytest: 1641 passing, coverage gate (--cov-fail-under=85) still GREEN.

Acknowledgements

The whole sprint ran on a 10× budget extension Adam authorised for “boil the ocean.” Eight subagent worktrees in parallel, Sonnet 4-6 on the heavy phases, Haiku 4-5 on the mechanical ones, Opus on planning and merge orchestration. Wall-clock from kickoff to v0.5.0 tag: about 4 hours. Realistic spend: $210.

Full plan-doc, with verified evidence per phase, lives in the Obsidian vault under projects/recipes/2026-05-20-recipes-2005-execution-plan.md. Reconciliation note (cost-vs-projection, what went wrong, what to retune for next sprint) at 2026-05-20-recipes-2005-execution-reconciliation.md.

Next sprint: recipes_2006_legacy_cleanup. Drop the cook / operator / studio aliases after the 30-day deprecation window. June 10.