DEV Community: Hsin Yen Chung

What Happens After the Agent Finishes? — Introducing Agent CONT'D

Hsin Yen Chung — Sat, 01 Aug 2026 22:11:43 +0000

Today, we are opening the first founding beta for Agent CONT'D.

Our team uses Claude, Codex, ChatGPT, and custom agents every day.
Creating the first draft is becoming easier.
The difficult part is what happens after the agent finishes.

A useful document stays inside one agent session.
A teammate reviews it in Drive, GitHub, Slack, or email.
The feedback becomes separated from the agent.
The next person—or the next agent—starts without the decisions that came before.

We built Agent CONT'D to test a different workflow:

An agent creates project work
A teammate reviews and comments
The agent reads and addresses the feedback
The approved work remains available to the team
Another person or agent continues from it

We are looking for small AI-native teams already using Claude, Codex, ChatGPT, OpenClaw, or custom agents.

Bring one real artifact:
• A PRD
• A research report
• A technical specification
• Project documentation
• A client deliverable

I am looking for teams willing to use Agent CONT'D on real work and tell us exactly where it breaks.

Sign up here: https://studio.spuree.com/waitlist
Join our Discord: https://discord.com/invite/mmTZvAPkFq
LinkedIn: https://www.linkedin.com/company/continuity-contd

One Markdown File, 15 Landing Pages: Separate Your Copy From Your Design

Hsin Yen Chung — Tue, 14 Jul 2026 16:58:07 +0000

Our homepage went through fifteen complete redesigns last week. Not Figma mockups — fifteen deployed, pixel-complete pages. A quiet dark "review suite." A blueprint spec sheet. A research paper. A sticker poster with a yellow highlighter headline.

They all say exactly the same thing, because all fifteen read their copy from one markdown file.

Here's the whole thing in 60 seconds:

Don't take my word for it — the winner is live at workupai.com, and the fourteen runners-up are still deployed at their version URLs. Compare the blueprint spec sheet, the research paper, and the original against the sticker-poster homepage: same words, different worlds.

