Что НЕЛЬЗЯ объединять: Mantine, Microstructure, Kanchi и другие ловушки нейминга — Блог
$ cat chto-nelzya-obedinyat-mantine-microstructure-kanchi.md

Что НЕЛЬЗЯ объединять: Mantine, Microstructure, Kanchi и другие ловушки нейминга

🤖 AI и машинное обучение
#Skills #Naming #Mantine #Microstructure #Kanchi #CEX vs DEX

Что НЕЛЬЗЯ объединять: Mantine, Microstructure, Kanchi и другие ловушки нейминга

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

Контекст: ловушка «похожее имя = дубликат»

При анализе 210 скиллов самая частая ошибка — решить, что похожие имена означают дублирование. На самом деле за похожими именами могут скрываться:

  1. Разные ниши одной темы (Mantine combobox vs Mantine form)
  2. Разные стадии pipeline’а (Kanchi sop vs Kanchi review)
  3. Разные рынки/парадигмы (CEX microstructure vs DEX microstructure)
  4. Singular vs plural (custom-indicator vs custom-indicators)
  5. Разные уровни абстракции (vortex vs vortex-pro)

Разберём каждую категорию с конкретикой.

Ловушка 1: Mantine — три разных подсистемы одной библиотеки

mantine-combobox       — Select/Autocomplete/Multi-select (useCombobox hook)
mantine-custom-components — factory(), Styles API, theme integration
mantine-form           — @mantine/form (отдельный npm-пакет!)

Почему НЕ объединять

СкиллAPI-поверхностьРазмерАртефакт
mantine-comboboxuseCombobox hook + <Combobox.Target>, <Combobox.Option>, <Combobox.Dropdown>73 строки + 2 references—
mantine-custom-componentsfactory(), polymorphicFactory(), useStyles, useProps, createVarsResolver112 строк + 2 references—
mantine-formuseForm, getInputProps, form.onSubmit, insertListItem, валидация98 строк + 2 references—

Критический факт: @mantine/form — это отдельный npm-пакет, не часть @mantine/core. Он поставляется отдельно, у него свой repository, своя команда maintainer’ов. Группировать его с core-примитивами = врать про архитектуру библиотеки.

Все три скилла ссылаются на одну и ту же структуру references (api.md + patterns.md), но это нормальная конвенция внутри одной экосистемы Mantine. Они не дублируют друг друга — они покрывают три разных API-поверхности.

Что выиграем от объединения

Ничего.

Что потеряем

  • Резко вырастет размер SKILL.md (300+ строк — тяжело для токенов, сложнее навигация)
  • Потеряется progressive disclosure: сейчас пользователь получает только то, что ему нужно (combobox, или form, или factory)
  • Сломается автоматический matching по description (он сейчас точечный: useCombobox / useForm / factory())

Вердикт: KEEP SEPARATE. Это три разных подсистемы одной библиотеки, объединение разрушит фокус.

Ловушка 2: Kanchi Dividend — три стадии одной методологии

kanchi-dividend-sop              — screening → 5 шагов Kanchi → entry plan
kanchi-dividend-review-monitor   — post-entry: T1-T5 триггеры, OK/WARN/REVIEW
kanchi-dividend-us-tax-accounting — qualified/ordinary, IRA/taxable placement

Почему НЕ объединять

СкиллЦельСтадияCadenceАртефакт
kanchi-dividend-sopСкрининг + 5 шагов Kanchi + заявкаДо входаЕженедельноbuild_sop_plan.py, build_entry_signals.py
kanchi-dividend-review-monitorT1-T5 триггеры: снижение дивидендов, 8-K события, финансовое здоровьеПосле входаЕжеквартальноbuild_review_queue.py
kanchi-dividend-us-tax-accountingQualified vs ordinary, 1099-DIV, REIT/BDC distribution, IRA vs taxableТактический слойЕжегодноbuild_tax_planning_sheet.py

Это три последовательные стадии одной методологии с явными handoff-контрактами:

  1. sop → выдаёт кандидатов и entry-планы → отдаёт в review-monitor
  2. review-monitor → мониторит T1-T5 → шлёт REVIEW обратно в sop (re-underwrite) и в us-tax-accounting (account relocation)
  3. us-tax-accounting → учитывает риск-события от monitor при размещении по счетам

Реальное пересечение: ~10% — у всех троих одинаковые входные поля (ticker, instrument_type, account_type) и общий формат вывода (Markdown + JSON).

Уникальные знания в каждом

