원클릭으로 Manus에서 모든 스킬 실행

okhp3-celestial-data

스타1

포크0

업데이트2026년 7월 22일 19:10

OverKill Hill P³ offline celestial data engine. Use when implementing or reviewing moon-phase, zodiac-season, Mercury-retrograde, or upcoming lunar-event features in JavaScript or TypeScript. Also activate when a UI needs display-grade night-sky data without a network request. Preserve the repo's exact functions and return shapes, use the bundled deterministic implementation, and validate date data with the supplied scripts.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

OKHP3

OKHP3/abrahamic-reference-engine

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

okhp3-celestial-data

Use the skill as a small, deterministic display-data layer. It is intentionally offline and dependency-free: do not replace the calculations with a network request, an npm package, or observatory-grade claims.

Scope

In scope	Out of scope
`getMoonPhase`, `getAstroSeason`, `getMercuryStatus`, `getNextLunarEvents`	Observatory-grade precision; target display accuracy is about ±12 hours for lunar phase
TypeScript contracts and local UI integration	Planetary positions beyond Mercury retrograde
Bundled 2026–2031 Mercury date table	Eclipses, solstices, equinox timestamps, natal charts, or ephemeris beyond 2031
Deterministic CLI checks and date-table validation	Server-side or API-backed celestial data

Workflow

1. Plan

Identify the required output and select the smallest public function set.
Inspect the destination types and existing imports before changing a caller.
Preserve these APIs and shapes:
- getMoonPhase(date?: Date) → { name, emoji, illumination, daysUntilNext }, with illumination as a 0.0–1.0 fraction.
- getAstroSeason(date?: Date) → { sign, emoji, element, dates }, with a zodiac symbol rather than a generic star.
- getMercuryStatus(date?: Date) → { retrograde: boolean, endDate: string | null }.
- getNextLunarEvents(count = 3) → up to count * 2 { type, date, emoji } entries, alternating New Moon and Full Moon discoveries.
Decide whether the caller needs a local calendar date or an ISO date. The engine uses local month/day parts for moon and season display, while Mercury status compares date.toISOString().split('T')[0] against ISO date strings.

2. Validate

Read references/celestial.ts only when implementing, porting, or debugging the calculation. Copy the needed functions; do not recreate lookup tables from memory.
Run a fixed-date smoke check before and after changes:
```
node .agents/skills/okhp3-celestial-data/scripts/check-date.cjs 2026-06-26
```
Confirm the output contains all three domains and that 2026-06-26 is not inside a Mercury window; the next bundled window begins 2026-07-17.
After any Mercury table edit, run:
```
node .agents/skills/okhp3-celestial-data/scripts/validate-mercury-dates.cjs
```
Require exit code 0. Treat warnings about gaps as review signals, not proof that the ephemeris is correct.
Check deterministic behavior with the same explicit Date twice. Verify that no implementation path calls fetch, reads a secret, or adds a dependency. Report the actual validation commands and results.

3. Execute

Import the public functions from the app's existing src/lib/celestial.ts when working in Kieran's LifeTrkr; do not add a second celestial module.
When building from scratch, use references/celestial.ts as the source of truth and adapt only import paths and local type names.
Keep the calculation engine separate from rendering. Convert illumination * 100 to a percentage at the UI boundary, and render endDate: null as “not currently retrograde.”
Keep the bundled scripts/ files as executable validation tools. Use a fixed ISO date for reproducible bug reports instead of relying only on the current clock.

Correctness notes and gotchas

Moon phase uses Julian Date math with the 367 * y conversion pattern, a known 2000 new-moon reference, and the average synodic month. It is suitable for display and wellness UX, not scientific observation.
Astrological seasons use an ASTRO_SEASONS lookup keyed by startMD and endMD (month * 100 + day). Capricorn wraps across December and January.
Mercury periods are a hardcoded 2026–2031 display ephemeris. The 2029-12-22 to 2030-01-11 entry intentionally crosses a year boundary; ISO lexicographic comparison handles it.
Do not use a generic ⭐ for a zodiac emoji, rename daysUntilNext, change illumination to an integer percentage, or silently change date semantics.
getNextLunarEvents advances from the current day and is therefore clock dependent. Use the other functions with explicit dates for deterministic tests; do not promise exact event timestamps.
Treat ephemeris data as maintained content. Cite the source used for a future table update and run the validator; do not invent dates.

Security and boundaries

All calculations run locally with no API key, network call, telemetry, or user data. If a request asks for an astrology API, server endpoint, or sensitive birth-chart service, state that it is outside this skill's boundary and do not silently expand the implementation.

Bundled resources

references/celestial.ts — complete TypeScript implementation and contracts. Read it on demand for code, porting, or debugging.
scripts/check-date.cjs — deterministic CLI inspection for a supplied date.
scripts/validate-mercury-dates.cjs — ordering, overlap, ISO-format, and gap checks for the Mercury table.

Output contract

