1c-estimation

Solid

Оценка трудозатрат задачи 1С и проверка ЧТЗ перед оценкой/разработкой: чего не хватает, чтобы оценивать честно, оценка по аналогии на реальных закрытых задачах (не сумма придуманных атомов), проверка ЧТЗ тех-лидом по рамке требований и работа со списком замечаний (что именно вписать в замечание, чтобы оно было конкретным и проверяемым). ОБЯЗАТЕЛЬНО используй, когда тебя просят оценить трудозатраты/сроки задачи 1С, сказать «сколько это займёт», проверить ЧТЗ на готовность к оценке или к разработке, свести открытые вопросы по ЧТЗ в список замечаний, или решить, чего не хватает во входных данных, чтобы оценка не была гаданием. Срабатывай даже без слов «оценка/estimation», если речь о трудозатратах, сроках, готовности ЧТЗ к разработке или ревью требований тех-лидом. Главное правило: без нужных для размера задачи артефактов (паспорт/ ЧТЗ) не оценивать вслепую — назвать, чего не хватает; оценка — по аналогии на РЕАЛЬНЫХ похожих задачах, а не сумма изобретённых атомов; исторические данные о факт-часах использовать т

AI & Automation 21 stars 6 forks Updated today MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
45
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Оценка трудозатрат и проверка ЧТЗ ## Локализация (сначала, если есть) Если в скилле есть каталог `references/local/` — прочитай его ПЕРЕД работой: `version-stack.md`, ролевые корзины оценки своей компании (`estimation-buckets.md`), источник данных для аналогов (`analogues-source.md`), где ведётся реестр замечаний (`remarks-registry.md`). При противоречии локальное побеждает generic. Контракт — `docs/SKILL_LOCALIZATION.md` toolkit. Роль этого скилла — не писать ЧТЗ (это `1c-analyst`) и не писать код (это `1c-dev`), а ответить на два смежных вопроса: «готовы ли мы честно оценить эту задачу» и «сколько это будет стоить с учётом похожих задач, которые уже сделаны». Оценка — не изолированное число, а суждение, опирающееся на конкретные документы и конкретные прецеденты; если их нет — оценки тоже нет, есть только гипотеза. ## Железное правило 1 — без артефактов не оцениваем вслепую Глубина требуемых артефактов зависит от размера/риска задачи (см. `document-frames.md` скилла `1c-analyst`: рамки `brief`/`requirements`/`tech-design`). Прежде чем дать число: 1. Определи размер задачи (S/M/L/XL) и по нему — какие рамки обязательны. 2. Проверь, что обязательные артефакты СУЩЕСТВУЮТ и удовлетворяют своему `acceptance` (не просто «есть файл», а «файл закрывает критерии готовности своей рамки»). 3. Артефакта нет или он не проходит `acceptance` → НЕ оценивай по названию задачи. Явно скажи, чего не хватает («нет паспорта — не видно границ и критериев приёмки бизнеса», «ЧТЗ без л...

Details

Author
vgtitov
Repository
vgtitov/bsl-ai-toolkit
Created
2 months ago
Last Updated
today
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

1c-expert

Эксперт по техническим/технологическим вопросам 1С и эксплуатации высоконагруженных систем (уровень 1С:Профессионал/Эксперт по техн. вопросам). Используй всякий раз, когда рассл��дуешь медленную работу, зависания, рост нагрузки или нестабильность 1С; настраиваешь технологический журнал (logcfg.xml: EXCP, TLOCK, TDEADLOCK, TTIMEOUT, QERR, SDBL, DBMSSQL, DBPOSTGRS, CALL/SCALL) и анализируешь его через grep/awk/perl или ЦУП/КИП; снимаешь и читаешь план запроса (EXPLAIN ANALYZE, план MS SQL) и оптимизируешь тяжёлый запрос; разбираешь блокировки и взаимоблокировки (управляемые vs автоматические, эскалация, гранулярность, дедлоки, retry); считаешь APDEX и делаешь замер производительности (проведение, отчёты, открытие формы); читаешь счётчики PerfMon / top/vmstat/iostat/sar и счётчики СУБД; анализируешь показатели и дашборды Zabbix/Prometheus и строишь по ним экспертный отчёт с приоритетами; проектируешь или чинишь кластер серверов 1С (балансировка, требования назначения функциональности, отказоустойчивость, масштаби

21 Updated today
vgtitov
AI & Automation Solid

1c-tester

Тестировщик/QA для 1С:Предприятие (BSL) — определяет, КАКОЙ уровень проверки нужен для конкретного изменения, и проводит его до реального доказательства (вывод прогона, не ощущение). Используй всякий раз, когда нужно проверить доработку перед сдачей, решить «CheckConfig хватит или нужен смоук», написать модульный тест на YAxUnit или сценарий Vanessa Automation/Gherkin, проверить доступ к данным живой ИБ (OData/HTTP-сервис расширения) для отладки или для AI, разобрать, почему прогон завис или дал ложный результат, или ревьюишь чужой набор тестов на покрытие кейсов. Срабатывай даже без слов «тест/QA», если речь о том, как ДОКАЗАТЬ, что доработка работает, а не просто «должна». Железное правило: вердикт — только по файлу-результату/выводу прогона, а не по коду возврата или ощущению; факты о 1С — по реальному коду/платформе через MCP, не по памяти. Написание/правка самого BSL-кода — `1c-dev`; расследование ПРОИЗВОДИТЕЛЬНОСТИ (медленно/ зависает/масштабирование) — `1c-expert`; анализ требований до кода — `1c-analy

21 Updated today
vgtitov
AI & Automation Solid

1c-analyst

Анализ и архитектура задач 1С: разбор задачи/ЧТЗ, какие контуры/базы существуют и что с чем связано, что затронет изменение, где уже реализован функционал; подготовка качественного ЧТЗ (ожидаемое поведение + модель данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь или уточняешь задачу по 1С, определяешь контур и базу, оцениваешь в��ияние доработки, готовишь/проверяешь ЧТЗ, формулируешь уточняющие вопросы, решаешь нужен ли архитектор, или проектируешь на уровне архитектуры (не написания BSL). Срабатывай даже без слов «анализ/архитектура», если речь о понимании задачи, контуров, влияния или подготовке требований. Главное правило: искать в ОБОИХ слоях контура (конфигурация + расширение) и проверять по РЕАЛЬНОМУ коду через MCP, не по памяти. Написание/ревью BSL — скилл `1c-dev`.

21 Updated today
vgtitov