ecubus-pro-ts-script

star 0

Create, modify, explain, and debug EcuBus-Pro TypeScript or JavaScript scripts. Use when the user asks for an EcuBus-Pro script, tester script, CAN/LIN/UDS/SOMEIP automation, variable or signal handling, event listeners, or code that should be based on the local Script API manual under D:\ProgramFiles\EcuBus-Pro\resources\app.asar.unpacked\resources\docs\scriptApi.

dazui0019 By dazui0019 schedule Updated 3/16/2026

name: ecubus-pro-ts-script description: Create, modify, explain, and debug EcuBus-Pro TypeScript or JavaScript scripts. Use when the user asks for an EcuBus-Pro script, tester script, CAN/LIN/UDS/SOMEIP automation, variable or signal handling, event listeners, or code that should be based on the local Script API manual under D:\ProgramFiles\EcuBus-Pro\resources\app.asar.unpacked\resources\docs\scriptApi.

EcuBus-Pro TS Script

Use this skill to turn user requirements into EcuBus-Pro TypeScript scripts that match the locally installed Script API documentation. Read only the API pages needed for the task, then write or modify the script in the current workspace.

Workflow

  1. Inspect the current workspace first if the request modifies an existing script or must integrate with project files.
  2. Map the request to the required protocol and capability:
    • CAN, LIN, SOMEIP send or receive
    • UDS diagnostic request, response, job, or sequence
    • Util lifecycle, key, timer, variable, signal, or message listeners
    • Serial port, CRC, crypto, or helper utilities
  3. Read references/api-map.md to locate the correct part of the manual.
  4. Run scripts/search-api.ps1 with the symbol names or protocol keywords from the request.
  5. Open the exact HTML pages for every EcuBus-Pro API, type, enum, class, or variable you plan to use.
  6. Inspect one or more official example scripts under D:\ProgramFiles\EcuBus-Pro\resources\app.asar.unpacked\resources\examples when import style or API usage patterns are unclear.
  7. Write the TypeScript file only after checking the documented signatures and examples.
  8. State assumptions when the docs do not define project-specific names such as tester names, database frame names, variables, or channels.

Doc Lookup

The local documentation root is:

D:\ProgramFiles\EcuBus-Pro\resources\app.asar.unpacked\resources\docs\scriptApi

Start with these pages:

  • index.html for environment and basic script usage
  • modules.html for the full API index
  • classes/UtilClass.html for lifecycle and event subscription helpers
  • functions/output.html for CAN, LIN, and SOMEIP transmission
  • variables/Util.html for the exported Util global, when needed

Use scripts/search-api.ps1 before reading raw HTML. The TypeDoc HTML is mostly minified, so filename and page title are often the fastest way to navigate.

Authoring Rules

  • Default to .ts output unless the user explicitly asks for .js.
  • Match the official import pattern used by EcuBus-Pro examples.
  • Prefer Util.Init(...) as the entry point for new scripts unless an existing script already establishes a different lifecycle.
  • Import functions, classes, enums, and types such as output, setSignal, CanMessage, DiagRequest, and CAN_ID_TYPE from 'ECB' when they are used in script code.
  • Treat Util as a global object unless local examples or project code show a different pattern.
  • Use documented types such as CanMessage, LinMsg, DiagRequest, DiagResponse, and documented enums such as CAN_ID_TYPE.
  • Keep dependencies limited to Node.js built-ins and documented EcuBus-Pro globals unless the user explicitly asks for something else.
  • Use Buffer for payload construction when the examples or signatures expect binary data.
  • Do not invent EcuBus-Pro functions, globals, or type names. Read the exact pages first.
  • Preserve existing script structure and unrelated behavior when modifying a file in place.
  • Keep comments short and only where the code is not self-evident.

Output

When creating a new script:

  • Produce a complete TypeScript file, not pseudocode.
  • Use concrete IDs, tester names, or variable names only when provided by the user or existing project files.
  • If the request is under-specified, keep placeholders obvious and explain them briefly.

When modifying an existing script:

  • Read the current file first.
  • Preserve unrelated logic, naming, and flow.
  • Mention which API pages justified the changes.

Resources

  • Read references/api-map.md for the doc layout and common page paths.
  • Run scripts/search-api.ps1 to find candidate API pages from keywords such as output, OnCan, DiagRequest, setVar, or SerialPortClient.
  • Inspect official examples in D:\ProgramFiles\EcuBus-Pro\resources\app.asar.unpacked\resources\examples before deciding whether an API should be imported from 'ECB' or used as a global.
Install via CLI
npx skills add https://github.com/dazui0019/ecb_lamp_ctrl --skill ecubus-pro-ts-script
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator