Movie Tracker again, with Claude Design

[bpurinton]

On #23, I built a complex version of Movie Tracker (https://github.com/bpurinton/movie-tracker-v2). It came out well, but the design was lacking, which wasn't very satisfying from a beginner perspective for initial interaction.

The question is: how can we integrate Claude Design in an pre- / mid- / post- Drawing Board build of the app.

I'll try a few approaches and report some notes here.

[bpurinton]

Claude Design > Drawing Board > Claude Design

In this approach, I started in Claude Design opus-5 on the web with this prompt:

Help me build a movie tracking app. I want movies with title, description, and year, with title and year required. There should also be directors with first and last name required. I want movies to have genres that can be applied to them. Movies should also have a field that tracks watched status (e.g. want to watch, watched, not interested), and a way to rate the movies with a 1-5 star system and a review comment. Users should be able to create movie lists and share lists with each other. Ask about important decisions

This led to a conversation that was not all that different from the /create-full-stack-app skill. Some upfront questions about database design, but also questions about the screens and theme. Not a lot of questions here, much less than our skill asks for.

It started working and took about 5 minutes to produce the first iteration. It looked pretty good off the bat.

I was going to download the HTML zip archive, but Claude Design said that might not be a complete feature set for the design and asked if I wanted something complete I could download instead, so I asked the chat:

Produce an archive that I can hand to another agent in an existing codebase to implement the design

That invoked a skill "Handoff to Claude Code" and I also prompted it to add screenshots. It finally produced a "design handoff" archive that I downloaded.

I then created a new Drawing Board codespace.

I then re-used my prompt from #23, which was similar to above but modified. (Note: somewhat awkward to have the same conversation twice.)

/create-full-stack-app Help me build a movie tracking app. I want movies with title, description, and year, with title and year required. There should also be directors with first and last name required. I want movies to have genres that can be applied to them. Movies should also have a field that tracks watched status (e.g. want to watch, watched, not interested), and a way to rate the movies with a 1-5 star system and a review comment. Users should be able to create movie lists and share lists with each other. Ask about important decisions. Show me the Foundation Plan and gaps before compiling. For this test, I want the app in the workspace root, not ./application. Do not deploy it.

