chore(chat-plugin): sync robotcode skill from agent-plugins

Author: d-biehl

chat-plugins/.upstream.json

@@ -1,5 +1,5 @@
 {
   "source": "github.com/robotcodedev/robotframework-agent-plugins",
-  "sha": "d34d3bb6c827396a7697df575ed716854b160eb2",
-  "syncedAt": "2026-06-08T21:40:39+00:00"
+  "sha": "ecd37256b627ed9c6e65e0bab981377e0f7c0d86",
+  "syncedAt": "2026-06-08T22:04:26+00:00"
 }

chat-plugins/robotcode/skills/robotcode/SKILL.md

@@ -35,7 +35,7 @@ Decide what the user actually wants *before* reaching for a command — these in
 
 - **Use the REPL — explore, with no existing test in play** — *"try this keyword", "open a Robot shell", "go to … and check", "fetch …", "build this keyword step by step", "does this keyword/library work?", "so I can watch it drive the app".* Standalone interactive work: poke at a keyword, drive the application, prototype a keyword/test line by line. **Not for anything involving a real test case** — running it, watching it run, stepping it, inspecting its live state, or *why it fails*: the REPL runs in a *different context* (no suite setup, variables, or `__init__.robot`), so use **Debug** for that — it runs the *real* test in its real context, with keywords available at the `(rdb)` stop. "Interactive" does **not** mean the REPL once a test case is in play. See [references/repl.md](references/repl.md).
 - **Author tests or keywords** — *"write / create / add a test or suite".* See [references/authoring.md](references/authoring.md).
-- **Run a suite or tests** — *"run the tests", "execute the smoke suite", "run only tag X", "run just suite Y / this one test".* A whole suite, or a subset filtered by tag/suite/name. **To run one test, select it by longname (`-bl`), not the `.robot` file** — the file may hold other tests, and a bare file skips the parent suites' `__init__.robot`. See [Running tests](#running-tests--robotcode-robot).
+- **Run a suite or tests** — *"run the tests", "execute the smoke suite", "run only tag X", "run just suite Y / this one test".* A whole suite, or a subset filtered by tag/suite/name. **To run one test, task, or suite, select it by longname (`-bl`), not a `.robot` file** — a single file becomes the top suite and skips the parent suites' `__init__.robot` (a whole directory is fine; it loads it). See [Running tests](#running-tests--robotcode-robot).
 - **Inspect or compare a finished run** — *"what failed?", "did it pass?", "why did X fail?", "did this regress?", "what changed since the last run?".* No re-run; try this **first** for "why did X fail?". See [references/results.md](references/results.md).
 - **Debug a live run** — *"fix this test", "why does this test fail / won't it run?", "step through it", "watch / inspect this test as it runs", "break at line X", "what is `${response}` there?", "try this in the actual test/suite".* Pause the real run; inspect the live stack/variables **and run keywords at the `(rdb)` prompt in the real context**. This — not the REPL — is how you experiment *inside* a real test or suite. Also the tightest **loop while developing or fixing a test**: run it via `robot-debug` rather than a plain `robot` run, so a failure stops you live to investigate and prove a fix on the spot — then write that fix into the file and re-run to confirm, since running it at the prompt doesn't change the source (a clean pass just runs through). See [references/debugging.md](references/debugging.md).
 - **Analyze / lint the code** — *"find issues", "check my robot code", "any undefined keywords / wrong arguments?", "are there unused keywords or variables?".* Static analysis (errors, undefined keywords, wrong args, unresolved/unused variables), no run. See [references/analyze.md](references/analyze.md).
@@ -140,12 +140,12 @@ robotcode discover suites
 
 RobotCode also adds exact longname filters:
 
-- `-bl, --by-longname "Suite.Sub.Test"` — include exact longnames.
-- `-ebl, --exclude-by-longname "Suite.Sub.Test"` — exclude exact longnames.
+- `-bl, --by-longname "Suite.Sub.Test"` — include by exact longname (a test, task, or whole suite).
+- `-ebl, --exclude-by-longname "Suite.Sub.Test"` — exclude by exact longname (test, task, or suite).
 
 Use longname filters when you copied a full name from `discover` or `results show` and want to avoid glob ambiguity.
 
-**To run or debug one specific test, select it by its longname (`-bl "<longname>"`) — never by passing the `.robot` file.** This holds for `robotcode robot` and `robotcode robot-debug` alike: the file usually contains other tests (a bare path runs them all), and pointing Robot at a single file makes it the top suite, so the parent suites' `__init__.robot` (suite setup/teardown, suite variables, tags, and timeouts) never runs and the test behaves unlike a real run. Get the longname from `discover` or `results`; to run a whole directory/suite, pass the directory (it loads its `__init__.robot`), not one file.
+**To run or debug one specific test, task, or suite, select it by its longname (`-bl "<longname>"`) — never by passing the `.robot` file.** This holds for `robotcode robot` and `robotcode robot-debug` alike: pointing Robot at a single file makes it the top suite, so the parent suites' `__init__.robot` (suite setup/teardown, suite variables, tags, and timeouts) never runs and it behaves unlike a real run (and a file with several tests runs them all). Get the longname from `discover` or `results`. The one path form that's fine is a whole **directory** (it loads its `__init__.robot`) — never a single `.robot` file.
 
 ## Discovery — what's in the project?
 
