Use one fresh local clock anchor for every direct user turn. Apply it through , resolve relative dates and times without changing the user's words, and persist the current acquisition time in the visible reply.

Treat an ordinary direct user message as . These control words exist for inspection and testing.

help

refresh

starting-point

If a request matches neither command, use . Do not ask the user to choose a command.

Run before every reply to a direct user message, even when the message has no date or time words. A tool result, system event, or assistant continuation does not start a new clock acquisition. An exact mid-turn out-of-band user-message marker does.

Before interpreting or acting on the newest direct user message:

Run on macOS or Linux with that working directory:

python3 scripts/current_anchor.py

Run on Windows with that working directory:

python scripts/current_anchor.py

Use or only when it is the installed interpreter. Do not use a skill-directory shell variable or guess an installation path. If the load result does not supply a concrete skill directory, report and stop date-dependent or time-dependent work. Never pass a fabricated timestamp. Reuse an anchor only when its process result occurs after the newest direct user message.

The portable script accepts , then checks , then uses system-local time. An explicit argument represents a profile configuration supplied by the host and wins over the environment.

If the command fails, returns invalid JSON, or omits a required field, stop date-dependent or time-dependent work and report followed by the short error. Do not guess, reuse an earlier date or time, or fall back to the conversation-start timestamp.

Add this private structure without exposing the full outcome map:

as_of: captured_at, date, time, weekday, timezone, zone_abbreviation, utc_offset, source

Apply it to:

On the first assistant reply for a local date, and again when the local date changes, begin with:

NOW: <weekday>, <full date> at <HH:MM:SS> | <zone abbreviation> | UTC<offset>

Begin every normal user-facing reply on that date with:

[YYYY-MM-DD HH:MM:SS <zone abbreviation>] <result or question>

Inspect retained assistant messages to decide whether the daily header already appeared. When context compaction makes that uncertain, prefer a repeated current header over a missing or stale header. Prefix an interactive clarification question inside its question text. Do not prefix tool calls or internal notes.

The literal templates also live in . When clock acquisition fails, use the failure marker instead of a dated prefix.

After resume or context compaction, reacquire the clock before using any retained date or time. If this skill body is unavailable from retained context, reload it before acting. Stored date-time prefixes prove prior turns only.

Read and before testing or changing this skill. Read when changing the package structure or checking native-to-port lineage. Load before changing script behavior and run those tests before implementation changes. Load the rest of only when measuring activation, behavior, enrollment, or timing. Do not load these files on ordinary turns.

The script cannot infer the user's intended timezone from prose. The host must supply an explicit IANA timezone through or when system-local time is not the intended context. The skill can resolve dates and times and prepare absolute tool arguments, but a separate capability owns any real reminder, calendar, or deployment action.

The turn is ready only when the skill was loaded, one fresh clock call produced every required field after the newest direct message, is bound to the private map, temporal language is resolved before date-sensitive or time-sensitive actions, and the actual user-facing response contains the required current date-time prefix. Any stale, missing, duplicate, or failed anchor leaves temporal work blocked.