repo-awarenesslisted

# Repo Awareness **Scope note**: this is deliberately narrow — feeding *repository-derived* signals into the memory system, not a general codebase-analysis or architecture-review skill. For deeper codebase quality/architecture review, this ecosystem already has `improve-codebase-architecture` and `codebase-design` — reach for those directly rather than duplicating their job here. This skill's only concern is: what does the repo's current state tell a memory-aware session that it should know. ## What to check, cheaply - **Recent commits** (`git log --oneline -20` or similar) — what's actually changed recently, which may not match what `.memory/` says was last worked on if changes happened outside a memory-aware session (a different tool, a human directly) - **Current branch and its relationship to main** — whether there's unmerged work in flight - **Files modified but not committed** — uncommitted work in progress that a fresh session needs to know about before touching those files - **TODO/FIXME comments in recently touched files** — lightweight, in-code signals that may not have made it into `.memory/tasks/` yet - **Open items in the project's issue tracker, if the project has one integrated** (see the `mattpocock`-style `issue-tracker` conventions elsewhere in this collection if the project uses local markdown issue tracking, or a real GitHub Issues/Linear integration if configured) ## Reconciling repo state with memory state The interesting case is **divergence** — wh