@@ -206,7 +206,7 @@ robotcode robot -bl "Suite.Sub.Test Name"
 robotcode robot --rerunfailed output.xml
 ```
 
-**To run one specific test, select it by longname (`-bl "<longname>"`, copied from `discover` or `results`) — not by its file path.** Pointing Robot at a single `.robot` file makes that file the top suite, so the parent suites' `__init__.robot` — its Suite Setup/Teardown, suite variables, and the setup/tags/timeouts it applies to the tests below — never runs, and the test can behave differently than in a full run. Selecting by longname builds the whole suite tree from `robot.toml` paths, so that initialization applies. The same holds under the debugger (see *Debugging a run*).
+**To run one specific test, task, or suite, select it by longname (`-bl "<longname>"`, copied from `discover` or `results`) — not by its file path.** Pointing Robot at a single `.robot` file makes that file the top suite, so the parent suites' `__init__.robot` — its Suite Setup/Teardown, suite variables, and the setup/tags/timeouts it applies — never runs, and it can behave differently than in a full run. Selecting by longname builds the whole suite tree from `robot.toml` paths, so that initialization applies. To run a whole **directory** tree, pass the directory (it loads its `__init__.robot`) — just never a single `.robot` file. The same holds under the debugger (see *Debugging a run*).
 
 Do not append paths or output options by default; `robot.toml` often already provides them. Add CLI paths only to narrow a one-off run (a *directory* is fine — it loads its `__init__.robot`; a single test file is not, see above).
 
@@ -282,7 +282,7 @@ For multi-step workflows, see [references/workflows.md](references/workflows.md)
 - `No profiles defined.` is an empty result, not an error.
 - REPL syntax is not `.robot` file syntax.
 - **A real test case is involved → `robotcode robot-debug`, never the REPL.** Running, watching, stepping, or inspecting a `*** Test Cases ***` (or `*** Tasks ***`) entry live — *not only when it fails* — is the debugger: `robot-debug -bl "<longname>"` pauses the real run so you inspect the live stack/variables and run keywords at the `(rdb)` stop, with the suite's setup, variables, imports, and `__init__.robot` all live. The REPL has **no test or task** — it runs only the keywords you type, in a different context — so "trying the test in the REPL" runs a misleading *copy*. The REPL is only for when **no** test or task is in play (a keyword, a library, free exploration). "Interactive" alone does not mean REPL.
-- **One test or task → select it by longname (`-bl`), never a bare `.robot` file — for `robotcode robot` and `robot-debug` alike.** The file holds other tests (all run) and skips the parent `__init__.robot` (setup/variables), so it behaves unlike a real run. Longname from `discover`/`results`; a whole suite → pass the *directory*.
+- **One test, task, or suite → select it by longname (`-bl`), never a bare `.robot` file — for `robotcode robot` and `robot-debug` alike.** A single file becomes the top suite and skips the parent `__init__.robot` (setup/variables), so it behaves unlike a real run. Longname from `discover`/`results`; a whole *directory* tree is the one path form that's fine (it loads its `__init__.robot`).
 - **"Fix this test/task" / "why does it fail or not run?"** → read the recorded error first with `robotcode results` (`show --failed`, `log`) — it often names the cause; if not, debug the *actual* test with `robotcode robot-debug -bl "<longname>"` (longname rule above). Don't reconstruct it in a REPL or detour into external tools / an MCP probe first — that's a *different context* and chases the wrong cause.
 - **`robot-debug`/`repl` are interactive terminal sessions** — run them in a terminal and step through live, end with `.continue`/`.detach`/`.abort`; never start one and block on its exit (it waits forever). At `(rdb)`, `Ctrl-C`/`Ctrl-D` *resume* — use `.abort` to stop. (Missing `repl` extra → `Error: No such command 'robot-debug'`.)
 - "What tests/**tasks**/tags/suites exist?" — and any "which tests or tasks have tag X / are in suite Y" question — is answered with `robotcode discover` (`discover tasks` for tasks), never by reading or grepping `.robot` files (don't `grep` for `*** Tasks ***` / `*** Test Cases ***`). The effective set is resolved at runtime (paths, config, profiles, variables, pre-run modifiers); static sources don't show it.

chat-plugins/robotcode/skills/robotcode/references/debugging.md

@@ -77,7 +77,7 @@ robotcode robot-debug -bl "MyProject.Login.Login Works"                  # only
 robotcode robot-debug --break login.robot:42 -t "Login Works"            # break at the line, but only run that test
 ```
 
-Handing over a bare **file** path (`tests/login.robot`) instead runs *every* test in the file — so, with break-on-failure on, it can stop on a *different* test first — **and** skips the parent suites' `__init__.robot` (the setup/variables loss described above). Select by longname; reserve a path for a whole suite — and note a *directory* like `tests/` still loads its `__init__.robot`, whereas a single file does not.
+Handing over a bare **file** path (`tests/login.robot`) instead runs *every* test in the file — so, with break-on-failure on, it can stop on a *different* test first — **and** skips the parent suites' `__init__.robot` (the setup/variables loss described above). Select a test, task, or single suite by longname; the one path form that's fine is a whole **directory** (`tests/` loads its `__init__.robot`), never a single file.
 
 ### The embedded `Breakpoint` keyword