Return the selected API, the files changed, the validation commands and results, the accuracy boundary, and any unresolved ephemeris or timezone concern. Do not claim astronomical precision or live-source verification when none was done.

About

Built by Jamie Hill · OverKill Hill P³ Published at github.com/OKHP3 Part of the OKHP3/skillz Agent Skill library. MIT License -- free to use, fork, and adapt. A nod to the source is appreciated.

이 저장소의 다른 Skills

같은 저장소

okhp3-cross-tradition-compare

OKHP3/abrahamic-reference-engine

Compare shared themes across Judaism, Christianity, and Islam using 20 seeded passage sets, neutral bridging notes, and the ARE proportional-representation rule. Use for side-by-side scripture comparisons, interfaith education, neutral common-ground explanations, comparison UI work, or requests about what these traditions share. Do not use it to rank traditions, prove theological priority, or invent a parallel where none is established.

2026-07-221

okhp3-skill-foundry

OKHP3/abrahamic-reference-engine

OverKill Hill P³ Skill FoundRy -- complete eight-phase methodology for creating, honing, and polishing production-quality Agent Skills. Activate when asked to create a new skill from scratch, hone or polish an existing skill, apply OKHP3 brand attribution, design live evals, run executor subagents for benchmarking, grade responses with evidence-anchored expectations, compute benchmark deltas, or iterate based on eval failures. Also activate when someone wants to turn a workflow into a distributable skill, needs to benchmark a skill's with-skill vs without-skill gap, wants a professional quality bar for a SKILL.md, or asks about the OKHP3 skill authoring process. This is the authoritative FoundRy methodology for any skill creation or honing work in this repo -- use it even when the user just says "make a new skill" or "improve this skill" without mentioning the FoundRy by name.

2026-07-221

okhp3-thread-context-extraction

OKHP3/abrahamic-reference-engine

Extract pasted or uploaded AI chat threads into standalone, actionable Markdown. Use when the user wants to evacuate context from ChatGPT, Claude, Gemini, Perplexity, Microsoft Copilot, Grok, Mistral Vibe, an unknown AI platform, or a mixed transcript; preserve goals, decisions, reasoning, next actions, prompts, code, files, images, citations, canvases, artifacts, diagrams, and provenance; resolve uncertain speaker boundaries; or requests rapid, balanced, comprehensive, essential, substantial, exhaustive, scan, distill, or catalog depth. Use for complete, partial, flattened, exported, or turn-by-turn human-supplied captures. Do not use for logging into or scraping source services, lossless transcript archival, ordinary short-form summaries, or platform support questions that do not require a durable handoff artifact.

2026-07-221

okhp3-tradition-observance-calendar

OKHP3/abrahamic-reference-engine

Fetch, compute, and format religious observance calendars for the three in-scope Abrahamic traditions of the Abrahamic Reference Engine: Judaism, Christianity, and Islam. Use this skill whenever an agent needs to retrieve religious holiday data, generate iCalendar (.ics) output, look up holiday descriptions for cross-tradition audiences, or produce a unified observance event list. Covers Hebcal API (Jewish), AlAdhan API (Islamic), TypeScript Computus algorithm (Christian -- Western and Orthodox), Wikipedia summary fetching for event descriptions, .ics file generation, emoji assignments, holiday filter lists, and session caching strategy. All data sources are free, public, and require no API key. Zero cost. MIT license. Also activate when a user asks to "add holidays to my calendar app", "download religious observances as .ics", "show Jewish/Islamic/Christian holidays for a year", or compute Easter dates -- including when they ask for "all three faiths" or any single tradition's observance list.

2026-07-221

okhp3-tradition-reference

OKHP3/abrahamic-reference-engine

Reference ARE scope, canon, denominations, translations, Pew US shares, and free API providers for Judaism, Christianity, and Islam. Use before answering canon or denomination questions, choosing a translation, writing scripture fetch code, checking whether a tradition is in scope, or explaining LDS, Catholic, Orthodox, Jewish, or Islamic reference coverage. Preserve denominational variation, source dates, licensing, and known API gaps.

2026-07-221

okhp3-verse-lookup

OKHP3/abrahamic-reference-engine

Fetch or integrate scripture passages from Judaism, Christianity, or Islam through the ARE free anonymous providers. Use for verse lookup, API endpoint and reference-format questions, translation IDs, normalization, attribution, error handling, fallback routing, or denomination-aware scripture UI work. Covers Sefaria, bible-api.com, Quran.com with AlQuran.cloud fallback, and LDS Standard Works routing. Never invent text or silently change translations.

2026-07-221

