Menu
Architecture review guidance. Use when reviewing architectural changes, assessing system design, or evaluating code structure.
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 | architecture-review |
| description | Architecture review guidance. Use when reviewing architectural changes, assessing system design, or evaluating code structure. |
Report ONLY when you found something concerning and then report what you found. If you didn't find anything, don't report it. Mention only things you actually found problematic. Don't "check off" certain points here by saying "passed" this or that point. I assume when you didn't mention an aspect that is precisely because it PASSED. (But, if there is really absolutely nothing you found, at least acknowledge with a single statement that you did found nothing.)
Does each namespace or function has a clear responsibility? And is it one, and a clearly nameable one? Or are there multiple things being done at once? In that case, why not break it down into modules which do just one thing?
Example, when we access an environment variable in a namespace, we can ask if we can access the variable one namespace "higher", at the current function's call-site, and pass it simply in as a paramter. The more functions are kept pure, the easier it is for us to test.
When we have an application like here which is part single page application (SPA) for the frontend and a backend (via REST, or GraphQL), we want to consider some things.
While the frontend is responsible for keeping a specific user's state, it should stay as dumb as possible. For example, instead of sorting something in the frontend, we always would chose sorting on the backend and hand over a list (which is sorted by definition) to the frontend.
