#Power tips

The difference between using the Shell and mastering it: background your long jobs, keep long sessions lean, sandbox the risky work, and match the permission level to the trust.

#Overview

You already know how to open a session, type a command, and watch the output stream back. These tips are about working at a higher level — keeping a long-running task out of your way, keeping a long session manageable, and choosing the right environment and permission level so that fast work stays fast and risky work stays contained.

None of this changes what the Shell does. It changes how smoothly you move through real work: fewer stalls, less waiting on a screen, and the confidence that a command can only reach where you meant it to.

#What you can do

  • Background long jobs so a slow build, test run, or operation keeps going while you do something else, and you are told when it finishes.
  • Keep long sessions lean with context and compact, so a session that has been running all day stays fast and readable.
  • Sandbox risky work by running a session in a secure, isolated environment kept separate from your system.
  • Match the permission level to the task, keeping yourself in the loop for delicate work and letting trusted, well-understood work flow.
  • Re-attach to a running session to check on a job you left in the background, and close a session cleanly when its work is done.
  • Stop instantly at any time — kill ends the current command, and stopping always works regardless of permission level.

#How to use it

#Background the long jobs

  1. Start a command that you expect to take a while.
  2. Let it run in the background and move on to other work — the Shell keeps the job going and tells you when it finishes.
  3. Come back whenever you like and re-attach to the session to watch its live output again, or review the session's durable receipt to see exactly what happened while you were away.
Tip

Background work is the default way to handle anything slow. You never have to sit and watch a build complete — start it, leave, and let the notification bring you back.

#Keep long sessions lean

  1. On a session that has been going for a while, type context to see the recent history and confirm where things stand. Add a number to limit how many lines you see.
  2. When the history has grown long, type compact to condense it. The session stays continuous — you keep the thread of the work — but it stays fast and easy to follow.
  3. Check cost when you want to see what the current session has used so far.
Note

compact condenses history; it does not end your session or lose your place. Use it on long-lived sessions to keep them responsive.

#Sandbox the risky work

  1. When you start a session, choose where its work runs: locally on your own machine, or in a secure, isolated environment kept separate from your system.
  2. Pick the isolated environment for anything experimental, unfamiliar, or potentially destructive — work you want kept away from your own files.
  3. Pick the local environment when you specifically want to operate on your own machine and files.
  4. Either way, keep the session inside its workspace so its actions stay within the project or folder you intend and do not reach outside that boundary.

#Match the permission level to the task

The Shell uses the same five permission levels as the rest of Nourva. Choose by how much you trust the task, not how eager you are to finish it.

LevelUse it when
Look onlyYou are inspecting or exploring and want nothing changed.
Plan firstYou want to see and approve the approach before anything happens.
Ask before actingThe work is delicate and you want to approve each change.
Work in your workspaceThe task is understood and confined to one project; let it act freely there.
Act automaticallyThe task is long, well-understood, and trusted end to end.
  1. Start cautious on anything new — Look only or Plan first lets you understand the work before it acts.
  2. Raise the level as your confidence grows, or for a long routine task you have run before.
  3. Change the level at any time mid-session as the work shifts from exploring to doing.
  4. Remember that stopping always works immediately, at every level — kill ends the running command no matter how much freedom you gave it.

#Examples

Backgrounding a long job

text
Run the full test suite and let me know when it's done.

The tests start, the Shell tells you they are running in the background, and you go back to other work. When they finish, you get a notification and can re-attach to read the full output.

Trimming a long session

text
compact

The session's history is condensed into a tight summary. You keep the same thread of work and your place in it, and the session is fast and readable again.

Sandboxing something risky

text
Try this unfamiliar build script for me.

Because you started the session in the isolated environment, the script runs sandboxed, separate from your own system — if it misbehaves, your machine and files are untouched, and you can see exactly what it did from the session's durable receipt.

#Tips

  • Default to backgrounding anything slow. Start the job, leave, and let the finish notification pull you back — there is no reason to watch a long command line by line.
  • Run compact before a session gets sluggish, not after. A condensed long session stays fast and keeps its thread; you lose nothing by trimming early.
  • Reach for the isolated environment whenever you are unsure. If the work is experimental or could be destructive, sandbox it; save the local environment for when you truly mean to touch your own files.
  • Lower the level for delicate work, raise it for trusted routine. And keep kill in mind — stopping is instant at every level, so giving more freedom never means losing control.