This post is about the pattern that made that possible, why it killed our longest-running meeting, and how you can steal it. (It's a follow-up to how our designer ships front-end changes without writing code — same philosophy, applied to our own landing page. The page sells Spuree, our review-and-memory layer for AI-generated work, but it lives at workupai.com — we give marketing experiments their own domain so we can rebuild them freely, behind their own infra, without ever touching the product site. Spuree becomes relevant again at the very end.)

The problem: copy debates and design debates in the same room

Every landing-page review I've ever sat in mixes two arguments that have nothing to do with each other:

"The headline should mention the team, not just the agent" (a copy problem)
"It feels too corporate, can it be more playful?" (a design problem)

When both live in the same React components, every change is entangled. You can't compare two designs fairly because they drifted to slightly different words. You can't fix a sentence without someone re-opening the color conversation.

So we physically separated them.

The workflow in 30 seconds

All copy lives in content/vme.md — one markdown file, plain key: value lines. Anyone can edit it.
Each design is one self-contained page — src/app/v1/page.tsx … v15/page.tsx. Every page reads the same file at build time.
A floating "versions" menu on every page lets anyone click between all fifteen designs.
Feedback comes as rankings ("I like v7 > v9 > v8"), and the next batch of designs mines the winners' DNA and drops the losers'.
Shipping the winner is one line — the root page re-exports the chosen version.

No CMS. No feature flags. Not a single client component. The whole thing is a Next.js static export.

The stack

Layer	Choice
Framework	Next.js (App Router), React Server Components only — we wrote zero client components
Styling	Tailwind CSS v4 — each version gets its own scoped design tokens in `globals.css`
Fonts	`next/font` for Google fonts (a different display face per design) + our brand OTFs via `@font-face`
Copy	One markdown file + a ~120-line parser (`fs.readFileSync` at build time)
Output	`output: "export"` — static files in `out/`, no server to run
Hosting	S3 (private bucket) + CloudFront (Origin Access Control, HTTP/2+3)
DNS / TLS	Route 53 + ACM (DNS-validated, auto-renews)
IaC	Terraform/OpenTofu — the whole `infra/` folder is nine small `.tf` files
Analytics	Plausible — one script tag, enabled at build time via env var
The agent	Claude Code — generated the variants, the parser, the infra, and most of this post's material

The deliberate constraint: everything renders at build time. Every page is fully readable with JavaScript disabled — the only JS on the wire is Next's own runtime, because we wrote no client components. It's also why sixteen routes cost nothing to host: this site's AWS bill rounds to pocket change.

The core trick: copy is data

The copy file looks like this:

## hero

kicker: The review and memory layer for AI-generated creative
headline: AI made drafts cheap. _Feedback is still scattered across your team._
subheadline: Creative Engine pulls client notes into one shared, searchable place...
cta-primary: See the review loop

## problem

headline: The AI workflow breaks right after generation.
items:

- Drafts get dumped into Slack, email, or Telegram.
- Feedback scatters across meeting notes, chat threads, and someone's memory.

A ~120-line parser turns it into { section: { key: value | values[] } } with fs.readFileSync in a Server Component — build-time only, nothing shipped to the client:

export function loadContent(name: string): PageContent {
  const raw = fs.readFileSync(
    path.join(process.cwd(), "content", `${name}.md`),
    "utf8",
  );
  // "## section" starts a section, "key: value" sets a string,
  // "- item" appends to the last list. That's the whole grammar.
}

The one detail I'd call genuinely reusable: emphasis is part of the copy, but its style belongs to the design. The _underscores_ in the headline mark which words get the special treatment. Each page decides what that treatment is:

// v1: white-to-grey gradient        withEm(headline, "text-gradient")
// v2: hollow outlined display type  withEm(headline, "v2-outline")
// v15: yellow marker highlight      withEm(headline, "v15-mark")

So the copywriter controls emphasis placement; the designer controls what emphasis means. Nobody steps on anyone.

(One war story: our markdown formatter silently rewrote *asterisks* to _underscores_ and broke the emphasis rendering. The fix — accept both, but ignore intra-word underscores so final_final_v3.png survives. Budget an hour for that class of bug.)

Where fifteen designs came from

I didn't design fifteen pages. I fed an AI coding agent real references and let it extract the design DNA:

our previous waitlist page (rendered it headless, pulled the fonts and layout patterns)
a landing page we admired (fetched its shipped CSS — found the exact accent #B6FC34 and font stack, no guessing)
screenshots of our actual product UI and login screen (that's where the cream-confetti-and-charcoal family came from)
our older marketing repo (lifted the brand font files and Tailwind tokens directly)

Each batch was three variants. Then the feedback loop did the real work: after "v7 > v9 > v8," the next three versions pushed the v7/v9 direction further and dropped v8's entirely.

Rankings beat reactions. "Make it pop" gives an agent nothing. "A > B > C" gives it a gradient to descend.

The version switcher: zero JavaScript

Every page gets a floating menu from the root layout. It's just a <details> element — works in a static export, no hydration, no state:

<details className="group fixed right-5 bottom-5 z-50">
  <summary className="... [&::-webkit-details-marker]:hidden">versions</summary>
  <nav className="absolute bottom-full right-0 mb-2 ...">
    {VERSIONS.map((v) => (
      <Link key={v.label} href={v.href}>
        {v.name}
      </Link>
    ))}
  </nav>
</details>

We also stripped version links out of every page's header and footer once this existed — one switching mechanism, defined once.

(After shipping the winner we gated the switcher and the /versions index behind a build-time flag — visible in dev, absent from production builds unless NEXT_PUBLIC_SHOW_VERSIONS=1. The variant URLs stay live for posts like this one; the comparison chrome doesn't follow visitors around.)

Shipping the winner

When the team picked v15, promotion was:

// src/app/page.tsx
export { default } from "./v15/page";

The old homepage moved to /v1. Nothing was deleted — fourteen alternates are still browsable, which turns out to be great for onboarding ("here's what we considered and why we didn't pick it").

How it deploys

Infra is provisioned once with terraform apply (S3, CloudFront, Route 53, ACM). After that, deploying is one script:

# scripts/deploy.sh (condensed)
NEXT_PUBLIC_PLAUSIBLE_DOMAIN="$DOMAIN" npm run build

# pass 1: hashed assets — cache forever
aws s3 sync out/ "s3://$BUCKET" --delete \
  --exclude "*.html" --exclude "*.txt" --exclude "*.xml" \
  --cache-control "public,max-age=31536000,immutable"

# pass 2: HTML — never cache
aws s3 sync out/ "s3://$BUCKET" --delete --exclude "*" \
  --include "*.html" --include "*.txt" --include "*.xml" \
  --cache-control "no-cache"

aws cloudfront create-invalidation --distribution-id "$DISTRIBUTION_ID" --paths "/*"

Three details that matter more than they look:

1. Two-pass sync for caching. Next's hashed assets (/_next/static/...) are immutable, so they get max-age=31536000,immutable. HTML gets no-cache so a deploy is visible immediately. Skipping this split is how you end up with users staring at a stale page for a day.

2. A 10-line CloudFront Function for pretty URLs. Static export writes /v7 as v7.html, but browsers request /v7. One viewer-request function bridges the gap — no server needed:

function handler(event) {
  var request = event.request;
  var uri = request.uri;
  if (uri.endsWith("/")) {
    request.uri = uri + "index.html";
  } else if (!uri.split("/").pop().includes(".")) {
    request.uri = uri + ".html";
  }
  return request;
}

This is the gotcha of S3 + CloudFront + output: "export" — without it, every route except / 404s and you'll lose an evening to it.

3. Analytics is a build-time decision. The deploy script injects NEXT_PUBLIC_PLAUSIBLE_DOMAIN, so local builds never track visits and production builds always do. No env drift, no "why is localhost in our analytics."

Total moving parts: an S3 bucket, a CDN, one function, one shell script. There's no CI pipeline yet on purpose — scripts/deploy.sh from a laptop is honest about what this stage of a startup needs.

What I've learned

Same copy, many skins turns taste into a fast decision. When every variant reads identically, "which one?" takes minutes. The moment wording differs between options, people argue about words while believing they're arguing about design.
Copy is a supply chain. Our hero names a problem ("feedback is scattered"), the problem section itemizes it, the solution section cancels each item using the same nouns, and the CTA lands the theme. If a later section can't reuse an earlier section's vocabulary, one of them is wrong. This is also why one shared file works at all.
The markdown-as-CMS pattern is absurdly cheap. ~120 lines of parser bought us: non-devs editing production copy, pure design A/B comparisons, and copy fixes that propagate to fifteen pages in one commit. I'd reach for this long before a headless CMS on any marketing site.

Steal it

The recipe, condensed:

Move every headline, list, and CTA label into one content/*.md file with a trivial key: value grammar.
Make each design a self-contained page that reads it at build time.
Mark emphasis in the copy; style it per design.
Add a <details> version menu in the layout.
Give feedback as rankings, ship the winner as a re-export.

Full disclosure: this workflow is also our product

The landing pages in this post sell Spuree Creative Engine — and the loop the copy describes is the loop I just walked you through, productized: your agent drafts, you share a client-safe review link (not a zip in a Slack thread), feedback lands pinned on the work itself, and every approval becomes per-client memory your agent reads before the next draft — from Claude Code, Codex, or OpenClaw.

Who it's for, concretely:

Freelance devs shipping agent output to clients — stop being the human clipboard between your agent and your client, and stop re-teaching your agent each client's taste after every revision round. One review link out, pinned feedback back, and the approval is remembered.
Agencies and brand studios — you're running this loop across many clients at once: campaign assets, product imagery, storyboards, social creative, character and IP canon. Creative Engine keeps a separate brand memory per client, so what Client A approved in March is what your agent drafts from in June — and no client ever repeats a note. The sign-off itself becomes the brand guideline.

And the multi-version trick from this post is becoming a feature. We're opening up HTML hosting on Creative Engine — upload your site or campaign variants, get shareable links and a version switcher, and collect client feedback on each one, with none of the S3/CloudFront setup you just read about. Freelancers: test landing page directions with your client before committing. Agencies: send three homepage directions as one link and let the client leave feedback where you'll actually find it. If you'd want that, say so in the comments — early access is going out to people who ask.

If you want to go deeper on any piece — the parser, the reference-driven design generation, the Terraform for the S3 + CloudFront setup, or how this plugs into the Slack + Claude Code workflow from the last post — drop a comment. Happy to share code.

And if you try this and get stuck — the routes 404 behind CloudFront, the emphasis markers break, the parser eats your copy — drop a comment too. I'll help you debug it. That's not politeness; comments about where this pattern fails are exactly what makes the next post better.

How Our Designer Ships Front-End Changes Without Writing Code

Hsin Yen Chung — Sat, 11 Apr 2026 22:35:15 +0000

Our product designer Zain just shipped a front-end change to our web app without writing a single line of code. He typed a request in Slack, and 10 minutes later there was a PR with a live preview environment.

This post breaks down exactly how we built this system at Spuree.

Video walkthrough: https://youtu.be/7_8cApBGWss

The Workflow in 30 Seconds

Zain types a request in our #ai-coding Slack channel
Spuree AI Coder (our AI agent) receives the message
Agent creates a Linear ticket automatically
Agent spins up a Claude Code sub-agent in a git worktree
Sub-agent implements the change, runs prettier, commits
Agent opens a PR on GitHub
CI/CD spins up a preview environment
Zain clicks the preview link, verifies the change visually, and approves — or asks for another iteration

No IDE. No git commands.

The Stack

Component	What it does
OpenClaw	A self-hosted AI agent for automating daily workflows
Claude Code	Anthropic's coding CLI — does the actual implementation
Linear	Ticket tracking — auto-created per request
GitHub	PRs, CI/CD, preview environments
Slack	Interface for the team
Spuree	Storage for agent output, backups, team sharing

How It Started: A Mac Mini and One Install

A few months ago, I installed OpenClaw on a 2018 Mac mini — a gift from a friend. One line to install:

npm install -g openclaw

I named it Chung.

Like onboarding a new employee, I taught it my workflows step by step:

How I review PRs
How I track Linear tickets
How I monitor tech blogs
How I summarize YouTube videos

Each workflow became a reusable skill — a markdown file with instructions, scripts, and configuration that the agent follows.

The Coding Skill: `claude-code-pr`

This is the skill that powers the designer workflow. Here's what it does:

1. Creates a Linear ticket

curl -s -X POST https://api.linear.app/graphql \
  -H "Authorization: $LINEAR_API_KEY" \
  -d '{"query": "mutation { issueCreate(input: { ... }) { ... } }"}'

The agent extracts the branchName from Linear's response — this ensures branch naming is consistent.

2. Creates a git worktree

cd $REPO_DIR
git fetch origin main
git worktree add ${REPO_DIR}-wt-${LINEAR_ID} -b $BRANCH_NAME origin/main

Worktrees let us work on multiple features in parallel without switching branches in the main repo.

3. Spins up Claude Code

cd $WORKTREE_DIR
claude --dangerously-skip-permissions

⚠️ Heads up: The --dangerously-skip-permissions flag lets Claude Code execute commands without asking for confirmation — file writes, terminal commands, all of it. We use this because the agent runs on a dedicated Mac mini with no sensitive data. If you're following along, only use this flag in sandboxed or isolated environments.

The agent sends a structured prompt with:

The requirements from the Slack message
A mandatory completion checklist (commit, PR, cleanup)
Formatting rules (run prettier before committing)

4. Creates a PR

Claude Code commits, pushes, and creates a PR with:

Summary of changes
Linear ticket link
Testing instructions

CI/CD automatically creates a preview environment from the PR.

5. Designer reviews

The preview URL appears in Slack. Designer clicks it, verifies the change visually, and approves — or asks for another iteration.

What Else the Agent Does

The coding skill is just one of many. Our agent runs cron jobs throughout the day:

Cron Job	Schedule	What it does
Morning AI Digest	8am daily	Searches for AI/tech news, sends bullet summary
Hacker News Summary	9am daily	Pulls HN front page, summarizes top stories
Tech Blog Monitor	9am daily	Checks RSS feeds + scrapers for new articles
PR Watcher	Every 30 min	Notifies about new PRs with code review summary
Video Summarizer	On demand	Transcribes YouTube videos, generates summaries

From Personal Assistant to Team Tool

After a few months, I realized everything was trapped on one machine. No backup. No team access. No way for others to comment on the agent's output.

The migration:

Backed up everything — memory, skills, cron jobs, config
Uploaded the backup to Spuree (our storage platform)
Spun up an EC2 instance on AWS
Downloaded and restored the backup
Adjusted file paths (Mac → Linux differences)
Connected to Slack

Spuree AI Coder was born. Now the whole team has access to the same workflows.

Agent output has a home

The key insight: agent output needs to be searchable, shareable, and backed up — just like any other work product.

When our agent creates something important — a strategy doc, a feature spec, meeting notes — it uploads it to Spuree automatically. Team members get a link, comment on it, and the agent creates the next version based on their feedback.

What I've Learned

Managing a team in the AI era, the gap between product, design, and engineering gets smaller — but only if you give your agents a proper setup:

Memory that persists — the agent needs to remember context across sessions
Skills that are reusable — turn workflows into shareable, version-controlled instructions
Output that's shareable — agent work needs a home where teams can collaborate on it

Get Started

OpenClaw: github.com/openclaw/openclaw
Spuree waitlist: spuree.com/waitlist — we'll share the skills and help you set up

I'm Steven, Head of Engineering at Spuree. We're building a storage platform for the age of AI agents. If you have questions about the setup, drop a comment — happy to go deeper on any part of this.