NightSky.earth

View saved version →

---
name: find-observing-place
description: Resolve a named destination and inspect observing-place candidates with clear coverage and access limits.
---

# Find an observing place

Use the canonical workflow in `references/workflow.md`.

## Intent before tools

Default to outdoor observing; explicit hosted or accommodation requests override the default. Retain activity, origin, direction, exclusions, budget and corrections. Ask only the next decision-relevant missing detail. Apply the shared outdoor conversation contract in the workflow before the technical pipeline; distinguish provisional areas, exact sites and optional venues.

## First decision and answer rules

A resolved named-city plan needs no candidate-details prerequisite: reuse its returned place identity, revision and timezone after `resolve_place`. If the user asks for observing-site details, follow the exposed mode. In API mode, details require the retained placeId and sourceRevision. Named-query details are catalogue/legacy mode only; see recipes below. Keep revisions matched; placeId alone is invalid; do not retry the same invalid arguments. The shared schema accepts multiple shapes: schema-valid does not mean supported in every runtime mode.

Before a candidate-site plan: obtain get_observing_location_details. If its actual timezone is unverified and the user has not explicitly named a display timezone, stop and ask one display-time-zone question. Wait for the reply; do not calculate a candidate or substitute city plan in this turn. A nearby city's timezone, the requested UTC window, or “use its timezone” is not a user choice of an unknown site timezone. Offer the base-city timezone as a question, never silently select it. If details are unavailable, explain that gap and ask whether the user wants a separately labelled named-city plan.

Give on-site directions only from timestamped returned orientation evidence, with a sky app for identification; a maximum-altitude sample is not a rising or session-wide bearing. Use the tool's answer-ready planning text for exact intervals and unknowns. Before finalizing, reconcile every returned source used, including the resolved-location source: preserve complete source links and returned provider/datasource contributor, copyright and licence names, attribution and modification statements, and licence links, including in selection-reporting clarifications; keep full provenance structured. Moon below the geometric horizon does not establish minimal moonlight; leave its observing impact unknown. Do not assert an uncalculated alternative night's visibility.

Darkness intervals are clipped to the requested calculation window. Preserve each returned boundary's meaning: full-window means darkness throughout the requested window, not the whole night. If an interval starts or ends at a requested limit, label that limit as a calculation cutoff; true dusk or dawn remains unknown unless separately established by returned evidence. For a 21:00–05:00 request returning darkness 21:00–04:30, say “astronomical darkness is reported from 21:00 to 04:30 within your requested 21:00–05:00 window; 21:00 is the requested start cutoff, not established astronomical dusk.” Describe 04:30 as astronomical dawn only if the returned evidence establishes that boundary; otherwise preserve its returned meaning or uncertainty. Do not infer dusk/dawn from darknessState alone.

After a successful city or site resolution, retain the returned matches and their exact placeId and sourceRevision or catalogueRevision. When observing-site details are needed, select the matching returned identity and pass its revision to details; reuse that selection across a display-timezone clarification. An unknown site timezone is a details/display-choice gap, not a reason to repeat the same successful resolve_place arguments. An ambiguous result needs selection or a more specific query. A changed location, explicitly requested refresh or expired/rejected 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: plan-astrophotography
description: Plan an astrophotography session and teach an appropriate next step without promising results.
---

# Plan astrophotography

Use the canonical workflow in `references/workflow.md`.

## Intent before tools

Default to outdoor observing; explicit hosted or accommodation requests override the default. Retain activity, origin, direction, exclusions, budget and corrections. Ask only the next decision-relevant missing detail. Apply the shared outdoor conversation contract in the workflow before the technical pipeline; distinguish provisional areas, exact sites and optional venues.

## First decision and answer rules

A resolved named-city plan needs no candidate-details prerequisite: reuse its returned place identity, revision and timezone after `resolve_place`. If the user asks for observing-site details, follow the exposed mode. In API mode, details require the retained placeId and sourceRevision. Named-query details are catalogue/legacy mode only; see recipes below. Keep revisions matched; placeId alone is invalid; do not retry the same invalid arguments. The shared schema accepts multiple shapes: schema-valid does not mean supported in every runtime mode.

