| 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-07-11T00: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. Leave encrypted profiles unloaded
Do not decrypt or read profiles during greeting. Profiles are optional and load
only when the user or an authorized workflow explicitly requests profile-backed
preferences. Announcement checks remain independent of profile authorization.
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
