You already know the terminal is the window where you type pnpm dev. What usually happens next is that you paste whatever Claude Code hands you, watch a wall of text scroll past, and scan it for the word "error". That works right up until the output is four hundred lines long and the failure is on line 212.

The idea

The is a small language for joining programs together. Each command reads some text, writes some text, and finishes with a number that says whether it worked. Once you know how to send one command's output into the next, how to stop a sequence when a step fails, and how to search a stream of text, you can build the exact question you want answered instead of reading everything the computer felt like printing.

code
  pnpm build            |          grep  "error"          →  exit status
  ────────────          ▼          ─────────────              ──────────
  writes 400 lines   the pipe   reads them, prints        0 = it worked
  of output          carries    only matching lines       1 = it failed
                     the text

How it works

  • The pipe, |. git log --oneline | head -20 runs git log, hands its output to head, and you see the last twenty commits instead of all nine hundred. Nothing is saved to disk. The text just moves left to right.
  • Chaining with &&. pnpm typecheck && pnpm test runs the typecheck, and runs the tests only if the typecheck succeeded. Compare with ;, which runs the second command regardless. If you have ever watched a test suite pass on code that does not compile, you wanted &&.
  • . Type echo $? right after a command to see it. Zero for success is backwards from how most people guess, and it is the reason && behaves the way it does.
  • grep. It prints the lines that match a pattern. grep -rn "DATABASE_URL" src/ searches every file under src/, recursively, and prints the file name and line number of each hit. This is how you answer "where is this thing used" in two seconds.
  • --help. Almost every command takes it: curl --help, git log --help. Read the first screen before you paste a you do not recognise.
  • Backgrounding. A trailing &, as in pnpm dev &, starts the command and gives you your prompt back. Useful when you need the dev server running and a terminal to work in. jobs lists what is running, fg brings it back.

What to do

  1. Next time a build fails, do not scroll. Run it again piped into grep: pnpm build 2>&1 | grep -i "error". The 2>&1 folds error output into the normal stream so grep can see it.
  2. Replace the next two commands you run in sequence with one && chain. Start with git add -A && git commit -m "message".
  3. Pick one command you use blind and read its help. git log --help is a good first one, because the flags there are the difference between a useless wall of commits and a one-line summary.

Where it breaks

grep matches text, so it has no idea what your code means. Searching for user will hit comments, variable names, and the word "user" inside a string. It gives you a short list of places to look, and you still have to look at them.

Chaining is also a way to build something dangerous quickly. A command that would have made you pause on its own gets less attention as the fourth link in a chain, and an AI assistant will happily compose a long one for you. Read chains right to left, ask what the last step touches, and be especially careful with anything containing rm, --force, or a production hostname. On Windows, PowerShell uses different syntax for several of these, so a command copied from a macOS or Linux example may fail or, worse, do something slightly different.