skills/likec4-dsl/references/configuration.md (2)

166-170: Clarify extends examples presentation.

Having two separate JSON objects on consecutive lines without explanation may confuse readers. Consider clarifying these are alternative examples.

📝 Suggested improvement

 ### `extends`

 Inherit styles from other config files (JSON only). Single path or array.

+Single path:
+
 ```json
 { "extends": "../shared/likec4.config.json" }
-{ "extends": ["../shared/base.json", "../shared/theme.json"] }
+```
+
+Multiple paths:
+
+```json
+{ "extends": ["../shared/base.json", "../shared/theme.json"] }

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @skills/likec4-dsl/references/configuration.md around lines 166 - 170, The
two consecutive JSON objects shown as examples for "extends" are ambiguous;
update the section in configuration.md so each example is clearly labeled and
separated (e.g., "Single path:" with { "extends": "../shared/likec4.config.json" } and "Multiple paths:" with { "extends": ["../shared/base.json", "../shared/theme.json"] }), wrap each example in its
own JSON code fence, and add a one-line explanatory note that they are
alternative usages of the extends property to avoid confusion.

</details>

---

`214-225`: **Consider adding a language identifier to the directory tree block.**

The directory structure block triggers a markdown lint warning. Using `text` or leaving it as-is are both acceptable, but adding a language identifier improves consistency.

<details>
<summary>📝 Suggested fix</summary>

```diff
-```
+```text
 workspace/
 ├─ project-a/
 │  ├─ likec4.config.json    ← project "a"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@skills/likec4-dsl/references/configuration.md` around lines 214 - 225, Update
the code block in configuration.md that shows the directory tree to include a
language identifier (e.g., change the opening fence from ``` to ```text) so the
markdown linter stops warning about an unspecified language; locate the
directory structure block under the example workspace (the triple-backtick block
containing workspace/, project-a/, project-b/, shared/) and add the language tag
to the opening fence.

skills/likec4-dsl/references/predicates.md (1)

13-18: Consider adding a language identifier to the grammar code block.

The syntax grammar block lacks a language identifier. While BNF/EBNF doesn't have a standard markdown identifier, using text or bnf improves consistency and avoids linter warnings.

📝 Suggested fix

-```
+```text
 BASE_PREDICATE ::= WILDCARD | ELEMENT_EXPRESSION | RELATIONSHIP_EXPRESSION
 FILTER_PREDICATE ::= BASE_PREDICATE where FILTER_CONDITIONS
 CUSTOM_PREDICATE ::= (BASE_PREDICATE | FILTER_PREDICATE) with { ... }
 PREDICATE ::= BASE_PREDICATE | FILTER_PREDICATE | CUSTOM_PREDICATE

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @skills/likec4-dsl/references/predicates.md around lines 13 - 18, Add a
language identifier to the fenced code block containing the grammar (the block
with BASE_PREDICATE, FILTER_PREDICATE, CUSTOM_PREDICATE, PREDICATE) to satisfy
linters and improve consistency; change the opening fence from totext
(or ```bnf) so the grammar lines (BASE_PREDICATE ::= WILDCARD |
ELEMENT_EXPRESSION | RELATIONSHIP_EXPRESSION, FILTER_PREDICATE ::=
BASE_PREDICATE where FILTER_CONDITIONS, CUSTOM_PREDICATE ::= (BASE_PREDICATE |
FILTER_PREDICATE) with { ... }, PREDICATE ::= BASE_PREDICATE | FILTER_PREDICATE
| CUSTOM_PREDICATE) are inside a labeled block.

</details>

</blockquote></details>
<details>
<summary>skills/likec4-dsl/references/views.md (1)</summary><blockquote>

`84-93`: **Align dynamic-view grammar with the ordering explanation.**

