The first two build conversations ended badly. I had written a fairly complete brief for a two-column prompt composer, and the assistant said the Sites environment would not start. If those messages were the only evidence, this project would look like a design that never became a site. The export also contains a frontend source bundle and a successful deployment record. Reading that bundle lets me tell a more useful story: what I asked for, what the saved code actually does, and where the interface still has limits.
I wanted to stop composing long project instructions by repeatedly typing the same prose. On the left, I could choose a task, role, domain, behavior, and short keyword tags. On the right, I wanted to see the instructions form immediately—and be able to edit them when a control produced wording I did not mean. The idea was a small working composer, with the text always visible and the user still in charge of it.
The two-column idea
The desktop layout put Prompt Controls on the left and the Live Generated Prompt on the right. Most inputs were deliberately small: selectable task buttons, dropdowns, radio groups, toggles, and removable keyword tags.
The original brief used a game-development example. Instead of writing a paragraph about a modular, open-source Godot game every time, I could select the domain and enter tags such as Godot, GDScript, crafting, procedural, and modular. Those choices belonged in distinct parts of the prompt rather than one undifferentiated list.
| Control group | What I wanted it to express |
|---|---|
| Task, role, and domain | The job to do and the perspective to take |
| Goals, technologies, and features | The desired outcome and the material being worked with |
| Constraints, priorities, and things to avoid | Boundaries and the choices that should guide tradeoffs |
| Clarification and strictness | When to ask questions and how closely to follow requirements |
| Source behavior | Whether outside research is allowed and how evidence should be handled |
| Output and validation | The deliverable, its level of detail, and how to check it |
The distinction between Project Instructions and a single-use prompt mattered. Standing instructions need to remain useful across tasks; a one-off request can be much more specific.
Turning controls into instructions
The saved implementation separates the text-generation rules from the browser interface. The engine contains the available choices, presets, tag operations, and the generate(state) function. The interface gathers changes and renders the result.
Generation builds named sections: Purpose, Assistant Role, Tasks, Context, Requirements, Constraints, Workflow, Source Rules, Output Expectations, and Validation. Empty sections are omitted, and identical lines within a section are deduplicated.
The behavior toggle Preserve accepted decisions, for example, maps to an instruction to keep those decisions unless new evidence justifies revisiting them. A source mode of Provided sources only explicitly tells the assistant to identify gaps rather than fill them with outside knowledge. These are meaningful sentences, not merely copies of the control labels.
There are three output modes. Standard retains headings; Compact joins each section’s instructions into paragraphs without the headings; Detailed adds working notes. Compact mode in this snapshot is a formatting reduction, not a separate model that rewrites the prompt to a target size.
Presets as starting points
The built-in presets cover General, Software, Godot Game, Research, Troubleshooting, Construction, Learning, Prompt Review, and Custom. Each starts from the same defaults and changes the relevant controls.
The Godot preset requests a playable prototype with Godot and GDScript, a small initial scope, modular scenes, and validation. The Research preset enables outside research and source-handling options. Selecting a preset is a quick beginning; changing a control then marks the configuration Custom.
Saved presets live in the browser. They capture the controls, not a manually edited copy of the output. That makes them reusable configurations rather than a general document library.
Editing without losing the previous draft
The generated text remains editable. In the saved source, changing a control regenerates the prompt. If the current text had manual edits, the interface first saves it as the previous draft and offers a restore action. The restore control swaps the current and saved text.
That is a small but consequential behavior: live generation would otherwise make a hand-edited paragraph easy to lose. It is still only an in-memory previous draft, not durable version history.
For Project Instructions, the character meter warns from 7,500 through 8,000 characters and marks anything above 8,000 as over the configured limit. Those were the limits in this project’s brief, not a claim about every current product’s limits. The meter reports length; it does not silently truncate the user’s words.
What this snapshot establishes
The two build-request conversations ended with reports that the Sites environment could not start. Separately, the export contains a frontend source bundle and deployment metadata recording a successful publication. Keeping both facts matters: the failed attempts should not erase the later artifact, and the artifact should not rewrite those attempts as successful.
The saved source answered how this version generated and edited prompts. The two failed build conversations and the separate successful deployment record are both part of its history. I could explain the implementation from the archive; I would still check the live browser separately before claiming how that old deployment behaves today. The source note holds that closer code reading.