mm-focus

name	mm-focus
version	0.1.0
description	Stage-scoped reload файлов текущего GSD-этапа в свежий контекст ПОСЛЕ ручного /clear, mid-phase. Не сводка «где мы» (это /mm resume), а ЗАГРУЗКА самих рабочих файлов этапа (STATE + CONTEXT/PLAN/SUMMARY по статусу), чтобы сразу продолжать работу. Только для GSD-проектов. Read-only. Use when user says "/mm-focus", "/mm focus", "перечитай этап", "перечитай файлы этапа после clear", "scoped reload", "загрузи текущий этап", "вернуть контекст этапа после /clear".

mm-focus — Stage-Scoped Reload after /clear

Решает узкую проблему: ты сделал ручной /clear посреди GSD-фазы, контекст пуст, и нужно снова втянуть в контекст рабочие файлы именно текущего этапа — не сводку, а сами файлы, чтобы продолжить работу с того же места.

Отличие от /mm resume: resume даёт компактную СВОДКУ «где мы» (passport + git + last session + выжимки). mm-focus НИЧЕГО не пересказывает — он загружает полное содержимое минимального scoped-набора файлов текущего этапа в контекст и выдаёт одну строку-ориентир. Это не дубль resume.

Когда вызывать:

• ПОСЛЕ ручного /clear, mid-phase, когда работа над фазой не закончена.
• Когда нужно «вернуть в голову» файлы текущего этапа, не читая весь проект.
• Цикл: GSD-этап в работе → /clear → /mm-focus → продолжаешь.

Чего скилл НЕ делает:

• НЕ выполняет /clear сам — это клиентская операция, недоступная из скилла. Скилл рассчитан на запуск ПОСЛЕ ручного /clear.
• НЕ пишет ничего — ни в .planning/*, ни в .gsd/*, ни куда-либо ещё (там file-lock'и/хуки). Только чтение.
• НЕ делает resume-стиль дамп — только scoped-набор этапа.
• Не для не-GSD проектов — там используй /mm resume.

Процесс

Шаг 1. Определи проект (worktree-aware)

То же, что в mm-resume Шаг 1:

• Если cwd внутри .claude/worktrees/... — resolve до main repo через .git файл-указатель.
• Иначе — поднимись до корня (где .git/, package.json, pyproject.toml, и т.п.).
• Имя проекта = из passport.md frontmatter (если есть) ИЛИ basename корневой папки.

Если нет passport.md ИЛИ проект не под GSD (см. Шаг 2 — ни .planning/, ни .gsd/) — скажи: GSD-фаз тут нет, используй /mm resume. и остановись.

Шаг 2. Dual-detection GSD (v1/core/v2) — как в mm-resume

Определи версию:

• <project_root>/.planning/ существует:
  • есть <project_root>/.planning/config.json → GSD Core
  • иначе → GSD v1
• <project_root>/.gsd/ существует → GSD v2
• Оба → возьми gsd_version из passport frontmatter; если нет — спроси.
• Ничего нет → остановись с подсказкой /mm resume (см. Шаг 1).

Шаг 3. Определи текущую фазу и ЭТАП

GSD v1 / Core (.planning/):

1. Прочитай .planning/STATE.md — оттуда текущий milestone и position (номер/имя текущей фазы).
2. Найди папку текущей фазы .planning/phases/<NN-current>/.
3. Определи ЭТАП по статусу фазы в STATE.md (draft/discussed/planned/in-progress/verified/complete) И по наличию артефактов — артефакты приоритетнее, если расходятся:
   • нет CONTEXT.md → Discuss
   • есть CONTEXT.md, нет PLAN.md → Plan
   • есть PLAN.md, нет SUMMARY.md → Execute
   • есть SUMMARY.md ИЛИ статус verified/complete → Verify

GSD v2 (.gsd/): этапная модель в файлах слабее — определи позицию из .gsd/STATE.md (rendered dashboard) и, если доступен sqlite3, из gsd.db (активный slice/tasks). Per-phase PLAN.md/SUMMARY.md может не быть — грузи что есть (см. Шаг 4).

Шаг 4. Прочитай scoped-набор (ЗАГРУЗИ ПОЛНОЕ содержимое в контекст, НЕ пересказывай)

Цель шага — чтобы файлы оказались в контексте целиком. Читай их Read-инструментом полностью. Не выжимай, не суммируй.

GSD v1 / Core (.planning/):

• Всегда: STATE.md + HANDOFF.json (если есть).
• Discuss → + строка текущей фазы из ROADMAP.md + PROJECT.md (vision/scope; если файл большой — раздел целей/scope или первые ~40 строк) + CONTEXT.md (если уже есть).
• Plan → + CONTEXT.md + PLAN.md (если уже частично есть).
• Execute → + PLAN.md + CONTEXT.md.
• Verify → + PLAN.md + SUMMARY.md.

Все per-phase файлы — из .planning/phases/<NN-current>/.

GSD v2 (.gsd/):

• Всегда: .gsd/STATE.md + .gsd/AGENTS.md (≈ CONTEXT).
• Задачи текущего slice из .gsd/gsd.db через sqlite3, если он в PATH:

  sqlite3 "<project_root>/.gsd/gsd.db" "SELECT title, status FROM tasks WHERE slice_id=(SELECT id FROM slices WHERE active=1) LIMIT 20;"
  

  Если sqlite3 недоступен — пропусти, набор беднее но не падает.
• Per-phase PLAN.md/SUMMARY.md в v2 может не быть — грузи только то, что реально существует.

Шаг 5. Вывод — МИНИМАЛЬНЫЙ

Это не resume-сводка. Суть в том, что файлы уже в контексте. Выдай только:

📍 Фаза <NN> «<title>» · этап <Discuss|Plan|Execute|Verify> · загружено: <file1>, <file2>, ...

И, если в HANDOFF.json есть «Точка возврата» / what_next — добавь её ОДНОЙ строкой:

↩️ Точка возврата: <следующий конкретный шаг>

Всё. Не делай развёрнутую сводку, не дублируй resume, не пересказывай содержимое загруженных файлов.

Шаг 6. После вывода — жди

Контекст загружен. Пользователь сам решит, что делать дальше.

Edge cases

• Артефакт этапа отсутствует (напр. на Discuss ещё нет CONTEXT.md): грузи что есть, в строке «загружено» отметь чего нет (CONTEXT.md — нет), не падай.
• GSD есть, но нет активной фазы (между milestone'ами): скажи GSD: активной фазы нет — /mm resume или /gsd-new-milestone. и остановись.
• HANDOFF.json отсутствует: пропусти строку «Точка возврата».
• Расхождение статуса STATE.md и артефактов: верь артефактам (наличие файлов важнее декларации), упомяни расхождение одной фразой.

Жёсткие правила

• Read-only по GSD. НИКОГДА не писать в .planning/* или .gsd/* (file-lock'и/охраняющие хуки). Никаких git-мутаций, никаких авто-коммитов.
• Не выполнять /clear — это клиентская операция вне скилла; mm-focus запускается ПОСЛЕ ручного /clear.
• Не дублировать /mm resume — никакого полного дампа и сводки, только scoped-набор текущего этапа и одна строка-ориентир.
• Только GSD-проекты — нет GSD → отправляй на /mm resume.