Agent Skills › likec4/likec4 › likec4-project-config-workflow

likec4-project-config-workflow

GitHub

指导 LikeC4 项目配置工作流，涵盖配置处理、路径匹配及所有权规则变更与审查。提供核心概念解析、回归测试矩阵及验证命令，确保多项目场景下的正确性。

.agents/skills/likec4-project-config-workflow/SKILL.md likec4/likec4

Trigger Scenarios

修改 LikeC4 项目发现或配置文件逻辑排查多项目工作流、文件排除或 Windows 路径匹配相关的 Bug

Install

npx skills add likec4/likec4 --skill likec4-project-config-workflow -g -y

More Options

Non-standard path

npx skills add https://github.com/likec4/likec4/tree/main/.agents/skills/likec4-project-config-workflow -g -y

Use without installing

npx skills use likec4/likec4@likec4-project-config-workflow

指定 Agent (Claude Code)

npx skills add likec4/likec4 --skill likec4-project-config-workflow -a claude-code -g -y

安装 repo 全部 skill

npx skills add likec4/likec4 --all -g -y

预览 repo 内 skill

npx skills add likec4/likec4 --list

SKILL.md

Frontmatter

{
    "name": "likec4-project-config-workflow",
    "description": "Use when changing or reviewing LikeC4 project discovery, `likec4.config` handling, include paths, excludes, workspace folders, document ownership, or `ProjectsManager` behavior. Trigger for bugs about multi-project workflows, excluded files, included external folders, default project ownership, or Windows path matching."
}

LikeC4 Project Config Workflow

Project ownership and exclusion rules are subtle. Preserve the distinction between "which project owns this document" and "is this document included for this project".

Ground rules

Start in packages/language-server/src/workspace/ProjectsManager.ts.
Check callers in WorkspaceManager.ts, LangiumDocuments.ts, and model parsing before changing semantics.
Prefer focused ProjectsManager.spec.ts coverage before implementation.
Keep Windows path behavior covered when touching path normalization or folder matching.

Concepts to preserve

A LikeC4 project is defined by config files such as .likec4rc or likec4.config.*.
The nearest config normally determines project ownership.
include.paths adds source roots for a project; paths are resolved relative to the project folder.
Project-level exclude affects that project, but another project may still include the same physical file.
Workspace-level excludes take precedence over project-level inclusion.
Default excludes such as node_modules still apply where no explicit project rule overrides them.

Important distinction:

ownerProjectId(document) answers ownership.
isExcluded(projectId, document) answers exclusion for a specific project.
isExcluded(document) answers whether the document should be skipped in the effective owner context.

Regression matrix

Add or update tests for the relevant rows:

Case	What to assert
nested projects	nearest config wins
sibling projects with similar prefixes	`qwe` does not own `qwe-qwe`
include path outside project folder	included document participates in the including project
document excluded by project A but included by project B	project-specific exclusion differs by project
shared include path	deterministic owner and no duplicate document processing
include path removed on reload	stale include ownership disappears
workspace startup scanning	include-path documents are loaded before project docs use them
workspace exclude	excluded even if project config includes it
Windows paths	drive and backslash paths match expected project

Focused commands

pnpm --filter @likec4/language-server test -- ProjectsManager.spec.ts
pnpm --filter @likec4/language-server typecheck
pnpm exec dprint check packages/language-server/src/workspace
git diff --check

If a unit test manually adds the document, also test the workspace-startup path. Manual document injection can pass while real include-path scanning still drops the file.