Will ChenClarity BearFrom idea to specification
Building Idyllic - Prior Iterations
October 2024
I wanted an AI interview that could turn a rough idea into a usable specification. In October 2024, I tried a simple version of the process myself: write a braindump, have AI process it, then answer questions until there was enough detail to make a list of work. The result gave me action items in a useful order and at a useful level of detail. I wanted to make that process into an Idyllic app.
We called it Clarity Bear. The person using it would begin with an incomplete account of what they wanted to do. The application would identify what was missing, ask about it and assemble the answers into something they could edit. The difficult part was deciding how the interview should progress and when it had enough information to finish.
Four stages for the interview
On October 31, I drew the app as four pages: braindump, processing, interview and review. Each page had a different job. The braindump page was a document editor with space to get the initial idea down. Processing would extract an outline and prepare the interview. The interview would gather missing information, and review would present the resulting specification.
Giving the stages separate screens made the transitions visible. After submitting the braindump, the person would see that it was being processed. During the interview, the conversation would have a particular purpose. At the end, the interface would provide a document to review. A chat history alone did not make those boundaries obvious.
Choosing the next question
The question loop needed more state than the most recent message. My sketch passes the previous question, the latest answer and the earlier questions into an evaluation step. The agent also keeps a scratchpad organized around a rubric. That gives it somewhere to collect what it has learned about the intended outcome and what remains unclear.
The next question would come from those gaps. The drawing includes prompts about success criteria, next steps and the smallest step that could be taken. These were ways to make a broad intention more specific. Asking an arbitrary follow-up could keep the conversation going indefinitely; the rubric was meant to give the interview a direction.
I also proposed a clarity score. Once the interview crossed a threshold, the interface would offer a way to finish and generate the specification. The score was a control for the proposed flow, with its meaning still to be worked out. We had not established that a percentage could reliably measure whether a project was sufficiently specified.
A related Figma design makes that interaction concrete. It combines the conversation with a visible clarity meter and a “Show results” control. The displayed percentage and greeting exchange are sample content. They show where the person would see progress and choose to leave the interview.
Implementing this meant treating the interview as a program that happened to use a chat interface. Each app run needed its own conversation. After an answer, the program would evaluate the history, update its notes, decide what to ask and change the interface state. The question text and the availability of the review step came from the same process.
A specification that stays editable
The third drawing follows the information through that process. The initial braindump becomes an outline and a set of questions. The interview contributes a history and a scratchpad. Those materials then feed the creation of a task list.
The output was intended to be an editable specification with tasks that could connect to Linear. I wanted it to remain useful after the interview ended. In the October design, this involved document blocks that the person could edit inside Idyllic.
For the first implementation, I planned to hardcode the app and its server routes. That would let me work through the interview before deciding how a general app builder should represent it. The reusable system still had to express a document editor, a processing step, a stateful conversation and a review screen.
Clarity Bear gave that system a concrete example to support. When a person answered a question, several things needed to happen together: the agent's record changed, the interview advanced and the controls on screen reflected the new state. The app builder needed a way to describe those connections.