Menu
General guidance on writing tests
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Describes the current local development setup, for when we want to perform development tasks on the actual Rhizome app
How to talk to the deployed plurama apps (treina, …) from the shell with the plurama-cli command — a curl-like client that carries baked-in prod credentials. Use whenever a task means reading or writing live plurama app data over HTTP, when `plurama-cli` is missing or unauthorized, or when a new app must be added to it.
Tracker's HTTP API — authenticate as a machine user, read tasks/meets/journals/today-board, ingest mail messages, write through the recording-mode gate via curl
How to run, test and develop the natural-language Telegram bot that queries tracker. The bot is NOT in tracker — it lives in the plurama umbrella app (plurama/src/plurama/app/agent). Covers the agent architecture, the secrets/config it needs, the locked-box egress-proxy gotcha, seeding a testable conversation, and driving it from the host as if you were Telegram.
To develop the user interface of the application, you need to know how to start, stop, restart the app and where to find it.
Rhizome's local REST API — search, read, and create contexts/items via curl
| name | writing-tests |
| description | General guidance on writing tests |
If something is hard to test, this points at architecture flaws, i.e. violation of high-cohesion/low-coupling.
Always do Red-Green-Refactor, i.e. verify that the test actually tests the thing. That is, changing the thing expected to be under test actually makes the test fail.
In test expectations, Roughly:
Don't test private functions. Such functionality should be implicit in the tests of the next higher up public function. If you feel tempted to test private functions, you are either overeager, or something which is private should actually be public.
