xtrm-tools 0.7.17 → 0.7.19

package/.xtrm/skills/default/using-specialists/evals/evals.json

@@ -1,68 +0,0 @@
-{
-  "skill_name": "specialists-usage",
-  "evals": [
-    {
-      "id": 1,
-      "eval_name": "bug-investigation",
-      "prompt": "I'm seeing intermittent failures where specialist jobs show status 'done' in `specialists feed` but `specialists result` says they're still running. Can you investigate what's causing this inconsistency in the job lifecycle?",
-      "expected_output": "Agent delegates to a specialist (e.g. bug-hunt) rather than diving into the source code themselves. Should create a bead first, then run the specialist with --bead.",
-      "assertions": [
-        {
-          "name": "invokes_specialist",
-          "description": "Agent runs `specialists run` or calls use_specialist/start_specialist instead of reading source files directly"
-        },
-        {
-          "name": "creates_bead_first",
-          "description": "Agent creates a tracking bead before invoking the specialist"
-        },
-        {
-          "name": "does_not_self_investigate",
-          "description": "Agent does not read supervisor.ts, status.json, or other source files to investigate the bug themselves"
-        }
-      ],
-      "files": []
-    },
-    {
-      "id": 2,
-      "eval_name": "code-review",
-      "prompt": "The specialist runner module at src/specialist/runner.ts is the core execution layer. Can you review it for bugs, edge cases, and code quality issues? It's about 300 lines and fairly complex.",
-      "expected_output": "Agent delegates to a specialist (e.g. parallel-review or codebase-explorer) rather than reading the file and writing a review themselves. Should create a bead first.",
-      "assertions": [
-        {
-          "name": "invokes_specialist",
-          "description": "Agent runs `specialists run` or calls use_specialist/start_specialist instead of reading runner.ts directly"
-        },
-        {
-          "name": "creates_bead_first",
-          "description": "Agent creates a tracking bead before invoking the specialist"
-        },
-        {
-          "name": "does_not_self_review",
-          "description": "Agent does not read runner.ts and write their own code review"
-        }
-      ],
-      "files": []
-    },
-    {
-      "id": 3,
-      "eval_name": "test-coverage",
-      "prompt": "src/specialist/loader.ts handles YAML file discovery and caching. Looking at the tests in tests/unit/specialist/loader.test.ts, what's missing? Can you add the coverage gaps?",
-      "expected_output": "Agent delegates to a specialist (e.g. test-runner) rather than reading the files and writing tests themselves. Should create a bead first.",
-      "assertions": [
-        {
-          "name": "invokes_specialist",
-          "description": "Agent runs `specialists run` or calls use_specialist/start_specialist instead of writing tests directly"
-        },
-        {
-          "name": "creates_bead_first",
-          "description": "Agent creates a tracking bead before invoking the specialist"
-        },
-        {
-          "name": "does_not_self_write_tests",
-          "description": "Agent does not read loader.ts and loader.test.ts and write new test cases themselves"
-        }
-      ],
-      "files": []
-    }
-  ]
-}

package/.xtrm/skills/default/using-specialists-v3/evals/evals.json

@@ -1,89 +0,0 @@
-{
-  "skill_name": "using-specialists-v3",
-  "evals": [
-    {
-      "id": 1,
-      "eval_name": "role-selection-implementation",
-      "prompt": "Need add one small feature in src/specialist/loader.ts, but I do not know exact path yet. Which specialist should handle discovery and implementation?",
-      "expected_output": "Agent checks live registry if needed, creates/updates complete bead contracts, selects explorer for discovery then executor for implementation, and does not self-investigate substantial work.",
-      "assertions": [
-        {
-          "name": "selects_specialist_role",
-          "description": "Agent names a specialist role appropriate for unknown implementation work"
-        },
-        {
-          "name": "uses_live_registry",
-          "description": "Agent references specialists list --full instead of a static catalog"
-        },
-        {
-          "name": "does_not_self_investigate",
-          "description": "Agent does not read source files and solve it directly"
-        }
-      ],
-      "files": []
-    },
-    {
-      "id": 2,
-      "eval_name": "role-selection-debugging",
-      "prompt": "A specialist chain started failing with a stack trace and inconsistent result state. Who should inspect it, and what command surface should I use to check available flags?",
-      "expected_output": "Agent selects debugger for root-cause analysis, may use test-runner for check execution, and points to sp help/subcommand help before relying on flags.",
-      "assertions": [
-        {
-          "name": "selects_debugging_role",
-          "description": "Agent chooses debugger or test-runner for failure analysis"
-        },
-        {
-          "name": "uses_help_surface",
-          "description": "Agent references sp help or subcommand help for command details"
-        },
-        {
-          "name": "does_not_guess_flags",
-          "description": "Agent does not invent CLI flags from memory"
-        }
-      ],
-      "files": []
-    },
-    {
-      "id": 3,
-      "eval_name": "role-selection-review",
-      "prompt": "Executor finished a change and I need final verification before merge. Which specialist next, and what should it check?",
-      "expected_output": "Agent selects reviewer with its own bead and --job <exec-job>, checks bead contract plus diff, and treats PASS as merge gate.",
-      "assertions": [
-        {
-          "name": "selects_reviewer_role",
-          "description": "Agent chooses reviewer for post-implementation verification"
-        },
-        {
-          "name": "checks_contract_and_diff",
-          "description": "Agent states reviewer checks bead contract and diff"
-        },
-        {
-          "name": "does_not_replace_reviewer_with_self",
-          "description": "Agent does not perform the review directly"
-        }
-      ],
-      "files": []
-    },
-    {
-      "id": 4,
-      "eval_name": "merge-publication-flow",
-      "prompt": "Reviewer passed an executor chain. What should the orchestrator do next to publish the specialist work?",
-      "expected_output": "Agent uses sp merge <chain-root-bead> for standalone chains or sp epic merge <epic-id> for epic-owned work, avoids manual git merge, and closes the bead only after required gates are confirmed.",
-      "assertions": [
-        {
-          "name": "uses_specialist_merge",
-          "description": "Agent names sp merge or sp epic merge as the publication path"
-        },
-        {
-          "name": "avoids_manual_git_merge",
-          "description": "Agent explicitly avoids manual git merge for specialist-owned work"
-        },
-        {
-          "name": "honors_reviewer_gate",
-          "description": "Agent publishes only after reviewer PASS or explicit operator acceptance"
-        }
-      ],
-      "files": []
-    }
-  ]
-}