Before a candidate-site plan: obtain get_observing_location_details. If its actual timezone is unverified and the user has not explicitly named a display timezone, stop and ask one display-time-zone question. Wait for the reply; do not calculate a candidate or substitute city plan in this turn. A nearby city's timezone, the requested UTC window, or “use its timezone” is not a user choice of an unknown site timezone. Offer the base-city timezone as a question, never silently select it. If details are unavailable, explain that gap and ask whether the user wants a separately labelled named-city plan.

Give on-site directions only from timestamped returned orientation evidence, with a sky app for identification; a maximum-altitude sample is not a rising or session-wide bearing. Use the tool's answer-ready planning text for exact intervals and unknowns. Before finalizing, reconcile every returned source used, including the resolved-location source: preserve complete source links and returned provider/datasource contributor, copyright and licence names, attribution and modification statements, and licence links, including in selection-reporting clarifications; keep full provenance structured. Moon below the geometric horizon does not establish minimal moonlight; leave its observing impact unknown. Do not assert an uncalculated alternative night's visibility.

Darkness intervals are clipped to the requested calculation window. Preserve each returned boundary's meaning: full-window means darkness throughout the requested window, not the whole night. If an interval starts or ends at a requested limit, label that limit as a calculation cutoff; true dusk or dawn remains unknown unless separately established by returned evidence. For a 21:00–05:00 request returning darkness 21:00–04:30, say “astronomical darkness is reported from 21:00 to 04:30 within your requested 21:00–05:00 window; 21:00 is the requested start cutoff, not established astronomical dusk.” Describe 04:30 as astronomical dawn only if the returned evidence establishes that boundary; otherwise preserve its returned meaning or uncertainty. Do not infer dusk/dawn from darknessState alone.

After a successful city or site resolution, retain the returned matches and their exact placeId and sourceRevision or catalogueRevision. When observing-site details are needed, select the matching returned identity and pass its revision to details; reuse that selection across a display-timezone clarification. An unknown site timezone is a details/display-choice gap, not a reason to repeat the same successful resolve_place arguments. An ambiguous result needs selection or a more specific query. A changed location, explicitly requested refresh or expired/rejected selection ca

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: plan-sky-event
description: Plan supported meteor, eclipse, aurora and other sky-event observing with local timing and explicit data limits.
---

# Plan a sky event

Use the canonical workflow in `references/workflow.md`.

## Intent before tools

Default to outdoor observing; explicit hosted or accommodation requests override the default. Retain activity, origin, direction, exclusions, budget and corrections. Ask only the next decision-relevant missing detail. Apply the shared outdoor conversation contract in the workflow before the technical pipeline; distinguish provisional areas, exact sites and optional venues.

## First decision and answer rules

A resolved named-city plan needs no candidate-details prerequisite: reuse its returned place identity, revision and timezone after `resolve_place`. If the user asks for observing-site details, follow the exposed mode. In API mode, details require the retained placeId and sourceRevision. Named-query details are catalogue/legacy mode only; see recipes below. Keep revisions matched; placeId alone is invalid; do not retry the same invalid arguments. The shared schema accepts multiple shapes: schema-valid does not mean supported in every runtime mode.

Before a candidate-site plan: obtain get_observing_location_details. If its actual timezone is unverified and the user has not explicitly named a display timezone, stop and ask one display-time-zone question. Wait for the reply; do not calculate a candidate or substitute city plan in this turn. A nearby city's timezone, the requested UTC window, or “use its timezone” is not a user choice of an unknown site timezone. Offer the base-city timezone as a question, never silently select it. If details are unavailable, explain that gap and ask whether the user wants a separately labelled named-city plan.

