michi-sustainability

The sustainability skill assesses long-term system health. It is a menu-driven review that scales from a quick check on recent work to a deep between-epic retrospective. The session skill includes a brief sustainability step before each commit; this skill is for broader reviews that don’t fit inside a milestone’s implementation flow.

When to use

• Within a milestone (10-15 min) — focused check on work just completed, when the built-in session sustainability step isn’t enough
• Between milestones (30-60 min) — review accumulated work across the current epic before starting the next milestone
• Between epics (1-2 hours) — deep review of overall direction, design coherence, and process health before starting new work

What it does

The skill presents a menu of review areas. You select what’s relevant — not everything applies every time.

Code quality. Scan recent changes for duplication, unclear naming, functions doing too many things. Check separation of concerns — could you reuse the logic with a different UI? Flag dead code from recent work.

Test quality. Are mocks at I/O boundaries (not between internal modules)? Do test names describe behavior? Is test data human-readable? Do tests assert on outcomes rather than implementation details? Is the suite fast enough for tight feedback without being so shallow it loses meaning?

Architectural alignment. Does accumulated code match the intended architecture? Has design drifted in a direction that should be acknowledged or corrected? Are naming conventions and patterns consistent? For multi-package projects, are boundaries clean and contracts explicit?

Knowledge and questions. Review open questions — any resolved by recent work? New ones raised? Capture learnings and gotchas in the journal. Check planning-phase assumptions that turned out wrong. Look for applied coding principles in the codebase that aren’t yet documented in code-style.md. Review docs/memory.md for stale or superseded content.

Direction (between-epic scope). Does the overall trajectory still make sense? Are we living the north stars or drifting? Is the knowledge base current? What should change about how the next epic is run? Should the autonomy mode (Paired vs. Entrusted) change based on demonstrated quality?

What it produces

• Findings logged in the plan doc’s Notes section (within-milestone) or the epic’s journal (between milestones/epics)
• Action items — immediate fixes (refactoring, test additions) or items deferred to the next milestone’s plan
• Discussion items for human review
• Process observations about methodology, captured in the journal

Key things to know

• This is a flexible skill — select from the menu based on what the current moment needs. A between-milestone check might only need code quality and test quality. A between-epic review might touch everything.
• The sustainability check explicitly looks for applied coding principles that are being followed in the codebase but not yet documented. This prevents good patterns from being lost between sessions.
• Memory hygiene is part of the knowledge review — pruning stale memories and challenging ones that have calcified into unexamined rules.
• If the sustainability check reveals significant drift or accumulated debt, it may indicate the need for a dedicated refactoring milestone in the next planning cycle.

For the full agent instructions, see the SKILL.md source.