ZCode

Choose the terminal interface when your normal workflow stays in a shell. Choose Web when you want a browser interface to a local workspace. Choose desktop when you need the Electron application. The repository also contains remote-workspace code, but a first trial need not include SSH or WSL. Official interface overview.

Our suggested first task is repository orientation: ask which files implement a specific feature and where its tests live. That gives you something concrete to verify before asking the agent to change code. If you only want to read the source, cloning the repository is enough; you do not need to run its services.

Source-development prerequisites

The checked README names Git, Node.js 24.14.0 and pnpm 10.33.2; verify the version manifest before starting. From a checkout of the official repository, bootstrap from the repository root:

pnpm bootstrap

For local Web development:

pnpm dev:web

The documented defaults are port 5173 for the frontend and 3030 for the backend. Open the frontend URL printed by your process. This starts a development environment, not an installation of a public hosted service.

Already-built command-line distribution

If you already have the distribution installed, the documented local Web entry is:

zcode --web --workspace /path/to/project --port 3030 --no-open

Replace the workspace path with your trial repository and choose a free port. This is a launch command, not an installer. For source packaging, follow the distribution instructions; building a package does not replace an older executable on PATH.

A detail that matters for desktop development

The README says pnpm dev:desktop selects production service configuration. Use the documented test-environment path when that is your intended target; do not assume a development command is isolated from product services. Review configuration before starting.

Editorial example; not a task we ran:

Read this repository without modifying files.
Identify the entry point for the feature named in my next message.
List the relevant source files and existing tests with paths.
Explain one concrete behavior and how I can verify it.
Do not install dependencies, run commands, or create a patch yet.
If the feature cannot be identified, ask one focused question.

Give the agent a feature you already know so you can check its answer. Open each cited file and confirm that the named function exists. An answer that only describes the project generally has not completed this task.

When you move on to edits, give a narrow acceptance case: the current input, the observed output, the desired output, and which behavior must remain unchanged. Inspect the resulting diff and run the relevant existing check yourself before deciding whether to merge.

In the documented packaged Web mode, the default binding is loopback. Non-local hosting has separate token behavior; follow the official instructions before exposing it beyond your computer. Stop the Web process with Ctrl+C. That ends the server process; it does not mean any repository edits have been reverted. Launch and authentication details.

For this trial, keep access limited to a disposable repository and inspect configuration before adding private material. A successful startup is only a startup check. It is not evidence that a particular provider works, that an edit is correct, or that your application has been deployed.

If a command appears to launch an old version, check which executable your shell resolves. If a port is occupied, choose another port. If a model request fails, record that separately from the local interface check; reinstalling the frontend is not evidence that the provider problem is fixed.