routeros-syntax-inspection

Name: routeros-syntax-inspection
Author: tikoci

36stars8forks

How to install routeros-syntax-inspection?

tikoci/routeros-skills/routeros-syntax-inspection

$npx -y skills add tikoci/routeros-skills --skill routeros-syntax-inspection

Installs into the current project.

Summary

Inspecting and validating RouterOS command/script syntax against a live device via /console/inspect (highlight, completion, syntax, child) and :parse IL. Use when: validating RouterOS commands before execution, explaining or linting RouterOS scripts, building syntax-aware tooling

Files · 1

View on GitHub

SKILL.md

1	# RouterOS Syntax Inspection
2
3	## Overview
4
5	RouterOS exposes its own parser over the REST API: `/console/inspect`
6	classifies every byte of console input (`highlight`), proposes continuations
7	(`completion`), returns structured help (`syntax`), and enumerates the command
8	tree (`child`); the `:parse` scripting command returns the intermediate
9	language (IL) the engine actually executes. Together these are the ground
10	truth for "is this valid RouterOS?" — version-exact, package-exact, and even
11	runtime-state-exact, which no static grammar can be.
12
13	This skill is a probe-selection and wire-format guide: which surface
14	answers which question, how to read each response, and which claims the
15	responses do and do not support. It is grounded in full-corpus captures
16	(913 scripts × multiple RouterOS versions) published in
17	[tikoci/lsp-routeros-ts](https://github.com/tikoci/lsp-routeros-ts) — the
18	`docs/` references there carry the full evidence [^1].
19
20	"Parse RouterOS" is not one operation. Pick the probe for the question:
21
22	\| Question \| Probe \| What it cannot establish \|
23	\|---\|---\|---\|
24	\| Which span is a command, argument, variable, comment, live-state marker? \| `request=highlight` \| Nested structure; value validity; anything after the first hard error \|
25	\| Is the script structurally valid; what blocks/expressions result? \| `:parse` \| Source ranges; partial IL on error; path/argument split without schema data \|
26	\| What is valid at this cursor position? Enum values? \| `request=completion` \| Requiredness; exhaustiveness of candidate lists; runtime acceptance \|
27	\| What paths, commands, arguments exist on this device? \| `request=child` + `request=syntax` \| Enum values (those come from `completion`); required arguments \|
28	\| Which arguments are required? \| Execute-error probe (`add` with no args) \| Conditional requirements past the first discriminator \|
29
30	Details per surface: [references/highlight.md](references/highlight.md),
31	[references/parseil.md](references/parseil.md),
32	[references/command-schema.md](references/command-schema.md),
33	[references/validation.md](references/validation.md).
34
35	For crawling the full command hierarchy (`child` traversal, schema/RAML/OpenAPI
36	generation), see the `routeros-command-tree` skill — this skill covers the
37	syntax/validity surfaces of the same `/console/inspect` endpoint.
38
39	## Request shape
40
41	All four inspect surfaces share one endpoint (basic auth, any RouterOS 7.x):
42
43	```text
44	POST /rest/console/inspect
45	{"request": "highlight" \| "completion" \| "syntax" \| "child",
46	"input": "<console input>", // optional
47	"path": "ip,address,add"} // optional comma-separated menu context
48	```
49
50	Every successful response is a JSON array of flat all-string objects with a
51	`type` field naming the request type. Beyond that, the four response shapes
52	share nothing — treat them as four APIs behind one endpoint.
53
54	## Version baseline and safety
55
56	- Baseline: RouterOS 7.20.8 — a long-term-channel release, used here as the
57	recommended floor: the parseIL and crash-path behavior below was captured on
58	it [^1][^3]. REST itself exists since 7.1beta4 (HTTPS-only at first [^2]);
59	behavior below 7.20.8 is best-effort (7.9.2 was measured but harsher — see
60	[references/highlight.md](references/highlight.md)), and RouterOS v6 has no
61	REST API at all.
62	- Always set a per-request timeout (a few seconds). Old versions can hang
63	the whole REST server on specific inspect calls; a hung server also makes
64	subsequent unrelated probes appear broken.
65	- Known hazards (all measured, see [^1] and [^3]):
66
67	\| Hazard \| Versions \| Rule \|
68	\|---\|---\|---\|
69	\| `request=syntax`/`completion` at bare path `do` deadlocks the REST server \| ≤ 7.20.8 (fixed by 7.21.4) [^3] \| Skip scripting-keyword paths (`where`, `do`, `else`, `rule`, `command`, `on-error`) on old/unknown versions; it is a conservative skip policy, not a timeless six-path crash rule \|
70	\| `request=syntax` with `input`, or command-level `syntax`, stalls ~60 s \| observed on 7.9.2 \| Query `syntax` by `path` only; feature-detect command-level lookups with a short timeout \|
71	\| `input` beyond 32,767 bytes rejected \| all \| Route oversized input to `:parse` (no cap) or reject it — never highlight a truncated copy and present it as validating the whole script \|
72	\| Highlight latency cliff near 28 KB \| observed 7.23.x \| Prefer a `:parse` pre-check for big scripts (no such cliff, no 32

People who liked this also viewed

6 picks

Type

routeros-syntax-inspection

36stars8forks

View on GitHub

How to install routeros-syntax-inspection?

tikoci/routeros-skills/routeros-syntax-inspection

$npx -y skills add tikoci/routeros-skills --skill routeros-syntax-inspection

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# RouterOS Syntax Inspection
2
3	## Overview
4
5	RouterOS exposes its own parser over the REST API: `/console/inspect`
6	classifies every byte of console input (`highlight`), proposes continuations
7	(`completion`), returns structured help (`syntax`), and enumerates the command
8	tree (`child`); the `:parse` scripting command returns the intermediate
9	language (IL) the engine actually executes. Together these are the ground
10	truth for "is this valid RouterOS?" — version-exact, package-exact, and even
11	runtime-state-exact, which no static grammar can be.
12
13	This skill is a probe-selection and wire-format guide: which surface
14	answers which question, how to read each response, and which claims the
15	responses do and do not support. It is grounded in full-corpus captures
16	(913 scripts × multiple RouterOS versions) published in
17	[tikoci/lsp-routeros-ts](https://github.com/tikoci/lsp-routeros-ts) — the
18	`docs/` references there carry the full evidence [^1].
19
20	"Parse RouterOS" is not one operation. Pick the probe for the question:
21
22	\| Question \| Probe \| What it cannot establish \|
23	\|---\|---\|---\|
24	\| Which span is a command, argument, variable, comment, live-state marker? \| `request=highlight` \| Nested structure; value validity; anything after the first hard error \|
25	\| Is the script structurally valid; what blocks/expressions result? \| `:parse` \| Source ranges; partial IL on error; path/argument split without schema data \|
26	\| What is valid at this cursor position? Enum values? \| `request=completion` \| Requiredness; exhaustiveness of candidate lists; runtime acceptance \|
27	\| What paths, commands, arguments exist on this device? \| `request=child` + `request=syntax` \| Enum values (those come from `completion`); required arguments \|
28	\| Which arguments are required? \| Execute-error probe (`add` with no args) \| Conditional requirements past the first discriminator \|
29
30	Details per surface: [references/highlight.md](references/highlight.md),
31	[references/parseil.md](references/parseil.md),
32	[references/command-schema.md](references/command-schema.md),
33	[references/validation.md](references/validation.md).
34
35	For crawling the full command hierarchy (`child` traversal, schema/RAML/OpenAPI
36	generation), see the `routeros-command-tree` skill — this skill covers the
37	syntax/validity surfaces of the same `/console/inspect` endpoint.
38
39	## Request shape
40
41	All four inspect surfaces share one endpoint (basic auth, any RouterOS 7.x):
42
43	```text
44	POST /rest/console/inspect
45	{"request": "highlight" \| "completion" \| "syntax" \| "child",
46	"input": "<console input>", // optional
47	"path": "ip,address,add"} // optional comma-separated menu context
48	```
49
50	Every successful response is a JSON array of flat all-string objects with a
51	`type` field naming the request type. Beyond that, the four response shapes
52	share nothing — treat them as four APIs behind one endpoint.
53
54	## Version baseline and safety
55
56	- Baseline: RouterOS 7.20.8 — a long-term-channel release, used here as the
57	recommended floor: the parseIL and crash-path behavior below was captured on
58	it [^1][^3]. REST itself exists since 7.1beta4 (HTTPS-only at first [^2]);
59	behavior below 7.20.8 is best-effort (7.9.2 was measured but harsher — see
60	[references/highlight.md](references/highlight.md)), and RouterOS v6 has no
61	REST API at all.
62	- Always set a per-request timeout (a few seconds). Old versions can hang
63	the whole REST server on specific inspect calls; a hung server also makes
64	subsequent unrelated probes appear broken.
65	- Known hazards (all measured, see [^1] and [^3]):
66
67	\| Hazard \| Versions \| Rule \|
68	\|---\|---\|---\|
69	\| `request=syntax`/`completion` at bare path `do` deadlocks the REST server \| ≤ 7.20.8 (fixed by 7.21.4) [^3] \| Skip scripting-keyword paths (`where`, `do`, `else`, `rule`, `command`, `on-error`) on old/unknown versions; it is a conservative skip policy, not a timeless six-path crash rule \|
70	\| `request=syntax` with `input`, or command-level `syntax`, stalls ~60 s \| observed on 7.9.2 \| Query `syntax` by `path` only; feature-detect command-level lookups with a short timeout \|
71	\| `input` beyond 32,767 bytes rejected \| all \| Route oversized input to `:parse` (no cap) or reject it — never highlight a truncated copy and present it as validating the whole script \|
72	\| Highlight latency cliff near 28 KB \| observed 7.23.x \| Prefer a `:parse` pre-check for big scripts (no such cliff, no 32

People who liked this also viewed

6 picks

Type