flow-resumelisted

## Procedure 1. Get the scratch directory: `!`scratch-dir.sh``. 2. If $ARGUMENTS specifies a path, read it. Otherwise, find the most recent plan or feature brief: `ls -t "$(scratch-dir.sh)"/plan-\*.md "$(scratch-dir.sh)"/feature-\*.md 2>/dev/null | head -1`. 3. Diff the plan against current code state: - Which steps are done (via git log on touched files since the plan timestamp) - Which are partially done (working copy changes) - Which are not started - Elapsed time since the plan's timestamp (parse `YYYYMMDD-HHMM` from the filename, compare to `date`). Past 7 days: flag that dependencies, other branches, or requirements may have moved since - do not silently assume the plan's context still holds. 4. Report status. Do not implement. 5. Recommend the next concrete action. ## Before context runs out This is the complementary case to resuming: acting early enough that a resume is easy. If the conversation is running long, before it exhausts, write a scratch note capturing files touched, the step in progress, open questions, and what comes next - use the scratch naming convention. Summarize to the user and stop; do not silently degrade output quality to fit the remaining window. This note is what a later `/flow-resume` reads to pick the work back up. ## Output Terminal only: - Plan being resumed (title, file path) - Elapsed time since the plan's timestamp, with the staleness caveat from step 3 if it crossed the 7-day mark - Step status: done | partial | pending