From setup to research output: models, literature review, and scientific writing.

1. Start from the release, not a random installer

The walkthrough begins at the public repository and its Releases page. Treat the release note as part of installation: it tells you which package matches your platform and what changed in that build.

Because this recording uses an earlier preview release, use the video to understand the sequence rather than to copy the exact position of every button.

• Match the package to both operating system and processor architecture.
• Read signing, notarization, and platform-warning notes before launching the installer.
• Keep the release page available so version-specific behavior can be checked later.

2. Create a project that can hold the research record

A Wisp Science project is more than a chat title. It is the boundary for conversations, source files, generated reports, figures, tables, and the provenance that connects them.

Choose a durable local folder and a name tied to the scientific question. That makes later exports and handoff easier than beginning in an anonymous scratch session.

3. Configure the model and review execution permissions

The video opens the settings used to select a provider, endpoint, model, and execution policy. These choices determine which service receives prompts and which local actions require review.

Store credentials only through the application setting intended for secrets. Do not paste an API key into a prompt, document, screenshot, or repository.

• Confirm the provider and model name before the first long task.
• Use approval boundaries that fit the sensitivity of the project.
• Run a small test request before starting a costly literature workflow.

4. Turn a broad topic into a checkable literature task

The useful part of the demonstration is not a magic prompt. It is the shape of the request: define the topic, time window, expected sources, and final artifact before the agent begins searching.

Ask the workflow to separate findings from interpretation, keep citations next to claims, and state what remains uncertain. Those constraints make the final report reviewable by another researcher.

5. Inspect the artifact instead of accepting the final paragraph

The walkthrough opens the generated Markdown artifact alongside the conversation and source list. A later review catches a mismatch in the reported paper count and corrects the output.

That correction is the core lesson: a polished report is still an intermediate research object. Check counts, dates, citations, and whether the cited paper actually supports the nearby claim.

• Open tables and reports in the artifact panel rather than relying on chat summaries.
• Trace surprising claims back to the cited source.
• Record corrections in the same session so the audit trail remains intact.

6. Save a proven method as a reusable skill

Once the literature-review sequence has been inspected, the demonstration packages the method as a project skill. The next task can then reuse a reviewed sequence instead of rebuilding it from memory.

Only save a workflow after its assumptions and failure points are understood. A reusable skill should make good review habits repeatable, not automate an unverified shortcut.