Case Study

QuickCopy

Five copy buttons and a share-link split — the second Marketplace product through the agentic pipeline, built end-to-end on the patches PageShot left behind.

Case Study4 min read

The five things marketers paste most

Marketers and content authors live in the SitecoreAI Pages editor. While they edit, they constantly need to paste the page they're on into Slack, Teams, Jira, email, or release notes. The data they actually paste is small and predictable:

  • The Live URL (the absolute public URL of the published page)
  • The Preview URL (the authoritative preview from the Agent API)
  • The Item ID (the page's GUID, no braces, no whitespace)
  • The Page Title (the display name as plain text)
  • A Share Link — [Title](URL) Markdown, or Title — URL plain text

QuickCopy is a Page Context Panel that puts those five buttons inside the editor and gets out of the way. Click. Pasted. Done.

5
copy buttons
(metadata)
2
share-link
variants
5
keyboard
shortcuts
0
scaffold
patches needed

How it actually works

The panel docks into the Pages editor sidebar and tracks the page the editor is currently on. The moment the page or its version changes, the panel pre-fetches everything it needs for the five buttons in parallel and caches it against that exact version. Clicks then read from the cache synchronously: no spinner on first click, no fetch on the click itself, and a failed pre-fetch leaves a persistent red mark on the affected button rather than pretending to succeed.

The UI is built from Sitecore's Blok design system, defaults to dark mode, and every action is keyboard-driven so an editor never has to take their hands off the keyboard to share a page.

What the build proved

QuickCopy was the second Marketplace product shipped through the full /create-prd → /architect → /task-breakdown → /implement → /code-review → /test → /document → /ship pipeline. PageShot's build had patched 42 things in the underlying skill catalogue. QuickCopy was the test of whether those patches actually held.

Build · 02

The closed-loop test

2026-04-26 · Pages Context Panel

If the skills had really hardened, the second build should produce a clean app on the first scaffold — no re-patching, no improvisation. That's exactly what happened.

  • Pure pipeline graduation — built end-to-end through /create-prd → /ship with all earlier-run patches already baked into the skills.
  • Zero scaffold friction — the first scaffold produced a clean app; lint, typecheck, tests, and build all green out of the box.
  • Validated the SDK story — the conventions hardened on PageShot (Live URL, Preview URL, Item ID) flowed straight into a second product without rework.
  • Exercised QA and accessibility gates — automated a11y checks integrated into the test suite, with two regressions caught and fixed before ship.
  • Proved the loop closed — the skills no longer needed patching to deliver a real, shippable Marketplace app.

What hardened in design-polish-1

A second pass landed three things worth naming:

  • A version-keyed cache — the cache evicts the moment the editor saves a new version, so the copy buttons can never hand a stale preview URL to a marketer.
  • Trust the SDK's declared shapes — hand-rolled response interfaces were swapped for the SDK's own type definitions. Two silent shape mismatches surfaced in the swap, the kind that would have rotted into runtime bugs without a type-driven prompt.
  • An honest live-URL story — when the tenant has no published hostname configured, the Live URL button stays disabled with a tooltip rather than producing a URL that points at a placeholder.

Where this leaves the loop

QuickCopy's clean first scaffold confirmed what the dogfood loop had been building toward: the skill set is now reliable enough to deliver a real, shippable Marketplace app on the first pass.

Component Atlas was the third build through the same pipeline — proof the loop kept holding when the surface area scaled from a five-button panel to a tenant-wide live atlas.

Related case studies