lci-parsing-languages

Maps lci's tree-sitter parser, extractor, and per-language symbol extraction coverage.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/standardbeagle/lci-cpp --skill lci-parsing-languages-standardbeagle
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: lci-parsing-languages
Source: https://github.com/standardbeagle/lci-cpp/tree/main/.agents/skills/lci-parsing-languages
Command: npx skills add https://github.com/standardbeagle/lci-cpp --skill lci-parsing-languages-standardbeagle

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When working on the lci code indexer, it is hard to know which source files implement parsing and extraction for a given language, what lci actually extracts per language (symbols, references, imports, receiver types, side effects, catch sites), and why a file might produce zero symbols. This Skill provides a code map, capability matrix, and diagnostic recipes for those questions. ## Core Features & Use Cases - Code map of the parse pipeline: Locates the exact files and line numbers for language detection, the parser pool, UnifiedExtractor dispatch, and per-language reference/symbol handlers across 13 tree-sitter grammars plus Svelte script masking. - Per-language capability matrix: Shows which languages support symbols, references, cross-file imports, receiver-type call resolution, type relationships, side effects, and catch sites, including known gaps like Java/Kotlin/Ruby lacking cross-file import resolution. - Debugging zero-symbol files: Documents ParseSkipReason values, config knobs like max_parse_file_size, and probe recipes using lci status, symbols, refs, and targeted gtest filters. - Use Case: A developer adds a new grammar or fixes a Kotlin extraction bug and uses this Skill to find the fieldless-grammar workaround, the relevant dispatch sites, and the exact test filters to run. ## Quick Start Use the lci-parsing-languages skill to find where lci extracts symbols for Python and check why a file produced zero symbols.

Frequently Asked Questions about lci-parsing-languages

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add or fix a language grammar in lci?▼

Grammar pins live in cmake/TreeSitterGrammars.cmake via declare_ts_grammar, and extension mapping lives in the header-only include/lci/language_map.h kLangMap table. Extraction behavior is dispatched per language in src/parser/unified_extractor*.cpp, with tests in tests/language_extraction_test.cpp.

What does lci extract for each programming language?▼

lci extracts symbols, scopes, references with receiver-type-qualified calls, imports, complexity, and optional side-effect and catch-site facts for 13 languages plus Svelte via script masking. Cross-file import resolution covers Go, JsTs, Python, Rust, CSharp, CFamily, Php, and Zig, but not Java, Kotlin, or Ruby.

Why does a file produce zero symbols in lci?▼

Zero symbols always sets a ParseSkipReason such as Oversize, MinifiedBundle, ParserUnavailable, or ParseFailed, recorded in pipeline_processor.cpp. Files above index max_parse_file_size (default 2 MB) are trigram-only, and UnsupportedGrammar skips are deliberately not reported as warnings.

Does lci support Swift, Scala, Lua, or Vue parsing?▼

No. Swift, Scala, Lua, Vue, and other is_code entries in kLangMap are text-searchable only and hit ParseSkipReason::UnsupportedGrammar. Only the 13 vendored tree-sitter grammars plus Svelte script masking get full symbol extraction.

How does lci compare to ctags, LSP, or SCIP for code navigation?▼

lci trades ctags' breadth for uniform extraction depth across 13 languages, and its receiver-type call resolution is a syntactic heuristic rather than type-checker precise like LSP or SCIP. It has no incremental parsing, no persisted ASTs, and no cross-file imports for Java, Kotlin, or Ruby.

Which tests verify lci language extraction behavior?▼

Run lci_tests with gtest filters like LanguageExtractionTest.*, ScopeTypeResolution.*, UnifiedExtractorTest.*, LanguageMap.*, ParserPoolTest.*, and SideEffectExtraction.*. Real-corpus receiver-type checks live in lci_real_project_tests under RealProjectLanguages.* and skip without corpora.