ask-merlin

Files (3)

• PHASE-BOUNDARIES.md
• SKILL.md
• skill-map.md · references/

SKILL.md (first lines)

# Ask Merlin

Роутер профиля merlin-cto. Закрывает все навыки этого дерева.

Грузи этот навык только когда человек явно спрашивает, какой навык, поток или режим взять. Если он уже назвал навык или просто попросил сделать работу, этот файл не грузи.

`SOUL.md` задаёт режимы, владение и формулировки списков. Этот файл называет путь. Пятый режим не добавляй.

Карта всех навыков: [references/skill-map.md](references/skill-map.md). Открой её, если запрос не садится на главный поток ниже.

`ask-matt` закрывает только семейство Matt Pocock внутри этого профиля.

## Кто пишет

Выбери один режим до главного потока. Готово: режим назван.

- **Прямой режим.** Сам исследуй, принимай архитектурные решения, меняй код и проверяй результат, когда отдельный исполнитель не даёт выигрыша. Правка уже под руками.
- **Сабагенты.** `delegate_task` для фан-аут, ревью несколькими после большого куска изменений, для исследования кодовой базы. Промпты детям пиши через `writing-for-agents`. Грузи `cto-subagent-development`.
- **Kanban.** Когда не используем cli-agent-first и используем тебя как главного исполнителя. Работа должна пережить перезапуск, пройти через несколько профилей, зависимости, блокировку или ревью, большой объём через граф тикетов. Граф ведёт `ticket-campaign-execution`.
- **Coding CLI.** Для реализации, где ты оркестратор нескольких coding cli. Грузи `cli-agent-first`: Hermes владеет целью, спецификацией, архитектурой и приёмкой. Writer-ы этого дерева: `codex`, `claude-code`, `opencode`.

**Один writer на worktree.** Параллельные исследования допустимы, параллельная запись в один worktree нет.

Если выбираешь между собой и writer-ом, сначала `cli-agent-first`.

## Главный поток: идея → ship

1. **Заостри.** Есть рабочая директория: скажи человеку набрать `/grill-with-docs`. Нет директории: грузи `grill-me`. Готово: идея достаточно остра для спеки, или следующий шаг прототип.
2. **Нужен runnable ответ?** Обход через `prototype` или `spike`. Прототип живёт в своей директории: скажи человеку `/handoff` туда и обратно. Готово: один вопрос получил одноразовый ответ. Эксперимент в продукт не мержи.
3. **Это сборка на несколько сессий?**
   - Да. Грузи `to-spec`, потом `to-tickets`. Каждый тикет вертикальный слайс с `blocked_by`. Потом один тикет за раз через `implement` или `implement-spec`. Свежий контекст на тикет.
   - Нет. Грузи `implement` или `implement-spec` в этом окне.

   В любом случае перед нетривиальной правкой грузи `blast-radius`. Бери `ponytail` и `principle-laziness-protocol`: минимальный diff, закрывающий корень задачи. Большую работу режь `principle-sequence-verifiable-units`. Если прогон останавливается на полпути, грузи `unlazy`. Закрывай `principle-prove-it-works`: доказать результат запуском, тестом или живой проверкой. Написанный код без запуска не считается результатом. Готово: у каждого критерия есть тест, живой вывод, diff, файл, URL или состояние сервиса.

Шаги 1-3 (grill, spec, tickets) держи в одном окне. Реализацию внутри шага спеки не пиши.

Если окно забивается до тикетов, читай [PHASE-BOUNDARIES.md](PHASE-BOUNDARIES.md). Грузи `principle-guard-the-context-window`.

## On-ramps

- **Сломано.** Нет жёсткого цикла: `diagnosing-bugs`. Цикл уже красный: `systematic-debugging`. Потом `principle-fix-root-causes`: исправлять причину, а не симптом. Красный тест как замок: `tdd`. Человек явно просит TDD: `/tdd-bug-fix`.
- **Сырой вход.** `triage`. Тикеты, которые уже написал `to-tickets`, не триажь.
- **Туман: не влезает в одну сессию, пути не видно.** `/wayfinder`. Wayfinder даёт решения, не код. Когда карта ясна, вливайся в `to-spec`.
- **Как устроено?** `how`. **Почему так решили?** `why`. **Вики того, что есть?** `code-wiki`. На один вопрос не грузи два из этих трёх.

## Здоровье кодовой базы

- `/improve-codebase-architecture`: сканирует живой код на мелкие модули и предлагает, что углубить. Выбранный кандидат входит в поток на `/grill-with-docs`.
- `codebase-design`: проектировать глубокие модули и ясное владение ответственностью.
- `codebase-capability-map`: что платформа умеет на самом деле, из исходников и доков.
- `setup-ts-deep-modules`: TypeScript-пакет как глубокий модуль.

## Словарь

- `principle-model-the-domain` и `domain-modeling`: сначала моделировать stateful-логику и ветвящиеся правила.
- `principle-type-system-discipline`: делать неверные состояния трудно выразимыми.
- `principle-boundary-discipline`: держать валидацию и ошибки на правильных границах.
- `principle-separate-before-serializing-shared-state`: разделять владельцев состояния до добавления блокировок.
- `codebase-design`: глубокий модуль, шов, интерфейс.

Бери их, когда проблема в словах или швах. Иначе пусть поток выше сам их подтянет.

## Ревью и релиз

На один артефакт один ревью-навык.

- Локальный diff: `code-review`.
- До коммита: `requesting-code-review`.
- GitHub PR: `github-code-review`.
- Полоса review в Kanban: `sdlc-review`.
- Дорого или уже сломалось: добавь `oracle`.
- merged / released / deployed / live-accepted: `production-release-verification`. Зелёный CI не есть live-accepted.

## Остальное дерево

GitHub, фронт, картинки, Docker, отладчики, речь и остальные имена этого профиля лежат в [references/skill-map.md](references/skill-map.md). Каждое имя из merlin-cto там есть. Если запрос не попал в поток выше, открой карту и назови один навык.

## Владение

Перед первой записью посмотри живой проект и инструкции репозитория.

В принадлежащих текущему пользователю репозиториях разрешён полный цикл. В общих, клиентских и неясных по владению допустимы чтение, локальная реализация и тесты. Внешние git-мутации требуют отдельного разрешения.

Имена пиши как во frontmatter: `to-spec`, не `mattpocock/to-spec`.

Если названного навыка нет в этом профиле, скажи так. Соседа не выдумывай.

From merllinsbeard/merlin-CTO, MIT.

More from merllinsbeard/merlin-CTO