kanchi-dividend-sop (Kanchi-методология)

  • 5 шагов: PER × PBR адаптация под US-сектора, dividend growth check, payout sustainability, balance sheet quality, pullback entry
  • «Kanchi-style» фокус на дивидендном росте (12%+ annual) с pullback timing (RSI ≤40)
  • Японская школа dividend investing (かんち式), адаптированная под US tickers

kanchi-dividend-review-monitor (T1-T5 triggers)

  • T1: dividend cut announcement (8-K filing)
  • T2: payout ratio > 80% (sustainability)
  • T3: free cash flow deterioration
  • T4: debt rating downgrade
  • T5: management change / accounting restatement
  • Состояния: OK / WARN (soft signal) / REVIEW (actionable) — без auto-sell, только сигнал пользователю

kanchi-dividend-us-tax-accounting (тактический слой)

  • Qualified vs ordinary dividends (разные tax rates)
  • 1099-DIV interpretation (Box 1a/1b/2a/2b/3)
  • REIT/BDC distribution treatment (ordinary даже если qualified-eligible)
  • Holding period check (60-day window для qualified)
  • Taxable vs IRA account placement decision

Что потеряем от объединения

  • Разные каденции (еженедельно / ежеквартально / ежегодно) — нельзя запустить всё раз в неделю
  • Разные audiences: sop = entry-focused, review = monitoring, tax = tactical
  • Чистота контрактов между стадиями: sop выдаёт candidates.json, review читает его + добавляет state

Вердикт: KEEP SEPARATE. Три последовательные стадии одной методологии, объединение разрушит cadences и handoff-контракты.

Ловушка 3: Market Microstructure — CEX ≠ DEX

market-microstructure              — DEX/AMM на Solana: trade flow, whale detection, wash trading
market-microstructure-traditional — CEX/LOB теория: Glosten-Milgrom, Kyle's λ, Avellaneda-Stoikov

Почему НЕ объединять

АспектDEX/AMM (market-microstructure)CEX/LOB (market-microstructure-traditional)
ЦенообразованиеConstant product x·y=kBid/ask matching
SpreadSlippage (цена зависит от размера)Fixed spread между best bid/ask
Order priorityFirst-come по slot в block’еQueue position в order book
Market makingLiquidity provision, ILInventory management, Avellaneda-Stoikov
Adverse selectionMEV / sandwich attacksGlosten-Milgrom model
Information leakagePublic mempoolHidden order types (iceberg)

В market-microstructure-traditional есть целая таблица сравнения CEX vs DEX (строки 280-298), подтверждающая, что авторы сознательно разделили и документировали разницу. В Related Skills явно указано: market-microstructure связан, а не дублирующий.

Уникальные знания

market-microstructure (Solana DEX)

  • trade_flow_analysis.py: классификация trades на buy/sell pressure через volume × direction
  • volume_profile.py: POC (Point of Control), Value Area, HVN/LVN detection
  • Whale detection: кластеризация кошельков, отслеживание крупных перемещений
  • Wash trading detection: correlated wallets, fake volume patterns
  • MEV exposure: sandwich attack probability по транзакциям в mempool

market-microstructure-traditional (CEX theory)

  • spread_analysis.py: реализованный spread, effective spread, quoted spread
  • market_maker_sim.py: Avellaneda-Stoikov market making с inventory penalty
  • Glosten-Milgrom model: information share из order flow
  • Kyle’s lambda: price impact per unit of order flow
  • VWAP/TWAP execution algorithms
  • Order book imbalance metrics (OBI, depth imbalance)

Что потеряем от объединения

  • Конфликты в формулах: spread ≠ slippage, queue ≠ slot priority
  • Потеря фокуса: CEX-трейдер не хочет читать про AMM-кривые, и наоборот
  • Сломанная навигация: разные audiences, разные use-cases

Вердикт: KEEP SEPARATE. Фундаментально разные рынки, объединение сломает формулы.

Ловушка 4: Singular vs Plural — custom-indicator vs custom-indicators

custom-indicator (singular)    — СОЗДАТЬ новый индикатор через Numba JIT + NumPy
custom-indicators (plural)     — ИСПОЛЬЗОВАТЬ 9 готовых crypto on-chain метрик

Почему НЕ объединять

