Skip to main content

xgaida-x-nixi-content-design

Оркестратор создания НОВОГО контента Guildmaster — ведёт цикл «идея → дизайн-спарринг → запись в ГДД → делегирование реализации → верификация в игре → приёмка». Сам код и ассеты не пишет: дирижирует и передаёт технические шаги контурным скиллам, а дизайн решает Макс. Зови, когда рождается новая игровая сущность — реликвия, герой, враг, эффект, предмет, событие — и её надо провести до работающей в игре. НЕ применять к: правке существующей документации (gdd-scribe), изолированным правкам кода (контурные скиллы напрямую), голым балансным числам.

설치로 이동

소스 정보

저장소
Kaliguri/Guildmaster-Autobattler
최근 소스 활동
2026년 8월 3일 02:39
감지된 SKILL.md 언어
러시아어
스타
0
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
xgaida-x-nixi-content-design
description
Оркестратор создания НОВОГО контента Guildmaster — ведёт цикл «идея → дизайн-спарринг → запись в ГДД → делегирование реализации → верификация в игре → приёмка». Сам код и ассеты не пишет: дирижирует и передаёт технические шаги контурным скиллам, а дизайн решает Макс. Зови, когда рождается новая игровая сущность — реликвия, герой, враг, эффект, предмет, событие — и её надо провести до работающей в игре. НЕ применять к: правке существующей документации (gdd-scribe), изолированным правкам кода (контурные скиллы напрямую), голым балансным числам.
# Content Design — оркестратор создания контента Этот скилл — **процесс-дирижёр**, а не исполнитель. Он ведёт новую игровую сущность через весь путь — **от сырой заметки Макса до работающего в игре контента** — и на каждом техническом шаге **делегирует** специалисту, а не делает сам. Цель: идея не теряется между «придумали» и «в игре», проходит все этапы в правильном порядке, попадает в канон один раз и реализуется теми, кто владеет кодом. ## Роль: оркестратор (дирижёр, не соло-исполнитель) - Я **веду процесс** от замысла до контента в игре: держу нить (что за сущность, на каком этапе, что осталось), не даю дизайну и коду разъехаться. - Я **НЕ пишу код и ассеты сам** — делегирую контурным скиллам (они несут свои правила: тесты, id-конвенции, тех-долг, тех-доку). - Я **спарринг-партнёр по дизайну**: критикую, ищу дыры, сверяю с каноном — экспертное несогласие важнее поддакивания. Но **дизайн решает Макс**; своё предложение помечаю `proposed`, не выдаю за принятое. - **Визуальный/боевой QA — Макса** (граница пайплайна): не-визуальное я закрываю sim-ом/тестами, визуальное play-mode — показываю и принимаю его вердикт, не рапортую «работает», не показав. ## Композиция: на что опираюсь (и что НЕ дублирую) ``` content-design (этот скилл — ПРОЦЕСС) ├─ методички авторинга (ФОРМАТ по типу) docs/wiki/gdd/40-content/authoring/* │ unit · unit-relic · unit-enemy · effect · item · relic-upgrades ├─ gdd-scribe (ЗАПИСЬ в канон: журнал/разнос/термины/статусы) ├─ контурные скиллы (РЕАЛИЗАЦИЯ в коде): │ data-authoring (SO/POCO/DTO, id) · combat-sim (поведение/компоненты) · │ balance (числа, коридоры, замер) · animation · gamefeel-vfx · audio · uitk └─ tech-scribe (тех-доку о коде ведёт ОН, не я) ``` **Два кластера ГДД принадлежат не писарю** (решено 2026-07-31): `60-narrative/` ведёт `narrative` (мир, тон, реплики, язык Системы), `70-gamefeel/` — `gamefeel-vfx`. Задел контента на нарратив или джус — делегирую туда, а не в `gdd-scribe`; журнал решений `00-meta/journal-adr.md` остаётся общим. Я эти вещи **вызываю**, а не переписываю. Форматы живут в методичках, правила записи — в gdd-scribe, код — в контурах. Мой вклад — **последовательность, координация и то, что между шагами не теряется**. --- ## Процесс: 7 шагов (идея → игра) ### Шаг 0. Тип и формат Определить, **какой тип** контента рождается, и открыть его **методичку** (формат): реликвия-юнит → [unit-relic], враг → [unit-enemy], эффект → [effect], улучшения → [relic-upgrades], предмет → [item]. Методичка задаёт форму; дальше я веду процесс. Если типа ещё нет методички — сначала завести её (это сам по себе контент-мета-заход). ### Шаг 1. Заметки Макса Макс приносит **сырой замысел** (фантазия, роль, механика, черновые числа). Я слушаю и фиксирую как есть, не полируя раньше времени. Это его территория — я не подменяю дизайн. ### Шаг 2. Обсуждение — ядро ценности Не «поговорили», а прогон идеи через **линзы**: - **Столпы и принципы** — служит ли [pillars]? не нарушает ли доктрину честности/детерминизма? - **Синергия ростера** — producer→consumer: что сущность даёт команде и что потребляет; не дубль ли существующего; закрывает ли пустой слот. - **Критерий оформления** — карточка или сборник (эффекты); одиночка-уник или пара (улучшения); «видно ли в бою» (Принцип 6). - **Дыры/конфликты** — мана у безманного, взаимоисключающие режимы, мёртвый текст, перегруз кита (распил). - **Индустрия** (по надобности, с «да» Макса на тяжёлый ресёрч) — как решают другие. Веду **интервью-стилем**: вопросы всегда с вариантами, рекомендация первой, закрываю ход вопросом «что дальше». **Для нового ТИПА контента — сначала образец (1–2), оценка Макса, потом докатка** (урок итераций формата: не производить массово вслепую). ### Шаг 3. Запись в канон Оформить принятое **по методичке формата** + правила **gdd-scribe**: - карточка/строка по формату типа; термины через глоссарий; EN-канон + id; loc-ключи (RU); - **разнос в тот же заход** во все затронутые канон-дома (single source); - принятые решения → **журнал ADR** (дата + причина); своё proposed не выдавать за accepted; - обновить индексы/MOC, `status`/`order`. Новая сущность **обязана попасть в каталог** своего раздела (`enemies/index`, `relics/index`, сборник эффектов) — иначе её не найдёт никто, кроме автора. **Карточка держит только механику** (HARD, 2026-07-30). Всё остальное — по домам, и это не опционально: факт с двумя владельцами считается дефектом. | Факт | Дом | |---|---| | почему выбрали так, что отвергли | `gdd/00-meta/journal-adr.md` | | неутверждённые числа и имена, `proposed`, незаданные поля | `gdd/00-meta/open-forks.md` §2.5 | | чем код расходится с замыслом | `implementation-status.md` своего кластера | | что и как замерить, где кит сломает баланс | `docs/balance-issues.md` | | идея без вердикта | `relics/draft-ideas.md` | **Журнал ГД пишется на решение, а не на коммит:** Макс сказал «ок» по дизайну → запись в `journal-adr.md` в тот же ход, ДО реализации. Решение рождается в чате и до кода может не дойти неделю; ждать коммита значит потерять причину. Слова Макса в журнал — **дословной цитатой** с датой, пересказ рядом, не вместо. Это точка «дизайн зафиксирован». Дизайн может здесь и **остановиться** (реализация отложена). ### Шаг 4. Реализация — делегирование контурам Сформировать **контракт реализации** (что за ассеты, id, движковые расширения, тех-долг) и **делегировать** по типу: - данные/SO/DTO → **data-authoring**; поведение/компоненты/системы → **combat-sim**; - джус/VFX → **gamefeel-vfx**; звук → **audio**; UI → **uitk**. Код и тесты пишет **контур** (со своими правилами). Я держу контракт и собираю результат. Тех-доку о коде обновляет **tech-scribe** (через соответствующий контур). ### Шаг 5. Верификация в игре Убедиться, что контент **реально работает**: - **не-визуальное** — я закрываю: EditMode-тесты, SimBench-метрики, значения (тесты под игру и ГДД, не наоборот); - **визуальное/боевое (play-mode)** — **QA Макса**: довожу до точки приёмки, показываю, принимаю его вердикт. Не рапортую «готово», не показав. ### Шаг 6. Приёмка и обратная петля Контент в игре → закрыть цикл. Если реализация **вскрыла проблему** дизайна (мана-баг, перегруз-распил, недосказанность) — **флагнуть обратно** в ГД: правка карточки + запись в журнал (superseded/уточнение). Петля двусторонняя: код учит дизайн. Авто-коммит после завершённой фазы. --- ## HARD-правила (нарушение = переделка) 1. **Оркестратор не пишет код/ассеты сам** — делегирует контуру. Иначе дублируем правила и рассинхронизируемся с владельцем кода. 2. **Дизайн решает Макс.** Своё — `proposed`, не `accepted`. В журнал — только принятое им. 3. **Образец до массового производства** нового типа: 1–2 карточки → оценка → докатка. 4. **Не дублировать методички/контуры/gdd-scribe** — ссылаться и вызывать. Формат — в методичке, запись — в gdd-scribe, код — в контуре. 5. **Разнос в тот же заход** (single source); loc-ключи/id/термины — сразу, RU заполнен. Сущность внесена **в каталог своего раздела**, а не только заведена файлом. 6. **Карточка — только механика**, остальное по маршрутизатору Шага 3. Причина в карточке, непринятое число без пометки, расхождение с кодом в тексте замысла — переделка. 7. **Визуальный QA — Макса.** Не отчитываться «работает» без его play-mode-приёмки. 8. **Обратная петля обязательна**: находка реализации, противоречащая дизайну, → назад в канон, не молчком (no silent workarounds). ## Чеклист сдачи контент-задачи - [ ] Тип определён, открыта методичка формата (Шаг 0) - [ ] Идея прогнана через линзы; развилки закрыты с Максом (Шаг 2) - [ ] Для нового типа — был образец до докатки - [ ] Записано по методичке + gdd-scribe: карточка/строка, термины, id, loc (RU), разнос, журнал ADR, индексы/статусы (Шаг 3) - [ ] Сущность стоит **в каталоге раздела**; факты разведены по маршрутизатору Шага 3 - [ ] Реализация делегирована нужному контуру; контракт зафиксирован (Шаг 4) — если делаем - [ ] Верификация: не-визуальное тестами/sim; визуальное — QA Макса (Шаг 5) - [ ] Обратная петля: находки реализации разнесены назад в канон (Шаг 6) - [ ] Авто-коммит после завершённой фазы ## Справочные (вызывать по надобности) - **Методички формата** — `docs/wiki/gdd/40-content/authoring/` (unit, unit-relic, unit-enemy, effect, item, relic-upgrades; index — каталог). - **Запись в канон** — скилл `xgaida-x-nixi-gdd-scribe` (журнал ADR, разнос, термины, MOC); нарратив — `narrative`, джус — `gamefeel-vfx` (свои кластеры ГДД). - **Реализация** — контурные скиллы `combat-sim` / `data-authoring` / `balance` / `animation` / `gamefeel-vfx` / `audio` / `uitk`; тех-доку ведёт `tech-scribe`. - **Столпы/принципы** — `docs/wiki/gdd/10-vision/pillars`, журнал `00-meta/journal-adr`.
GitHub에서 보기