The prose explains `exclude` ordering, but `DYNAMIC_VIEW_RULES` only lists `STEP` and style rules. Consider adding `include`/`exclude` entries (or narrowing the prose) to avoid ambiguity.

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@skills/likec4-dsl/references/views.md` around lines 84 - 93, The grammar and
prose disagree: the DYNAMIC_VIEW_RULES production lists only STEP and
DYNAMIC_VIEW_STYLE_RULE but the text discusses include/exclude ordering; update
the grammar to reflect the described ordering by adding tokens/productions for
include and exclude (e.g., INCLUDE_STEP / EXCLUDE_STEP or explicit INCLUDE_RULE
/ EXCLUDE_RULE entries) into DYNAMIC_VIEW_RULES so rules are applied in
sequence, or alternatively adjust the prose to remove mention of include/exclude
and describe only the existing STEP/style semantics; reference
DYNAMIC_VIEW_RULES, STEP, and DYNAMIC_VIEW_STYLE_RULE when making the change.
```

</details>

</blockquote></details>
<details>
<summary>packages/language-services/src/common/LikeC4.ts (3)</summary><blockquote>

`21-23`: **Consider documenting the magic number for severity.**

The value `1` corresponds to `DiagnosticSeverity.Error` from `vscode-languageserver-types`. Since the import was removed, consider adding a brief comment to clarify this mapping for future maintainers.

```diff
+// DiagnosticSeverity.Error === 1 (from vscode-languageserver-types)
 const isErrorDiagnostic = (diagnostic: { severity?: number }): boolean => {
   return diagnostic.severity === 1
 }
```

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@packages/language-services/src/common/LikeC4.ts` around lines 21 - 23, The
function isErrorDiagnostic uses a magic number (1) for diagnostic.severity;
document that mapping by adding a brief inline comment near isErrorDiagnostic
explaining that 1 corresponds to DiagnosticSeverity.Error (from
vscode-languageserver-types) so future maintainers understand the value without
the import; keep the function logic unchanged and place the comment next to the
isErrorDiagnostic declaration or the diagnostic.severity comparison.
```

</details>

---

`204-209`: **Simplify `documentCount()` implementation.**

The `toArray()` call creates an intermediate array just to get the length. Consider using a more direct approach if the stream supports it, or document why `toArray()` is necessary.

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@packages/language-services/src/common/LikeC4.ts` around lines 204 - 209,
documentCount() builds an intermediate array via
this.LangiumDocuments.all.toArray().length; replace it with a direct count to
avoid allocation: if this.LangiumDocuments.all exposes a size/length property
use return this.LangiumDocuments.all.size (or .length), otherwise iterate the
iterable and increment a counter (e.g. let c=0; for (const _ of
this.LangiumDocuments.all) c++; return c;). Update the documentCount() method
accordingly (referencing documentCount and LangiumDocuments.all).
```

</details>

---

`165-167`: **Use optional chaining for cleaner code.**

As flagged by static analysis, the condition can be simplified using optional chaining.

<details>
<summary>♻️ Proposed fix</summary>

