planning-with-files is a persistent, file-based task-planning system for AI coding agents. It maintains task_plan.md, findings.md, and progress.md on disk and wires into agent lifecycle hooks (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact, Stop) across Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode, Pi, Hermes, and a dozen other assistants, re-injecting plan context into the model's context window on every turn. Plans survive context loss, /clear, compaction, and crashes; a session-catchup mechanism recovers prior transcripts. A v3 gated mode can block the agent from stopping until plan phases complete, backed by an append-only JSONL run ledger, stall detection, and SHA-256 plan attestation that makes hooks refuse to inject tampered content. Architecturally it is a distribution hub rather than a single application: a canonical skill under skills/planning-with-files is mirrored byte-identical into 15+ IDE-specific directories, with native TypeScript plugins (OpenCode, Pi, DSH), a Python plugin (Hermes), and shell/PowerShell hook dispatchers. Plan resolution is a fail-closed chain (PLAN_ID env → .active_plan pointer → newest plan dir → legacy root) guarded by slug validation, containment checks, symlink/junction rejection, and strict PWF_PLAN_ROOT pinning. The engineering is unusually rigorous for an agent-skill repo: 400+ pytest tests, byte-parity tests between shell/PowerShell/Python/TypeScript twins, a PATH-stub BSD userland simulation to catch GNU-only flags that silently fail on macOS, and heavy Windows PowerShell 5.1 / Git Bash portability hardening. Non-obvious patterns include KV-cache-stable injection output (no timestamps or free text in summaries, wall-clock normalization to T00:00:00Z) and an mtime-keyed attestation cache for performance. The repository is a developer tool, not a data/research project; although it ships benchmark and eval documentation (assertion pass rates, recovery-turn comparisons), those are verification evidence for the skill, not analysis artifacts. It is actively maintained at v3.24.0 with recent commits, 4 open issues, and 100+ releases; technical drift is low, with the main maintainability risk being deliberate duplication across 20+ canonical mirrors, mitigated by sync-ide-folders.py and parity tests but still a possible source of silent drift.
claude-mem is a persistent memory system for AI coding assistants, primarily targeting Claude Code but also supporting Codex, Cursor, Windsurf, OpenClaw, and other platforms. It captures observations, summaries, and user prompts from coding sessions via lifecycle hooks (SessionStart, PostToolUse, etc.), stores them in SQLite (local) or Postgres (server), and injects relevant context into future sessions to maintain continuity across agent interactions. The system operates as a background worker daemon (Bun) or a multi-user server (Express + BullMQ + Valkey) with API key authentication, team/project scoping, and rate limiting. Architecturally, claude-mem is a hybrid of a CLI plugin and a standalone server. The CLI component integrates into IDEs via hook scripts and MCP servers, while the server component provides REST APIs for memory management, search, and cloud sync. It features a dual-storage backend (SQLite for local, Postgres for server) with vector search via ChromaDB and full-text search via SQLite FTS5. The system includes a React-based viewer for browsing memory feeds, telemetry (opt-out PostHog), and a Cloudflare Workers-based sync hub for cross-device synchronization. The codebase demonstrates strong engineering practices with well-abstracted components (search strategies, provider abstraction, atomic file operations, telemetry scrubbing) but carries some technical debt from its dual-runtime evolution (legacy worker vs. server-beta) and extensive Windows-specific workarounds. It is actively maintained with frequent releases and comprehensive test coverage.