| name | greeting-checkin |
| description | Greeting-triggered self-check — recognise greetings, check Edition version against the upstream tag, scan AI-Memory announcements, and report inside the greeting reply |
| lastReviewed | "2026-04-30T00:00:00.000Z" |
Greeting Check-in
The heir's pull-based health check. Replaces the deleted weekly auto-update workflow. Fires from greeting-checkin.instructions.md on the first greeting of a session, or on demand via /checkin.
Greeting Recogniser
Match case-insensitively against the trimmed first message. Treat as a greeting if it is substantially one of:
| Bucket | Examples |
|---|
| Salutation | hi, hello, hey, yo, howdy |
| Time-of-day | good morning, good afternoon, good evening, morning, evening |
| Check-in question | how are you, how's it going, how have you been, what's up, you there |
| Compound | any of the above plus the heir's name or a comma-suffix (hi alex,, hey there) |
Do not trigger on:
- Substantive requests that happen to start with "hi" (e.g.
hi, can you fix this build error?) — process the request normally
- Acknowledgements (
thanks, ok, cool, got it)
- Anything longer than ~80 characters — long messages aren't pure greetings
Check Protocol
Run these in order. Each step is best-effort: if it fails, note the failure and continue.
1. Confirm this is a heir
Read .github/.act-heir.json. If absent, this isn't an ACT heir — abort the check silently and respond as a normal greeting.
Capture: heir_id, edition_version (current), last_sync_at.
2. Check Edition version
Run the upgrade script in dry-run mode and capture stdout:
node .github/scripts/upgrade-self.cjs
Parse the output for the Edition version available: line. Compare to edition_version from the marker.
Outcomes:
- Same version → "you're on the latest Edition (
vX.Y.Z)"
- New patch/minor available → "Edition
vX.Y.Z is out — patch/minor bump from vA.B.C. Run /upgrade when you're ready."
- New major available → "Edition
vX.0.0 is out — major bump from vA.B.C. /upgrade requires --allow-major and you'll want to read the release notes first."
- Network error / git failure → "couldn't reach Edition; will retry next session" — don't block
3. Check shared memory announcements
Resolve the shared memory bus using resolveMemoryBus() from _registry.cjs (sibling ../Alex_ACT_Memory). CLI: node .github/scripts/_registry.cjs --resolve .
Once the root is resolved, check <root>/announcements/ for *.md files (skip README.md).
Parse frontmatter for date (or fall back to file mtime). Filter to files newer than last_sync_at from the heir marker.
Outcomes:
- Memory bus not found → note silently; do not prompt
- No new announcements → "no new announcements"
- 1-3 new announcements → list them by title, with one-line summaries
- 4+ new announcements → say how many, list the most recent 3, point at the folder
3b. Execute auto_actions from announcements
If any announcement has auto_actions in its frontmatter, execute them immediately — do not ask the user. These are Supervisor-issued maintenance commands, not suggestions.
For each auto_action:
- Read the
check_file path relative to the repo root
- If the file exists, execute the
if_exists instruction
- If the file is absent, execute the
if_absent instruction
- After all actions, stage changes and commit silently (unless nothing changed)
- Report what was done in the greeting reply — one line per action with its result
3c. Load user profile
Read the user profile from the memory bus: call readProfile(memoryRoot) (or read <memoryRoot>/profile/<username>/user-profile.json directly). If found, apply any session-relevant preferences (communication style, confidence badge visibility, tool preferences). If absent, continue without — profiles are optional.
Do not report profile loading in the greeting reply unless the profile contains an explicit greeting_note field.
4. Write the session marker
Create /memories/session/greeting-checkin.md with:
# Greeting check-in fired
- date: <ISO date>
- edition_current: <version from marker>
- edition_available: <version reported by upgrade-self>
- announcements_new: <count>
This gates the instruction so it doesn't re-fire mid-session.
Reply Format
Wrap the findings inside a normal greeting response. Keep it short — one paragraph if everything is clean, a tight bullet list if there's anything to act on. Examples:
All clean:
Hey! Edition v0.8.0 is current and AI-Memory has no new announcements. What are we working on?
Update available:
Hi! Quick check-in: Edition v0.9.0 shipped (minor bump from v0.8.0). One new announcement in AI-Memory: "Brain-qa workflow update". Run /upgrade when you've got a moment. What's on the agenda?
Major bump:
Morning. Heads up — Edition v1.0.0 is out, which is a major bump from v0.8.0. Read the release notes before running /upgrade --allow-major. AI-Memory has 2 new announcements I'll list if you want. Where do you want to start?
Failure Modes
| Failure | Behaviour |
|---|
upgrade-self.cjs not found | Note "upgrade script missing — bootstrap may be incomplete", point at heir-doctor |
| Network unreachable | Skip the version check silently, still do AI-Memory + greeting |
| AI-Memory folder missing | Mention it once ("AI-Memory not configured"), don't repeat next session |
| Heir marker malformed | Run node .github/skills/greeting-checkin/scripts/heir-doctor.cjs and report what it says |
Falsifiability
This skill is decorative if, after 30 days of typical use, the user reports that:
- Greeting check-ins fire on non-greetings (false positives), or
- The reply text adds friction the user works around by skipping greetings, or
- Real Edition releases ship without the heir surfacing them within the first session after release
Re-evaluate at the 30-day mark; tune the recogniser or the reply format accordingly.
Related