name	okhp3-celestial-data
description	OverKill Hill P³ offline celestial data engine. Use when implementing or reviewing moon-phase, zodiac-season, Mercury-retrograde, or upcoming lunar-event features in JavaScript or TypeScript. Also activate when a UI needs display-grade night-sky data without a network request. Preserve the repo's exact functions and return shapes, use the bundled deterministic implementation, and validate date data with the supplied scripts.
license	MIT
compatibility	JavaScript or TypeScript with standard Date support; Node.js is required only for the bundled validation scripts. The calculation engine needs no network, package, or API access.
metadata	{"author":"Jamie Hill (OverKill Hill P³)","version":"1.3.0","category":"wellness-astrology","origin":"okhp3/skillz","homepage":"https://overkillhill.com","author-github":"https://github.com/OKHP3","implementation":"references/celestial.ts","scripts":"scripts/check-date.cjs; scripts/validate-mercury-dates.cjs","scope":"Moon phase, zodiac season, Mercury retrograde status, and upcoming New/Full Moon display data","boundaries":"Display-grade local calculations only; no external astrology service, natal chart, eclipse timing, or ephemeris beyond the bundled 2026-2031 data"}

okhp3-celestial-data

Scope

In scope	Out of scope
`getMoonPhase`, `getAstroSeason`, `getMercuryStatus`, `getNextLunarEvents`	Observatory-grade precision; target display accuracy is about ±12 hours for lunar phase
TypeScript contracts and local UI integration	Planetary positions beyond Mercury retrograde
Bundled 2026–2031 Mercury date table	Eclipses, solstices, equinox timestamps, natal charts, or ephemeris beyond 2031
Deterministic CLI checks and date-table validation	Server-side or API-backed celestial data

Workflow

1. Plan

Identify the required output and select the smallest public function set.
Inspect the destination types and existing imports before changing a caller.
Preserve these APIs and shapes:
- getMoonPhase(date?: Date) → { name, emoji, illumination, daysUntilNext }, with illumination as a 0.0–1.0 fraction.
- getAstroSeason(date?: Date) → { sign, emoji, element, dates }, with a zodiac symbol rather than a generic star.
- getMercuryStatus(date?: Date) → { retrograde: boolean, endDate: string | null }.
- getNextLunarEvents(count = 3) → up to count * 2 { type, date, emoji } entries, alternating New Moon and Full Moon discoveries.
Decide whether the caller needs a local calendar date or an ISO date. The engine uses local month/day parts for moon and season display, while Mercury status compares date.toISOString().split('T')[0] against ISO date strings.

2. Validate

Read references/celestial.ts only when implementing, porting, or debugging the calculation. Copy the needed functions; do not recreate lookup tables from memory.
Run a fixed-date smoke check before and after changes:
```
node .agents/skills/okhp3-celestial-data/scripts/check-date.cjs 2026-06-26
```
Confirm the output contains all three domains and that 2026-06-26 is not inside a Mercury window; the next bundled window begins 2026-07-17.
After any Mercury table edit, run:
```
node .agents/skills/okhp3-celestial-data/scripts/validate-mercury-dates.cjs
```
Require exit code 0. Treat warnings about gaps as review signals, not proof that the ephemeris is correct.
Check deterministic behavior with the same explicit Date twice. Verify that no implementation path calls fetch, reads a secret, or adds a dependency. Report the actual validation commands and results.

3. Execute

Import the public functions from the app's existing src/lib/celestial.ts when working in Kieran's LifeTrkr; do not add a second celestial module.
When building from scratch, use references/celestial.ts as the source of truth and adapt only import paths and local type names.
Keep the calculation engine separate from rendering. Convert illumination * 100 to a percentage at the UI boundary, and render endDate: null as “not currently retrograde.”
Keep the bundled scripts/ files as executable validation tools. Use a fixed ISO date for reproducible bug reports instead of relying only on the current clock.

Correctness notes and gotchas

Moon phase uses Julian Date math with the 367 * y conversion pattern, a known 2000 new-moon reference, and the average synodic month. It is suitable for display and wellness UX, not scientific observation.
Astrological seasons use an ASTRO_SEASONS lookup keyed by startMD and endMD (month * 100 + day). Capricorn wraps across December and January.
Mercury periods are a hardcoded 2026–2031 display ephemeris. The 2029-12-22 to 2030-01-11 entry intentionally crosses a year boundary; ISO lexicographic comparison handles it.
Do not use a generic ⭐ for a zodiac emoji, rename daysUntilNext, change illumination to an integer percentage, or silently change date semantics.
getNextLunarEvents advances from the current day and is therefore clock dependent. Use the other functions with explicit dates for deterministic tests; do not promise exact event timestamps.
Treat ephemeris data as maintained content. Cite the source used for a future table update and run the validator; do not invent dates.

Security and boundaries

Bundled resources

references/celestial.ts — complete TypeScript implementation and contracts. Read it on demand for code, porting, or debugging.
scripts/check-date.cjs — deterministic CLI inspection for a supplied date.
scripts/validate-mercury-dates.cjs — ordering, overlap, ISO-format, and gap checks for the Mercury table.

Output contract

About

Built by Jamie Hill · OverKill Hill P³ Published at github.com/OKHP3 Part of the OKHP3/skillz Agent Skill library. MIT License -- free to use, fork, and adapt. A nod to the source is appreciated.