```diff
   hasErrors(): boolean {
     return this.LangiumDocuments.userDocuments.some(doc => {
-      return doc.diagnostics && doc.diagnostics.some(isErrorDiagnostic)
+      return doc.diagnostics?.some(isErrorDiagnostic) ?? false
     })
   }
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@packages/language-services/src/common/LikeC4.ts` around lines 165 - 167,
Replace the manual null-check with optional chaining: in the expression that
inspects this.LangiumDocuments.userDocuments, change the predicate to use
doc.diagnostics?.some(isErrorDiagnostic) so the some() call is only invoked when
diagnostics exists; reference the LangiumDocuments.userDocuments array and the
isErrorDiagnostic function when making this change.
```

</details>

</blockquote></details>
<details>
<summary>packages/likec4/src/cli/validate/index.ts (1)</summary><blockquote>

`146-151`: **Stats `filteredFiles` may be misleading when no filter is applied.**

When `fileFilter` is null, `filteredFiles` is set to `totalFiles` (all workspace files). However, this doesn't represent files with errors—it represents all files. This could confuse consumers expecting `filteredFiles` to mean "files with errors in scope."

Consider renaming or documenting the semantics more clearly, or computing the actual count of files with errors.

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/src/cli/validate/index.ts` around lines 146 - 151, The stats
field currently sets filteredFiles to totalFiles when fileFilter is null, which
misrepresents "files with errors in scope"; change the logic so
stats.filteredFiles always reflects the count of files with errors in scope by
using filteredFileSet.size (i.e., set filteredFiles: filteredFileSet.size)
instead of conditional totalFiles, and ensure filteredFileSet is constructed to
contain only files that have errors (so filteredErrors and filteredFileSet
remain consistent); alternatively, if you prefer to keep the existing semantics,
rename filteredFiles to something explicit (e.g., scopedFileCount) and update
any callers/documentation accordingly.
```

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>🤖 Prompt for all review comments with AI agents</summary>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @packages/language-services/src/common/LikeC4.ts:

• Around line 172-200: printErrors() currently iterates
  this.LangiumDocuments.all causing inconsistency with getErrors()/hasErrors()
  which use this.LangiumDocuments.userDocuments; change the iteration in
  printErrors() to use this.LangiumDocuments.userDocuments, preserving the
  existing filtering (errors = doc.diagnostics?.filter(isErrorDiagnostic) ?? []),
  message truncation and logging logic so printed errors match what
  getErrors()/hasErrors() report for user documents only.
• Around line 148-159: The truncation logic builds a messages array but never
  uses it in the errors.map callback, leaving dead code; fix by either removing
  the messages variable and its truncation block, or by returning the truncated
  text (e.g., set the returned object's message to the truncated value built
  from messages, e.g., join with '\n'); locate the callback where errors.map(({ message, range }) => { ... }) and update the message field in the returned
  object (or remove the unused messages block) accordingly, keeping range,
  line, and sourceFsPath: doc.uri.fsPath as-is.

In @packages/likec4/src/cli/validate/index.ts:

• Around line 111-116: The fallback for resolving the file path creates entries
  like '/workspace/.' when view.sourcePath is undefined; update the resolve call
  in the layout error push (layoutErrors.push block) to use a better fallback than
  '.' — e.g., use an empty string or view.id (resolve(args.path, view.sourcePath
  ?? '', ) or resolve(args.path, view.sourcePath ?? view.id)) so reported file
  paths are meaningful; ensure you update the message/file pair consistently where
  view.sourcePath is referenced.
• Around line 134-136: The current file filtering logic (building filteredErrors
  from allErrors using fileFilter and e.file.endsWith(f)) can yield false
  positives (e.g., "model.c4" matching "other-model.c4"); update the filter in
  validate/index.ts to perform a path-aware comparison: for each f in fileFilter
  compare against e.file using path utilities (e.g., path.basename(e.file) === f
  or normalize both paths and check equality or check endsWith with a path
  separator like ${path.sep}${f}) so matches respect directory boundaries;
  adjust the filtering loop that constructs filteredErrors (references:
  filteredErrors, fileFilter, allErrors, e.file) to use the chosen path-based
  comparison and ensure both relative and absolute paths are normalized before
  comparison.
• Around line 119-126: The catch currently lumps all errors into layoutErrors;
  change it so infrastructure errors from ensureProjectId are surfaced as
  fatal/descriptive errors while only actual layout validation failures are pushed
  to layoutErrors. Concretely: in the catch near layoutErrors push, detect
  infrastructure errors from ensureProjectId (preferably by making/using a
  specific error class like ProjectNotRegisteredError or checking e.name/e.message
  for the known ensureProjectId failure texts) and for those call process.exit(1)
  or rethrow a clear Error (e.g., Project ID X is not registered); otherwise
  (non-infrastructure errors) keep the existing behavior of pushing a diagnostic
  into layoutErrors. Update imports/signatures to use the specific error class if
  you add one and reference ensureProjectId, layoutErrors and the current catch
  block when making the change.

In @skills/likec4-dsl/references/configuration.md:

• Around line 176-185: The code block contains inline JavaScript-style comments
  which are invalid in standard JSON; update the examples around the "landingPage"
  object to either remove the comment lines or mark the fences as json5 if
  comments are intended. Specifically, provide three separate valid code blocks
  showing the "landingPage" examples (one with { "landingPage": { "redirect": true
  } }, one with { "landingPage": { "include": ["overview","cloud-detail"] } }, and
  one with { "landingPage": { "exclude": ["internal-debug"] } }) and remove the
  leading // comments (or change the triple-backtick fence to ```json5 if you want
  to keep comments).