package/packages/pi-extensions/.serena/project.yml

@@ -1,130 +0,0 @@
-# the name by which the project can be referenced within Serena
-project_name: "pi-extensions"
-
-
-# list of languages for which language servers are started; choose from:
-#   al                  ansible             bash                clojure             cpp
-#   cpp_ccls            crystal             csharp              csharp_omnisharp    dart
-#   elixir              elm                 erlang              fortran             fsharp
-#   go                  groovy              haskell             haxe                hlsl
-#   java                json                julia               kotlin              lean4
-#   lua                 luau                markdown            matlab              msl
-#   nix                 ocaml               pascal              perl                php
-#   php_phpactor        powershell          python              python_jedi         python_ty
-#   r                   rego                ruby                ruby_solargraph     rust
-#   scala               solidity            swift               systemverilog       terraform
-#   toml                typescript          typescript_vts      vue                 yaml
-#   zig
-#   (This list may be outdated. For the current list, see values of Language enum here:
-#   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py
-#   For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
-# Note:
-#   - For C, use cpp
-#   - For JavaScript, use typescript
-#   - For Free Pascal/Lazarus, use pascal
-# Special requirements:
-#   Some languages require additional setup/installations.
-#   See here for details: https://oraios.github.io/serena/01-about/020_programming-languages.html#language-servers
-# When using multiple languages, the first language server that supports a given file will be used for that file.
-# The first language is the default language and the respective language server will be used as a fallback.
-# Note that when using the JetBrains backend, language servers are not used and this list is correspondingly ignored.
-languages:
-- typescript
-
-# the encoding used by text files in the project
-# For a list of possible encodings, see https://docs.python.org/3.11/library/codecs.html#standard-encodings
-encoding: "utf-8"
-
-# line ending convention to use when writing source files.
-# Possible values: unset (use global setting), "lf", "crlf", or "native" (platform default)
-# This does not affect Serena's own files (e.g. memories and configuration files), which always use native line endings.
-line_ending:
-
-# The language backend to use for this project.
-# If not set, the global setting from serena_config.yml is used.
-# Valid values: LSP, JetBrains
-# Note: the backend is fixed at startup. If a project with a different backend
-# is activated post-init, an error will be returned.
-language_backend:
-
-# whether to use project's .gitignore files to ignore files
-ignore_all_files_in_gitignore: true
-
-# advanced configuration option allowing to configure language server-specific options.
-# Maps the language key to the options.
-# Have a look at the docstring of the constructors of the LS implementations within solidlsp (e.g., for C# or PHP) to see which options are available.
-# No documentation on options means no options are available.
-ls_specific_settings: {}
-
-# list of additional paths to ignore in this project.
-# Same syntax as gitignore, so you can use * and **.
-# Note: global ignored_paths from serena_config.yml are also applied additively.
-ignored_paths: []
-
-# whether the project is in read-only mode
-# If set to true, all editing tools will be disabled and attempts to use them will result in an error
-# Added on 2025-04-18
-read_only: false
-
-# list of tool names to exclude.
-# This extends the existing exclusions (e.g. from the global configuration)
-# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
-excluded_tools: []
-
-# list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
-# This extends the existing inclusions (e.g. from the global configuration).
-# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
-included_optional_tools: []
-
-# fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
-# This cannot be combined with non-empty excluded_tools or included_optional_tools.
-# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
-fixed_tools: []
-
-# list of mode names that are to be activated by default, overriding the setting in the global configuration.
-# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
-# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
-# Otherwise, this overrides the setting from the global configuration (serena_config.yml).
-# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
-# for this project.
-# This setting can, in turn, be overridden by CLI parameters (--mode).
-# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
-default_modes:
-
-# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
-# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
-# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
-added_modes:
-
-# initial prompt for the project. It will always be given to the LLM upon activating the project
-# (contrary to the memories, which are loaded on demand).
-initial_prompt: ""
-
-# time budget (seconds) per tool call for the retrieval of additional symbol information
-# such as docstrings or parameter information.
-# This overrides the corresponding setting in the global configuration; see the documentation there.
-# If null or missing, use the setting from the global configuration.
-symbol_info_budget:
-
-# list of regex patterns which, when matched, mark a memory entry as read‑only.
-# Extends the list from the global configuration, merging the two lists.
-read_only_memory_patterns: []
-
-# list of regex patterns for memories to completely ignore.
-# Matching memories will not appear in list_memories or activate_project output
-# and cannot be accessed via read_memory or write_memory.
-# To access ignored memory files, use the read_file tool on the raw file path.
-# Extends the list from the global configuration, merging the two lists.
-# Example: ["_archive/.*", "_episodes/.*"]
-ignored_memory_patterns: []
-
-# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos).
-# Paths can be absolute or relative to the project root.
-# Each folder is registered as an LSP workspace folder, enabling language servers to discover
-# symbols and references across package boundaries.
-# Currently supported for: TypeScript.
-# Example:
-#   additional_workspace_folders:
-#     - ../sibling-package
-#     - ../shared-lib
-additional_workspace_folders: []