Give on-site directions only from timestamped returned orientation evidence, with a sky app for identification; a maximum-altitude sample is not a rising or session-wide bearing. Use the tool's answer-ready planning text for exact intervals and unknowns. Before finalizing, reconcile every returned source used, including the resolved-location source: preserve complete source links and returned provider/datasource contributor, copyright and licence names, attribution and modification statements, and licence links, including in selection-reporting clarifications; keep full provenance structured. Moon below the geometric horizon does not establish minimal moonlight; leave its observing impact unknown. Do not assert an uncalculated alternative night's visibility.

Darkness intervals are clipped to the requested calculation window. Preserve each returned boundary's meaning: full-window means darkness throughout the requested window, not the whole night. If an interval starts or ends at a requested limit, label that limit as a calculation cutoff; true dusk or dawn remains unknown unless separately established by returned evidence. For a 21:00–05:00 request returning darkness 21:00–04:30, say “astronomical darkness is reported from 21:00 to 04:30 within your requested 21:00–05:00 window; 21:00 is the requested start cutoff, not established astronomical dusk.” Describe 04:30 as astronomical dawn only if the returned evidence establishes that boundary; otherwise preserve its returned meaning or uncertainty. Do not infer dusk/dawn from darknessState alone.

After a successful city or site resolution, retain the returned matches and their exact placeId and sourceRevision or catalogueRevision. When observing-site details are needed, select the matching returned identity and pass its revision to details; reuse that selection across a display-timezone clarification. An unknown site timezone is a details/display-choice gap, not a reason to repeat the same successful resolve_place arguments. An ambiguous result needs selection or a more specific query. A changed location, explicitly requested refresh or expired/rejected select

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: plan-stargazing-night
description: Build a source-aware stargazing plan for a named place, date and observing goal.
---

# Plan a stargazing night

Use the canonical workflow in `references/workflow.md`.

## Intent before tools

Default to outdoor observing; explicit hosted or accommodation requests override the default. Retain activity, origin, direction, exclusions, budget and corrections. Ask only the next decision-relevant missing detail. Apply the shared outdoor conversation contract in the workflow before the technical pipeline; distinguish provisional areas, exact sites and optional venues.

## First decision and answer rules

A resolved named-city plan needs no candidate-details prerequisite: reuse its returned place identity, revision and timezone after `resolve_place`. If the user asks for observing-site details, follow the exposed mode. In API mode, details require the retained placeId and sourceRevision. Named-query details are catalogue/legacy mode only; see recipes below. Keep revisions matched; placeId alone is invalid; do not retry the same invalid arguments. The shared schema accepts multiple shapes: schema-valid does not mean supported in every runtime mode.

Before a candidate-site plan: obtain get_observing_location_details. If its actual timezone is unverified and the user has not explicitly named a display timezone, stop and ask one display-time-zone question. Wait for the reply; do not calculate a candidate or substitute city plan in this turn. A nearby city's timezone, the requested UTC window, or “use its timezone” is not a user choice of an unknown site timezone. Offer the base-city timezone as a question, never silently select it. If details are unavailable, explain that gap and ask whether the user wants a separately labelled named-city plan.

Give on-site directions only from timestamped returned orientation evidence, with a sky app for identification; a maximum-altitude sample is not a rising or session-wide bearing. Use the tool's answer-ready planning text for exact intervals and unknowns. Before finalizing, reconcile every returned source used, including the resolved-location source: preserve complete source links and returned provider/datasource contributor, copyright and licence names, attribution and modification statements, and licence links, including in selection-reporting clarifications; keep full provenance structured. Moon below the geometric horizon does not establish minimal moonlight; leave its observing impact unknown. Do not assert an uncalculated alternative night's visibility.