After we had our conversation, I compiled and pushed to GitHub (https://github.com/bpurinton/movie-tracker-v3), then uploaded the zip to the design/.firstdraft/ folder, and used this prompt:

I've uploaded a Claude Design .zip archive to the design/.firstdraft/ folder. I'd like you to use that archive to build the UI for the app that follows that design. You don't need to follow it exactly if there are differences in our codebase that can't be implemented given our previous decisions, but use the design as a reference for the approximate screens and arrangement of elements I want. You don't need to use the custom CSS in the design, and can instead re-use the CSS framework that you currently have for the views, unless these are insufficient. Create some diverse sample data so that I can review the design in the live app preview when it's ready.

Important

We could have skipped this download / upload step with /design-login skill, which takes you to a login screen and allows you to sync designs. However, there's this annoying inability to copy-paste URLs from the chat in a codespace, which make this step really awkward. I noted this elsewhere. Claude confirmed that the zip archive download / upload does the same thing that connecting via /design would do, so I'm going with that approach

Claude made good choices about where to adhere to the design and where to diverge, preferring to limit design elements to what is achievable with the compiled app, rather than making changes that fit the design. It also fixed and wrote new tests around the design.

It looked really good in the live app preview

The process took 60 minutes, which is beyond the limit for sitting around in a workshop (not to mention token usage). But I did make this app purposefully complex.

Here is the unedited commit from when it finished its work (it's a huge diff, unsurprisingly): https://github.com/bpurinton/movie-tracker-v3/commit/7fb2bc03e3c9499017ce519034f1b6a32f4b88ee

[raghubetina]

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Standardize early design handoff without repeating the interview

Decision packet; recommendation pending. Covers observations 35, 36, with 37 as positive evidence. Suggested owner: existing Drawing Board #28, linked to the Skills authoring/Plan-review follow-up. Keep #460 as UI architecture context; this is not another design-system replacement.

What happened

Ben's account describes a design-first Movie Tracker, roughly five minutes to the first prototype, and a downloaded “Handoff to Claude Code” bundle. He then repeated a similar domain interview in Drawing Board, compiled the Plan, and only afterward uploaded the design. He reported a good final preview and an agent that adapted the design to the existing backend.

That sequence explains the repeated conversation: the second agent did not receive the first interview's context before modeling. It does not establish that First Draft must import a designer's generated code or couple itself to one provider. The same report says direct /design-login might replace upload, but no observed authenticated sync receipt establishes that path in a Codespace.

Current behavior and original rationale

Source inspected September 19:

• The testing guide already places the chosen reference before Plan authoring, asks the agent to reconcile behavior, and defers UI implementation until the baseline has been saved. It labels the complete design-to-scaffold journey unqualified.
• Skills main modeling guide already distinguishes confirmed/delegated/open/out-of-scope choices and avoids a mandatory questionnaire. It does not explicitly start by reading a prior design bundle/conversation and inventorying settled choices.
• Skill UI continuation correctly carries references into ordinary source work, follows UI.md, and avoids another Compile. This is post-Compile guidance, not proof that intake happens early.
• Drawing Board README recommends continuing in the same conversation, with existing components. Its broad UI prompt lacks the guide's one-flow boundary.
• Archive paths are being reconciled under #730; current Skill source uses .firstdraft/design/ while the fetched Board/guide still describe design/. The implementation-notes flow is already owned by Skills #77 and Service #751. Reuse those decisions rather than defining another archive or document contract.

The existing rationale is sound: visual prototyping can expose records, actions, and unanswered access questions, but a prototype is not an authority for data/authorization semantics. Compile the approved Plan, then adapt the normal Rails source with the original design as context. A local retained artifact also works when the planning and implementation agents differ.

Prior art and conventions

• Anthropic's design handoff tutorial describes a bundle with design files, conversation, and a README, usable by a coding agent. This supports retaining meaningful context, rather than a screenshot alone.
• Anthropic's current product help documents both ZIP export and direct handoff, plus /design and /design-sync. Its presence in current vendor docs is not proof of the user account's access, CLI version, browser authentication, or Codespaces operation. Avoid perpetuating an unverified historical /design-login recipe.
• Figma Code Connect is useful analogous prior art: design context is accompanied by actual component usage and code references so generated implementation respects the existing library. It is not a recommendation to add Figma or a mapping registry to First Draft.
• Kiro's import guidance supports both ordinary uploaded documents and optional connected tools. We can use the intake principle without adopting Kiro's additional specification artifacts.

Options

1. Standardize bundle-first intake (recommended). When references exist, inspect the brief, conversation/decisions, screens, and selected revision before interviewing. Reuse confirmed facts, ask about conflicting or missing behavior, then summarize what was carried into the Plan. Keep manual files as the documented fallback for either agent.
2. Make direct provider sync the primary design path. Potentially fewer file-transfer steps and easier revision updates, but adds authentication, availability, and provider-specific failure cases. Needs a separate actual Codespaces test before recommendation. It does not itself prevent repeated questions.
3. Leave the existing distributed guidance alone. Lowest work, but keeps the strongest instructions in the colleague gist instead of the Skill the agent actually reads.

No option requires a new FP design grammar or a Compiler design service. An optional design step must remain skippable for a user with a simple written idea.

Provisional recommendation

Adopt option 1 for the next trial, carrying known user intent into the existing compact semantic review. Treat direct sync as an optional convenience with a future independent smoke test, not a prerequisite. Have one maintained guidance owner with brief links from Board/guide; do not copy another large instruction block into every surface.

The intake should distinguish user-approved decisions, visual suggestions from the prototype, and unresolved product behavior. An attractive screen showing sharing or payment does not silently authorize those features. Preserve out-of-grammar intent in the already-approved implementation-notes workflow and refer to the immutable GapSet only for structured ungenerated meaning.

Owner question: For design-assisted trials, should the portable reviewed bundle be the default handoff, with direct provider sync optional until we qualify it?

Acceptance checks after a decision

• Replay Ben's initial brief with a handoff supplied before authoring. Previously settled fields/access choices are reused; only material conflicts/open decisions are asked again.
• Repeat with a brief/screenshots only and without design references; both remain viable.
• Use a fresh implementation agent with retained files/notes. It identifies the selected design and does not need private vendor-chat access to recover the approved context.
• Save and inspect the generated baseline, then perform the first UI task in existing Rails source without recompiling or replacing it with prototype code.
• Preserve references through the actual selected materialization route; align paths with #730 and do not claim GitHub-mediated transfer is qualified before #751's chosen path is exercised.
• Record source/package identities and whether the test used file upload or authenticated sync. Validate discoverability/behavior, not exact prose strings.

[raghubetina]

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Make the first design task a small working flow and measure it separately

Decision packet; recommendation pending. Covers observation 38 and uses 37 as positive evidence. Suggested home: Drawing Board #28; link the qualification to Service #504. This can be one implementation issue with the design-intake packet, provided both acceptance boundaries remain explicit.

Evidence behind the sixty-minute report

Ben reported that the final design application looked good but took about an hour. The actual unedited feature commit 7fb2bc03 changed 47 files, +2,471/−860 lines. Direct inspection confirms much more than colors or spacing:

• Movie search, status and genre filtering, sort choices, and grid/table views;
• watched/rating/review writes through a newly added nested route and controller;
• list pickers, ownership-aware sharing, and previously missing read policies;
• Director, Genre, Movie List, Movie, and Profile screens, navigation, substantial sample data;
• new request/system tests and accessibility checks.

For example, MoviesController#index adds filter/query/view/sort selection and MovieListPolicy#read? adds an owner-or-shared rule. This evidence supports “the task was too large for a workshop's first feedback loop.” It does not isolate model time, setup time, image downloads, compilation, test time, repair time, or pure visual adaptation. File count is scope evidence, not a benchmark.

The same commit replaces the development seed dispatcher with unguarded demo seeds and account provisioning. That should not be copied as a recommended pattern. No production exposure was established; keep this limitation beside the otherwise successful continuation evidence.

Current guidance

The testing guide, step 8 already requests one list/detail/form flow, real records, empty/error states, browser checks, and a separate UI commit. It then asks for one small feature in a later commit. The current Board README's more general scaffold-shaping prompt and Skill continuation reference do not give an equally concrete scope boundary.

The user already chose the broad direction of UI work after Compilation. The pending refinement is the first-task appetite and how to demonstrate it, not whether to add a whole design platform.

Prior art

Basecamp's “Get One Piece Done” recommends integrating one small usable slice so the team can try real behavior early. Its examples resist completing disconnected frontend/backend layers first. This maps well to a single resource interaction that already works in the compiled app.

“Set Boundaries” distinguishes time appetite from an estimate and adjusts scope to fit. Applied here, an agreed first-result target should trigger a status/re-scope checkpoint, not a claim that any arbitrary prototype can be implemented within that duration.

Options and tradeoffs

1. One complete existing flow first (recommended): name the resource and routes, retain existing behavior, apply its chosen visual direction, verify an actual successful and invalid interaction, and save a separate commit. Changes to other screens or domain behavior become subsequent tasks.
2. One screen only: fastest visible checkpoint, useful if time is especially tight, but a static index can hide broken forms or unrealistic data. It should not be called complete end-to-end continuation.
3. Whole prototype: can be satisfying and valid for an experienced owner, but depends heavily on missing backend work and produces an unpredictable first workshop wait.

Use dependencies only where they are needed for the selected flow. If a design includes ungenerated sharing, authentication, payments, notifications, or a new data model, surface that as additional scope before allowing “match the design” to absorb it.

Provisional recommendation: standardize option 1. Pick a small resource already supported by the compiled baseline. Agree on a first-result appetite (for example 10–15 minutes as an experiment), then report incomplete work and narrow the scope when the appetite is reached. This is a proposed experimental target, not a measured performance promise.

Owner question: Should the next trial explicitly timebox the first list/detail/form adaptation and stop to re-scope if it grows into missing feature implementation?

Acceptance experiment

• Reuse an exact compiled baseline and the same approved reference; record agent/model/version and any setup corrections.
• Name the allowed routes/behavior and completion checks before starting. Include desktop/narrow layout, populated/empty list, valid write, and invalid-input redisplay.
• Record separate elapsed intervals for design intake, Plan discussion, Analysis/Compile, setup, UI work, relevant verification, and repairs. Preserve interruptions/tool failures as such; do not charge them all to “restyling.”
• Save baseline, setup repair (if any), UI slice, and later feature separately. Verify normal Rails/Hotwire source remains the owner-facing implementation.
• Compare the same small flow with both supported agents before presenting a general workshop-duration claim. One successful assisted run is not an unaided-student result.
• Keep per-flow focused checks meaningful and do not remove existing accessibility/security checks to hit the time target. The current final-candidate qualification owns the broader gate.

[raghubetina]

The September 19 reconciliation is tracked in Drawing Board #43. It maps all 49 observations from the original reports and trials 3/4 to existing accepted work, source fixes, remaining qualification, positive/no-change evidence, and researched decisions awaiting the owner. Each pending packet includes examples, original rationale, primary-source prior art, alternatives and one owner question.

This is research and disposition tracking, not a claim that every issue is fixed or released. The original report remains the provenance; its unresolved items are not closed by this cross-link.

[raghubetina]

Findings status refreshed — 2026-09-22

Current reconciliation is in the complete 49-observation ledger and the emitted-code implementation tracker. Original observations and dated evidence remain unchanged. Design-input timing, avoiding repeated interviews, direct versus portable handoff and the scope of the first design milestone remain decisions; the reported successful design result remains positive evidence. Useful development data and real-example/artifact discovery are now accepted implementation work in Skills #83/#84. Broad design/interview overhaul remains behind emitted-code quality. No new design benchmark or authenticated sync trial was run by this refresh.