메뉴
General guidance on writing tests
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
