cron-log-writer

name	cron-log-writer
description	Appends a timestamped, sequenced line to a log file on a recurring schedule. Use this skill to demonstrate durable cron execution, crash recovery, and no-duplicate guarantees. The simplest skill that touches the most execution patterns — a read, a reasoning step, and a write on a timer.
allowed-tools	read write

Cron Log Writer

A minimal durable cron skill designed to prove the tenure lifecycle. It reads the current state of a log file, generates the next sequenced entry, and appends it. When run on a Temporal Schedule, it survives Worker death, catches up missed runs, and never duplicates a line.

Why This Skill Exists

This is the canonical proof skill for Tenure. It is intentionally simple because simplicity makes the durability guarantees verifiable. A correct run produces exactly one line per cycle with sequential numbering, correct timestamps, and zero gaps or duplicates — even across process death and restart.

The skill is designed to progress through the full tenure lifecycle:

• Probationary: the entire skill runs as one opaque Activity. Crash recovery works at the whole-skill level. A failure restarts everything.
• Decomposed: the skill is broken into three Activities (read → reason → write). Each step is independently checkpointed. A crash after the read does not re-execute the read. A crash after the write does not duplicate the write.
• Reviewed: human or automated review confirms the decomposition is correct and the write step has an idempotency key.
• Tenured: five or more consecutive successful runs with zero gaps and zero duplicates.

Workflow

1. Read the current contents of log.txt in the working directory. If the file does not exist, treat the current state as empty with sequence number 0. Count the number of existing lines to determine the next sequence number.

2. Generate the next log entry. The entry format is: {sequence} | {ISO 8601 timestamp} | OK. The sequence number is the previous line count plus one. The timestamp is the current UTC time at generation. Do not use any other format.

3. Append the generated line to log.txt. Do not overwrite existing content. The append must be atomic — if the process dies mid-write, the partial line must not appear in the file on recovery. Use the sequence number as the idempotency key: if a line with this sequence number already exists in the file, skip the write.

Example Output

After six cycles (including a crash and recovery):

1 | 2026-04-12T10:00:00.000Z | OK
2 | 2026-04-12T10:01:00.000Z | OK
3 | 2026-04-12T10:02:00.000Z | OK
4 | 2026-04-12T10:05:12.000Z | OK
5 | 2026-04-12T10:05:13.000Z | OK
6 | 2026-04-12T10:06:00.000Z | OK

Lines 4 and 5 were caught up by the Temporal Schedule after the Worker restarted. The gap in wall-clock time between line 3 and line 4 reflects the downtime. The sequence numbers have no gaps. No line is duplicated.

Verification

After any run, the following must be true:

• Line count equals the highest sequence number in the file.
• Every sequence number from 1 to N is present exactly once.
• No two lines share the same sequence number.
• Every timestamp is a valid ISO 8601 string.
• Lines are ordered by sequence number ascending.
• The SHA-256 hash of the file is deterministic for a given sequence of runs (timestamps vary, but the structure is fixed).

Execution Characteristics

Step 1: Read

This is an idempotent read. It can be retried any number of times without side effects. If the file does not exist, the result is an empty state — this is not an error. On Temporal replay after a crash, this Activity returns the cached result from Event History without re-reading the file.

Step 2: Reason

This is a deterministic computation. Given a line count of N, the output is always sequence number N+1 with the current timestamp. No LLM call is needed for this skill — the reasoning is pure arithmetic and string formatting. On Temporal replay, this Activity returns the cached result.

Step 3: Write

This is a side-effect mutation. It appends bytes to a file on disk. It must not execute twice for the same sequence number. The idempotency key is the sequence number itself: before appending, check whether a line with this sequence number already exists. If it does, return success without writing. On Temporal replay after a crash, this Activity returns the cached result from Event History and the write is not re-executed.

Failure Modes

Worker dies after Step 1, before Step 3

The read result is in Event History. On Worker restart, Temporal replays the Workflow, returns the cached read result, re-executes Step 2 (deterministic, produces the same sequence number), and executes Step 3. The line is written exactly once.

Worker dies during Step 3

The write may have partially completed. On restart, Step 3 re-executes. The idempotency check (does this sequence number already exist in the file?) prevents a duplicate. If the previous write was partial (incomplete line), the idempotency check does not match, and the line is re-written. The partial line must be handled — either by truncating incomplete trailing content before appending, or by using atomic write-then-rename.

Worker dies after Step 3

The write is complete and recorded in Event History. On replay, Step 3 returns the cached result. No re-execution. No duplicate.

Temporal Schedule misses runs during downtime

The Schedule's catchupWindow policy (default 10 minutes) queues missed triggers. When the Worker restarts, the queued triggers execute in sequence. Each execution reads the current file state (which includes lines from previous catch-up runs), generates the next sequence number, and appends. The catch-up is self-correcting because each run reads the latest state.

Multiple catch-up runs execute concurrently

The Schedule's overlap policy should be set to SKIP to prevent concurrent executions of the same skill. If two catch-up runs execute simultaneously, both read the same line count and generate the same sequence number. The idempotency check on write prevents the duplicate, but the second run wastes work. SKIP prevents this entirely.

Cron Configuration

When run through Tenure with a cron schedule:

npx tenure run --cron "*/60 * * * * *" ./cron-log-writer/SKILL.md

This creates a Temporal Schedule that triggers createSkillWorkflow every 60 seconds. The Schedule configuration:

• catchupWindow: 10 minutes (catches up runs missed during downtime up to 10 minutes)
• overlap: SKIP (prevents concurrent executions)
• pauseOnFailure: false (a single failure does not stop the schedule; the next trigger runs normally)

Tenure Lifecycle Progression

This skill is designed to demonstrate each stage of the tenure lifecycle.

Stage: Probationary (score ~20)

The skill runs as uploaded — one Activity wrapping the entire workflow (read + reason + write). Crash recovery works at the skill level: if the process dies, the whole skill re-executes from the beginning. This means the read happens again (safe, it is idempotent) and the write happens again (unsafe if no idempotency check exists at this level). The probationary stage relies on the idempotency logic in the write step to prevent duplicates even without per-step checkpointing.

Stage: Decomposed (score ~60)

The skill-creator analyzes the skill body and decomposes it into three separate Temporal Activities: ReadLogState, GenerateEntry, AppendEntry. Each Activity is independently checkpointed. A crash between ReadLogState and AppendEntry does not re-execute ReadLogState. The write Activity has its own retry policy (2 attempts, 1-second backoff) and its own idempotency key (sequence number). The decomposition follows the strangler fig pattern: the monolith Activity is replaced by three granular Activities, and the monolith is eliminated.

Stage: Reviewed (score ~80)

Human or automated review confirms: the read Activity is correctly classified as idempotent (safe to cache and retry), the write Activity has an idempotency key (sequence number), the reasoning step is deterministic (no LLM needed), and the cron configuration has overlap: SKIP. Review approval advances the skill to reviewed status.

Stage: Tenured (score 100)

Five consecutive successful cron runs with zero gaps and zero duplicates. The file contains exactly 5 lines, sequence numbers 1 through 5, each with a valid timestamp. The tenure assessment verifies this from .tenure/history.json. The skill is now tenured — proven durable in production.