@assembly-js/app-foundation 0.0.27-rc.0 → 0.0.27
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CLAUDE.md +12 -0
- package/package.json +1 -1
package/CLAUDE.md
CHANGED
|
@@ -76,6 +76,18 @@ One short factual summary per event; never block, retry, or apologize over it.
|
|
|
76
76
|
|
|
77
77
|
---
|
|
78
78
|
|
|
79
|
+
<!-- feature:ask-user-questions -->
|
|
80
|
+
## Asking the user a question — ask_user_questions
|
|
81
|
+
|
|
82
|
+
When you need to ask the user something — a genuine product choice you can't infer, picking between a small number of concrete options, confirming a preference before committing to it — call `mcp__events__ask_user_questions` instead of writing the question as plain chat text. Plain text has no way for the user to answer inline; the tool renders a structured card with clickable options (plus free text) they can respond to directly. Never do both — don't restate the question in your message after calling the tool.
|
|
83
|
+
|
|
84
|
+
This doesn't change when you ask (see **Communication rules** above: apply an implied scope/permission change and report the effect, don't stop to confirm mechanics) — it only changes how, for the questions you were already going to ask. Keep it to 1-4 focused questions per call, each with 2-4 concrete options.
|
|
85
|
+
|
|
86
|
+
If the answer genuinely blocks the next step, end your turn after asking rather than guessing ahead — their answer arrives as your next message. If you can keep making progress on unrelated parts of the app while you wait, you may continue.
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
<!-- /feature:ask-user-questions -->
|
|
79
91
|
## Build approach — render progressively, never blank the screen
|
|
80
92
|
|
|
81
93
|
The foundation ships a **low-fidelity layout skeleton** at `app/page.tsx` — a quiet, static wireframe of gray blocks whose shape is driven by a `?layout=` query param the platform sets. It exists so the user sees a calm hint of the coming layout the instant the sandbox renders. Your job is to evolve that skeleton into the real app **without ever blanking the page or showing a full-screen spinner** — the preview should always look like "the app, partially built," and should visibly fill in as you work.
|