steelmorgan/vanessa-authoring
framework_eng/skills/tool-usage/vanessa/vanessa-authoring/SKILL.md
Creating and refining Vanessa Automation feature scenarios based on real project requirements. Use when you need to write or update a scenario test, not just run it.
$ install --global
skillsauthnpx skillsauth add steelmorgan/1c-agent-based-dev-framework vanessa-authoringInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 13, 2026, 5:59 AM14.2s3 files scanned
SKILL.md
- name:
- vanessa-authoring
- description:
- Creating and refining Vanessa Automation feature scenarios based on real project requirements. Use when you need to write or update a scenario test, not just run it.
Authoring Vanessa Automation Scenarios
Writing Algorithm
- Determine the source of the requirement: a specification or business case (
vanessa-scenario-policy). - Determine which user the scenario runs under (see "User Context").
- Find suitable steps: first in the Vanessa library, then in the project scenarios.
- Write one smoke scenario: open -> one action -> one observable outcome.
- If the step does not exist, mark
# unknown_step_candidate; do not invent a BSL step. - Pass the scenario to
v8-runner(v8-runner test va).
Anatomy of a feature file
# language: ru
# encoding: utf-8
# Задача: task-103 — Оформление заказа клиента через портфель
@task-103 @тег-фичи
Функциональность: Краткое название
Как <роль пользователя>
Я хочу <что сделать>
Чтобы <бизнес-польза>
Контекст:
Дано Я запускаю тест-клиент для пользователя "Логин" с паролем "Пароль" или подключаю уже существующий
Сценарий: Название сценария
Когда <действие>
И <следующее действие>
Тогда <ожидаемый результат>
Context:is executed before each scenario in the file.- Step keywords:
Given,When,Then,And,Butare syntactically interchangeable. - Strings use apostrophes or quotes; special characters:
\',\",\\. Scenario structure:+Examples:runs the scenario for each row in the parameter table.@treein the header enables Turbo Gherkin: Tab indentation defines the step tree (spaces are not allowed!).@exportscenariosmakes the scenario available as a subscenario from another feature file.
User Context
MUST: every scenario runs under a specific business user, not under admin/AgentAI. The only exception is when the function being checked is available exclusively to an administrator.
How to determine the user:
- Specified in the task description -> use that user.
- Not specified -> ask a person before writing the scenario.
One user (in the Context: section):
Дано Я запускаю тест-клиент для пользователя "SalesManager" с паролем "123" или подключаю уже существующий
Multiple users (in the scenario body - named TestClient instances):
И я подключаю TestClient "Менеджер" логин "SalesManager" пароль "123"
И я подключаю TestClient "Руководитель" логин "Director" пароль "456"
И я активизирую TestClient "Менеджер"
# ... steps on behalf of the manager ...
И я активизирую TestClient "Руководитель"
# ... steps on behalf of the director ...
И я закрываю TestClient "Менеджер"
И я закрываю TestClient "Руководитель"
Password is plain text in the feature file. Test users must have a simple or empty password (
password "").
Two-Session Split (MUST)
.feature file is logically divided into two parts:
- Setup / infrastructure - runs under a technical user (
AgentAIin this project): preparing test data (creating documents, catalog items, register records),VAExtension (Расширение)steps, BSL fixtures fromvanessa-tests/support/, everything that requires technical roles outside the business user's normal access. - Business flow (verification) - runs under a specific business user (for example
Gavrilova Nataliafor OC-23400): only steps that verify user behavior under test. The business user MUST NOT receive technical roles (for example roles fromVAExtension.cfe) just to make the step pass.
Session switching:
И я закрываю сеанс TESTCLIENT
or
И я закрываю TestClient "<имя>"
after which a new session opens:
Дано я подключаю TestClient "<роль>" логин "<пользователь>" пароль "<пароль>"
Rationale (Infostart id=249957, id=249958): if the business flow runs with full rights, the test stops checking real role restrictions and creates a false sense of correctness. Granting the business user technical roles just to satisfy an infrastructure step is the same anti-pattern in another form.
Anti-pattern: putting (Расширение) / fixture steps into the business user's session, then "fixing" the failure by granting technical roles. Instead, move the step into the setup block under the technical user.
Step Search
Library: /opt/onescript/2.0.0/lib/add/features/libraries/
| Category | Library file |
|-----------|-----------------|
| Interface, fields, buttons, tabs | UITestRunner/РаботаСИнтерфейсом.feature |
| Tables (tabular sections) | UITestRunner/РаботаСТаблицами.feature |
| Form element state | UITestRunner/СостояниеЭлементаФормы.feature |
| Flags / switches | UITestRunner/РаботаСФлагами.feature |
| User messages | UITestRunner/РаботаСОкномСообщений.feature |
| Data in DB, catalogs | Данные/ЗапросыКБД.feature |
| One / multiple TestClient | UITestRunner/ОткрытьTestClient.feature, UITestRunner/ПодключениеНесколькихКлиентовТестирования.feature |
| Conditions, variables | Условие/Условие.feature |
| Pause | Пауза/СделатьПаузу.feature |
Cheat sheet for common steps with syntax → references/steps-cheatsheet.md.
Full library: references/steps.json (1116 steps). Do not read it in full - use grep to search by keywords from the task. Structure of each record:
Step name- example invocation with parametersStep description- what the step doesFull step type- category (UI, Misc, Files, Variables, etc.)
Tags
| Tag | Meaning |
|-----|---------|
| @task-<ID> | Link to the tracker task (MUST, vanessa-scenario-policy) |
| @draft / @Draft@ | Exclude from execution when running the catalog |
| @manual-data | Scenario depends on data created manually |
| @regression | Regression test |
| @ui | UI test through TestClient |
| @tree | Turbo Gherkin: Tab indentation = nesting (spaces are forbidden) |
| @exportscenarios | Scenario is called as a subscenario from another file |
| @IgnoreOnXxx | System: skip in the specified environment |
Anti-patterns
| Anti-pattern | Consequence | |--------------|-------------| | Scenario under admin without justification | Does not verify real user permissions | | Step checks an internal detail (method call, direct DB query) | Fragile: no observable UI behavior | | Invented step instead of searching the library | Will not resolve at runtime | | Long scenario (7+ actions) | Hard to localize the failure | | Data preparation is mixed with verification | Breaks the Given/Then separation |
depends_on:
- framework/rules/vanessa-scenario-policy.mdc
- framework/rules/vanessa-test-isolation-policy.mdc
- framework/rules/vanessa-tests-location.mdc
- framework/rules/vanessa-run-loop.mdc
- framework/skills/tool-usage/vanessa/vanessa-diagnostics/SKILL.md
- framework/skills/tool-usage/platform-data/xml-generation/SKILL.md requires:
- tools
Related Skills
steelmorgan/source-of-truth
testing
VerifiedTrustedCommunity
MUST use BEFORE making a judgment about the cause of a conflict, a test failure, or an artifact dispute. Defines the end-to-end verification method L1→L6 and the classification of the first broken link.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/skill-learning
development
VerifiedTrustedCommunity
MUST use AFTER a work cycle with ≥2 iterations (wrote → error → fixed → success). Provides the retrospective procedure and the format for recording practice/anti-patterns in references/learned-patterns.md or {project}/.context/learned-patterns.md.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/rlm-workflow
tools
VerifiedTrustedCommunity
MUST use WHEN you are writing reusable knowledge into RLM (pattern / architectural decision / stable domain fact) OR reading it before a non-trivial task/solution in the domain. Provides the breakdown of native-push vs RLM-pull, tools for writing and reading RLM, H-MEM levels, and hygiene.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/quick-fix
testing
VerifiedTrustedCommunity
MUST use WHEN the task is classified as simple (< 20 lines, 1 file, no new metadata objects, no architectural decisions). Provides a short cycle of 3 steps with a guard on the self path and mandatory verify.
69SKILL.mdUpdated Jun 13, 2026