Claude Design Day One: フレームカーテンジ用のコンソールを開発した

Anthropic は金曜日に Claude Design をリリースしました。土曜日の午前中には、それを構造化された開発ワークフローに統合する機能完备なカートリッジ（コンソール）を完成させました。これは私が事前に計画したわけではありませんが、アーキテクチャがその可能性を直感的に示唆していたからです。 私が検証したものは、何か新しいものが登場した際、フレームのエンジン・カートリッジ分離モデルが依然として機能するかどうかってこと。新しいツール、新しいドメイン、新しいワークフローです。エンジンはそれをカバーできるのか、それともパッチ適用を余儀なくされるのか。 以下是その過程。 フレームについてはまだ知らなかったかもしれません：Claude Code 用プロンプトネイティブなワークフローエンジンです。フリーフォームのセッションではなく、特定の種類の作業に対してフェーズ、ロール、チェックポイントなどを定義するマーカー ファイルのセットであるカートリッジをロードします。SHAPE は要件を集めます。BREAKDOWN はスコープを分解します。DESIGN はアプローチを選択します。BUILD は一度に 1 ヶ単位のユニットを実装します。CHECK は出力を確認します。固定的なエンジンが状態管理、コミット、/clear での再開を処理します。ドメイン定義はカートリッジに任せています。 このアーキテクチャは意図的に分割されています：エンジン自体は変化せず、カートリッジが何が起こるかを決めます。この分割こそが今回の記事の本質です。 Claude Design は驚異的です。あなたが望むことを説明すると、美学的方向性とレイアウトに関するいくつかの焦点を当てた質問を返して、作業可能なインタラクティブプロトタイプを生成します。静的なモーショークライとしてではなく、実際に localStorage 状態、シードデータ、ライブインタラクションを備えた React アプリです。たった 1 つのセッションです。 日常習慣トラッカー Web アプリ。3 つの画面: ダッシュボード – 今日のリハビットのリストチェックボックス、各リハビットのストリームカウント、および週完了リングを表示します。ヘッダーには今日の日付と今日の全体の完了率が表示されます。 リハビット追加/編集 – リハビットの作成または編集のためのフォーム。フィールド：名前、頻度（毎日/週休日に/カスタム日）、カラータグ、オプションのリマインド時間。保存とキャンセルアクション。 履歴表示 – 月間カレンダーグリッド。各日のセルにはリハビットごとの完了を示すカラードットを表示します。タップするとその日の詳細を表示するポップアップが開きます。 目標：Web アプリ、ライトモード、清潔でミニマルな美学。 認証は不要です。単一ユーザーを想定します。 問題は次に何になるかです。「Claude Code へハンドオフ」ボタンは、このデザインファイルをフェッチし、README を読み、デザインの関連部分を実装するコマンドを返します。Claude Code はそれを文字通り解釈します。 これはいいように聞こえます– 直至到你思考它不知道什么。它不知道你要什么。它不知道 Claude Design 超出范围添加了什么。它不知道你想用什么生产栈，因为 Claude Design 特意推迟了这个决定。它不知道原型的设计选择中哪些是有意限制，哪些是默认值。 フレームは全てを知っています、なぜならそれが質問するためです。 フェーズのシーケンスは、ハンドオフの実際の仕組みを見るだけですぐにまとまりました。 生の sw-development カートリッジは：SHAPE → BREAKDOWN → DESIGN → BUILD → CHECK です。Claude Design ワークフローにとって、DESIGN は冗長です。Claude Design は既にその決定を下しています。代わりに、ハンドオフと分解の間にチェックを行うレビューステップが必要です。それとは何かを確認するものです：戻ってきたものとあなたが同意して構築したものとの違い。 私はそれを DESIGN-REVIEW と呼びました。 SHAPE → [Claude Design - external] → DESIGN-REVIEW → BREAKDOWN → BUILD → CHECK design_brief.md は、フレームではなく Claude Design 用に整形されたクリーンなブラフです。SESSION ヘッダーはありませんし、ゲートブロックもありません。単に何を作るか、どの画面か、どの制約を課すか。 SHAPE の最後のゲートは、コードベースを Claude Design に添付する前に design-assets/ へブランド資産をドロップさせるよう指示します。それはそれらを自動的に拾います。そして戻ってくるときに何をすべきかを正確に指示します：ハンドオフコマンドを貼り付けるが、まだ実装は行わない。 DESIGN-REVIEW はハンドオフコマンドを干渉します。それはバンドル URL を抽出し、フェッチし、README とプロトタイプ HTML を読みます– 次に生ハンドオフがスキップする作業を行います: – クラウドデザインがどの画面で動作したか

