Add hippo-memory shared workflow and daily learn workflow

[Copilot]

Wraps hippo-memory as a reusable shared workflow and adds a daily agent that mines git commits for lessons and surfaces actionable improvement suggestions.

shared/hippo-memory.md

Importable shared wrapper providing:

• Setup steps — npm install -g hippo-memory + symlinks .hippo/ → /tmp/gh-aw/cache-memory/hippo-store/ so the SQLite index persists across runs via cache-memory automatically
• mcpscripts-hippo MCP tool — exposes the full hippo CLI to the importing agent (learn --git, sleep, recall, remember, export, etc.)

Usage:

runtimes:
  node:
    version: "22"     # hippo requires Node.js 22.5+
network:
  allowed:
    - node            # npm install
imports:
  - shared/hippo-memory.md

daily-hippo-learn.md

Daily Copilot workflow (≈07:00 UTC) that:

1. Runs hippo learn --git to extract lessons from recent commits
2. Runs hippo sleep for full consolidation (decay, dedup, global-store promotion)
3. Recalls memories across four lenses — errors/bugs, code quality, CI health, architectural decisions
4. Posts a 🦛 Hippo Memory Insights — YYYY-MM-DD GitHub Discussion with categorised improvement suggestions

[Copilot]

Pull request overview

Adds hippo-memory integration to Agentic Workflows by introducing a reusable shared import and a scheduled daily Copilot agent that learns from recent git commits and posts summarized insights.

Changes:

• Added a shared workflow import that installs/configures hippo-memory and exposes a mcpscripts-hippo tool.
• Added a daily scheduled “Hippo Learn” Copilot workflow that runs learn, sleep, recalls insights, and posts a discussion.
• Added the compiled lockfile for the new daily workflow.

Show a summary per file

File	Description
.github/workflows/shared/hippo-memory.md	Shared import: installs hippo-memory, symlinks .hippo/ into cache-memory, and defines mcpscripts-hippo.
.github/workflows/daily-hippo-learn.md	Daily Copilot workflow definition + prompt to mine commits, consolidate, and publish a discussion via safe-outputs.
.github/workflows/daily-hippo-learn.lock.yml	Compiled gh-aw workflow reflecting the new daily job and imported shared modules.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 3/3 changed files
• Comments generated: 3

[Copilot]

This workflow relies on shared/hippo-memory.md to enable cache-memory, but because that import also defines steps:, the compiled workflow restores cache-memory after the hippo setup steps (see daily-hippo-learn.lock.yml: Initialize hippo store runs before Restore cache-memory file share data). To ensure the hippo store is restored before any initialization/migration runs, declare tools.cache-memory: true in this workflow’s own frontmatter (and adjust the shared import accordingly), then re-run gh aw compile so the lock file reflects the correct ordering.

[Copilot]

The .hippo initialization logic will fail if .hippo exists as a broken symlink: [ ! -e ".hippo" ] will be true, but ln -s … .hippo will still error because the path already exists. Consider explicitly handling the broken-symlink case (e.g., detect [ -L .hippo ] and remove it, or use a force/replace approach) so the workflow can self-heal after partial/corrupted state.

Suggested change

	if [ ! -e ".hippo" ]; then
	ln -s /tmp/gh-aw/cache-memory/hippo-store .hippo
	if [ -L ".hippo" ] && [ ! -e ".hippo" ]; then
	# Broken symlink present — remove and recreate it so setup can self-heal.
	rm -f .hippo
	ln -s /tmp/gh-aw/cache-memory/hippo-store .hippo
	echo "🔗 Repaired broken .hippo symlink → cache-memory/hippo-store"
	elif [ ! -e ".hippo" ]; then
	ln -s /tmp/gh-aw/cache-memory/hippo-store .hippo

[Copilot]

tools.cache-memory: true is declared in this shared import and the import also defines steps: that read/write /tmp/gh-aw/cache-memory/.... In the compiled workflow this results in the cache restore happening after these steps (see daily-hippo-learn.lock.yml where Initialize hippo store runs before Restore cache-memory file share data), so the initialization step won’t see the restored store and may write data that later gets overwritten by the restore. To make persistence reliable, consider moving cache-memory: true to the importing workflow (so restore happens early), or refactor this shared import so any steps that depend on cache-memory run after the cache restore phase.