Slash commands

A slash command is a direct instruction to Perch itself rather than a task for the model. Type / at the prompt and the list appears. Most of them are quick session controls, but four of them do real work: /goal runs autonomously across many turns, /verify re-checks an answer against your sources, /delegate hands a task to a background agent, and /flock runs a team of workers.

This page covers when to use each one and what happens when you do. For the compact list of every command and flag, see the CLI reference.

/goal

/goal is the one people underuse. A normal turn does what you asked and stops, and if the job takes twelve steps you have to keep saying "continue". /goal sets an objective that Perch pursues across turn after turn on its own, re-invoking itself until a completion audit passes or it runs out of budget.

Reach for it when the work has many steps and a finish line you could describe out loud:

/goal make the test suite pass
/goal reconcile every invoice in this folder against the GL and write up the exceptions

Do not reach for it for a single question. A goal that could have been one turn just adds an audit step.

Watching and steering it

Once a goal is running you see each turn as it happens, with its tool calls. The controls are:

/goal status is the same as bare /goal, and /goal continue is the same as /goal resume.

Where a run stops

A goal never runs forever. It ends for one of these reasons, and Perch tells you which:

Except for Complete, every one of these can be picked back up with /goal resume.

Permission modes matter here

This is the thing that surprises people. In Default permission mode, the first write or command pauses for your approval, and the goal reports Blocked and stops. That is correct behavior, but it means an unattended overnight goal in Default mode will not get far.

If you want a goal to run while you are away, put it in Auto Review (reversible work runs on its own, irreversible actions still ask) or Take the Wheel (full autonomy). See permission modes for what each one allows.

It survives quitting

A goal is saved with its thread, so it outlives the session. Quit the CLI, close the desktop app, or reload the page, then come back to the same folder or thread and run /goal resume. The objective and the turn count are still there.

Two things follow from goals being per thread. A goal set in one folder's thread is not visible from another, since the CLI scopes the default thread to your working directory. And starting /goal again with the exact same objective text continues the existing goal rather than resetting its count, while different text starts fresh.

/verify

/verify re-checks the claims in an answer against your indexed sources. It is retrieval only, with no model call behind it, which is why it comes back fast and does not spend tokens.

/verify                  # check the last answer Perch gave
/verify <paste text>     # check text you wrote or pasted
/verify --changed        # re-check only what moved since your last check

You get a tally and then a line per claim:

Citation check — 6 claims in the last answer checked against your sources
✓ 4 verified · ~ 1 uncertain · ✗ 1 not found

A ✓ means a source backs the claim, ~ means the match is weak enough that you should look, and ✗ means nothing in your sources supports it. The ✗ lines are the reason the command exists. Run it after Perch drafts anything with citations, and before that draft leaves your hands.

--changed, and what a checkpoint is

/verify --changed answers a narrower question: since I last checked, did any source move under me, and does anything I relied on no longer hold?

The key detail is that your last /verify run is the checkpoint. There is no separate command to set one. Each check records the sources it relied on, so a later --changed pass re-checks only the claims whose sources actually changed and leaves the rest alone. If you have never run /verify in the thread, --changed has nothing to compare against and says so.

It leads with regressions, meaning claims that got weaker, because that is the only part that needs you to do something. --since-last is an alias if it reads better to you.

/delegate

/delegate <task> hands a scoped task to a background agent and gives you back the prompt. The agent runs async and returns its result for review, so a long job never blocks the session you are in. /bg <task> is the same command with less typing.

/delegate summarize every PDF in ./contracts and list the renewal dates

Use it when the task is self-contained and you would rather keep working than watch it run. If the task needs your input partway through, or you want to steer it, keep it in the main session instead.

/flock

/flock <task> runs a team of workers on one hard task and has checker workers verify the result before you see it. It is experimental and does not appear in the command menu, but it works in the desktop app and the CLI.

/flock review this branch for regressions and verify the tests

It is built for work where a single pass is not enough, and it declines small tasks before starting because a normal turn is faster. See Flock for how the team is planned and run.

Session commands

These do not run a task, they change or show something about the session.

Next steps

CLI reference→

Every command and flag, including the perch subcommands you run from your shell.

Personas→

Quill for writing with sources, Saffron for reading files under pressure.