The third implementation is a markdown file

"Put my festival picks on my phone's calendar." One sentence, and it sounds like a feature you'd knock out before lunch. It took two apps, one iPhone, and a pile of standards archaeology to get right — and the punchline is that the third implementation isn't code at all. It's a markdown file that teaches our code generator to one-shot the whole thing.

First implementation: the festival

The Pickathon picker already let you star sets and build a personal schedule. The ask was a live calendar subscription — star a set on the farm, and it shows up on your phone without re-exporting anything.

Calendar apps refresh subscriptions with anonymous GETs — no login, no headers you control. Our platform deliberately refuses to let an anonymous request query an access-controlled database (that would bypass every permission rule). The move that makes the feature possible: a vibe's backend runs its fetch handler and its scheduled tick in the same isolate, so a once-a-minute tick reads the database as the owner and parks an aggregate in module state, and the anonymous GET serves from that.

Then the iPhone got involved, and the spec met the street:

• iOS maps webcal:// to plain http and shows one "insecure connection" prompt — but flat-out rejects webcals://, the "secure" variant you'd reach for. Settled on-device, not in documentation.
• If the feed answers a validation-time fetch with an error — any error, even a well-intentioned 503 — iOS says "Validation failed" and refuses the subscription. So a cold cache serves a valid placeholder calendar instead of an error, and established subscribers get protected the opposite way: a broken upstream is an error response (a 502 here; the port below answers 503 with a Retry-After), never an empty 200 that would wipe their synced events.
• ICS lines fold at 75 octets, not characters — byte-count them or a multibyte name splits mid-character and some parser somewhere gives up.

All of it is device-confirmed, not just parser-confirmed: a real iPhone subscribed to the live token feed syncs every pick at its correct instant — same-slot sets render side by side, stage names intact — and keeps doing so from the other side of the world, where iOS re-renders the same UTC instants in whatever timezone the phone wakes up in.

And one that came straight from a user report: the URL originally carried your handle, which meant your calendar was one guessable string away from anyone. The fix is a capability token — 16 random bytes minted in the browser the moment you open the calendar view, stored as a private doc, joined by the backend tick. Opt-in by construction (no visit, no token, no feed), unguessable, revocable by deleting one doc. That redesign shipped with the skill in PR #3267.

Second implementation: the pattern

Porting the feature to Rolling Today — a Pedalpalooza ride tracker — took hours instead of days, and the differences were as instructive as the sameness. Rolling Today's favorites carry a snapshot of the ride, so its feed degrades gracefully when the upstream API is down. And that upstream taught its own lesson: it rejects over-long date ranges with a 200 OK and an error body. If an API can say "no" with a 200, treating shape-mismatch as "empty" silently disables your feature.

One implementation is an anecdote. Two is a pattern — and a stable lesson list across two apps is the signal it's ready to become a skill.

Third implementation: the skill

Vibes DIY codegen has a catalog of skills — markdown docs a fast pre-selection model picks from before generating your app. calendar.md now carries everything above: the tick-and-cache architecture, the token privacy model, the iOS-proof serving contract, the octet folding, a compact backend to adapt. The selection model only ever sees a one-line description, so that line leads with what users say — favorites, picks, RSVPs, "on my phone's calendar" — not with ICS jargon.

Then we proved it, the only way that counts: a raw one-sentence generate against the live platform, asking for a Portland bike-ride list where you star rides and get a calendar link.

The generated backend was a faithful re-derivation, not a copy: byte-counted folding, opt-in token aggregation, the valid-placeholder cold path, even rejecting URLs with control characters. Where the generation slipped (a UI wiring bug in one run), the fix became a new guard line in the skill the same day — the skill is a living document with a feedback loop, not a snapshot.

The second generated app, Feed Filter, is a shape we didn't hand-build at all: paste any public calendar feed URL, parse it in the browser, star what matters, and subscribe to the filtered result. (When a feed's server doesn't allow cross-origin reads, the app says so and links MDN's CORS article — most calendar servers don't, though delightfully, Shift2Bikes does.)

The prompts are the eval suite

The proven prompts now live on the vibes.diy homepage — "Portland Bike Summer Calendar", "Team Calendar", "Training Plan", "Calendar Filter" (PR #3269). A homepage suggestion is a public promise that a prompt one-shots, which makes the carousel double as a standing regression test: if the skill regresses, the most visible prompts fail first.

Vibes are cheap to fork but expensive to teach. Skills are how a hard-won implementation stops being an artifact of one app and becomes a capability of the platform — institutional memory with a selection function.