# Product Roadmap > Используй, чтобы собрать продуктовый роадмап GitHub-репозитория — или мультирепо-продукта (org или набор репо как один продукт) — выведенный из issues и PR через граф рассуждений. Триггеры: «собери роадмап из issues/PR», «роадмап по продукту», «что в этом репо делать дальше», roadmap from repo/github, roadmap for my org, multi-repo roadmap, quick roadmap, product-roadmap. Отыгрывает мейнтейнера: проверенная почва настоящего, взвешенный бэклог как шабда, направления (bianhua), рендер graph+markdown+HTML. Композирует iskronify, intake и assembly. Нужны gh CLI и тулы iskron_*. - Skill: `iskron-ai/product-roadmap` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add iskron-ai/product-roadmap` - Raw SKILL.md: https://api.skillmd.com/api/skills/iskron-ai/product-roadmap/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: iskron-ai (https://skillmd.com/u/iskron-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/iskron-ai/product-roadmap --- # Продуктовый роадмап Преврати GitHub-репо, **которое ты сопровождаешь**, — или мультирепо-продукт — в роадмап, из которого можно действовать. Ценность (обещание solo-разработчику): овладеть контекстом, рассыпанным по кодовой базе и бэклогу issues/PR, и дать графу поднять *направления, под которыми проект действительно находится*, — а не плоский список тикетов. Ты отыгрываешь **мейнтейнера**. Конвейер: ``` рамка + бутстрап графа → моделирование текущего продукта (vartamana-почва) → сбор milestones + issues + PR → взвешивание по автору → запись в граф (шабда-интейк) → сборка (превращения: фигура-на-почве) → рендер (граф + markdown + HTML) → проверка ``` Скилл **композирует** три других: `iskronify` (понимание кодовой базы, граф/контур), `intake` (источник-независимая дисциплина шабда-интейка — хребет Шага 5) и `assembly` (различение превращений — сердце Шага 6). Сам он добавляет GitHub-**адаптер** (Шаги 3–4) и **рендер** роадмапа (Шаг 7). `references/self-checks.md` — полный проверочный гейт: Шаг 8 его прогоняет; без него не публикуй. ## Обязательства — держи их через все шаги - **Фигура на почве.** Issues/PR — это *дельта*: что люди хотят изменить; сами по себе они читаются как триаж тикетов. Сначала смоделируй существующий продукт — проверенной `vartamana`-почвой, зримо отделённой от `kalpita`/`shabda`-бэклога. Тогда каждое направление преобразует нечто реальное. - **Рычаг графа, не только его текст.** Акторы — роли с реальными рёбрами; фигура-на-почве — граф-легальная связь; ключевые потоки — эстафета `ahara`/`utpatti`; структурные риски — из собственных натяжений графа. Роадмап, который мог быть плоским markdown-списком, графом не воспользовался — а всякий рычаг, заявленный прозой, должны нести рёбра (проверка — режим claim-аудита скилла `integrity`). - **Один продукт, даже через много репо.** ОДИН фокус-контур; каждый репо — top-level-подсистема; кросс-репо-поток — заголовок. Никогда N сшитых роадмапов. Подтверди с мейнтейнером, какие репо в продукте, до моделирования. - **Читай-и-освежай, никогда не пересевай (контракт повторного прогона).** В существующий граф ориентируются и освежают его **на месте** — locate-before-write на каждой записи: обнови существующее, добавь только подлинно новое, закрой отгруженное. Отсутствующий граф *предлагается*, не создаётся молча. Выход — снимок настоящего, не межпрогонный журнал. - **Честно прежде эффектно.** Пустой или тощий бэклог констатируется, не надувается; срезы объявляются; превосходные степени — только над множествами, которые ты реально вычислил; каждый процитированный примитив проверен. Полный список стражей — `references/self-checks.md`. - **Дисциплина ссылок.** `#N` зарезервирован за реальными номерами GitHub issue/PR. Мультирепо: каждая ссылка репо-квалифицирована полным ключом (`backend#1`) — без самодельных сокращений, группировок и диапазонов, без голых `#N`. Внутренние seq графа — с не-репо-префиксом (`ISKRON#1120`). Направления — `D1`/`D2` или по имени. ## Предпосылки - `gh` CLI аутентифицирован (`gh auth status`); целевые репо доступны. - **Локальный чекаут каждого репо в объёме** (`git clone --depth 1`; приватные: `gh repo clone`). Шаг 2 читает реальную структуру кода — моделирование по одним `gh`-метаданным недослуживает продукту. - Тулы iskron_*; граф — по контракту повторного прогона выше. - Тяжёлые шаги (модель продукта, сбор, записи в граф, сборка, рендер) гоняй сабагентами; результаты между шагами передавай **файлами на диске**, возвращай короткие подтверждения + пути — большие возвраты роняют соединение. Проверяй шаг сабагента по произведённому артефакту (файлы, узлы графа), не по его отчёту; и никогда не пускай двух пишущих в граф сабагентов над одним графом параллельно — одноимённые создания сталкиваются или дедупятся поперёк дорожек. ## Шаг 1 — Рамка и бутстрап - Определи цель — один `owner/repo` или набор (org или названный мейнтейнером список) — и границу продукта одной строкой. Несколько репо: подтверди, что это один продукт, и что в объёме. - Сначала найди граф + фокус-контур (`iskron_realm` list; `iskron_orient` / `iskron_semantic_search`). Существует → ориентируйся и веди прогон как инкрементальное освежение. Отсутствует → предложи создание, создавай только по отмашке мейнтейнера. - Ровно **один фокус-контур**, названный по **продукту**, `contains` от корня — один контур даже через много репо, никогда по контуру на репо. - Чтение в духе `iskronify` настраивает граф/контур, но никогда не пиши `AGENTS.md` в репо, владение которым только отыгрываешь. ## Шаг 2 — Смоделируй текущий продукт (vartamana-почва) Пропустишь — и весь граф будет `shabda`: роадмап прочтётся как триаж бэклога, висящего в вакууме. **Читай то, что ЕСТЬ:** README + доки (собственная заявка продукта); CHANGELOG + релизы (`gh release list` — что реально отгружено, текущая версия); структура кодовой базы (top-level директории/пакеты — реальные границы подсистем, точки входа, таблицы роутов); поверхность конфигурации (флаги, env); поверхность API (endpoint'ы, CLI-команды). **Засей почву в модусе наблюдения (Pt/Va/Up)** — засвидетельствовано, действует, принято — строго отдельно от бэклога: | Что прочитал | Узел | given_as | модус | |---|---|---|---| | подсистема (crawler, indexer, auth, storage) | **holon** | — | (граница) | | существующая способность («полнотекстовый поиск») | **phenomenon** | vollzug / sachverhalt | Pt/Va/Up | | доменная сущность (Bookmark, Library, User) | **phenomenon** | bildung / sinn | Pt/Va/Up | | ключевой поток, который продукт исполняет сегодня | **kriya** | — | Pt/Va/Up | | отгруженный факт, подтверждённый релизом | phenomenon | sachverhalt | **Pm**/Va/Up | - Вкладывай подсистемы под фокус-контур (`contains`); способности/сущности живут в своей подсистеме. **Мультирепо: репозитории И ЕСТЬ top-level-подсистемы** (`attrs.repo` на каждой); внутри репо может делиться дальше. - **Правила заземления — каждый узел почвы:** цитируй реальный примитив в `attrs.source_ref` (путь модуля, конфиг-флаг, endpoint, релиз-тег; репо-квалифицированно для мультирепо). Цитируй **точный** примитив — названный символ существует по этому пути; цитируй, где поведение **реализовано**, не где читается; предпочитай **исполняемые примитивы прозе доков**; версии читай из **манифеста**, никогда из дока. `vartamana`-заявка без цитируемого примитива — догадка: понизь или выброси. Не выводи способность из feature-request'а (это бэклог, не почва). - **Объём:** подсистемы, главные доменные сущности, горстка ключевых потоков — карта, которую мейнтейнер узнаёт как «да, это мой продукт», не полный реверс-инжиниринг. - **Смоделируй акторов — сначала роль-тест (скилл writing): ролью становится только адресуемый делатель.** Два слоя, из двух разных источников, никогда не схлопнутых: - **Операторы рантайма** — кто действует на *живую* систему / кого она обслуживает. Внешний потребитель → `agantuka` 客; внутренний оператор (админ, модератор, онбординг-стафф) → `adhikarin` 能 — *активный* делатель, который отвечает и действует, никогда не пассивно-«обслуживаемая» сторона. Парк воркеров / CI / cron — **не** роль: это ⚙️ феномен (`upadhi`); повысить его, чтобы заглушить no-actor-натяжение, — ровно тот антипаттерн, о котором натяжение предупреждает. Моделируется из **почвы** (роли, которым служит код): эти люди почти никогда не пишут issues. - **Драйверы разработки** — кто авторствует *бэклог*. Мейнтейнер → `svatantra` 主 (делегированный dev-scope → `adhikarin`); залётный контрибьютор → `agantuka`. Только этот слой виден сбору. Чем уже круг контрибьюторов (solo-проект = один 主), тем сильнее реальный акторный сигнал прячется в слое рантайма. Карта с нулём рёбер — театр: прошей её к деяниям, которые она двигает, или выброси; каждая роль несёт `manifested_as`. - **Прошей ключевые потоки эстафетой:** каждая крия ключевого потока потребляет (`ahara`) феномены, которые читает-и-съедает, и производит (`utpatti`) те, что пишет, в последовательности `next` — хребет продукта как реальная эстафета (трассируется в Шаге 7) и причина, по которой структурные риски становятся вычислимыми. **Мультирепо: кросс-репо-хребет — заголовок**: крия в репо A производит *шарнирный феномен* (общая таблица БД, API-контракт, публикуемый артефакт), который потребляет крия в репо B; шарнирные феномены — граф-доказательство единого продукта. ## Шаг 3 — Собери milestones + issues + PR `gh`, JSON. **Три источника** — обязательный план мейнтейнера живёт в milestones / Projects-доске и есть сильнейший одиночный сигнал. - **Мультирепо:** собирай каждый репо в объёме, помечай элемент его репо, координированную работу поперёк репо веди одной кросс-репо-темой. - **Сначала milestones:** `gh api repos///milestones?state=open`, затем issues каждого не-«Backlog»-майлстоуна. **Читай прозу описания самого майлстоуна** — мейнтейнеры называют там цели, у которых нет issue. Проверь и Projects-доски, и закреплённые «roadmap»-issues. - **Issues:** `gh issue list --state open --limit --json number,title,body,author,authorAssociation,labels,reactionGroups,comments,milestone,createdAt,updatedAt` - **PR (открытые + недавно смерженные):** `gh pr list --state all --limit --json number,title,body,author,authorAssociation,labels,state,milestone,additions,deletions,createdAt,mergedAt` - **Отбор = ОБЪЕДИНЕНИЕ, срез объявлен, никогда молча:** (a) каждый issue с майлстоуном, (b) каждый с меткой accepted/approved/roadmap, (c) топ-N по реакциям / комментариям, (d) недавно активные N, (e) контрибьюторские PR. Одни реакции роняют уже решённую малореакционную работу — ровно то, что на роадмапе и должно быть. Не оконь PR до новейших N: долго открытый мейнтейнерский PR — высокий сигнал. Залогируй срез и что исключено. - **Пустой/тощий бэклог честен, не провал:** элементы НЕ выдумываются. Почва плюс траектория смерженных PR (`gh pr list --state merged` — что недавно строилось, в каком направлении) несут роадмап; так и скажи в рендере. - Фиксируй по элементу: номер, заголовок, обрезанное тело, **проверенный логин автора + authorAssociation (из API, никогда не выведенный)**, метки, майлстоун, вовлечённость, связанные issues, состояние. ## Шаг 4 — Взвесь по роли автора | authorAssociation | вес | заметка | |---|---|---| | OWNER / MEMBER / COLLABORATOR | высокий | голос мейнтейнера | | CONTRIBUTOR | высокий | есть смерженная работа — реален | | FIRST_TIME_CONTRIBUTOR / FIRST_TIMER | средний | суди по содержанию + вовлечённости | | NONE (issue) | средний | пользовательская нужда — держи, если содержательна | | NONE (PR без связанного issue) | низкий | залётный; впускай только при реальной вовлечённости | Повышай за вовлечённость и метки `accepted`/`roadmap`; понижай дубликаты, `wontfix`, ботов, чистые dependency-бампы. - **Членство в майлстоуне перевешивает реакции** — issue следующего релиза есть обязательная работа независимо от счёта реакций. - **Авторство проверяй из API, никогда не выводи** — приписать общинный вклад мейнтейнеру значит испортить само взвешивание, ради которого шаг существует. ## Шаг 5 — Запиши бэклог (шабда-интейк + роадмап-надстройки) **Прогони скилл `intake` над собранным** — Шаги 3–4 суть его GitHub-адаптер (они дают каждому элементу содержание / форму / провенанс / авторитет). Хребет у intake — не пересказывай: форма → тип узла; эпистемика по виду (`kalpita` для непроверенной просьбы — собственная обязательная воля мейнтейнера *не* kalpita-на-проверку); `source_kind=shabda`; семантический дедуп, locate-before-write; якорь `arose_from` к источнику; сверка и градация модуса; срез селективности (из Шага 3). **Одно сознательное расхождение с таблицей intake:** feature-request ложится здесь **феноменом** (желаемая способность, sinn/bildung) или семенной **крией** (anagata/chanda) — **не** intake-овским превращением. Направления различаются позже сборкой; Шаг 5 сеет желаемую способность, не превращение. GitHub-PR-формы, которых таблица intake не называет: | Элемент источника | Узел | |---|---| | смерженный контрибьюторский PR | **kriya** (деяние сделано) или произведённый им феномен | | открытый контрибьюторский PR | **kriya** (anagata) — работа в полёте | | маловесный залётный PR | пропустить — или низкоприоритетный феномен с пометкой | **Роадмап-надстройки, которых intake не несёт:** - **Якори каждый элемент к его подсистеме** (`context` / `vimarsha_of` к контуру подсистемы из Шага 2 или к способности, которую он расширяет) — бэклог кластеризуется по подсистемам. Элемент без дома — сигнал: недомоделированная почва (вернись в Шаг 2) или подлинно новая почва — скажи, что именно. Кросс-репо-тема якорится к фокус-контуру и линкует каждую задетую подсистему. - **Дедуплицируй против ПОЧВЫ, не только бэклога:** просьба, совпадающая с отгруженной способностью, — *дельта*: формулируй «улучшить X», никогда «добавить X»; если базовая форма уже отгружена — переформулируй в реальный оставшийся зазор. Назвать уже отгруженное как to-build — подорвать мастерство продукта. Неси GitHub-реф (номер, автор, вес) в `attrs` для трассируемости рендера. - **Ставь модус момента честно:** закоммичено майлстоуном → `adhimoksha`; спекулятивная просьба → `chanda`; проектируемая работа → `anagata`; почва остаётся `vartamana`/`pramanita`. Моделируй поле, как оно стоит сейчас; никогда не пере-переходи заранее. - **Дай каждой бэклог-крие её ведущую роль как `actor`** — dev-драйверскую роль проверенного автора, никогда рантайм-актора. Именно это делает «кто владеет направлением» ребром графа, а не прозаическим ярлыком. ## Шаг 6 — Сборка (различи направления) Прогони скилл `assembly` над засеянным графом: ориентация поля → триаж свободных вимарш → различение **превращений** → имя + телос → anga драйверов → порядок `anantara`. Играя владельца, принимай имена/телосы inline, но держи дисциплину: имя читается человеком-владельцем; телос — *качество назначения*; никогда превращение на одну вимаршу; риски остаются рисками. - **Освежающие прогоны сверяют, не переразличают с нуля:** обнови телос / anga / порядок направлений, которые держатся; направление добавляй только для подлинно новой темы; закрой (visarjana) те, чья работа отгружена. Никогда — направление-близнец. - **Фигура-на-почве как реальная стрелка:** ведущая крия направления достигает способности почвы через `upadhi`/`context` — никогда буквальным `ahara` от превращения (граф запрещает). Направление, чьи ведущие крии не касаются никакой способности почвы, плавает: либо подлинно новая почва (скажи явно), либо знак недомоделированного Шага 2 (иди досей способность). - **Подними структурные риски из собственных натяжений графа** (`iskron_orient(lens="tensions")`): способность без производящего потока, relay-gap эстафеты, деяние без роли — самодиагноз графа, отличный от рисков из бэклога; плоский список тикетов структурно не может их произвести. **Мультирепо: кросс-репо dead-recipe или relay-gap — находка высшей ценности.** Чистые артефакты моделирования чини на месте, а не рапортуй. - **Атрибутируй каждое направление по двум осям:** его **драйвер** (ведёт мейнтейнер и закоммичено / ведёт контрибьютор и ждёт ревью / просит сообщество и без владельца — из ролей сбора) и его **рантайм-цель** (кому служит изменённая система: внешний потребитель 客 или внутренний оператор 能 — из почвы). Не схлопывай вторую в первую — жди операторских направлений (админка, онбординг стаффа) рядом с потребительскими; на solo-продукте ось драйвера плоская, и направления реально различаются рантайм-целью. Владение — **факт графа**: anga-крии направления несут `actor` → роль-драйвера, иначе ярлык понижается до «выведено». - **Когерентная высокосигнальная тема сообщества заслуживает направления** даже без закоммиченной работы — топ-реакционные issues есть роадмап-сигнал; сознательная отсрочка помечается «отложено, но реально», никогда не роняется молча. - **Майлстоуны целиком:** закоммиченный ближний майлстоун — собственное направление, перечисляющее **каждый** открытый issue майлстоуна; топ-N ранжируй как гейтящие, но назови общее число и что остальное остаётся; никогда телос, заявляющий завершение по частичному списку. Перечисли каждый ОТКРЫТЫЙ майлстоун; catch-all «Backlog» — целиком или явно «сэмплировано». Закоммиченный мейнтейнерский issue из майлстоуна никогда не уступает место менее сигнальному по той же теме. - **Каждому ребру `anantara` — свидетельство**: issue/PR или заявление мейнтейнера, его устанавливающее; собственный архитектурный вывод помечай эвристикой (`kalpita`) и хеджируй в рендере. **Не пере-называй «blocked»:** направление со своей работой в полёте — *sequenced-after*, не заблокировано. - **Именуй направления на языке аудитории репо** — они станут заголовками роадмапа, которые читает владелец. ## Шаг 7 — Рендер (веди собранной картиной) Роадмап ведёт собранной кросс-репо-картиной и тем, что нашёл граф, — дифференцирующая ценность на первом экране, не закопана. Три артефакта: 1. **Граф** — `iskron_orient(lens="bianhua")`; HTML рендерит его визуальным граф-видом (хребет + направления в порядке зависимостей + флаги структурных рисков). 2. **`roadmap.md`**, в этом порядке: - **«Продукт, собранный»** — подсистемы (по одной на репо) + кросс-репо-хребет, одно-два предложения; реальная картина из ВСЕХ источников. - **«Что нашёл граф»** — структурные риски из натяжений, каждый с помеченным швом. Веди ими. - **«Следующие 3 хода»** — список действий на 3–5 строк. - **«Что этот продукт сегодня»** — почва, каждая строка процитирована к примитиву; доказывает мастерство продукта. - **«Как это работает сегодня»** — одна ключевая эстафета, протрассированная насквозь (`lens="trace"`): хребет одним проходом. - **Направления** в порядке `anantara`; по направлению: расширяемая способность, телос, ведущие элементы (дословные заголовки + рефы + вес автора), роль-драйвер **и** рантайм-цель (客/能), anga (ведущий вопрос), открытые риски, что разблокирует. - **«Чтение поля»** — роли-драйверы (+ рантайм-цели), структурные риски, карта фигура-на-почве. Написано для мейнтейнера, не методолога: глоссируй каждый термин графа по-простому при первом употреблении. - **«Аудит сигнала»** — топ по реакциям и комментариям среди ОТКРЫТЫХ issues (числа + основание запроса), каждый помечен included / deferred / out-of-scope, с названным порогом вовлечённости. Тощий бэклог → таблица траектории (счётчики смерженных PR по репо + темы). Точные числа, никогда оценки. 3. **`roadmap.html`** — страницу НЕ пиши руками. Скопируй `references/roadmap-template.html` и замени ТОЛЬКО его data-объект `ROADMAP` (схема задокументирована в начале `