Notify users when tech packs have available updates

[bguidolim]

Summary

mcs is not a command users run frequently — they sync once and work for days or weeks. There's currently no mechanism to inform users that their installed packs have newer versions available upstream. Users miss improvements, bug fixes, and new features until they manually run mcs pack update.

Problem

• Packs evolve independently of user projects
• Users have no visibility into whether their packs are outdated
• Running mcs pack update is a manual, unprompted action
• Stale packs may cause doctor check failures or miss new capabilities

Proposed Approach: Claude Code Session Hook

Since mcs already composes hooks into settings.local.json, the most natural solution is a lightweight session-start hook that checks pack freshness:

1. mcs check-updates subcommand — a fast, non-interactive command that:

   • Reads ~/.mcs/registry.yaml for installed git packs (skip local packs)
   • Does a git ls-remote (or similar) for each pack to compare remote HEAD vs. local HEAD
   • Optionally respects a cooldown (e.g., check at most once per 24h, tracked via a timestamp file like ~/.mcs/last-update-check)
   • Prints a short notice if updates are available, or nothing if everything is current

2. Hook integration — packs (or mcs itself) could install a session_start hook that runs mcs check-updates, so users see a non-blocking notification when they start a Claude Code session

3. Output should be minimal and non-intrusive, e.g.:

   ℹ️ mcs: 2 pack(s) have updates available. Run `mcs pack update` to update.
   

Alternatives Considered

Approach	Pros	Cons
Session-start hook (proposed)	Runs during natural workflow, leverages existing hook system	Requires Claude Code session
Shell prompt integration (e.g., zsh precmd)	Works outside Claude Code	Invasive, performance-sensitive, hard to manage
Background daemon / cron job	Always running	Over-engineered for this use case
Check during mcs sync only	Simple	Users rarely run sync, defeats the purpose
Lockfile staleness warning	Works with --lock flow	Only helps lockfile users

Design Considerations

• Performance: git ls-remote is fast but still a network call per pack. Batch or parallelize, and use a cooldown to avoid checking on every session start
• Local packs: Skip entirely — they're development packs with no remote to check
• Lockfile users: If a project uses mcs.lock.yaml, the check could note that updates are available but locked, suggesting mcs sync --update
• Global vs. project scope: The check is global (pack versions are global), but the notification could mention which projects are affected
• Offline resilience: Network failures should be silent — never block or warn when offline

Tasks

• Add mcs check-updates subcommand
• Implement cooldown/timestamp tracking (~/.mcs/last-update-check)
• Decide on hook delivery mechanism (built-in vs. pack-provided)
• Handle lockfile-aware messaging
• Add --quiet flag or config to suppress notifications