The Idea

Freddy doesn't exist yet. All you have is a feeling: "every notes app annoys me, I want my own." This chapter is about turning that feeling into a spec — using Elyra as a thinking partner, not a code printer.

The problem

The most expensive mistakes in software are made before any code exists. Agents make this worse if you let them: type "build me a notes app" into any coding agent and it will happily generate three thousand lines of something. It will have auth you didn't want, a rich text editor you didn't ask for, and folder hierarchies when you wanted tags. Now you're not designing — you're arguing with a codebase.

The hard way

The classic failure mode looks like this:

> build me a notes app with laravel and svelte

  Creating 47 files...

Three sessions later you're deleting features and re-explaining what you actually meant. The agent wasn't wrong — it was unconstrained. The fix is embarrassingly old-fashioned: talk first, build second.

The Elyra way: the first conversation

Make an empty directory and start Elyra in it. No scaffold, no framework, nothing to edit yet — that's deliberate. An agent with no files to touch can only do one thing: think with you.

mkdir freddy && cd freddy
elyra

Then open with intent, and explicitly tell it not to build:

> I want to build a personal notetaker called Freddy. Web app.
  My frustrations with existing apps: too slow to capture a
  thought, folders force me to decide where things go before I
  know, search is always an afterthought. Don't write any code
  yet. Interview me: ask me the 5 questions that would most
  change the design.

That last sentence is the most useful prompting pattern in this whole course. Instead of guessing, the model asks. A typical exchange:

  Five questions:

  1. Single user or multi-user? (Auth changes everything.)
  2. Capture speed: is "open page, type, press enter" fast
     enough, or do you want a global hotkey / PWA?
  3. Tags: flat or hierarchical? Can a note have zero tags?
  4. Search: full-text over everything, or title-first with
     filters? How large do you expect the corpus to get?
  5. Lifetime: do notes get archived/deleted, or is Freddy
     append-only like a journal?

Answer honestly and tersely. Every answer here deletes a week of wrong code later:

> 1. Single user, but build auth anyway - I might share it.
  2. Open page and type. Capture box focused on load.
  3. Flat tags, zero allowed. 4. Full-text, thousands of notes.
  5. Soft delete with an archive view.

Side questions with /btw

Mid-conversation, a doubt appears: should search be Postgres full-text, SQLite FTS5, or something like Meilisearch? You want the answer — but you don't want a database comparison essay dumped into the middle of your product conversation, eating context and derailing the thread.

This is what /btw is for (@elyracode/btw — installable later, but worth knowing from day one). It runs your question in a separate, parallel session that shares nothing with your main conversation:

/btw for a single-user Laravel app with a few thousand notes,
is SQLite FTS5 enough for full-text search or do I want
Meilisearch? Short answer.

The answer lands as a notification while your main thread stays clean. When a side conversation produces something the main session should know, inject a summary:

/btw :summarize
  Summary injected: SQLite FTS5 is sufficient at this scale;
  Meilisearch adds an operational dependency Freddy doesn't
  need. Revisit only if corpus exceeds ~100k notes.

Landing the spec

After ten minutes of interview you have real decisions. Now make the agent write them down — into a file that will outlive this session:

> Write SPEC.md: a one-page spec from our conversation.
  Sections: What Freddy is, What Freddy refuses to be, Data
  model (plain words, no SQL), The four screens, V1 scope,
  Explicitly out of scope for V1.

"What Freddy refuses to be" is not a joke section. Scope creep kills side projects, and agents amplify it — adding features is what they're best at. Freddy's spec says: no folders, no rich text (Markdown only), no collaboration, no mobile app. When a future session suggests adding realtime collaborative editing, that line in the spec is what lets the agent say no to itself.

A condensed version of what lands in SPEC.md:

# Freddy the Notetaker

## What Freddy is
Fast capture, flat tags, real search. One user (auth-ready).

## What Freddy refuses to be
No folders. No rich text - Markdown only. No collaboration.
No mobile app. No AI features in V1.

## Data model
A note has: content (markdown), optional title, tags (0..n),
created/updated timestamps, archived flag. A tag has: a name.

## The four screens
Capture (default, box focused), Browse (list + tag filter),
Search (full-text via SQLite FTS5), Archive.

## V1 scope
Capture, edit, tag, browse, search, archive. Seeded demo data.

## Out of scope for V1
Sharing, export, keyboard palette, dark mode toggle.

End the session by naming it, so future-you can find it:

/name freddy: spec conversation

What you learned

• Start in an empty directory. An agent with nothing to edit is forced to think.
• "Interview me" beats "build me". Make the model ask the questions; your answers are the spec.
• /btw for research, main session for decisions. Protect your context window.
• Write SPEC.md, including anti-scope. Files outlive sessions; "refuses to be" is your defense against feature creep — including the agent's.
• Name your sessions (/name) — in a week you'll have thirty of them.