# Interview Me

> Use when требования расплывчаты, противоречат друг другу или короче, чем заслуживает задача — перед тем как ставить acceptance criteria и делегировать реализацию. Триггерные фразы: "добавь оффлайн", "сделай синхронизацию", "разберись сам", одна-две фразы на фичу, которая явно больше одной фразы, противоречие между тем, что просит пользователь, и тем, что уже делает код. Структурированный опрос малыми пачками вопросов вместо накопления предположений: поднимает уверенность в требованиях до ~95%, прежде чем main-сессия сформулирует задачу профильному агенту (`kotlin-engineer`, `compose-builder`, `swift-engineer`, `swiftui-builder`, `guide-android-builder` и т.д.) или бизнес-аналитику `business-analyst`. Не используй, если задача маленькая и однозначная (переименование, точечный багфикс с понятной причиной) или acceptance criteria уже явно заданы пользователем/issue — в этом случае сразу делегируй по `rules/workflow.md`.

- Skill: `michaelbel/interview-me` (Agent Skill)
- Install (CLI): `npx skillmds@latest add michaelbel/interview-me`
- Raw SKILL.md: https://api.skillmd.com/api/skills/michaelbel/interview-me/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: michaelbel (https://skillmd.com/u/michaelbel)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/michaelbel/interview-me

---


# Интервью с пользователем

## Обзор

Самый дешёвый баг — тот, что не написан, потому что нужный вопрос задали до реализации, а не после
код-ревью. Этот skill заменяет накопление предположений структурированным интервью: задавай
целевые вопросы малыми пачками, скармливай каждый ответ следующему раунду и останавливайся только
тогда, когда acceptance criteria можно написать не выдумывая. Он выносит разговор, который иначе
случится как rework после ревью, в начало — до того как задача уйдёт профильному агенту.

## Когда использовать

- Запрос на одну-две фразы описывает то, что явно больше одной-двух фраз ("добавь оффлайн-режим").
- Требования противоречат друг другу или текущему поведению приложения/бэкенда.
- Возможны несколько трактовок, и ошибиться в выборе дорого (миграция схемы, публичный контракт,
  необратимое решение — см. также `doubt-driven-development`, если он у вас появится, либо сразу
  `documentation-and-adrs`-практику для фиксации решения).
- Перед тем как отдать задачу `business-analyst` на проверку acceptance criteria, или профильному
  инженерному агенту на реализацию.
- Пользователь говорит в духе "ты понимаешь, о чём я" — не понимаешь.

**Не используй, если:** задача маленькая и однозначная (rename, точечный багфикс с понятной
причиной), или acceptance criteria уже заданы явно пользователем/issue/спекой — тогда сразу
делегируй по `rules/workflow.md`. Интервью не должно быть предлогом не начинать работу.

## Процесс

### Шаг 1. Зафиксируй, что уже понятно

Прежде чем задавать вопросы, письменно зафиксируй текущее понимание и уровень уверенности:

```markdown
## Понимание: оффлайн-очередь мутаций задач
- Пользователь видит закэшированные задачи офлайн — уверенно (сказано явно)
- Пользователь может СОЗДАВАТЬ задачи офлайн — предположение, не сказано
- Стратегия разрешения конфликтов — неизвестно
- Триггер синка (при открытии приложения? WorkManager?) — неизвестно
Уверенность: ~40%
```

Строки "предположение" и "неизвестно" становятся списком вопросов. Если таких строк не возникло —
интервью не требовалось.

### Шаг 2. Задавай вопросы малыми целевыми пачками

3–5 вопросов за раунд, самое дорогое решение — первым. Один вопрос — одно решение, конкретные
варианты вместо открытых формулировок:

```markdown
1. Если задачу отредактировали офлайн на двух устройствах, что побеждает при синке — последняя
   запись или конфликт показывается пользователю?
2. Создание задач должно работать офлайн, или в v1 офлайн — только чтение?
3. Синк по открытию приложения или фоновый через WorkManager (с учётом Doze/App Standby)?
4. Что происходит с несинканными офлайн-изменениями при логауте?
```

Правила вопросов:
- Спрашивай про поведение, которое видит пользователь, а не про реализацию ("что побеждает?", а не
  "OT или CRDT?").
- Предлагай дефолт: "Предлагаю last-write-wins для v1 — годится?" — легко подтвердить, легко
  поправить.
