search actually matches, the | Twig pipeline, and /tmp as a compute surface. Load it before your first search comes back empty.Your terminal tool runs ONE command line per call -- verb, arguments, and flags together, exactly as you would type them at a prompt. Everything below is a COMMAND, not a tool of its own: there is no separate search tool, only search ... typed into the terminal.
It is NOT a Unix shell. It has only the documented commands -- ls, find, search, read, write, append, edit, copy, rm -- plus a trailing | pipeline. A few Unix names work as aliases -- cat (read), grep (search), dir (ls), cp (copy) -- and everything else errors, echo and awk included.
search needs a fulltext index, which only a mounted volume has. With nothing but /tmp you do not have it -- filter /tmp with a pipeline instead.
Write every path in full. cd exists, but assume it does not stick: your terminal call starts at / every time, so a cd is gone by your next call. Use an absolute path (/cerb-docs/references/docs/kata.md) or the @<filesystem>/path shorthand (@cerb-docs/references/docs/kata.md). A mount is read-only unless its overview says otherwise; /tmp is always read-write.
The search command matches file CONTENTS with AND, not OR -- every word in the query must appear in the same file. Piling on keywords narrows to zero hits fast, and zero hits is NOT evidence the topic is undocumented.
--path or --ext instead of adding more words.--terms is the OR view, and it is how you find the right word. It counts how many files contain EACH word, ranked, instead of searching for all of them: search --terms school college academic university tuition. One call, any number of synonyms, no reading. Take the highest count, require it with +, and throw the next set of words at it: search --terms +college tuition fees pricing. Repeat until the word list is good, THEN run the real search.auto* reports automations (476) automation (374) automatically (228) .... That is how you learn the vocabulary this corpus actually uses instead of guessing at it; a trailing ... means the list was capped.+ term is echoed as a heading above the counts; every count below it is within the files that contain it, so numbers collapse fast. That collapse is the signal -- keep the words that survive it.+ you already had, so a failed AND search still tells you which words exist alongside it.- instead of a count means the index skips that word as too common (the, not, can, com, www, ...) -- it was never searched for, which is not the same as finding nothing.--top <n> raises or lowers that cap and --top 0 returns every match unranked, so a full list is one flag away. Don't report a capped list as the whole answer.find to match names and search to match contents. Add --lines only after you've picked a file worth reading in context.find also carries every Markdown file's frontmatter, so you can select on metadata without opening anything. Each row has its keys under meta, and --fields title,description prints chosen ones as columns: find *.md --fields name | files|filter(f => f.meta.name starts with \"cerb\"). Listing never opens a file, so this costs nothing.search/find to locate a file, then read only the part you need (--offset/--limit)./tmp is a read-write scratch area. Reach for it whenever you'd otherwise scan a long piece of text by hand, or need to hold intermediate work across steps.
write /tmp/scratch.txt), then read it back through a trailing Twig filter chain to count, filter, reshape, or diff it -- for example staging alternate drafts, or reducing a large document to just the lines that matter, before committing a final version anywhere.search. Filter it with a pipeline rather than searching it.| pipelinePipe ANY command through Twig filters with a trailing | (lines, filter, map, length, column, ...). The pipeline runs on the FULL output before any truncation, so it is how you reduce a big result to just what you need instead of paying for the whole thing in context.
read /tmp/scratch.txt | lines|filter(l => \"field\" in l)\nsearch widgets | results|map(r => r.meta.title ?? r.path)\nls /docs | files|filter(f => not f.is_dir)|column(\"name\")\nlines preserves original line indices as keys. Each command sets its own row variable -- lines, results, files above -- and that is what makes a pipe iterate ROWS rather than text. For a longer transform than fits on one line, put a Twig template in script instead of a trailing |.
This is Cerb scripting, not a pipeline language of its own -- the same Twig, the same filters, functions and operators you would write anywhere else in Cerb. Read @cerb-agents/skills/scripting/SKILL.md for what is available rather than guessing at a filter name here.
cerb -- the command line into this installationSome agents also have cerb, a command line into THIS Cerb install rather than into files. It reports what this installation actually has, custom record types and fieldsets included, which the documentation cannot. Run cerb help to see what it answers, and cerb <topic> help for one topic's usage. Its rows pipe like any other command's.