BB fintech-agreement-drafting-stephane-boghossian
Комплексный метод разработки и завершения сложного, многокомпонентного регулируемого финтех-соглашения — от запроса до подписания. Разработано на основе руководства старшего финтех-юриста: лицензированный поставщик платежных услуг, взаимодействующий с контрагентом по вопросам внесения/снятия наличных через агента, QR-платежей, электронных платежей через кошелек и маркетплейса, каждый со своим регуляторным профилем. Включает пять фаз и четырнадцать шагов: регуляторное картирование (матрица «деятельность-лицензия», ворота классификации «серых зон»), архитектура (структура «основной договор + субагентский договор», обособленный маркетплейс), баланс между регулированием и коммерцией (что гибко, а что нет), основная разработка (полномочия, механика оборота средств, жестко заданные регуляторные лимиты, ответственность — все с отслеживанием контроля), сортировка блокирующих факторов исполнения и проверка перед подписанием для устранения открытых блокирующих факторов как предварительных условий. Отказывается изобретать значения, специфичные для лицензии, или составлять заверение как истинное без исполнительных доказательств. Используйте для структурирования, разработки, согласования или проверки любого регулируемого платежного контракта.
машинный переводПоказать оригиналСкрыть оригинал«An end-to-end method for drafting and finalising a complex, multi-pill…»
An end-to-end method for drafting and finalising a complex, multi-pillar regulated fintech agreement — from intake to signature. Authored from a senior fintech lawyer's manual: a licensed payment-services provider engaging a counterparty across agent cash-in/cash-out, QR payments, wallet e-payments, and a marketplace, each with its own regulatory profile. Runs five phases and fourteen steps: regulatory mapping (activity-to-licence matrix, grey-zone classification gates), architecture (framework-plus-sub-agreement structure, ring-fenced marketplace), the regulatory–commercial balance (what flexes vs what cannot), core drafting (authority, float mechanics, hard-coded regulator caps, liability — all tracking control), execution-blocker triage, and a pre-signature check closing open blockers as conditions precedent. It refuses to invent licence-specific values or draft a representation as true without executed evidence. Use it to structure, draft, negotiate, or review any regulated payments contract.
Комплексный метод разработки и завершения сложного, многокомпонентного регулируемого финтех-соглашения — от запроса до подписания.
Как процесс B 72/100 · Почти готов — слабые места: входы и предусловия, повторный запуск
Как улучшить
- Тело SKILL.md длиннее 5 000 токенов: вынесите справочные детали в references/ и подключайте по необходимости.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 4. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- предупреждение
body-longтело SKILL.md ≈ 7249 токенов (рекомендуется < 5000); вынесите детали в references/ - заметка
frontmatter-keyнеизвестное поле фронтматтера "triggers"
Процессный рейтинг: все десять параметров 72/100
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 30Повторный запуск. Изменяющих операций: 3, без проверки текущего состояния
- 50Ошибки и развилки. Развилок: 0, есть раздел про ошибки
- 60Результат и критерий готовности. Формат результата описан, критерия завершения нет
- 70Стоимость исполнения. Тело инструкции 7249 токенов
- 85Шаги. Шагов: 31, расплывчатых формулировок: 1
- 100Инструменты и файлы. Инструменты объявлены во frontmatter
- 100Когда включается. Сказано, когда применять и когда не применять
- 100Согласованность. Имя и обязательные поля на месте
- 100Отчётность по ходу. Скилл сообщает о ходе работы
- medium Правила безопасности и запреты внутри скилла: их место в системном промпте, здесь они не защищают
- low Разделов верхнего уровня: 23. Похоже на несколько доменов в одном скилле
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Длина description 1011: рекомендуется 120–800 символов
- +2Инструкции на одном языке
- +4Структура: 31 заголовков
- +3Пошаговые инструкции: 31 пунктов
- +3Формат ответа описан явно
- +4Есть примеры (0 блоков кода)
- +1Лицензия указана
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 74.