СкиллЗадачаРазмерАртефакт
custom-indicatorСгенерируй мне новый индикатор по Numba-шаблону148 строкШаблон custom_indicators/&#123;name&#125;/&#123;name&#125;.py
custom-indicatorsВот готовые 9 крипто-индикаторов (NVT, MVRV, holder momentum), примени их398 строк + 2 references + 2 scriptscompute_crypto_indicators.py, holder_momentum.py

Это две разные сущности под похожими именами. Singular — это создание, plural — это применение готовых. Разные entry points, разные аргументы, разные артефакты.

Уникальные знания

custom-indicator (Numba-специфика)

  • @njit + prange для параллельных циклов
  • Sanity-check через benchmark vs numpy
  • Warm-up вызов (Numba компилирует при первом запуске)
  • O(n) vs O(n²) проверка expected complexity

custom-indicators (crypto on-chain)

  • NVT (Network Value to Transactions) — аналог P/E для крипты
  • MVRV (Market Value to Realized Value) — over/undervalued signal
  • Exchange Flow (inflow/outflow) — selling pressure indicator
  • Funding Rate (perpetual futures) — market sentiment
  • OI (Open Interest) Momentum — позиционирование
  • Holder Momentum — распределение по кошелькам
  • Liquidity Score — depth assessment
  • Smart Money Flow — отслеживание «умных денег»
  • Token Velocity — скорость обращения

Рекомендация по неймингу (без слияния)

  • custom-indicator → create-custom-indicator (явный глагол, избежать путаницы)
  • custom-indicators → crypto-onchain-indicators (точное описание содержимого)

Вердикт: KEEP SEPARATE + RENAME. Это разные ниши, нейминг — это баг.

Ловушка 5: Похожие workflow ≠ одинаковые артефакты

В категории HTML-артефактов есть группа business-doc скиллов с идентичным workflow (read DESIGN.md → layout list → write → self-check → emit):

eng-runbook, hr-onboarding, invoice, meeting-notes, pm-spec, team-okrs

Все 6 имеют 47-52 строки SKILL.md каждый (то есть 90% — повторяющийся boilerplate). Кажется — явный merge-кандидат. Но:

  • eng-runbook выдаёт runbook с alerts table, on-call rotation, severity tier, code blocks
  • hr-onboarding выдаёт onboarding с 30/60/90 milestones, “you’re set when…” checklist
  • invoice выдаёт invoice с line items + tax breakdown + print stylesheet
  • meeting-notes выдаёт minutes с agenda checklist + decisions + action items
  • pm-spec выдаёт PRD со status pill, user stories, scope milestones
  • team-okrs выдаёт OKR tracker с progress bars, owner avatars, status pills

Когда объединять (CONDITIONAL)

Если вы готовы к conditional merge в business-doc скилл с 6 named layouts — это безопасно:

/business-doc runbook   DATA
/business-doc onboarding DATA
/business-doc invoice   DATA
/business-doc notes     <data>
/business-doc spec      <data>
/business-doc okrs      <data>

Layout-блоки переносятся 1:1 в ## Layout: <name> секции. ~210 строк против текущих 6×50 = 300 строк. Чистая экономия ~30%.

Вердикт: CONDITIONAL MERGE возможен, но только если готовы к рефакторингу layout-блоков в единый скилл с маршрутизацией.

Ловушка 6: Marketing skills — orthogonal оси

marketing-ideas       — 139 идей по 14 категориям (ЧТО делать)
marketing-psychology  — 60+ ментальных моделей (ПОЧЕМУ это работает)

Оба про маркетинг, оба имеют boot-блок «Check for product-marketing.md first». Кажется — объединить. Но:

  • marketing-ideas = тактики/идеи (список действий по стадиям)
  • marketing-psychology = ментальные модели (почему работает)

Это ортогональные оси. Идея «запустить referral program» (marketing-ideas) и модель «Reciprocity» (marketing-psychology) — это разные слои одного процесса.

marketing-psychology уже 455 строк, идеи тоже растут. При объединении SKILL.md превысит комфортный размер (>600 строк — тяжело для токенов).

Что можно улучшить без merge

В marketing-ideas добавить ссылку на marketing-psychology в секции Top Ideas (например, для Reciprocity/Social Proof → отсылка к модели). Перекрёстные ссылки — без слияния.

Вердикт: KEEP SEPARATE + cross-link.

Ловушка 7: Vite vs VitePress

vite       — Build tool: config, plugins, HMR, SSR, Vite 8 / Rolldown
vitepress  — SSG: docs/blog sites на базе Vite + Vue 3

