# Practice > Свободная тренировка — открытая задача области или короткий drill, без учебного плана. Триггерься на "/practice", "хочу потренироваться", "дай задачу", "дай челлендж", "порешаем что-нибудь", "challenge", "давай порешаем". Читает progress/competencies.json и mistakes_log чтобы подобрать задачу, которая бьёт в пробелы. Два формата: короткий drill (5-10 мин) или открытая задача (для доменов с постановкой задачи — по фазам с тайм-боксами). Не связано с curriculum. - Skill: `infinity-kim/practice` (Agent Skill) - Install (CLI): `npx skillmds@latest add infinity-kim/practice` - Raw SKILL.md: https://api.skillmd.com/api/skills/infinity-kim/practice/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: infinity-kim (https://skillmd.com/u/infinity-kim) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/infinity-kim/practice --- # Свободная тренировка Практика — это не урок. Урок добавляет **новое**, практика закрепляет **уже известное** через применение в свежем контексте (interleaving, §1.4 R2). «Применить» значит решить задачу области вслух — оценивается **процесс рассуждения**, а не артефакт. ## Когда использовать practice vs learn - **`/learn`** — пройти следующую тему из curriculum (вводит новое) - **`/practice`** — потренировать уже знакомое на новой задаче - **`/quiz`** — короткий retrieval practice на факты области Practice — для ситуаций, когда ученик хочет «просто порешать задачу» без большого фрейма урока. ## Два формата ### Формат A — короткий drill (5-10 мин) Короткое сфокусированное задание на один навык. Такой навык требует повторений (§4.3 R2) и идеален для разогрева. > **Задача:** одна маленькая задача-прикидка/применение. > > **Что делаем:** только то, что влияет на решение. Не считай/не разбирай то, что на решение не влияет. > > **Критерий:** результат с нужным порядком/направлением + один вывод для дела. Drill бьёт по конкретной базовой компетенции. Опорный материал — в доменном контентном скилле области. Пример drill (область System Design) — estimation: > **Задача:** прикинь, сколько storage в год нужно сервису коротких ссылок, если создаётся 100M ссылок/день, средняя запись — 500 байт. > **Что считаем:** только метрики, влияющие на дизайн (writes/sec, storage/год, нужен ли шардинг). > **Критерий:** число с порядком величины + один вывод для дизайна («влезет в один Postgres / нужен шардинг»). Бьёт по компетенции `estimation_skill`. Опорные числа — в `estimation/references/`. ### Формат B — открытая задача (опционально, для доменов с постановкой задачи) Если область предполагает развёрнутую «постановку задачи» (от требований до решения), полезен формат с **фазами и тайм-боксами** (§2.1 R2). Подача — **сократическая**: ученик начинает с наивного решения, проблемы всплывают по одной, он дорабатывает (§2.3 R2). Не вываливай условия и решение сразу. Если в области нет естественного деления на фазы — пропусти этот формат, используй Формат A или свободную задачу. Пример фазовой структуры (область System Design — по структуре SD-интервью): | Фаза | Тайм-бокс | Что делает ученик | |---|---|---| | **Requirements** | ~5 мин | Функц. (топ-3) + нефункц. (квантифицированные: «лента < 200мс»), выбор приоритета по CAP | | **Estimation** | ~3-5 мин | RPS, storage, read/write ratio — на салфетке | | **High-level design** | ~10-15 мин | Компонентная схема. «Не наслаивай сложность рано» | | **Deep dive** | ~10 мин | Итерация по нефункц. требованиям, поиск bottleneck/SPOF | | **Trade-offs** | ~5 мин | Разбор: какие развилки были, что выбрал и почему | Адаптируй тайм-боксы под доступное время — можно прогнать только первые фазы, если ученик хочет короткую сессию. ## Шаг 1: Выбор задачи Прочитай `progress/competencies.json` и `progress/mistakes_log.json`. Выбирай по приоритету: 1. Есть компетенция с `p_known < 0.4` и `observations >= 2` → задача, которая её нагружает (см. таблицу-пример ниже — какая задача бьёт по какой компетенции) 2. Есть свежая ошибка в mistakes_log (за последние 3 сессии) → задача на ту же тему 3. Иначе — задача из текущего уровня ученика, **от простого к сложному** Пример соответствия «компетенция → задача» (область System Design): | Пробел (низкий `p_known`) | Подходящая задача / формат | |---|---| | `estimation_skill` | drill estimation (формат A) | | `requirements_clarification` | любая открытая система, фокус на фазе requirements | | `data_modeling` | «спроектируй хранилище для мессенджера», «лента новостей» | | `scalability_thinking` | «rate limiter», «URL shortener на 100M/день» | | `failure_thinking` | «платёжный сервис» (что при отказе?), «выдержит ли при падении ноды?» | | `tradeoff_reasoning` | любая система с явной развилкой (кеш? очередь? SQL vs NoSQL?) | ## Шаг 2: Банк задач (генерируется, не статичен) Задачи **генерируются** по запросу, не хранятся в файле: состояние ученика (BKT, mistakes, scaffolding) меняется, и задача должна это учитывать. Держи градацию **от простого к сложному**. Пример банка задач (область System Design) — открытые системы по сложности: | Сложность | Система | |---|---| | Простая | URL shortener, pastebin, rate limiter, counter сервис | | Средняя | news feed, чат 1-на-1, notification service, file storage (Dropbox-lite) | | Сложная | мессенджер с группами, search/autocomplete, ride-sharing matching, video streaming | Начинай ученика с простого. Сложную бери, только когда базовые шаги он проходит сам (proactiveness — главный маркер уровня, §3.2 R2). ## Шаг 3: Сократическая подача и помощь Скилл `scaffolding` определяет, сколько помогать. Два важных момента для practice: - **Не вываливай решение.** Веди вопросами: «С чего начнём?» → ждёшь первый шаг → уточняющий вопрос → следующий шаг → «Где это упрётся при усложнении?» Наивное решение → проблема → доработка, пока выбор не станет логичным выводом (§2.3 R2). - **`young_male_26` — предлагай помощь проактивно.** Из-за help-avoidance он не попросит `/hint`, даже застряв. На сигналах застревания (пауза, «хм», повтор одной развилки) сам предложи направление — мягко, как опцию. Калибруй overconfidence: его «всё понятно» проверяй вопросом про невыбранный компромисс. Если ученик застрял — эскалация подсказок из `feedback`/`hint` (вопрос → направление → worked example → прямая помощь). ## Шаг 4: После решения Независимо от того, насколько «хорош» результат — спроси (мета-рефлексия, помогает увидеть прогресс): - «Какая развилка была самой сложной — и почему ты выбрал именно этот путь?» - «Что бы ты уточнил в самом начале, если бы делал это снова?» Затем дай фидбек по `feedback`: процессная похвала за конкретный ход + один сократический вопрос про невыбранный/необоснованный компромисс. Не «правильно/неправильно». Обнови: - `profile.json`: `xp += 150` (практика даёт больше XP, чем урок — это retrieval, §1 R2). XP — информация о прорыве, не награда за задачу. - `mistakes_log.json`: если всплыла типичная ошибка области — добавь запись - `competencies.json`: если задача нагружала компетенцию — обнови observations (через `diagnostics`) ## Правила - **Тайм-бокс.** Для формата A — 10 минут. Для формата B держи фазы по времени, не давай зависнуть на одной фазе. «Время, давай зафиксируем и пойдём дальше». - **Не превращай в урок.** Practice — это **применение**, не **изучение**. Если ученик вообще не знает, как подступиться к задаче → это не practice, а learn. Мягко переключи. - **Давай выбор.** Нет настроения на одну задачу — предложи 2-3 альтернативы разной сложности (автономия, §1 R2). - **Не компенсируй слабое решение лекцией.** Если задача далась тяжело — разобрали один компромисс, пошли дальше. Не разворачивай «а теперь я расскажу, как правильно» — во многих областях нет единственно «правильного». - **Первый вариант всегда наивный** — даже у эксперта. Нормализуй это до разбора (§ нормализация ошибок в `feedback`).