In @skills/likec4-dsl/references/deployment.md:

• Around line 171-174: The documentation's style block references an undefined
  node "server4" (style server1., server4. { color green }) while the deployment
  example only defines server1, server2, and server3; update the example to
  include a server4 definition or change the style rule to reference an existing
  node (e.g., replace server4._ with server2._ or server3.) so the FQN in the
  style rule matches an actual deployment node (look for the deployment model
  definitions for server1/server2/server3 and the style block containing
  server1., server4._).

In @skills/likec4-dsl/references/dynamic-views.md:

• Line 3: The fenced code block in dynamic-views.md is missing a language tag
  which triggers MD040; update the opening triple-backtick fence for the
  tree-style block to include the language tag "text" (i.e., change ``` to

In `@skills/likec4-dsl/references/predicates.md`:
- Line 26: The example predicate `include * where tag s `#production`       //
FILTER_PREDICATE` contains a typo; replace `tag s` with `tag is` in the
FILTER_PREDICATE example so the predicate reads `tag is `#production`` (fix the
example line that includes the comment `// FILTER_PREDICATE`).

In `@skills/likec4-dsl/references/views.md`:
- Line 14: Several fenced code blocks in the document are missing language
identifiers (triggering MD040); update the fences so the block containing the
DSL "views { ... }" and the block starting with "include PREDICATE, PREDICATE,
..." use a likec4 fence (```likec4) and the block that defines the grammar "STEP
::=" uses a text fence (```text), ensuring each opening triple-backtick is
followed by the correct language identifier to satisfy markdown linting.

In `@skills/likec4-dsl/SKILL.md`:
- Line 91: Several fenced code blocks in SKILL.md lack language identifiers and
fail MD040; update the unlabeled blocks for decision trees to use the language
tag "text" and the DSL snippets to use "likec4" (specifically the unlabeled
blocks showing the decision tree "What kind of diagram?" and the DSL blocks with
"specification { ... }", "model { ... }", and "views { ... }"), i.e., change the
opening triple-backtick lines so they read ```text for the decision-tree block
and ```likec4 for each DSL snippet (also apply the same change to the other
occurrences noted at lines 104, 124, 138, 152, 210, and 369).

---

Nitpick comments:
In `@packages/language-services/src/common/LikeC4.ts`:
- Around line 21-23: The function isErrorDiagnostic uses a magic number (1) for
diagnostic.severity; document that mapping by adding a brief inline comment near
isErrorDiagnostic explaining that 1 corresponds to DiagnosticSeverity.Error
(from vscode-languageserver-types) so future maintainers understand the value
without the import; keep the function logic unchanged and place the comment next
to the isErrorDiagnostic declaration or the diagnostic.severity comparison.
- Around line 204-209: documentCount() builds an intermediate array via
this.LangiumDocuments.all.toArray().length; replace it with a direct count to
avoid allocation: if this.LangiumDocuments.all exposes a size/length property
use return this.LangiumDocuments.all.size (or .length), otherwise iterate the
iterable and increment a counter (e.g. let c=0; for (const _ of
this.LangiumDocuments.all) c++; return c;). Update the documentCount() method
accordingly (referencing documentCount and LangiumDocuments.all).
- Around line 165-167: Replace the manual null-check with optional chaining: in
the expression that inspects this.LangiumDocuments.userDocuments, change the
predicate to use doc.diagnostics?.some(isErrorDiagnostic) so the some() call is
only invoked when diagnostics exists; reference the
LangiumDocuments.userDocuments array and the isErrorDiagnostic function when
making this change.

In `@packages/likec4/src/cli/validate/index.ts`:
- Around line 146-151: The stats field currently sets filteredFiles to
totalFiles when fileFilter is null, which misrepresents "files with errors in
scope"; change the logic so stats.filteredFiles always reflects the count of
files with errors in scope by using filteredFileSet.size (i.e., set
filteredFiles: filteredFileSet.size) instead of conditional totalFiles, and
ensure filteredFileSet is constructed to contain only files that have errors (so
filteredErrors and filteredFileSet remain consistent); alternatively, if you
prefer to keep the existing semantics, rename filteredFiles to something
explicit (e.g., scopedFileCount) and update any callers/documentation
accordingly.

In `@skills/likec4-dsl/references/configuration.md`:
- Around line 166-170: The two consecutive JSON objects shown as examples for
"extends" are ambiguous; update the section in configuration.md so each example
is clearly labeled and separated (e.g., "Single path:" with `{ "extends":
"../shared/likec4.config.json" }` and "Multiple paths:" with `{ "extends":
["../shared/base.json", "../shared/theme.json"] }`), wrap each example in its
own JSON code fence, and add a one-line explanatory note that they are
alternative usages of the extends property to avoid confusion.
- Around line 214-225: Update the code block in configuration.md that shows the
directory tree to include a language identifier (e.g., change the opening fence
from ``` to ```text) so the markdown linter stops warning about an unspecified
language; locate the directory structure block under the example workspace (the
triple-backtick block containing workspace/, project-a/, project-b/, shared/)
and add the language tag to the opening fence.

In `@skills/likec4-dsl/references/predicates.md`:
- Around line 13-18: Add a language identifier to the fenced code block
containing the grammar (the block with BASE_PREDICATE, FILTER_PREDICATE,
CUSTOM_PREDICATE, PREDICATE) to satisfy linters and improve consistency; change
the opening fence from ``` to ```text (or ```bnf) so the grammar lines
(BASE_PREDICATE ::= WILDCARD | ELEMENT_EXPRESSION | RELATIONSHIP_EXPRESSION,
FILTER_PREDICATE ::= BASE_PREDICATE where FILTER_CONDITIONS, CUSTOM_PREDICATE
::= (BASE_PREDICATE | FILTER_PREDICATE) with { ... }, PREDICATE ::=
BASE_PREDICATE | FILTER_PREDICATE | CUSTOM_PREDICATE) are inside a labeled
block.

In `@skills/likec4-dsl/references/views.md`:
- Around line 84-93: The grammar and prose disagree: the DYNAMIC_VIEW_RULES
production lists only STEP and DYNAMIC_VIEW_STYLE_RULE but the text discusses
include/exclude ordering; update the grammar to reflect the described ordering
by adding tokens/productions for include and exclude (e.g., INCLUDE_STEP /
EXCLUDE_STEP or explicit INCLUDE_RULE / EXCLUDE_RULE entries) into
DYNAMIC_VIEW_RULES so rules are applied in sequence, or alternatively adjust the
prose to remove mention of include/exclude and describe only the existing
STEP/style semantics; reference DYNAMIC_VIEW_RULES, STEP, and
DYNAMIC_VIEW_STYLE_RULE when making the change.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1f9bbcbb-b68d-4b4d-a80f-ff568ff298ac

📥 Commits

Reviewing files that changed from the base of the PR and between 221dc04 and b268f5a.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (17)

• .changeset/improve-validate-command.md
• .claude/skills/likec4-dsl
• apps/docs/astro.config.mjs
• apps/docs/package.json
• apps/docs/src/content.config.ts
• packages/language-services/src/common/LikeC4.ts
• packages/likec4/src/cli/check-update/utils.ts
• packages/likec4/src/cli/index.ts
• packages/likec4/src/cli/options.ts
• packages/likec4/src/cli/validate/index.ts
• pnpm-workspace.yaml
• skills/likec4-dsl/SKILL.md
• skills/likec4-dsl/references/configuration.md
• skills/likec4-dsl/references/deployment.md
• skills/likec4-dsl/references/dynamic-views.md
• skills/likec4-dsl/references/predicates.md
• skills/likec4-dsl/references/views.md

packages/likec4/src/cli/validate/index.ts (1)

107-126: ⚠️ Potential issue | 🔴 Critical

Do not turn invalid --project into a filterable validation diagnostic.

packages/language-services/src/common/LikeC4.ts:95-98 resolves the project inside diagrams(). If that throws, this catch wraps the failure as { file: '' }, so a later --file filter can drop it and return valid: true / exit 0 for an invalid project. Re-throw setup/project-resolution failures instead of pushing them into layoutErrors.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/src/cli/validate/index.ts` around lines 107 - 126, The catch
around languageServices.diagrams(args.project) is turning
project-resolution/setup failures into a filterable validation diagnostic;
instead, detect and re-throw those setup/project-resolution errors (so they
cannot be dropped by a --file filter) and only push true diagram layout
validation errors into layoutErrors. Update the try/catch in index.ts: call
languageServices.diagrams(args.project) inside try, and in the catch rethrow
when the error originates from project resolution (preferably by checking for a
specific error type exported by LikeC4 such as ProjectResolutionError or by
matching a clear marker on the Error), otherwise push the error into
layoutErrors as before; reference symbols: languageServices.diagrams,
layoutErrors, args.project, and the project-resolution error type from LikeC4
(e.g., ProjectResolutionError).

packages/language-services/src/common/LikeC4.ts (2)

158-160: Consider using optional chaining for conciseness.

The static analyzer flagged that optional chaining would be more idiomatic here.

♻️ Proposed fix

   hasErrors(): boolean {
     return this.LangiumDocuments.userDocuments.some(doc => {
-      return doc.diagnostics && doc.diagnostics.some(isErrorDiagnostic)
+      return doc.diagnostics?.some(isErrorDiagnostic) ?? false
     })
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/language-services/src/common/LikeC4.ts` around lines 158 - 160,
Replace the verbose null-check in the predicate with optional chaining: inside
the some over this.LangiumDocuments.userDocuments (the arrow function that
currently checks doc.diagnostics && doc.diagnostics.some(isErrorDiagnostic)),
use doc.diagnostics?.some(isErrorDiagnostic) (or
Boolean(doc.diagnostics?.some(isErrorDiagnostic))) so the code is more concise
and idiomatic while still using the existing LangiumDocuments, userDocuments and
isErrorDiagnostic symbols.

---

197-202: Consider using .toArray().length for consistency and explicitness.

The userDocuments property returns a Stream<LikeC4LangiumDocument> which doesn't expose a direct .length or .size property. While spreading to get the length works, it's slightly inefficient since it forces full array materialization. Other parts of the codebase explicitly call .toArray() (e.g., packages/language-services/src/node/index.ts) before accessing .length. For consistency and clarity, use .toArray().length instead of spreading.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/language-services/src/common/LikeC4.ts` around lines 197 - 202, The
documentCount() method currently computes length by spreading
LangiumDocuments.userDocuments into an array; change it to call
LangiumDocuments.userDocuments.toArray().length for consistency and explicit
materialization (replace [...this.LangiumDocuments.userDocuments].length with
this.LangiumDocuments.userDocuments.toArray().length in the documentCount()
method).

skills/likec4-dsl/SKILL.md (1)

48-66: ⚠️ Potential issue | 🟡 Minor

json example is invalid due to inline comments.

The stats object uses // comments inside a ```json block, so the example is not valid JSON and can fail copy/paste validation.

🛠️ Proposed fix

   "stats": {
-    "totalFiles": 100, // Total number of files in the project
-    "totalErrors": 500, // Total number of errors in the project
-    "filteredFiles": 1, // Number of files that match the --file filter
-    "filteredErrors": 1 // Number of errors in the filtered files
+    "totalFiles": 100,
+    "totalErrors": 500,
+    "filteredFiles": 1,
+    "filteredErrors": 1
   }

#!/bin/bash
# Read-only check: find JSON-fenced blocks in SKILL.md that contain JS-style comments.
# Expected: no matches after fix.
awk '
  /^```json$/ { in_json=1; next }
  /^```$/ && in_json { in_json=0; next }
  in_json && /\/\// { print FNR ":" $0 }
' skills/likec4-dsl/SKILL.md

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@skills/likec4-dsl/SKILL.md` around lines 48 - 66, The JSON example in the
```json``` block contains JS-style inline comments inside the stats object which
makes it invalid JSON; edit the SKILL.md JSON example to remove the // comments
(or replace them with real numeric values or a separate explanatory field) so
the block is valid JSON, specifically update the "stats" object in the code
fence (the keys "totalFiles", "totalErrors", "filteredFiles", "filteredErrors")
to not include any // comments and ensure the entire fenced block parses as
strict JSON.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes