--- name: astrology-reading-compose description: Top-level orchestrator for astrology readings. Picks one or more lens skills (rulership-chains, decans-36-faces, future nakshatras / pythagorean-geometry / elemental-shamanic), runs them, weaves their structured outputs into a single reading, and persists to astral-tenant-kb. Use whenever the user asks for an astrology reading or chart interpretation. version: 0.1.0 author: Hermes Agent + Alex license: MIT metadata: hermes: tags: [astrology, orchestrator, compose, lenses, reading] related_skills: [astrology-lens-rulership-chains, astrology-lens-decans-36-faces, astral-chart-api, astrology-location-time-utc, astral-tenant-kb, llm-wiki] --- # Astrology Reading Compose Top-level reading orchestrator. **Always** the entry point for "give me a reading" / "interpret this chart" prompts. Never invoke a lens skill directly from the user-facing reply. ## Pipeline ``` 1. Resolve subject ← Hermes-memory-first; see "Self vs other" below 2. Resolve birth → UTC ← astrology-location-time-utc (only if new person) 3. Compute or load chart ← astral-chart-api (cache via astral-tenant-kb.save_chart) 4. Pick lens combo ← see "Lens selection" below 5. Run each lens ← parallel; collect structured outputs 6. Weave reading ← prose synthesis (see "Weaving rules") 7. Save reading ← astral-tenant-kb.save_reading with lens-combo frontmatter 8. Reply ← reading + optional chart image ``` ## Self vs other — Hermes-memory-first resolution (HARD RULE) Astrology readings are usually for the user themselves. Hermes built-in memory is loaded on every turn and is the fastest, cheapest place to recognize "this is the user's own chart." Use it FIRST. ### Step 1 — Is this reading for the user (self)? The reading is for the **user** when ANY of these are true: - The user uses first-person language: "my chart", "do me", "my Saturn return", "read my…" - The user gives their own name or a self-alias that matches their Hermes USER.md identity. - The user gives no name at all and the request is open-ended ("do a reading"). When self is detected: 1. **Read Hermes memory** (USER.md identity + birth data summary). Do NOT ask the user for birth data they already gave Hermes. 2. **Recall the self profile** from the tenant KB: look up the person whose frontmatter has `relationship: self`. If exactly one exists, use it. If memory's birth data and the KB self-profile disagree, surface the conflict to the user — never silently pick. 3. **If no `relationship: self` profile exists yet**, create one from Hermes memory's identity + birth data via `save_person(slug, birth, relationship='self')` before computing the chart. This is how a fresh tenant bootstraps its self-profile on first reading. ### Step 2 — Is this reading for someone else? The reading is for someone else when the user names a specific other person ("do Stephen's chart", "Kathleen, born…", "my brother", "this client"). When other is detected: 1. Apply the **disambiguation policy** from `astral-tenant-kb` (slug → exact name → alias → fuzzy → no match). 2. If multiple candidates exist, show all with birth-data summary and ask. NEVER silently pick. 3. If no match, ask for birth data, propose a slug, and `save_person` with appropriate `relationship` (client, family, friend, partner, public-figure). ### Step 3 — Ambiguous "Alex" / "Stephen" / first-name only If the user's first name matches the input AND other people in the KB also match (e.g. `alex-mataha` + `alex-durran`): - Do NOT assume self by default — even if you're inside the user's own Hermes. - Show all candidates including self, with birth-data summary, and ask. - This protects against the failure mode where the user is researching someone with their own first name. ## Lens roster | Lens skill | Ready | Notes | |---|---|---| | `astrology-lens-rulership-chains` | ✅ | Default. Alex's traditional rulership method. | | `astrology-lens-decans-36-faces` | ✅ | Coppock 36 Faces; pulls `astro-sources` wiki. | | `astrology-lens-nakshatras` | ❌ planned | Sidereal 27 lunar mansions. | | `astrology-lens-pythagorean-geometry` | ❌ planned | Tight harmonics / midpoints / minor aspects. | | `astrology-lens-elemental-shamanic` | ❌ planned | Element balance, archetypal/animistic voice. | | `astrology-lens-hellenistic-time-lords` | ❌ future | Zodiacal releasing, profections. | When adding a new lens: drop a skill named `astrology-lens-`, follow the lens contract (structured `claims[] + citations[]`, no prose), then list it here. ## Lens selection **Default combo**: `[rulership-chains]` — matches Alex's primary style. **User intent → combo**: - "Coppock / decans / face / 36 Faces" → add `decans-36-faces` - "deep dive" / "everything" → run all ready lenses - "Pythagorean / harmonics / geometry" → add `pythagorean-geometry` (when ready) - "shamanic / elemental / archetypal" → add `elemental-shamanic` (when ready) - "Vedic / sidereal / nakshatra" → swap rulership-chains for `nakshatras` (when ready) - Explicit list ("rulership + decans") → exactly those. **A/B testing**: if the user says "compare lenses" or "diff lens combos", run two separate compose passes with different combos and produce two readings labeled by combo for side-by-side comparison. ## Weaving rules The lens outputs are structured claims; compose layer turns them into one coherent reading. 1. **Lead with the strongest claim across all lenses**, not the first lens's first claim. Strongest = main-engine loop, main-theme cluster, or main lens emphasis. 2. **Group by chart factor** (Sun, then Moon, then Asc, then chart ruler, then notable bodies), and within each factor present claims from each lens in this order: rulership-chains → decans → other lenses. This stops lenses from talking past each other. 3. **Honor lens identity** — when a claim comes from decans, name it ("In the 36 Faces system, your Sun falls in Libra I..."). Don't blend voices into mush. 4. **Cite the wiki when a lens cited it** — inline `[[concepts/libra-i]]` style links. 5. **Cap length**: aim for ~5–9 paragraphs unless user asked for long-form deep dive. 6. **No "folk" language** (per Alex's North Star). 7. **End with one targeted question** the user might want to explore next. ## Hard rules - Never invoke a lens twice in the same reading. - Never emit a reading without `lenses: [...]` frontmatter saved in the KB. - **Hermes built-in memory is the source of truth for the user's identity and birth data**, not the KB. The KB is the source of truth for structured per-person content (charts, readings, transits). When the two disagree, ask — never silently pick. - If a reading is for self and a `relationship: self` profile exists, do NOT re-collect birth data. - If a reading is for someone else, always pass through the disambiguation policy in `astral-tenant-kb`. - Never write chart content, reading prose, or per-person birth data INTO Hermes memory. Memory holds identity, preferences, and KB pointers only. - If a requested lens isn't ready, say so once and proceed with the available lenses; don't fabricate. ## Reading file format (saved to KB) ```yaml --- person: alex date: chart_hash: lenses: [rulership-chains, decans-36-faces] sources_cited: - astro-sources:concepts/libra-i - astro-sources:concepts/scorpio-i prompt: "" --- ``` ## Verification - [ ] Person recalled from KB or saved as new - [ ] Chart hash computed, chart cached - [ ] Lens combo logged in reading frontmatter - [ ] At least one citation per lens that emitted citations - [ ] Reading saved under `readings/--.md` - [ ] Log line appended to KB `log.md` ## Future: combo presets Once 4+ lenses exist, define named combos in `references/combo-presets.md` (e.g. `traditional-deep`, `vedic-traditional-mash`, `geometric-shamanic`) so the user can ask for them by name. ## See also - `astrology-audit` — sibling meta-skill. Renders the current astrology / HD / synthesis pipeline as a Telegram-native flowchart PNG + legend with `MEDIA:` links to each step's SKILL.md. Invoke when Alex asks to "audit", "show the pipeline", "show the flow", or before mutating the reading flow for an experiment. - `astral-tenant-kb` `references/modular-lens-architecture.md` — full architecture journal: three-layer principle, lens contract, the Hermes-memory ↔ tenant-KB seam, the May 2026 disambiguation lesson (Alex MaTaHa vs Alex Durran collision), tenant onboarding bootstrap pattern, when-to-extend-vs-add-lens guide, and a worked example of a live compose run. - `birth-data-onboarding-gate` — how new tenants get their self-profile seeded between onboarding and `/chat`.