Project Chat in Licuse: From Conversation to Reviewed Changes

Start with the right project

Open the project folder you intend to work on and check the selected project before sending an instruction. A general chat and a project conversation have different jobs: one can help you think through an idea, while the other needs evidence from a specific codebase. A project name mentioned in an earlier message is not proof that the same folder is still open.

For an unfamiliar repository, begin with a question instead of an editing request. Ask where a flow starts, which source files implement it and what existing checks cover it. This gives you a small map of the work before anything changes.

In the open Still Studio project, explain how a selected membership reaches the visit form.
Read the relevant source and earlier project conversation.
Point to the files you used. Do not change anything yet.

References: Licuse user guide

Use history to recover decisions, then read the current code

Chat can discover Code and Design conversations and read their transcripts. This helps answer questions such as why a fallback was chosen or which screen was already reviewed. It is more useful than asking a model to reconstruct every decision from the latest source alone.

A transcript describes earlier work. The current files describe what exists now. If the two disagree, investigate the difference rather than treating either a confident answer or an old completion message as final evidence. Ask for the exact file and the relevant source range.

Make the handoff explicit

When you are ready for a change, describe the action and its boundary. Chat can send an instruction to a real Code conversation, or a design brief to a real Design conversation. Those are actionable handoffs rather than a second, unrelated demonstration of the same work. The conversation can be inspected and continued from its own workspace.

For Code, name the behavior to change and the checks you expect. For Design, identify the screen or selected element and the content, layout or typography to refine. Avoid one instruction that mixes an open-ended redesign, a database migration and a deployment.

Update the membership handoff in the open project.
Keep the selected plan in the visit URL and use the day pass for an unknown plan.
Reuse the existing membership data. Keep the current visual design.
Show the changed files and report which checks actually ran.

Keep the evidence beside the answer

Open linked source files in Chat's side panel to compare the explanation with the implementation. The integrated browser can hold documentation beside the conversation, so you can inspect a reference without losing the project view. These panels make verification convenient; their presence alone does not establish that the assistant read a page or tested an application.

For a small change, review the route, the component and the shared data together. If a claim has no file, tool result or other visible evidence behind it, ask the assistant to obtain that evidence rather than simply restating the conclusion.

Review completion separately from correctness

Queued, running, failed and completed describe execution state. A completed task may still have an incorrect implementation, a missing check or a poor layout. Ask what changed, which commands ran and what the results showed. Then test the actual interaction yourself where appropriate.

The Still Studio sequence above is an illustrative workflow, not a published benchmark. It does not establish a speedup, cost saving or success rate. Your result depends on the repository, selected model, context, permissions and the quality of the review.

• Inspect the diff and any unexpected files.
• Verify the normal route and the unknown-plan fallback.
• Read actual test output rather than assuming a check passed.
• Check a narrow viewport if the change affects a screen.

Understand the data boundary

Local history and local project storage do not mean every AI request runs on your computer. Selected prompts, source excerpts, attachments and tool results can be transmitted to the configured provider or service. Opening a website also contacts that website. Review the data practices and provider settings for the feature you use.

Do not paste API keys into a conversation. Use the provider configuration in the application, and keep sensitive files out of a task unless their inclusion is deliberate and appropriate.

References: Licuse data practices