Оба сгенерированы одним автором (Anthony Fu) из одного источника (antfu/skills). Кажется — объединить. Но:

  • vite = build tool (используют миллионы, не только VitePress)
  • vitepress = конкретный SSG (один из потребителей Vite)

Это два разных продукта в одном стеке, как React ≠ NextJS или PostCSS ≠ Autoprefixer. Объединять = сломать matching (если юзер спрашивает про плагин Vite, не нужно подгружать 65 строк про markdown-контейнеры VitePress).

Вердикт: KEEP SEPARATE. Это разные продукты в одном стеке.

Ловушка 8: MPH (авторский стиль)

mph-substack-writer   — Тон Substack-статей (voice, no em-dash, no MD tables)
mph-synthwave-theme   — CSS-тема (Bloomberg + Cyberpunk) для UI

Оба привязаны к одному автору (Michael Hanko / «Momentum Phinance») и его бренду. Кажется — объединить. Но:

  • mph-substack-writer = текст/voice/структура статьи (40 строк)
  • mph-synthwave-theme = цвета/шрифты/анимации UI (70 строк)

Полностью разные домены. Trigger-описания чётко разведены: «Write Substack articles» vs «Generates UI components». 40 и 70 строк — это уже очень компактно, объединять — значит раздувать.

Вердикт: KEEP SEPARATE. Бренд не повод для слияния, если домены разные.

Ловушка 9: Position Sizing — US stocks vs crypto

position-sizer   — US stocks, long-only, 3 метода: Fixed Fractional, ATR, Kelly
position-sizing  — Crypto/multi-asset, 5 методов: FF, Vol-Adj, Kelly, Liquidity-Constrained, Anti-Martingale

Реальное пересечение ~40% (оба реализуют FF и Kelly). Кажется — объединить. Но:

  • position-sizer — длинные US-stocks сделки, портфельный менеджер, Alpaca-friendly JSON-отчёт
  • position-sizing — crypto-трейдер, Solana tokens, DEX execution, meme/PumpFun правила

Уникальные знания

position-sizer (US stocks)

  • Alpaca-friendly JSON-отчёт (для интеграции с broker API)
  • Portfolio heat (6-8% rule): max суммарный риск портфеля
  • Max-position / max-sector constraints
  • Strictness rule: консервативный/средний/агрессивный профиль

position-sizing (crypto)

  • Liquidity-constrained: position size не должен превышать X% от pool depth
  • Anti-martingale: уменьшение размера после losses, увеличение после wins
  • Meme/PumpFun правила: высокая volatility, slippage adjustment
  • Multi-asset portfolio: корреляция между позициями

Рекомендация без слияния

Оставить, но перелинковать: position-sizer в Related Skills должен ссылаться на position-sizing для крипто-специфики. И наоборот.

Вердикт: KEEP SEPARATE + cross-link. Контекстно-зависимые нюансы не переносятся в общий скилл без раздувания.

Общий принцип: когда НЕ объединять

Из всех разобранных случаев вырисовывается универсальный чек-лист для отказа от объединения:

УсловиеСледствие
Похожее имя, разные задачи (singular vs plural, create vs use)KEEP SEPARATE, рассмотреть RENAME
Разные ниши одной темы (Mantine combobox vs form)KEEP SEPARATE, объединение разрушит фокус
Разные стадии pipeline’а (Kanchi sop vs review vs tax)KEEP SEPARATE, объединение сломает cadences
Разные парадигмы/рынки (CEX vs DEX)KEEP SEPARATE, формулы несовместимы
Разные audience (US stocks vs crypto)KEEP SEPARATE, cross-link
Разные уровни абстракции (framework vs single-frame)KEEP SEPARATE, scale matters
Один автор, разные медиумы (текст vs UI)KEEP SEPARATE, бренд не повод
Идентичный workflow, разные layout’ыCONDITIONAL MERGE возможен

Итоги

Ловушка нейминга — главная причина ложных срабатываний при попытке объединить скиллы. За похожими именами могут скрываться:

  • Разные ниши одной темы (Mantine подсистемы)
  • Разные стадии pipeline’а (Kanchi, refactoring audit/execute)
  • Разные парадигмы (CEX vs DEX)
  • Singular vs plural (custom-indicator vs custom-indicators)
  • Разные аудитории (US stocks vs crypto)

Перед объединением всегда задавайте 7 вопросов (см. обзорную статью) и проверяйте по чек-листу выше. Если попадает в KEEP SEPARATE — не объединяйте, даже если имя просится.

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

Ссылки

← Все статьи