| name | edt-mcp-project-code-research |
| description | Investigate 1C BSL behavior, dependencies, impact, and implementation differences through EDT-MCP. Read-only by default; not for plugin development. |
EDT-MCP code research
Purpose and trigger
Use this skill to produce a bounded, evidence-backed explanation of 1C project
code, dependencies, impact, or implementation differences.
Operating rule
Read and apply the common operating rules before this workflow.
Task boundary
Keep the task read-only and tied to exact project, metadata FQN, module, method,
or symbol targets. Route a known bounded correction to
edt-mcp-project-local-fix; do not turn research into implementation without
authorization.
Primary workflow
- Resolve candidates with
get_metadata_objects, list_modules, and
search_in_code. Search is literal and not dialect-aware: for identifiers,
use AST-backed definition/reference/hierarchy tools and do not infer absence
from one Russian or English spelling.
- Narrow with
get_module_structure, then prefer read_method_source over
read_module_source unless module-level context is required.
- Follow only the relationships needed using
go_to_definition,
find_references, get_method_call_hierarchy, get_outgoing_structures,
or get_symbol_info.
get_method_call_hierarchy scans only one project's <project>/src.
Inspect each relevant base/extension project separately and name any project
left unsearched. Treat get_outgoing_structures as a heuristic lower bound,
even when its response is not marked partial.- Treat every single-hop/depth-1 result and structured-output analysis as a
lower bound. Inspect bounded source and relevant projects before claiming a
complete contract.
- Start with counts, file lists, filters, or method/range reads; request full
payloads or more pages only when needed. Preserve truncation and cursor
evidence in the result.
- Use
get_platform_documentation when the conclusion depends on platform
behavior rather than project code.
Authority rule
Do not write code, metadata, runtime data, or Git state. Request a new task
boundary before any implementation or runtime experiment.
Stop rule
Stop when the exact target cannot be resolved, required project evidence is
unavailable, or the conclusion needs unauthorized runtime proof.
Completion signal
Return exact targets, the evidenced call/data flow, relevant dependencies and
exceptions, impact classification, partial-result caveats, unknowns, and the
smallest useful next validation step.
