|
| 1 | +# organoid_Symbionts Skill Library |
| 2 | + |
| 3 | +This library was derived from the local `organoid_Symbionts` repo by reading the root README, `package.json`, `render.yaml`, the runtime entrypoints, health and observability code, prompt assets, state store code, tests, and the operator docs under `docs/`. |
| 4 | + |
| 5 | +## Branch Structure |
| 6 | + |
| 7 | +### 1. Render Deploy Branch |
| 8 | + |
| 9 | +This branch exists because the repo has a real multi-service Render blueprint: |
| 10 | + |
| 11 | +- worker |
| 12 | +- health web service |
| 13 | +- landing app |
| 14 | +- daily cron |
| 15 | + |
| 16 | +The Render branch holds the deploy-topology, env-contract, readiness, and rollback skills. |
| 17 | + |
| 18 | +### 2. Runtime Control Branch |
| 19 | + |
| 20 | +This branch covers the worker loop, fail-closed write policy, health and metrics, and durable state handling. |
| 21 | + |
| 22 | +### 3. Prompt, Embodiment, and Signal Branch |
| 23 | + |
| 24 | +This branch covers the canonical prompt fragments, embodiment routing, timeline engagement policy, and external read paths. |
| 25 | + |
| 26 | +### 4. Validation and Derived Artifacts Branch |
| 27 | + |
| 28 | +This branch covers testing, compliance, and semantic artifact regeneration so the runtime stays reproducible. |
| 29 | + |
| 30 | +## Top Starter Skills |
| 31 | + |
| 32 | +1. `render-blueprint-review` |
| 33 | +2. `fail-closed-write-policy-review` |
| 34 | +3. `health-and-metrics-review` |
| 35 | +4. `testing-and-compliance-gates-review` |
| 36 | +5. `prompt-canon-and-embodiment-review` |
| 37 | + |
| 38 | +## Inferred Areas |
| 39 | + |
| 40 | +- The lore layer is real, but the skill set treats it as an operational prompt and embodiment surface instead of assuming extra hidden runtime behavior. |
| 41 | +- The semantic build and snippet extraction flows are real, but they are treated as derived-artifact maintenance, not as a separate product model. |
| 42 | + |
| 43 | +## Why Render Got Its Own Branch |
| 44 | + |
| 45 | +The deploy model is visible in `render.yaml`, and it matters operationally: |
| 46 | + |
| 47 | +- worker and web health run separately |
| 48 | +- landing is isolated from the worker runtime |
| 49 | +- a cron job exists alongside the always-on services |
| 50 | +- env variables differ by service |
| 51 | + |
| 52 | +That is enough topology complexity to justify a dedicated branch rather than burying deploy review inside a generic ops skill. |
| 53 | + |
0 commit comments