- Поднимай платформенные реалии, которые заказчик может не знать: фоновые ограничения (Doze,
  WorkManager retry/backoff), KMP-паритет поведения между Android и iOS (если фича общая для
  `shared/`), реконнект realtime-канала (SignalR) после разрыва сети, требования Google
  Play/App Store review.
- Никогда не переспрашивай то, что уже закрыл предыдущий ответ.

### Шаг 3. Скорми ответы обратно и итерируй

После каждого раунда обнови документ понимания — перескажи ответы своими словами, отметь закрытые
пункты, дай новым вопросам возникнуть из ответов:

```markdown
Закрыто: офлайн-чтение и создание в v1; last-write-wins; синк по открытию приложения.
Новый вопрос из "last-write-wins": тихая потеря данных при конфликте — ок, или логировать для
саппорта?
Уверенность: ~80%
```

### Шаг 4. Останавливайся на ~95% и передавай дальше

Выходи из интервью, когда каждый acceptance criterion можно написать не выдумывая. Идеальная
уверенность — не цель; оставшиеся ~5% фиксируются как явные предположения:

```markdown
Предположения (продолжаем, пока не поправят):
- Конфликты достаточно редки, чтобы тихий last-write-wins был приемлем для v1.
```

Передай результат дальше по `rules/workflow.md`: если решение архитектурное или необратимое —
сначала `business-analyst` на проверку с продуктовой стороны и/или ADR по
`documentation-and-adrs`-практике; реализацию отдай профильному агенту (`kotlin-engineer`,
`compose-builder`, `swift-engineer`, `swiftui-builder`) вместе с документом понимания как частью
постановки задачи — не как отдельное сообщение, которое потеряется в чате. Для оффлайн-очереди
из примера выше следующий шаг обычно — `create-offline-outbox`.

## Типичные отговорки

| Отговорка | Почему не работает |
|---|---|
| "Сделаю разумные предположения и отмечу их" | Десять сложенных "разумных" предположений дают неразумный результат. Предположения — для последних 5%, а не для первых 50%. |
| "Задавать вопросы — выглядит неуверенно" | Реализация не того выглядит хуже. Хорошие вопросы демонстрируют понимание задачи. |
| "Пользователь занят, не буду дёргать" | Пять минут его времени сейчас дешевле недели переделки и более тяжёлого разговора потом. |
| "Разберусь по ходу реализации" | Структурные решения (модель офлайна, стратегия конфликтов) дёшево менять в разговоре и дорого — в коде. |
| "Один большой список вопросов эффективнее" | Двадцать вопросов разом просто пролистают. Маленькие пачки получают настоящие ответы, а ответы меняют следующие вопросы. |
| "Передам неопределённость профильному агенту, он разберётся по контексту" | Профильный агент реализует, а не уточняет продуктовые решения — по `rules/workflow.md` он получает уже поставленную задачу. Нерешённая неоднозначность в постановке становится неверной реализацией, а не вопросом. |

## Красные флаги

- Реализация начата, а документ понимания всё ещё содержит "неизвестно" по ключевому поведению.
- Вопросы про детали реализации, а не про видимое пользователю поведение.
- Задача делегирована профильному агенту с нерешённой неоднозначностью вместо того, чтобы закрыть
  её в main-сессии до делегирования.
- Один и тот же вопрос задан дважды, потому что ответ не зафиксировали.
- Ноль зафиксированных предположений в задаче, где неоднозначность точно была (значит, их сделали
  молча).
- Стена из двадцати вопросов одним сообщением.
- "Интервью" продолжается после того, как acceptance criteria уже можно написать — это уже
  затягивание, а не уточнение.

## Чек-лист

- [ ] Документ понимания существует и явно делит пункты на подтверждённые / предположенные /
      неизвестные.
- [ ] Каждое видимое пользователю поведение закрыто ответом или явным предположением — без тихих
      пробелов.
- [ ] Оставшиеся предположения записаны и показаны пользователю, а не оставлены только в голове
      агента.
- [ ] Acceptance criteria можно сформулировать, ничего не выдумывая.
- [ ] Платформенные ограничения стека (Doze/WorkManager, KMP-паритет Android/iOS, реконнект
      realtime, Play/App Store review) подняты там, где релевантны.
- [ ] Результат передан дальше как часть постановки задачи для `business-analyst` и/или
      профильного агента — по `rules/workflow.md`, а не потерян в чате.