Skill for generating 1C:Enterprise (BSL) code with mandatory validation through MCP tools to prevent hallucinations. Use when generating, editing, or validating 1C BSL code, working with 1C metadata, or answering questions about 1C platform API.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Skill for generating 1C:Enterprise (BSL) code with mandatory validation through MCP tools to prevent hallucinations. Use when generating, editing, or validating 1C BSL code, working with 1C metadata, or answering questions about 1C platform API.
1C BSL Code Generation with Anti-Hallucination Validation
Introduction & When to Use
This skill provides mandatory procedures for generating 1C:Enterprise (BSL) code with strict validation to prevent hallucinations and ensure code correctness.
Trigger this skill when:
Generating, editing, or validating 1C BSL code
Working with 1C metadata objects (Справочники, Документы, Регистры, etc.)
Using 1C platform API
Writing 1C Query Language code
Answering questions about 1C platform capabilities
Keywords for detection:
1с, bsl, 1c:enterprise, справочник, документ, регистр, язык запросов
catalog, document, register, query language
Semantic triggers:
Creating/editing/validating BSL code
Working with 1C configuration metadata
Implementing 1C business logic
Writing procedures/functions in BSL
🚨 CRITICAL: Absolute Compliance Requirements
⚠️ THESE RULES ARE NON-NEGOTIABLE AND MUST BE FOLLOWED WITHOUT EXCEPTION ⚠️
Failure to follow these rules constitutes a CRITICAL ERROR and produces hallucinated, potentially broken code.
Core Anti-Hallucination Principles
MANDATORY RULES - NO EXCEPTIONS ALLOWED:
1. 🚫 NEVER ASSUME 1C API EXISTS
PROHIBITION: Writing ANY platform API call without validation
MANDATORY ACTION: ALWAYS call getMembers() BEFORE using any method/property
CONSEQUENCE: Hallucinated methods that don't exist = broken code
ENFORCEMENT: If API not validated → STOP and validate first
2. 🚫 NEVER ASSUME METADATA EXISTS
PROHIBITION: Using metadata objects (Справочники., Документы., etc.) without verification
MANDATORY ACTION: ALWAYS verify through search_metadata or search_metadata_by_description
CONSEQUENCE: References to non-existent objects = runtime errors
ENFORCEMENT: If metadata not verified → STOP and verify first
3. 🚫 NEVER WRITE CODE FROM SCRATCH IF PATTERN EXISTS
PROHIBITION: Writing new implementations without searching for existing patterns
MANDATORY ACTION: ALWAYS call search_code() FIRST before writing new code
CONSEQUENCE: Duplicate code, missed best practices, inconsistent patterns
ENFORCEMENT: If pattern search not performed → STOP and search first
4. ✅ ALWAYS VALIDATE BEFORE WRITE
REQUIREMENT: Complete validation workflow BEFORE writing ANY .bsl file
MANDATORY CHECKS: API validated + Metadata verified + Patterns searched
CONSEQUENCE: Skip validation = high probability of errors
ENFORCEMENT: Cannot proceed to file write without completed validation
5. ✅ ALWAYS LINT AFTER WRITE
REQUIREMENT: Run read_lints() IMMEDIATELY after writing ANY .bsl file
MANDATORY FIX: Fix ALL critical errors before proceeding
CONSEQUENCE: Linter errors left unfixed = broken code in repository
ENFORCEMENT: 0 critical errors required, max 3 fix attempts, then escalate to user
🔴 CRITICAL ENFORCEMENT POLICY
These rules are NOT suggestions or recommendations
These rules are ABSOLUTE REQUIREMENTS
Agent MUST NOT skip any validation step
Agent MUST NOT proceed if validation fails
Agent MUST STOP and report if unable to validate
Violation examples that are STRICTLY FORBIDDEN:
❌ "I'll write the code quickly without checking API"
❌ "I assume this method exists based on similar patterns"
❌ "I'll skip search_code() because I know the pattern"
❌ "Linter check can be done later"
❌ "This is simple code, doesn't need validation"
Correct approach - MANDATORY statements:
✅ "BEFORE writing code, I MUST validate API via getMembers()"
✅ "BEFORE using metadata, I MUST verify via search_metadata()"
✅ "BEFORE implementing, I MUST search existing patterns via search_code()"
✅ "AFTER writing file, I MUST run read_lints() immediately"
✅ "IF validation fails, I MUST STOP and resolve before proceeding"
MCP Tools Reference
A. API Validation Tools (mcp_bsl-platform-context_*)
Usage strategy: Proactive validation BEFORE code generation + Reactive fixes AFTER linter errors
PROACTIVE Tools (use BEFORE writing code)
1. getMembers - Get ALL members of a type
When: BEFORE generating code that uses platform types
Purpose: Understand available methods/properties of a type
Parameters: name (exact name), type (method/property/type)
Example: Complex linter error → info("НайтиПоСсылке", "method") for full docs
Example call:
{"name":"НайтиПоСсылке","type":"method"}
API Validation Workflow
BEFORE code generation (proactive):
1. Identify platform types used in task (СправочникМенеджер, ДокументОбъект, etc.)
2. For EACH type:
├─ Call getMembers(type) → get available methods/properties
└─ If creating instances → call getConstructors(type)
3. Select correct methods from validated list
4. Write code using ONLY validated API
AFTER linter errors (reactive):
If linter reports API errors:
1. Identify error type:
├─ Unknown method/property → use search() to find correct name
├─ Wrong signature → use getMember() to verify parameters
└─ Complex error → use info() for full documentation
2. Fix code with correct API
3. Re-run linter
B. Metadata Validation Tools (mcp_1c-metacode_*)
Priority order of tool usage:
search_code (PRIMARY) - ALWAYS search for existing patterns FIRST
search_metadata_by_description - when uncertain about metadata names
search_metadata - for structural queries and finding usage
Critical use case: "Find all documents that use Справочник.Контрагенты" → use find_objects_using_object
Metadata Validation Workflow
Step 1: Pattern Search (PRIMARY - do this FIRST!)
└─ Call search_code() with task description in RUSSIAN
└─ If patterns found → use as foundation for implementation
Step 2: If uncertain about metadata names
└─ Call search_metadata_by_description() in RUSSIAN
└─ Identify correct object names
Step 3: Structural validation
├─ Call search_metadata(op: "object_structure") → get full structure
└─ Validate that required attributes/tabular parts exist
Step 4: Find usage (if needed)
├─ find_objects_by_attribute() → "What uses this attribute?"
├─ find_objects_by_resource() → "What uses this resource?"
├─ find_objects_by_dimension() → "What uses this dimension?"
└─ find_objects_using_object() → "What references this object?"
Step 5: Write code based on validated patterns and metadata
C. Code Validation Tools
Error Severity Levels (for Cursor Linter)
CRITICAL:
Definition: Errors that MUST be fixed before code can be considered complete
Examples: Syntax errors, undefined variables, type mismatches, missing required methods
Requirement: 0 critical errors MANDATORY for completion
WARNING:
Definition: Issues that should be addressed but don't break functionality
ENFORCEMENT: Agent MUST NOT consider task complete until all steps pass. Zero critical errors is MANDATORY requirement.
Special Cases & Advanced Validation
1C Query Language Validation
When writing 1C Query Language code:
1. Parse query text
2. Extract ALL object names (tables)
3. FOR EACH object name:
└─ Call search_metadata(op: "object_structure", object: name)
4. Extract ALL field names
5. FOR EACH field:
└─ Verify exists in object structure (from step 3)
6. IF any object/field NOT found:
├─ STOP code generation
└─ Report missing elements to user
7. Write query with validated object and field names
Example:
Query: "ВЫБРАТЬ Контрагенты.Наименование, Контрагенты.ИНН ИЗ Справочник.Контрагенты"
Validation steps:
1. Extract object: "Контрагенты"
2. Call search_metadata(op: "object_structure", object: "Контрагенты")
3. Verify fields: "Наименование", "ИНН" exist in structure
4. IF all verified → write query
БСП/SSL (Standard Subsystems Library) Code
When working with standard subsystems:
1. ALWAYS set is_ssl_api: true in search_code()
2. Search for standard procedures BEFORE writing custom ones
3. Example: File operations → search "работа с файлами" with is_ssl_api: true
4. Prefer standard procedures over custom implementation
Example call:
{"op":"find_routines_by_description","text":"работа с файлами","is_ssl_api":true,"limit":50}
Query Strings in Code
When code contains query as string variable:
1. Extract query text from string
2. Parse query (identify SELECT, FROM, WHERE clauses)
3. Extract table and field names
4. Validate each name via search_metadata
5. IF validation fails:
├─ STOP
└─ Report invalid names to user
6. Write code with validated query
Integration with Existing Rules
This skill complements existing project rules:
Integration Order
1. Skills Index Detection
└─ Keywords detected → load 1C_BSL_SKILL
2. Apply Anti-Hallucination Rules (this skill)
├─ NEVER assume API/metadata
├─ ALWAYS validate before write
└─ ALWAYS lint after write
3. Follow TDD Workflow (if AgentMode.rules.md exists)
├─ Write tests first
├─ Implement with validation
└─ Run tests
4. Apply Project-Specific Rules (if project_bsl_rules.mdc exists)
├─ Add required comment blocks
├─ Update registry.md
└─ Follow DSSL UT conventions
Rule Files Reference
project_bsl_rules.mdc - Change commenting rules (DSSL UT specific)
1. Report to user: "Method X not found for type Y"
2. Call getMembers(Y) → show available alternatives
3. Ask user: "Available methods: [list]. Which should I use?"
4. Wait for user confirmation
5. Use confirmed method
Example:
Agent: "Method 'НайтиПоКоду' not found for 'СправочникМенеджер'.
Available methods: НайтиПоНаименованию(), НайтиПоРеквизиту().
Which method should I use for finding by code?"
If Metadata Not Found
1. Report to user: "Object X not found in configuration"
2. Call search_metadata_by_description() with similar terms
3. Show similar objects found
4. Ask user: "Did you mean: [list of similar]? Or provide exact name?"
5. Wait for user clarification
6. Use confirmed object name
Example:
Agent: "Object 'Контрагент' not found.
Similar objects found:
- Справочники.Контрагенты
- Справочники.КонтрагентыПоставщики
Which one did you mean?"
If Linter Finds Errors (Auto-Fix)
1. Display errors to user
2. Attempt automatic fix (max 3 attempts):
├─ Iteration 1: Use search()/getMember() for API errors
├─ Iteration 2: Re-validate metadata if object not found
└─ Iteration 3: Try alternative approach from search_code()
3. IF fixed → report success
4. IF not fixed after 3 attempts:
├─ Show remaining errors to user
├─ Explain what was tried
└─ Request user guidance
Example:
Agent: "Linter found 2 errors. Attempting auto-fix...
Iteration 1: Fixed API call using getMember()
Iteration 2: Fixed metadata reference using search_metadata()
✅ All errors resolved. Code validated."
If Validation Tools Fail
IF MCP tool returns error:
1. Log the error
2. Report to user: "Validation tool X failed: [error message]"
3. Explain impact: "Cannot validate Y without tool X"
4. Ask user: "Proceed without validation? (NOT recommended)"
5. IF user approves:
└─ Add comment in code: "// WARNING: Not validated due to tool failure"
6. IF user declines:
└─ STOP and wait for tool to be available
Agent Checklist
Before completing BSL code generation, verify ALL items:
Pre-Write Validation
Pattern search performed via search_code() (if applicable)
ALL platform API calls validated via getMembers() or getMember()
ALL metadata objects verified via search_metadata() or search_metadata_by_description()
Object structures validated (attributes, tabular parts confirmed to exist)
