New day
Skill ztnkv/personal-operating-system/.claude/skills/new-day
Portable personal-memory system for AI agents (Claude Code). Markdown + git. Skills for memory, lists, daily check-ins, blind-spot interviews — your agent gets a stable, evolving model of you.
npx -y skills add ztnkv/personal-operating-system --skill new-dayAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Creates a day check-in — a Markdown file with today's prompts in days/. Triggered by "/new-day", "new day", "let's start the day". Works in two stages — first it creates a blank template (planning horizons, abstinence, errand of the day) and stops so the user can fill it in by hand; once the user signals "done / filled", it runs a defensive cross-check against the dynamics of the last days (flags focus drift, project switching, defensive scripts being acted out), then a retrospective of the contents, optionally proposes memory updates, and commits everything in a single commit.
SKILL.md
11.2 KB, ~2.7k tokens by cl100k_base, as published. Nobody here has run it
new-day
Creates a morning check-in in days/YYYY-MM-DD.md and a retrospective once it is filled.
When to invoke
/new-day- "new day", "let's start the day", "start a new day"
Do NOT invoke on:
- Plain "hi", "good morning" without an explicit ask to create a day entry.
- Requests to view or edit past days — that's regular file work, no skill.
Algorithm
The skill works in two stages with an explicit pause between them — the user fills the file in by hand in between.
Stage 1. Create the day file and stop
Step 1.1. Determine today's date
date +%Y-%m-%d via Bash. Do not take the date from the conversation or from memory — only the system clock.
Step 1.2. Check whether the file already exists
Check days/YYYY-MM-DD.md. If it already exists:
- Tell the user: "
days/YYYY-MM-DD.mdalready exists. Continue filling it / go to retrospective / start over?" - Do not overwrite silently. Wait for an answer.
- "continue" / "to retro" → jump to Stage 2 (if the file already has content).
- "start over" → delete the old one, recreate from the template.
Step 1.3. Create the days/ directory if missing
mkdir -p days.
Step 1.4. Create the file from the template
days/YYYY-MM-DD.md (date is the real one for today):
# YYYY-MM-DD
- Good for the year:
- Good for the half-year:
- Good for the month:
- Good for the week:
- Habits I'm abstaining from:
- Errand of the day:
Hard requirements for the template:
# YYYY-MM-DDheading — required.- The blank lines between the "Good for …" block, the abstinence block, and the errand block — required (visual separation for the user).
- A colon at the end of each prompt — the user writes their answer on the same line.
- Do not add anything to the template on your own.
You may customize the prompts if the user has asked you to (different planning horizons, different intimate prompts). The skill simply stores the template they chose and reproduces it every morning.
Step 1.5. Report and stop
Short message to the user, one or two sentences:
Created
days/YYYY-MM-DD.md. Fill it in and let me know when you're done.
Important: do not ask about the content, do not propose to fill prompts for the user, do not hint. Filling is manual and private. Just stop and wait for an explicit signal.
Stage 2. Retrospective and commit
Triggered when the user explicitly says: "done", "filled", "all set", "go ahead", "do the retro" — provided that the day file was created today.
Step 2.1. Read the file
days/YYYY-MM-DD.md (today's).
Step 2.2. Defensive cross-check against past dynamics
Goal — catch signs of drift (focus switching, watering down of horizons, the user acting out their own avoidance scripts) before they harden.
A safeguard-as-voice, not a validator. Never blocks the commit, never moralizes, never says "all clear" if there is no signal — it just stays silent and moves on.
Step 2.2.1. Minimum bar to run
If days/ contains fewer than 2 files (no dynamic to compare against) — skip Step 2.2 entirely and go to 2.3.
Step 2.2.2. Gather the comparison window
Read all files in days/, but no more than the last 14 by date in filename (including today's). Sort descending.
Step 2.2.3. Load defensive memory entries
Read memory/index.md, then pull the bodies of entries relevant to the defensive frame:
- The user's own named avoidance / drift scripts, if any (memory entries the user has explicitly tagged as their own anti-patterns).
- Current main focus (whatever the user marked as the primary focus entry).
- Switching patterns the user has explicitly recorded (e.g. "Monday as a switch trigger", if such an entry exists).
- Active goals (sport, health, work, finances — whichever exist).
- Anchor values / non-negotiables.
If some of those entries don't exist — don't crash, use what's there.
Step 2.2.4. Run today's file through the signal list
Generic signals. For each one, a concrete trigger rule grounded in the files.
- Focus changed at month/week horizon. If "Good for the month" or "Good for the week" today names a different main thing than it did in the majority of the last 7 days — flag.
- Multiple projects in the weekly focus. If "Good for the week" lists more than one product / project — flag (violates "one thing at a time" if that is a stated principle in memory).
- A stable role formulation at the longest horizon got watered down. If a long-standing role anchor in "Good for the year" disappeared or was replaced by a vague phrase — flag.
- Monday switch. If today is Monday (
date +%u= 1) AND the month/week focus differs noticeably from the previous workday — separate flag with an explicit pointer to the "Monday-trigger switching" entry if it exists. - Return to a previously dropped project while the current one hasn't shipped. If today's focus mentions a project that previously appeared in
days/and then disappeared, AND the project that has occupied the focus since then never made it to release — flag. - Disappearance of named bad habits. If "Habits I'm abstaining from" today is "—", empty, "none" while previous days had concrete entries — flag.
- Repeating errand without execution. If "Errand of the day" today carries the same (or semantically equivalent) content as a file 3+ days back and the errand has not left the list in between — flag.
- Health / sport disappeared from the horizons. If active memory goals include sport / weight, but none of today's horizons (year / half-year / month / week) mention sport, training, health, weight — flag.
A signal counts only when its rule actually fires. Do not soften "looks like" into a flag when the file doesn't support it.
Step 2.2.5. If nothing fires
Silently jump to 2.3. No "all clear" message, no "defensive check passed".
Step 2.2.6. If one or more signals fire — emit a warning
Calm, observant tone, no alarmism, no moralizing. Template:
**Defensive check note:**
I compared today's entry with the last N days and the defensive memory entries.
What stood out:
- **[Signal N — short name]**: [concrete facts from files — what was earlier (with date), what is now]
- **Looks like**: [script/pattern name with a reference to a memory entry, if one exists]
- **Question to sit with**: [one precise question, not rhetorical]
[repeat per fired signal, max 3 — if more fired, keep the loudest 3]
Want to talk it through, or is this a conscious shift?
Hard formatting rules:
- Only facts observable in files. No "I feel" / "I sense".
- No more than 3 signals in one warning even if more fired — pick the loudest, drop the rest.
- A reference to a script / pattern entry in memory — required when one exists. Use the entry filename, not a paraphrase.
- One precise question per signal, not rhetorical. The point is to make the user formulate an answer, not deflect.
Step 2.2.7. Pause for the user's response
After the warning — stop and wait. Do not proceed to retro/commit until the user replies.
Two paths:
- User explains it as a conscious shift — accept it, go to 2.3. Their explanation may become a candidate for a memory entry on the next step.
- User acknowledges the pattern — short conversation, the insight is named. Then still go to 2.3 (memory-retro will record the insight if it's significant).
Do not insist, do not lecture. The safeguard-voice did its job — the word was said.
Step 2.3. Retrospective via memory-retro
Pass the contents of today's file and the short summary of the defensive check (if any signal fired and a conversation happened) to memory-retro as the source. It will:
- analyze whether there are facts, patterns, goal/habit changes worth recording in
memory/; - if yes — build a diff proposal and confirm with the user;
- if there is nothing — say so explicitly.
Do not duplicate memory-retro's logic here. Just delegate.
Step 2.4. Wait for memory-retro to finish
Two outcomes:
- Memory was not updated — proceed to commit, day file only.
- Memory was updated —
memory-retroalready wrote changes viamemory-write. Proceed to commit, day file + memory changes.
Step 2.5. One combined commit
One commit for everything. No splitting into "day" and "memory". This rule matters.
git add days/YYYY-MM-DD.md
# if memory was updated:
git add memory/
Commit message:
- Without memory updates →
chore(days): add YYYY-MM-DD entry - With memory updates →
chore(days): add YYYY-MM-DD entry + memory updates
Step 2.6. Push
git push origin <current branch>. On a network error — up to 4 retries with exponential backoff 2/4/8/16s.
Step 2.7. Confirm to the user
One short line: "Day committed. Memory — updated / unchanged."
Edge cases
File created but the user goes quiet
If between Stage 1 and Stage 2 the user moves to another topic — don't rush. The skill just waits for the "done" signal. The file is on disk, nothing is lost.
Empty / partially filled file
If at Stage 2 the file is empty or almost empty (only the template, no answers):
- Ask: "Looks unfilled. Commit and close the day anyway, or wait?"
- Don't retro-against-nothing — there's nothing to capture.
File for a past date
If the user says "new day" but date shows a date for which a file already exists, and there's an uncommitted file for yesterday or earlier — mention it: "There's also an uncommitted days/YYYY-MM-DD.md from an earlier date — what about it?" Don't touch it silently.
/new-day repeated the same day
See Step 1.2 — do not overwrite, ask intent.
Don'ts
- Do not propose answers to the prompts. Filling is manual.
- Do not nudge ("maybe write something about sport?"). This is an intimate check-in, not an interview.
- Do not echo the file contents back to the user at Stage 1 (they're about to open it in an editor).
- Do not make two separate commits (day + memory). One commit only.
- Do not push if the commit didn't go through (hook failure etc.) — fix first.
- Do not block the commit/push based on defensive-check signals (Step 2.2). It's a safeguard-as-voice, not a validator.
- Do not emit a warning if no signal fired. Do not write "all good, no patterns" — just move on.
- Do not moralize in the defensive check. Only facts from files + a reference to a memory entry + one precise question.
- Do not run the defensive check if
days/has fewer than 2 files, or if today's file is empty (template only). - Do not bundle more than 3 signals into one warning — pick the loudest, drop the rest.