Anthropic launched Claude Design on Friday. By end of Saturday I had a working cartridge that wires it into a structured development workflow. Not because I planned to – but because the architecture made it obvious. That’s the thing I wanted to test: whether FRAME’s engine/cartridge split actually holds when something new drops. New tool, new domain, new workflow. Does the engine stretch to cover it, or do you end up patching around it? Here’s what happened. If you haven’t heard of FRAME (which is likely): it’s a prompt-native workflow engine for Claude Code. Instead of a freeform session, you load a cartridge – a set of Markdown files that defines phases, roles, and checkpoints for a specific kind of work. SHAPE gathers requirements. BREAKDOWN decomposes scope. DESIGN decides the approach. BUILD implements one unit at a time. CHECK reviews the output. A fixed engine handles state, commits, and resume across /clear. Cartridges define the domain. The architecture is deliberately split: the engine never changes, cartridges define what happens in between. That split is what this post is actually about. Claude Design is impressive. You describe what you want, it asks a few focused questions about aesthetic direction and layout, and it produces a working interactive prototype — not a static mockup, an actual React app with localStorage state, seed data, and live interactions. In a single session. A daily habit tracker web app. Three screens: Dashboard – shows today’s habits as a list with checkboxes, a streak count per habit, and a weekly completion ring per habit. Header shows today’s date and an overall completion percentage for the day. Add/Edit habit – form to create or edit a habit. Fields: name, frequency (daily / weekdays / custom days), colour tag, optional reminder time. Save and cancel actions. History view – a monthly calendar grid where each day cell shows a coloured dot per habit indicating completion. Tapping a day shows a popover with that day’s detail. Target: web app, light mode, clean and minimal aesthetic. No authentication needed. Assume a single user. The problem is what comes next. The “Handoff to Claude Code” button gives you a command that says: fetch this design file, read its readme, and implement the relevant aspects of the design. Claude Code takes that literally. It fetches the bundle, reads the prototype HTML, and starts implementing. Which sounds fine – until you think about what it doesn’t know. It doesn’t know what you originally asked for. It doesn’t know what Claude Design added beyond scope. It doesn’t know what production stack you want, because Claude Design deliberately deferred that decision. It doesn’t know which of the prototype’s design choices were intentional constraints and which were defaults. FRAME knows all of those things, because it asks. The phase sequence came together quickly once I looked at how the handoff actually works. The raw sw-development cartridge goes: SHAPE → BREAKDOWN → DESIGN → BUILD → CHECK. For a Claude Design workflow, DESIGN is redundant – Claude Design already made those decisions. What you need instead is a review step between the handoff and decomposition: something that checks what came back against what you agreed to build. I called it DESIGN-REVIEW. SHAPE → [Claude Design - external] → DESIGN-REVIEW → BREAKDOWN → BUILD → CHECK design_brief.md, a clean brief formatted for Claude Design, not for FRAME. No SESSION headers, no gate blocks. Just: what to build, which screens, what constraints. The gate at the end of SHAPE tells you to drop brand assets into design-assets/ before attaching the codebase in Claude Design – it’ll pick them up automatically. Then it tells you exactly what to do when you come back: paste the handoff command, don’t implement yet. DESIGN-REVIEW intercepts the handoff command. It extracts the bundle URL, fetches it, reads the README and the prototype HTML – then does the work the raw handoff skips: – Which screens did Claude Design actually cover? – What did it add that wasn’t in scope? – What stack decisions need confirming? – What production gaps does BUILD need to address that the prototype didn’t? The output is a structured review that BREAKDOWN and BUILD read instead of a DESIGN document. Everything from BREAKDOWN onward is inherited from the sw-development cartridge unchanged. I used the cartridge to build a habit tracker – the same prompt I’d used earlier to test Claude Design itself, so I could compare prototype to implementation directly. SHAPE ran cleanly. One question at a time, screens locked, out-of-scope list explicit. Then I took design_brief.md to Claude Design by attaching the project folder via Import → Link code folder. Claude Design reads everything in the linked folder, picking up the brief and any assets in design-assets/ automatically. It asked a few questions about aesthetic direction (should have kept the white background) and produced this: Then the handoff. The command came back as a URL instruction – not a zip, not a set of files. Just a hosted bundle with a README telling Claude Code to fetch, read, and implement. I pasted it unchanged into the Claude Code session. DESIGN-REVIEW didn’t implement. It fetched the bundle, read it, then surfaced the scope additions: drag-to-reorder (Claude Design added it; HTML5 drag works desktop-only), a history stats bar (not in the original brief but already designed), and the Tweaks panel (explicitly out of scope). It asked about each one. I kept the stats bar, scoped drag-to-reorder to desktop-only, descoped Tweaks. BREAKDOWN split the confirmed scope into five units. BUILD worked through them with the prototype HTML and CSS as visual reference. This is what the cartridge produced, single run, no tweaks, running on Sonnet 4.6 – not the Opus 4.7 model that made the original: The cream background, terracotta accent, strikethrough on completed habits, the “Not today” section, the weekly rings. Not identical – the flame emoji became a droplet, the date header got a touch of italic weight – but close enough that you’d use it. After CHECK passed, I ran the deploy cartridge – Vercel target, one command. The habit tracker is live at habit-tracker-nu-blue.vercel.app (demo only – resets on reload, nothing is persisted). That’s the full loop: brief → prototype → scope review → build → check → deploy. FRAME handled every step except the creative work itself. Two things, I think. One: the engine/cartridge split works. Claude Design is a new tool with a new workflow. The engine didn’t change. I wrote a cartridge. The phases, gates, state management, and resume mechanic all carry over without modification. That’s the whole point of the architecture. Two: the separation of concerns between Claude Design and FRAME is genuinely useful, not just structural. Claude Design does the creative work fast – aesthetic decisions, interaction design, visual hierarchy – better than a requirements interview ever could. FRAME does the disciplined work that turns a prototype into a production build: scope review, decomposition, unit-by-unit implementation, test coverage. Neither replaces the other. Claude Design produces something FRAME would struggle to produce in a DESIGN phase. FRAME produces something Claude Design’s raw handoff doesn’t: a structured build process with a paper trail, scope discipline, and a resume point if you run out of context halfway through. The Tweaks panel was out of scope. DESIGN-REVIEW caught it. BUILD never saw it. That’s the workflow working. FRAME is open source at github.com/SeriousByDesign/frame.