القائمة
Remap the function_id:pc_index to the original source code position by provided debug info json file.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Generate valid OpenUI Lang v0.5 functional-notation programs for the Lynx OpenUI renderer. Use when Codex must turn a natural-language UI request into raw OpenUI DSL for OpenUiRenderer, including static mobile UI, $state, Query/Mutation tool flows, Action plans, streaming-friendly output, or catalog-constrained revisions. Do not use for JSX, HTML, CSS, A2UI JSON, or implementing new ReactLynx components.
Convert natural-language UI requests into A2UI v0.9 JSON protocol messages that an A2UI renderer can consume.
Query @lynx-js/css-defines compat_data to check Lynx CSS property and nested feature/value support by rendering backend and Lynx version, or check whether a newer dataset version exists. Use when asked whether CSS is supported in Lynx or ReactLynx, which backends support it, when support was added, whether a style change is compatible, whether the bundled data is current, or when inspecting the raw definition JSON.
Use this Skill when building Lynx applications directly with vanilla Lynx Element PAPI APIs from @lynx-js/type-element-api, without ReactLynx JSX. It covers Rspeedy project structure for native Lynx artifacts, main-thread Element PAPI rendering, UI event binding, main/background thread event communication, CSS packaging, and common Element API patterns. Trigger Scenarios: - User wants to build a Lynx app without ReactLynx, JSX, or a framework - User asks to use @lynx-js/type-element-api, Element PAPI, vanilla Lynx, or APIs such as __CreatePage, __CreateView, __CreateText, __AppendElement, __SetAttribute, or __FlushElementTree - User needs a native Lynx artifact with main-thread, optional background-thread, and CSS assets - User asks how vanilla Lynx UI events should stay on the main thread or be forwarded to background logic
Use when working with Lynx DevTool or debugging a Lynx app, page, or device, especially when the task mentions clients or sessions, CDP or App commands, DOM/CSS inspection, runtime or console logs, screenshots, heap snapshots, Page.reload or App.openPage, global switches, or inspecting a ReactLynx component tree (`reactlynx tree`), searching components (`reactlynx find`), inspecting props/state/hooks (`reactlynx component`), or mutating props/state/context (`reactlynx update-prop` / `update-state` / `update-context`) on Android, iOS, or Desktop.
Guidance on using Habitat to manage multi-repo source and asset dependencies via .habitat/DEPS and hab sync, plus troubleshooting common sync failures.
استنادا إلى تصنيف SOC المهني
| name | lynx-debug-info-remapping |
| description | Remap the function_id:pc_index to the original source code position by provided debug info json file. |
In Lynx, main thread script is encoded to bytecode and uses an external debugging information scheme. Under this scheme, the row and column numbers in the runtime error messages are not the actual row and column numbers. The row and column numbers need to be deciphered from the external debug-info.json file.
debug-info.json format is as follows:
{
"lepusNG_debug_info": {
"function_info": [
{
"function_id": 1,
"function_name": "App",
"line_col": [
{ "line": 1, "column": 1 },
{ "line": 2, "column": 1 },
{ "line": 3, "column": 1 }
]
}
]
}
}
This skill is useful when you want to remap the function_id:pc_index to the original source code position.
When the user encounters a runtime error message with function_id:pc_index, along with main-thread.js and debug-info.json in the error message, for example:
main-thread.js exception: App render failed at main thread backtrace:
at App (file:///main-thread.js:1356:13)
at doRender (file:///main-thread.js:1002:12)
at call (native)
at render (file:///main-thread.js:466:52)
at _renderToString (file:///main-thread.js:1001:569)
at renderToString (file:///main-thread.js:998:191)
at renderMainThread (file:///main-thread.js:766:45)
at renderPage (file:///main-thread.js:853:69)
Where function_id:pc_index is 1356:13.
function_id:pc_indexUser should provide the function_id:pc_index in the error message. Or give you the full backtrace.
You should check if it is a main-thread backtrace. Since background thread backtrace does not need remapping.
Ask the user for the debug-info.json path. For example in a rspeedy project with main entry it will locate at:
main-thread.js: $PROJECT_DIR/dist/.rspeedy/main/main-thread.jsdebug-info.json: $PROJECT_DIR/dist/.rspeedy/main/debug-info.jsonIf the user uses rspeedy build and there is no .rspeedy folder, remind them to build the project with DEBUG='rspeedy,rsbuild' rspeedy build.
For each function_id:pc_index pair in the stack trace, run the remapping script.
node ${CLAUDE_PLUGIN_ROOT}/skills/debug-info-remapping/scripts/index.mjs $PROJECT_DIR/[dist]/.rspeedy/[main]/debug-info.json $function_id $pc_index
The remapping script will output the remapped position in the format of line:column.
You should output the remapped position for each function_id:pc_index pair.
Replace the function_id:pc_index pair in the stack trace with the remapped position and show the remapped stack trace.
If you can reach the main-thread.js file, show the remapped stack trace with the remapped positions source code.
The final output should be something like this:
main-thread.js exception: App render failed at main thread backtrace:
at App (./dist/.rspeedy/main/main-thread.js:9368:56)
at doRender (./dist/.rspeedy/main/main-thread.js:7237:44)
at call (native)
at render (./dist/.rspeedy/main/main-thread.js:3706:72)
at _renderToString (./dist/.rspeedy/main/main-thread.js:7177:78)
at renderToString (./dist/.rspeedy/main/main-thread.js:7067:91)
at renderMainThread (./dist/.rspeedy/main/main-thread.js:5423:113)
at renderPage (./dist/.rspeedy/main/main-thread.js:6199:46)
╭─[5:55]
3 │ export function App() {
4 │ if (__MAIN_THREAD__) {
5 │ throw new Error('App render failed at main thread');
· ─┬
· ╰── main-thread.js exception: App render failed at main thread backtrace
6 │ }
7 │
╰────
... (the same for other callstacks such as doRender, call, render, _renderToString, renderToString, renderMainThread, renderPage here)
Files used:
- Debug Info: ./dist/.rspeedy/main/debug-info.json
- Source File: ./dist/.rspeedy/main/main-thread.js
The ./dist/.rspeedy/main/main-thread.js:9368:56 will make sure it is clickable in the editor/terminal.