Vertical-agent design spec
← All agent specs

Relay -- Professional Project Wrap-Up for Designers and Developers - Vertical Agent Spec

One-line definition

An agent that assembles and formats client handoff documentation for freelance designers and developers by reading project artifacts and producing a structured, deliverable-ready package.

The workflow it owns end-to-end

  • Designer or developer signals project completion and connects their source of truth: Figma file, GitHub repo, folder of notes, or a filled intake form.
  • Agent inventories the artifacts it can actually see: named layers and components in Figma, directory structure and README content from the repo, and any notes the user has pasted in.
  • Agent drafts four sections in sequence: asset inventory with verified file paths, a usage guide written for a non-technical client, a maintenance playbook listing recurring tasks and estimated effort, and a support terms block using the freelancer's declared rate and scope limits.
  • Freelancer reviews, edits in-line, and approves each section before the agent assembles the final package.
  • Agent exports to the target format (PDF, Notion page, Google Doc) and flags any section where it had to infer rather than verify.

What it knows that a generic LLM doesn't

  • Figma layer and component naming conventions well enough to distinguish a placeholder frame from a deliverable, and to recognize when a component library is missing a published version.
  • Standard freelance support tier structures: the difference between a bug-fix window, a retainer, and a handoff-only engagement, and which language creates implied scope creep versus clear limits.
  • The vocabulary gap between how designers and developers name things ("tokens," "variants," "breakpoints," "environment variables") and how clients expect to read about them in a handoff doc.
  • Common failure modes in handoff packages: missing font licenses, undocumented CMS credentials, maintenance tasks listed without time estimates, assets referenced by local path rather than hosted URL.
  • Which fields a client is likely to ask about first (logins, who to call, what breaks first) and where to surface those in the document hierarchy rather than burying them in an appendix.
  • The reputational stakes of this document type: it is the last thing a client reads before the freelancer stops answering, so fabricated paths or placeholder support terms land differently than a hallucinated blog post draft.

What it explicitly declines

  • Writing or interpreting legal language in support terms beyond standard boilerplate. The agent produces scope-of-work language; actual contract review stays with the freelancer or a lawyer.
  • Documenting credentials, API keys, or passwords directly in the handoff package. It notes that credentials exist and should be transferred separately, but does not store or relay secrets.
  • Generating asset inventories for files it cannot read. If Figma access is not granted or the repo is not connected, it lists the gap rather than inferring what might be there.
  • Expanding into post-handoff relationship management, client communication, or invoicing. Those are adjacent products, and doing them poorly inside this agent would undermine trust in the core output.

Tools and integrations required

  • Figma REST API (read-only): pull file structure, page names, component inventory, and published library status.
  • GitHub API (read-only): read directory tree, README, and package.json or equivalent manifest to surface tech stack and dependencies.
  • Notion API (read/write): ingest project notes as input and publish the finished handoff page to a client-facing workspace.
  • Google Docs API: alternative export path for freelancers who share deliverables as Drive links.
  • A PDF renderer (Puppeteer or equivalent): produce a locked, branded PDF that does not require the client to have an account anywhere.
  • A simple structured intake form (Typeform or equivalent) for freelancers who do not use Figma or GitHub and are working from plain notes.

Trust escalation: when it pings a human

  • Any section where the agent had to infer rather than read from source. If no README exists and the tech stack was guessed from file extensions, the freelancer must confirm before that section ships.
  • Support terms that include a response time commitment or liability limit. The agent drafts the language but requires explicit approval before it appears in a client-facing document.
  • Asset inventory mismatches: if the agent counts fewer assets than the freelancer's notes describe, it stops and requests reconciliation rather than publishing an incomplete list.
  • Any hallucination flag its own output-checking pass raises. The agent runs a second pass looking for invented file paths, placeholder text left in, and numeric inconsistencies before submitting for human review.

Pricing model

The right pricing unit here is per completed handoff package, not a monthly seat. A flat $29 per exported package is defensible because it replaces two to four hours of documentation work that most freelancers either skip or resent. A bundle of five packages for $99 addresses the sporadic usage pattern by giving the freelancer a reason to prepay. The honest concern is that usage frequency is low: a freelancer wrapping two projects a month pays $58, which is fine, but one who wraps two projects a quarter may cancel between uses and only re-subscribe when the next handoff arrives. Retention will look bad on a subscription model. Per-package pricing at least aligns cost with value and avoids the churn optics of a low-engagement SaaS.

Differentiation from a generic LLM wrapper

The case for a purpose-built agent here is narrower than it looks at first. A freelancer who pastes their project notes into Claude and asks for a handoff doc will get 80% of the way there in one prompt. The remaining 20% is the wedge: pre-authorized read access to Figma and GitHub so the inventory is based on what is actually in the files rather than what the freelancer remembered to mention; a structured output format with the verification flags that tell the client which sections were checked against source and which were drafted from notes; and a second-pass hallucination check before the document reaches a client. That last point matters more for handoff docs than for almost any other LLM output category, because the client will act on what is in that document and the freelancer is accountable for it. The product is not the generation. The product is the audit trail that makes the freelancer comfortable sending it.

→ See handoff-ai as a SaaS landing page · → Fermi math (SaaS shape)