Lyre / documentation
Get Lyre

Working with an assistant

Give a clear task, review the changes, and test the result.

On this page

1 · Describe a result you can check

Start with the person using the app, the action they need, and how you will recognize success. Keep the first request small.

Make a checklist for preparing a community event.
I need to add a task, mark it complete, and filter unfinished tasks.
Explain your plan before changing files.
Keep the first version usable on a phone.
  1. Say what a person should be able to do

    Describe the outcome, not which technology to use. “Add a task and mark it complete” is easier to check than a list of files.

  2. Ask for the plan first

    Reading the plan costs one message and saves a lot of undoing.

  3. Ask it to explain the jargon

    Ask for unfamiliar terms to be explained, and for any setup you must do yourself to be listed.

It’s a good request when

you could tell someone else whether it worked without reading the code.

2 · Review before moving on

  1. Check the work is in the right project

    The proposal should belong to the project you have selected.

  2. Read each approval request

    A command or permission request describes an action on your computer. Read it before you allow it.

  3. Open Changes and read the diff

    Open Changes to see exactly which files were edited, how, and the assistant’s explanation.

  4. Test the exact behavior you asked for

    Do the thing yourself, in the running app.

  5. Save a working checkpoint

    Commit before you add the next feature, so you can come back to this state.

“Done” is not evidence

An assistant saying “done” is not evidence that the app works on your phone. Run the interaction yourself.

It worked when

you performed the new behaviour yourself and it did what you described.

3 · Recover from a failed change

  1. Write down what happened

    What you did, what you expected, and what happened instead. Include the visible error, with no private values.

  2. Ask for a focused fix

    One problem at a time, rather than “start again”.

  3. Go back if the result is worse

    Use your project’s saved version or Git history to recover before attempting another change.

The assistant and the running preview have separate lifecycles. A finished conversation does not necessarily stop the project, and restarting the app does not undo source edits.

You’re back when

the app behaves as it did before the bad change, and you understand what caused it.