Use this guide after installing Magistr and connecting your agent in the project. You will describe a result, agree on a bounded piece of work, and inspect what was delivered.
Work in your agent conversation unless a step explicitly says to use a terminal. Save unrelated work first and tell the agent which files or areas belong to other sessions.
Start from what you have
For an existing project, ask:
Read the code and Magistr’s saved work. Explain what already works, any unfinished task, and the smallest useful change toward my request. Make a plan before editing.
Add your actual request and constraints. For example, in a web application with an existing sign-in form, you might ask for a readable error when the password is wrong. The agent should inspect how that form works before proposing changes.
For an empty project, describe who will use it and one thing they should be able to do. Ask the agent to establish the stack, project structure, and check commands before implementation. Setup cannot infer a working test command from files that do not exist yet.
Agree on a finish
A useful first task has a small, observable result. Define what should work, how to check it, and what is outside the task.
For the sign-in example, a finish might be: a rejected password shows a readable message, entered email remains available, and a valid sign-in still works. That is an example of acceptance criteria: conditions you can check before calling the task complete.
For a larger project, ask the agent to save deliverables and dependencies on a roadmap. Each deliverable is a chunk. A direct, small request can use a saved work plan without creating a roadmap chunk.
Start the change
If the agreed work is a ready roadmap chunk, invoke the skill inside your chat:
| Agent | Start one chunk |
|---|---|
| Codex | $next |
| Claude Code | /next |
These skills resume interrupted roadmap work first. Otherwise they select one ready chunk, read its requirements and current code, save an objective and task plan, implement, verify, and commit the finished change.
For a direct task, say to implement the agreed change and record its work and
checks in Magistr. Do not invoke next merely to execute an unrelated request.
Terminal users can instead run magistr next from the project root. This
launches a separate agent session. Working in chunks explains
the difference and how to bound a longer run.
Inspect the result
Ask the agent to report:
- What changed and where to inspect it.
- Which acceptance criteria it checked.
- The commands that actually ran and their results.
- Any unverified behavior or remaining limitation.
Try the changed behavior yourself. For an interface, use the real controls and review screenshots at relevant sizes and appearances. A successful build does not establish that a screen is usable.
Magistr keeps the task, actions, recorded decisions, checks, and artifact links. A failed check stays useful history; the agent should diagnose it and rerun the affected check after a correction. See Verification.
Decide how to deliver
State your delivery instructions before work starts: a local commit, a pull request, a push to a branch, or a deployment. For example:
After the relevant checks pass, make a local commit and report its hash.
The roadmap skills include a commit; a push or deployment also needs your instruction. Store persistent delivery preferences in the project’s agent instructions so future sessions can read them.
Continue later
Open the same project with Magistr connected and ask the agent to read the saved objective, remaining tasks, decisions, and checks before editing. It should compare those records with the current files. Sessions explains recovery and switching agents.
If trying the result reveals a new problem, save it as feedback or make a new bounded request.