Darkness intervals are clipped to the requested calculation window. Preserve each returned boundary's meaning: full-window means darkness throughout the requested window, not the whole night. If an interval starts or ends at a requested limit, label that limit as a calculation cutoff; true dusk or dawn remains unknown unless separately established by returned evidence. For a 21:00–05:00 request returning darkness 21:00–04:30, say “astronomical darkness is reported from 21:00 to 04:30 within your requested 21:00–05:00 window; 21:00 is the requested start cutoff, not established astronomical dusk.” Describe 04:30 as astronomical dawn only if the returned evidence establishes that boundary; otherwise preserve its returned meaning or uncertainty. Do not infer dusk/dawn from darknessState alone.

After a successful city or site resolution, retain the returned matches and their exact placeId and sourceRevision or catalogueRevision. When observing-site details are needed, select the matching returned identity and pass its revision to details; reuse that selection across a display-timezone clarification. An unknown site timezone is a details/display-choice gap, not a reason to repeat the same successful resolve_place arguments. An ambiguous result needs selection or a more specific query. A changed location, explicitly requested refresh or expired/rejected selection can require re

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: prepare-outing
description: Turn a night-sky plan into practical, activity- and gear-aware preparation steps.
---

# Prepare a night-sky outing

Use the canonical workflow in `references/workflow.md`.

## Intent before tools

Default to outdoor observing; explicit hosted or accommodation requests override the default. Retain activity, origin, direction, exclusions, budget and corrections. Ask only the next decision-relevant missing detail. Apply the shared outdoor conversation contract in the workflow before the technical pipeline; distinguish provisional areas, exact sites and optional venues.

## First decision and answer rules

A resolved named-city plan needs no candidate-details prerequisite: reuse its returned place identity, revision and timezone after `resolve_place`. If the user asks for observing-site details, follow the exposed mode. In API mode, details require the retained placeId and sourceRevision. Named-query details are catalogue/legacy mode only; see recipes below. Keep revisions matched; placeId alone is invalid; do not retry the same invalid arguments. The shared schema accepts multiple shapes: schema-valid does not mean supported in every runtime mode.

Before a candidate-site plan: obtain get_observing_location_details. If its actual timezone is unverified and the user has not explicitly named a display timezone, stop and ask one display-time-zone question. Wait for the reply; do not calculate a candidate or substitute city plan in this turn. A nearby city's timezone, the requested UTC window, or “use its timezone” is not a user choice of an unknown site timezone. Offer the base-city timezone as a question, never silently select it. If details are unavailable, explain that gap and ask whether the user wants a separately labelled named-city plan.

Give on-site directions only from timestamped returned orientation evidence, with a sky app for identification; a maximum-altitude sample is not a rising or session-wide bearing. Use the tool's answer-ready planning text for exact intervals and unknowns. Before finalizing, reconcile every returned source used, including the resolved-location source: preserve complete source links and returned provider/datasource contributor, copyright and licence names, attribution and modification statements, and licence links, including in selection-reporting clarifications; keep full provenance structured. Moon below the geometric horizon does not establish minimal moonlight; leave its observing impact unknown. Do not assert an uncalculated alternative night's visibility.

Darkness intervals are clipped to the requested calculation window. Preserve each returned boundary's meaning: full-window means darkness throughout the requested window, not the whole night. If an interval starts or ends at a requested limit, label that limit as a calculation cutoff; true dusk or dawn remains unknown unless separately established by returned evidence. For a 21:00–05:00 request returning darkness 21:00–04:30, say “astronomical darkness is reported from 21:00 to 04:30 within your requested 21:00–05:00 window; 21:00 is the requested start cutoff, not established astronomical dusk.” Describe 04:30 as astronomical dawn only if the returned evidence establishes that boundary; otherwise preserve its returned meaning or uncertainty. Do not infer dusk/dawn from darknessState alone.

After a successful city or site resolution, retain the returned matches and their exact placeId and sourceRevision or catalogueRevision. When observing-site details are needed, select the matching returned identity and pass its revision to details; reuse that selection across a display-timezone clarification. An unknown site timezone is a details/display-choice gap, not a reason to repeat the same successful resolve_place arguments. An ambiguous result needs selection or a more specific query. A changed location, explicitly requested refresh or expired/rejected selection can require resol

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.