[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MHREK1NSP2ANN0CP46TFR9":3,"skill-same:01M6MHREK1NSP2ANN0CP46TFR9":137},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6MHREK1NSP2ANN0CP46TFR9","rust-reverse-engineering",null,"Use when analyzing a Rust binary without source code, reverse engineering Rust executables or libraries, demangling Rust symbols, recovering likely crate namespaces, tracing panic or unwind paths, identifying FFI boundaries, or mapping behavior from ELF, Mach-O, PE, `.so`, `.dylib`, `.dll`, `.a`, `.rlib`, or object files.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"rust reverse engineering","engineering","reverse","reverse engineering","rust","files","when","source code","source","object","namespaces","paths","mapping","use","behavior","analyzing","ELF","tracing","ffi","code","libraries","2026-11-10 10:12:30",false,"---\nname: rust-reverse-engineering\ndescription: Use when analyzing a Rust binary without source code, reverse engineering Rust executables or libraries, demangling Rust symbols, recovering likely crate namespaces, tracing panic or unwind paths, identifying FFI boundaries, or mapping behavior from ELF, Mach-O, PE, `.so`, `.dylib`, `.dll`, `.a`, `.rlib`, or object files.\n---\n\n# Rust Reverse Engineering\n\nReverse engineer Rust-compiled binaries methodically. Start with fast triage, confirm that the target is actually Rust, recover namespaces and runtime clues, then move into static or dynamic analysis with a clear hypothesis.\n\nDo **not** jump straight into decompiler output and treat it as source truth. Rust binaries often contain compiler-generated glue, monomorphized generic code, panic paths, and async state machines that will drown the signal if you skip the triage stage.\n\n## When to Use\n\nUse this skill when the user wants to:\n\n- analyze a Rust executable, shared library, static archive, `.rlib`, or object file\n- confirm whether a binary was built from Rust\n- demangle Rust symbols and recover likely crate namespaces\n- trace entry points, panic\u002Funwind paths, FFI exports\u002Fimports, or async executors\n- understand high-level architecture without source code\n- prepare a Rust binary for deeper work in Ghidra, IDA, Binary Ninja, `gdb`, or `lldb`\n\n## When NOT to Use\n\nDo **not** use this skill when:\n\n- the user already has the Rust source code and wants normal code review or debugging\n- the target is primarily an Android APK\u002FDEX\u002FJAR\u002FAAR package — use an Android-focused workflow instead\n- the task is generic PE\u002FELF malware triage with no Rust-specific angle\n- the request is to bypass licensing, DRM, or authorization controls on software the user is not authorized to analyze\n\n## Prerequisites\n\nRequired command-line tools:\n\n- `file`\n- `strings`\n- `readelf` or `llvm-readelf` for ELF, or `otool` for Mach-O\n- `nm` or `llvm-nm`\n- `objdump` or `llvm-objdump`, or `otool` on macOS\n\nRecommended:\n\n- `rustfilt`\n- `gdb` or `lldb`\n- Ghidra, IDA Pro, or Binary Ninja\n\nVerify availability first:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcheck-deps.sh\n```\n\nIf tooling is missing, install one dependency at a time:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh rustfilt\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh ghidra\n```\n\nIf automatic installation is not possible on the current machine, read `references\u002Fsetup-guide.md`.\n\n## Workflow\n\n### Phase 1: Check and install dependencies\n\nRun the dependency checker first:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcheck-deps.sh\n```\n\nParse the output looking for:\n\n- `INSTALL_REQUIRED:`\n- `INSTALL_OPTIONAL:`\n\nIf required tooling is missing, install it one dependency at a time:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh \u003Cdependency>\n```\n\nThe installer:\n\n- uses Homebrew when available on macOS\n- uses `apt`, `dnf`, or `pacman` on Linux when available\n- uses `cargo install rustfilt` for `rustfilt` when `cargo` exists\n- prints exact manual instructions and exits when a dependency cannot be installed automatically\n\nFor optional tooling, recommend at least:\n\n- `rustfilt`\n- one debugger: `gdb` or `lldb`\n- `ghidra`\n\nRe-run `check-deps.sh` after installation attempts. Do not proceed until all required dependencies show `OK`.\n\n### Phase 2: Materialize reverse-engineering artifacts first\n\nDo not keep the analysis ephemeral. Create an artifact bundle on disk before doing interpretation.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcollect-artifacts.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nThe script writes a reusable output directory:\n\n```text\n\u003Ctarget>-reverse-output\u002F\n├── input\u002F\n├── triage\u002F\n├── symbols\u002F\n├── headers\u002F\n├── disassembly\u002F\n├── decompiled\u002F\n│   └── ghidra\u002F\n└── reports\u002F\n```\n\nTreat this directory as the source of truth for the rest of the workflow. It should contain:\n\n- `triage\u002Fsummary.txt` — file type, architecture, strip\u002Fdebug-info status, Rust confidence\n- `triage\u002Fstrings.txt` and `triage\u002Finteresting-strings.txt` — raw and filtered strings\n- `symbols\u002Fraw.txt`, `symbols\u002Fdemangled.txt`, `symbols\u002Fnamespaces.txt`, `symbols\u002Fimports.txt`, `symbols\u002Fexports.txt`\n- `headers\u002F*` — readelf, otool, or PE header dumps\n- `disassembly\u002Fdisassembly.txt` — best-effort disassembly when available\n- `decompiled\u002Fghidra\u002Fstatus.txt`, `summary.txt`, `functions.tsv`, `decompile-errors.tsv`, and `functions\u002F*.c` — headless Ghidra pseudocode artifacts when available\n- `reports\u002Fsummary.md` and `reports\u002Fpattern-hits.txt`\n\n### Phase 3: Fast triage before any deep analysis\n\nIf you need a quick rerun or a narrower pass, the underlying triage script is still available.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Ftriage.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nCapture these facts before doing anything else:\n\n1. **Container and file type**\n   - ELF, Mach-O, PE\u002FCOFF, static archive, object file, or `.rlib`\n   - target architecture and bitness\n   - executable vs shared library vs archive\n\n2. **Symbol quality**\n   - stripped vs not stripped\n   - exported vs imported symbols\n   - whether a usable symbol table still exists\n\n3. **Debug-info availability**\n   - DWARF sections\n   - macOS DWARF segments \u002F dSYM hints\n   - Windows PDB hints in strings\n   - split-debug or external-debug indicators when visible\n\n4. **Rust confidence**\n   - v0 or legacy Rust mangling patterns\n   - demangled `core::`, `alloc::`, `std::`, or crate-like namespaces\n   - panic\u002Funwind strings and runtime artifacts\n   - Rust-specific crate names in symbols or strings\n\nDo not describe the binary as “definitely Rust” from a single clue. Use multiple, independent signals.\n\n### Phase 4: Recover symbols and namespaces\n\nDump symbols and demangle them as early as possible.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fdemangle-symbols.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nFocus on these buckets:\n\n- **standard runtime buckets**: `core::`, `alloc::`, `std::`, `panic`, unwinding, formatting\n- **user-space buckets**: crate-like top-level namespaces that are not runtime crates\n- **interop buckets**: `main`, `_start`, exported C ABI functions, imported libc \u002F Win32 \u002F networking APIs\n- **framework buckets**: likely third-party crates such as serialization, async runtimes, HTTP stacks, crypto, CLI parsing, and logging\n\nBuild a short namespace inventory:\n\n```text\n- runtime crates:\n- likely app crates:\n- likely third-party crates:\n- exported ABI functions:\n- imported platform APIs:\n```\n\nUse `references\u002Ftriage-and-fingerprinting.md` for the triage rubric and `references\u002Frust-patterns.md` for common Rust-specific fingerprints.\n\nFor targeted bucket searches across the generated artifacts, run:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Ffind-rust-patterns.sh \u003Ctarget>-reverse-output\n```\n\n### Phase 5: Recover high-level structure without assuming a stable Rust ABI\n\nRecover structure conservatively.\n\nLook for:\n\n1. **Entry and boundary functions**\n   - `_start`, `main`, CRT glue, loader entry points\n   - exported `extern \"C\"` \u002F `no_mangle` style boundaries\n   - plugin or callback registration functions\n   - thread starts, task executors, and worker loops\n\n2. **Subsystem anchors**\n   - config parsing\n   - logging initialization\n   - network \u002F filesystem \u002F crypto imports\n   - panic setup and error paths\n   - serialization and IPC edges\n\n3. **Call-shape clues**\n   - large dispatcher-style functions that may be async state machines\n   - indirect calls through vtable-like structures\n   - formatter-heavy branches around error handling or panic paths\n   - repeated monomorphized helpers with type-specific variants\n\nCritical rule: **do not assume undocumented Rust layouts are stable**.\n\n- Treat `Option`, `Result`, `Vec`, `String`, trait objects, and closure layouts as hypotheses until confirmed by debug info, repeated call-site evidence, or explicit `repr(C)` \u002F `repr(transparent)` style interop boundaries.\n- Do not label every two-word structure as a trait object.\n- Do not infer source-level module boundaries from one demangled symbol alone; confirm using clusters of neighboring symbols, xrefs, and strings.\n\n### Phase 6: Static analysis in a decompiler \u002F disassembler\n\nOnce triage is complete, load the target into Ghidra, IDA, or Binary Ninja.\n\nIf `analyzeHeadless` is installed, `collect-artifacts.sh` should already materialize a decompiler bundle under `decompiled\u002Fghidra\u002F`. Treat those `.c` files as working pseudocode and review aids, not as original Rust source.\n\nIf the target is a universal Mach-O, thin it to the slice you actually want to analyze before trusting any disassembly or decompiler output. The automation now does this for you, defaulting to the host architecture when `--macho-arch` is omitted and recording the chosen slice in `input\u002Fanalysis-target.txt` and `decompiled\u002Fghidra\u002Fanalysis-target.txt`. If the host slice is not the slice you want, pass `--macho-arch` explicitly.\n\nDo not treat the export as complete until `decompiled\u002Fghidra\u002Fstatus.txt` says `STATE: completed` or `decompiled\u002Fghidra\u002Fcomplete.marker` exists. The export now writes progress and partial summary state during the run, so interrupted batches are clearly marked as partial or failed instead of looking empty.\n\nInside Codex, long-running Ghidra exports must stay attached to a live session and be allowed to run until `STATE: completed`. Do not interrupt them just because they are slow. Do not stop because “enough signal was gathered”, because the expected remaining value seems low, or because the auto-analysis phase looks quiet for a while. If the process is alive and `decompiled\u002Fghidra\u002Frunner-status.txt` is still getting fresh heartbeats, the job is still in progress.\n\nUse `decompiled\u002Fghidra\u002Frunner-status.txt` to distinguish “slow but alive” from “actually stopped”, and use `decompiled\u002Fghidra\u002Fwarning-summary.txt` to see whether a small set of hotspot functions is dominating the `Unable to resolve constructor` \u002F `pcode error` noise in `headless.log`. A fresh runner heartbeat together with `PROCESS_ALIVE: yes` means the export is still live. For detached jobs, `ghidra-job.sh status` now derives `RUNNER_HEARTBEAT_AGE_SECONDS`, `RUNNER_HEARTBEAT_STALE`, and `LIVENESS_HINT` so you can separate a slow analysis phase from a dead wrapper.\n\nRecommended order:\n\n1. Run auto-analysis\n2. Apply or verify Rust demangling\n3. Rename obvious runtime buckets away from the app-specific namespace inventory\n4. Start from one of:\n   - exported C ABI functions\n   - `main` \u002F startup glue\n   - strong strings with xrefs\n   - networking \u002F filesystem imports\n   - panic and formatting anchors\n5. Label crate clusters and subsystem boundaries\n6. Trace only one feature path at a time\n\nPrefer **strings, imports, exports, and clear subsystem anchors** over huge decompiler functions. In stripped Rust binaries, anchor-based analysis is more reliable than trying to understand every generic helper.\n\nUse `references\u002Fstatic-analysis-workflow.md` for the detailed workflow.\n\n### Phase 7: Dynamic analysis when static evidence is weak\n\nWhen stripped code or compiler-generated glue makes static analysis ambiguous, move to a debugger.\n\nUse `gdb` or `lldb` to:\n\n- break at exported ABI functions or `main`\n- watch network, file I\u002FO, process creation, and crypto-adjacent imports\n- break on panic \u002F abort paths\n- confirm which indirect call sites are real dispatch points\n- trace buffer lifetimes and ownership hand-offs across FFI boundaries\n\nDynamic analysis is especially valuable for:\n\n- heavily stripped binaries\n- async runtimes\n- plugin or callback architectures\n- binaries with large amounts of monomorphized generic code\n- distinguishing app logic from runtime support\n\nUse `references\u002Fdynamic-analysis-notes.md` for breakpoint ideas and debugger notes.\n\n### Phase 8: Produce a structured report\n\nAt the end, deliver both the artifact bundle and a structured report.\n\nThe artifact bundle should exist on disk and include at least:\n\n1. **Captured input and triage**\n   - original target under `input\u002F`\n   - triage summary\n   - raw and filtered strings\n\n2. **Recovered symbol artifacts**\n   - raw symbols\n   - demangled symbols\n   - namespace histogram\n   - imports and exports\n\n3. **Low-level evidence**\n   - header dumps\n   - disassembly when available\n   - grouped pattern hits\n   - Ghidra pseudocode files when headless export is available\n\n4. **Human-readable report**\n   - `reports\u002Fsummary.md`\n\nThen, in the chat response, deliver:\n\n1. **Binary fingerprint**\n   - format, architecture, strip\u002Fdebug-info status, Rust confidence\n\n2. **Namespace inventory**\n   - runtime crates\n   - likely application crates\n   - likely third-party crates\n\n3. **Entry points and boundaries**\n   - startup path\n   - exported functions\n   - imported APIs\n   - likely FFI edges\n\n4. **Recovered subsystems**\n   - networking\n   - storage\n   - crypto\n   - config\n   - async\u002Ftask execution\n   - panic\u002Ferror handling\n\n5. **Key call flows**\n   - one or two high-value paths only\n   - note confidence and evidence for each path\n\n6. **Open questions**\n   - what remains ambiguous\n   - what extra evidence is needed next (debug info, runtime breakpoints, comparison build, related library)\n\n## Rationalizations to Reject\n\nReject these shortcuts:\n\n- “The decompiler said it, so it must be true.”\n- “This looks like a trait object because it has two pointers.”\n- “Demangled symbols prove the original source layout.”\n- “A crate name in strings means the feature is definitely used.”\n- “This large dispatcher is obviously business logic.”  \n  It may just be compiler-generated async or panic\u002Fruntime machinery.\n\n## Output standard\n\nAlways mention the output directory first, then summarize the findings.\n\nUse this format when reporting to the user:\n\n```markdown\n## Reverse output\n\n- **Output dir**: `path\u002Fto\u002Ftarget-reverse-output`\n- **Summary report**: `path\u002Fto\u002Ftarget-reverse-output\u002Freports\u002Fsummary.md`\n\n## Rust binary summary\n\n- **Target**: `path\u002Fto\u002Fbinary`\n- **Format \u002F arch**: `ELF x86-64`\n- **Symbols**: `partially stripped`\n- **Debug info**: `DWARF absent`\n- **Rust confidence**: `high`\n\n## Namespaces\n\n- **Runtime crates**: `core`, `alloc`, `std`\n- **Likely app crates**: `my_app`, `engine`\n- **Likely third-party crates**: `tokio`, `serde_json`, `reqwest`\n\n## Entry points and boundaries\n\n- **Startup**: `_start -> ... -> main`\n- **Exports**: `plugin_init`, `process_request`\n- **Imports**: `connect`, `send`, `recv`, `pthread_create`\n- **FFI edges**: `plugin_init`, `process_request`\n\n## Key findings\n\n1. `process_request` appears to drive the request parsing path.\n2. Networking likely flows through a `reqwest`\u002F`hyper`-adjacent stack.\n3. A large dispatcher near `...::poll` is a strong async-state-machine candidate.\n\n## Next best move\n\n- break on `process_request`\n- trace the async poll path\n- inspect nearby strings\u002Fxrefs for request routing or serialization formats\n```\n\n## References\n\n- `references\u002Fsetup-guide.md`\n- `references\u002Ftriage-and-fingerprinting.md`\n- `references\u002Frust-patterns.md`\n- `references\u002Fstatic-analysis-workflow.md`\n- `references\u002Fdynamic-analysis-notes.md`\n","# Rust Reverse Engineering\n\nReverse engineer Rust-compiled binaries methodically. Start with fast triage, confirm that the target is actually Rust, recover namespaces and runtime clues, then move into static or dynamic analysis with a clear hypothesis.\n\nDo **not** jump straight into decompiler output and treat it as source truth. Rust binaries often contain compiler-generated glue, monomorphized generic code, panic paths, and async state machines that will drown the signal if you skip the triage stage.\n\n## When to Use\n\nUse this skill when the user wants to:\n\n- analyze a Rust executable, shared library, static archive, `.rlib`, or object file\n- confirm whether a binary was built from Rust\n- demangle Rust symbols and recover likely crate namespaces\n- trace entry points, panic\u002Funwind paths, FFI exports\u002Fimports, or async executors\n- understand high-level architecture without source code\n- prepare a Rust binary for deeper work in Ghidra, IDA, Binary Ninja, `gdb`, or `lldb`\n\n## When NOT to Use\n\nDo **not** use this skill when:\n\n- the user already has the Rust source code and wants normal code review or debugging\n- the target is primarily an Android APK\u002FDEX\u002FJAR\u002FAAR package — use an Android-focused workflow instead\n- the task is generic PE\u002FELF malware triage with no Rust-specific angle\n- the request is to bypass licensing, DRM, or authorization controls on software the user is not authorized to analyze\n\n## Prerequisites\n\nRequired command-line tools:\n\n- `file`\n- `strings`\n- `readelf` or `llvm-readelf` for ELF, or `otool` for Mach-O\n- `nm` or `llvm-nm`\n- `objdump` or `llvm-objdump`, or `otool` on macOS\n\nRecommended:\n\n- `rustfilt`\n- `gdb` or `lldb`\n- Ghidra, IDA Pro, or Binary Ninja\n\nVerify availability first:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcheck-deps.sh\n```\n\nIf tooling is missing, install one dependency at a time:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh rustfilt\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh ghidra\n```\n\nIf automatic installation is not possible on the current machine, read `references\u002Fsetup-guide.md`.\n\n## Workflow\n\n### Phase 1: Check and install dependencies\n\nRun the dependency checker first:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcheck-deps.sh\n```\n\nParse the output looking for:\n\n- `INSTALL_REQUIRED:`\n- `INSTALL_OPTIONAL:`\n\nIf required tooling is missing, install it one dependency at a time:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Finstall-dep.sh \u003Cdependency>\n```\n\nThe installer:\n\n- uses Homebrew when available on macOS\n- uses `apt`, `dnf`, or `pacman` on Linux when available\n- uses `cargo install rustfilt` for `rustfilt` when `cargo` exists\n- prints exact manual instructions and exits when a dependency cannot be installed automatically\n\nFor optional tooling, recommend at least:\n\n- `rustfilt`\n- one debugger: `gdb` or `lldb`\n- `ghidra`\n\nRe-run `check-deps.sh` after installation attempts. Do not proceed until all required dependencies show `OK`.\n\n### Phase 2: Materialize reverse-engineering artifacts first\n\nDo not keep the analysis ephemeral. Create an artifact bundle on disk before doing interpretation.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fcollect-artifacts.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nThe script writes a reusable output directory:\n\n```text\n\u003Ctarget>-reverse-output\u002F\n├── input\u002F\n├── triage\u002F\n├── symbols\u002F\n├── headers\u002F\n├── disassembly\u002F\n├── decompiled\u002F\n│   └── ghidra\u002F\n└── reports\u002F\n```\n\nTreat this directory as the source of truth for the rest of the workflow. It should contain:\n\n- `triage\u002Fsummary.txt` — file type, architecture, strip\u002Fdebug-info status, Rust confidence\n- `triage\u002Fstrings.txt` and `triage\u002Finteresting-strings.txt` — raw and filtered strings\n- `symbols\u002Fraw.txt`, `symbols\u002Fdemangled.txt`, `symbols\u002Fnamespaces.txt`, `symbols\u002Fimports.txt`, `symbols\u002Fexports.txt`\n- `headers\u002F*` — readelf, otool, or PE header dumps\n- `disassembly\u002Fdisassembly.txt` — best-effort disassembly when available\n- `decompiled\u002Fghidra\u002Fstatus.txt`, `summary.txt`, `functions.tsv`, `decompile-errors.tsv`, and `functions\u002F*.c` — headless Ghidra pseudocode artifacts when available\n- `reports\u002Fsummary.md` and `reports\u002Fpattern-hits.txt`\n\n### Phase 3: Fast triage before any deep analysis\n\nIf you need a quick rerun or a narrower pass, the underlying triage script is still available.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Ftriage.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nCapture these facts before doing anything else:\n\n1. **Container and file type**\n   - ELF, Mach-O, PE\u002FCOFF, static archive, object file, or `.rlib`\n   - target architecture and bitness\n   - executable vs shared library vs archive\n\n2. **Symbol quality**\n   - stripped vs not stripped\n   - exported vs imported symbols\n   - whether a usable symbol table still exists\n\n3. **Debug-info availability**\n   - DWARF sections\n   - macOS DWARF segments \u002F dSYM hints\n   - Windows PDB hints in strings\n   - split-debug or external-debug indicators when visible\n\n4. **Rust confidence**\n   - v0 or legacy Rust mangling patterns\n   - demangled `core::`, `alloc::`, `std::`, or crate-like namespaces\n   - panic\u002Funwind strings and runtime artifacts\n   - Rust-specific crate names in symbols or strings\n\nDo not describe the binary as “definitely Rust” from a single clue. Use multiple, independent signals.\n\n### Phase 4: Recover symbols and namespaces\n\nDump symbols and demangle them as early as possible.\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Fdemangle-symbols.sh \u002Fpath\u002Fto\u002Fbinary\n```\n\nFocus on these buckets:\n\n- **standard runtime buckets**: `core::`, `alloc::`, `std::`, `panic`, unwinding, formatting\n- **user-space buckets**: crate-like top-level namespaces that are not runtime crates\n- **interop buckets**: `main`, `_start`, exported C ABI functions, imported libc \u002F Win32 \u002F networking APIs\n- **framework buckets**: likely third-party crates such as serialization, async runtimes, HTTP stacks, crypto, CLI parsing, and logging\n\nBuild a short namespace inventory:\n\n```text\n- runtime crates:\n- likely app crates:\n- likely third-party crates:\n- exported ABI functions:\n- imported platform APIs:\n```\n\nUse `references\u002Ftriage-and-fingerprinting.md` for the triage rubric and `references\u002Frust-patterns.md` for common Rust-specific fingerprints.\n\nFor targeted bucket searches across the generated artifacts, run:\n\n```bash\nbash \u003Cpath-to-skill>\u002Fscripts\u002Ffind-rust-patterns.sh \u003Ctarget>-reverse-output\n```\n\n### Phase 5: Recover high-level structure without assuming a stable Rust ABI\n\nRecover structure conservatively.\n\nLook for:\n\n1. **Entry and boundary functions**\n   - `_start`, `main`, CRT glue, loader entry points\n   - exported `extern \"C\"` \u002F `no_mangle` style boundaries\n   - plugin or callback registration functions\n   - thread starts, task executors, and worker loops\n\n2. **Subsystem anchors**\n   - config parsing\n   - logging initialization\n   - network \u002F filesystem \u002F crypto imports\n   - panic setup and error paths\n   - serialization and IPC edges\n\n3. **Call-shape clues**\n   - large dispatcher-style functions that may be async state machines\n   - indirect calls through vtable-like structures\n   - formatter-heavy branches around error handling or panic paths\n   - repeated monomorphized helpers with type-specific variants\n\nCritical rule: **do not assume undocumented Rust layouts are stable**.\n\n- Treat `Option`, `Result`, `Vec`, `String`, trait objects, and closure layouts as hypotheses until confirmed by debug info, repeated call-site evidence, or explicit `repr(C)` \u002F `repr(transparent)` style interop boundaries.\n- Do not label every two-word structure as a trait object.\n- Do not infer source-level module boundaries from one demangled symbol alone; confirm using clusters of neighboring symbols, xrefs, and strings.\n\n### Phase 6: Static analysis in a decompiler \u002F disassembler\n\nOnce triage is complete, load the target into Ghidra, IDA, or Binary Ninja.\n\nIf `analyzeHeadless` is installed, `collect-artifacts.sh` should already materialize a decompiler bundle under `decompiled\u002Fghidra\u002F`. Treat those `.c` files as working pseudocode and review aids, not as original Rust source.\n\nIf the target is a universal Mach-O, thin it to the slice you actually want to analyze before trusting any disassembly or decompiler output. The automation now does this for you, defaulting to the host architecture when `--macho-arch` is omitted and recording the chosen slice in `input\u002Fanalysis-target.txt` and `decompiled\u002Fghidra\u002Fanalysis-target.txt`. If the host slice is not the slice you want, pass `--macho-arch` explicitly.\n\nDo not treat the export as complete until `decompiled\u002Fghidra\u002Fstatus.txt` says `STATE: completed` or `decompiled\u002Fghidra\u002Fcomplete.marker` exists. The export now writes progress and partial summary state during the run, so interrupted batches are clearly marked as partial or failed instead of looking empty.\n\nInside Codex, long-running Ghidra exports must stay attached to a live session and be allowed to run until `STATE: completed`. Do not interrupt them just because they are slow. Do not stop because “enough signal was gathered”, because the expected remaining value seems low, or because the auto-analysis phase looks quiet for a while. If the process is alive and `decompiled\u002Fghidra\u002Frunner-status.txt` is still getting fresh heartbeats, the job is still in progress.\n\nUse `decompiled\u002Fghidra\u002Frunner-status.txt` to distinguish “slow but alive” from “actually stopped”, and use `decompiled\u002Fghidra\u002Fwarning-summary.txt` to see whether a small set of hotspot functions is dominating the `Unable to resolve constructor` \u002F `pcode error` noise in `headless.log`. A fresh runner heartbeat together with `PROCESS_ALIVE: yes` means the export is still live. For detached jobs, `ghidra-job.sh status` now derives `RUNNER_HEARTBEAT_AGE_SECONDS`, `RUNNER_HEARTBEAT_STALE`, and `LIVENESS_HINT` so you can separate a slow analysis phase from a dead wrapper.\n\nRecommended order:\n\n1. Run auto-analysis\n2. Apply or verify Rust demangling\n3. Rename obvious runtime buckets away from the app-specific namespace inventory\n4. Start from one of:\n   - exported C ABI functions\n   - `main` \u002F startup glue\n   - strong strings with xrefs\n   - networking \u002F filesystem imports\n   - panic and formatting anchors\n5. Label crate clusters and subsystem boundaries\n6. Trace only one feature path at a time\n\nPrefer **strings, imports, exports, and clear subsystem anchors** over huge decompiler functions. In stripped Rust binaries, anchor-based analysis is more reliable than trying to understand every generic helper.\n\nUse `references\u002Fstatic-analysis-workflow.md` for the detailed workflow.\n\n### Phase 7: Dynamic analysis when static evidence is weak\n\nWhen stripped code or compiler-generated glue makes static analysis ambiguous, move to a debugger.\n\nUse `gdb` or `lldb` to:\n\n- break at exported ABI functions or `main`\n- watch network, file I\u002FO, process creation, and crypto-adjacent imports\n- break on panic \u002F abort paths\n- confirm which indirect call sites are real dispatch points\n- trace buffer lifetimes and ownership hand-offs across FFI boundaries\n\nDynamic analysis is especially valuable for:\n\n- heavily stripped binaries\n- async runtimes\n- plugin or callback architectures\n- binaries with large amounts of monomorphized generic code\n- distinguishing app logic from runtime support\n\nUse `references\u002Fdynamic-analysis-notes.md` for breakpoint ideas and debugger notes.\n\n### Phase 8: Produce a structured report\n\nAt the end, deliver both the artifact bundle and a structured report.\n\nThe artifact bundle should exist on disk and include at least:\n\n1. **Captured input and triage**\n   - original target under `input\u002F`\n   - triage summary\n   - raw and filtered strings\n\n2. **Recovered symbol artifacts**\n   - raw symbols\n   - demangled symbols\n   - namespace histogram\n   - imports and exports\n\n3. **Low-level evidence**\n   - header dumps\n   - disassembly when available\n   - grouped pattern hits\n   - Ghidra pseudocode files when headless export is available\n\n4. **Human-readable report**\n   - `reports\u002Fsummary.md`\n\nThen, in the chat response, deliver:\n\n1. **Binary fingerprint**\n   - format, architecture, strip\u002Fdebug-info status, Rust confidence\n\n2. **Namespace inventory**\n   - runtime crates\n   - likely application crates\n   - likely third-party crates\n\n3. **Entry points and boundaries**\n   - startup path\n   - exported functions\n   - imported APIs\n   - likely FFI edges\n\n4. **Recovered subsystems**\n   - networking\n   - storage\n   - crypto\n   - config\n   - async\u002Ftask execution\n   - panic\u002Ferror handling\n\n5. **Key call flows**\n   - one or two high-value paths only\n   - note confidence and evidence for each path\n\n6. **Open questions**\n   - what remains ambiguous\n   - what extra evidence is needed next (debug info, runtime breakpoints, comparison build, related library)\n\n## Rationalizations to Reject\n\nReject these shortcuts:\n\n- “The decompiler said it, so it must be true.”\n- “This looks like a trait object because it has two pointers.”\n- “Demangled symbols prove the original source layout.”\n- “A crate name in strings means the feature is definitely used.”\n- “This large dispatcher is obviously business logic.”  \n  It may just be compiler-generated async or panic\u002Fruntime machinery.\n\n## Output standard\n\nAlways mention the output directory first, then summarize the findings.\n\nUse this format when reporting to the user:\n\n```markdown\n## Reverse output\n\n- **Output dir**: `path\u002Fto\u002Ftarget-reverse-output`\n- **Summary report**: `path\u002Fto\u002Ftarget-reverse-output\u002Freports\u002Fsummary.md`\n\n## Rust binary summary\n\n- **Target**: `path\u002Fto\u002Fbinary`\n- **Format \u002F arch**: `ELF x86-64`\n- **Symbols**: `partially stripped`\n- **Debug info**: `DWARF absent`\n- **Rust confidence**: `high`\n\n## Namespaces\n\n- **Runtime crates**: `core`, `alloc`, `std`\n- **Likely app crates**: `my_app`, `engine`\n- **Likely third-party crates**: `tokio`, `serde_json`, `reqwest`\n\n## Entry points and boundaries\n\n- **Startup**: `_start -> ... -> main`\n- **Exports**: `plugin_init`, `process_request`\n- **Imports**: `connect`, `send`, `recv`, `pthread_create`\n- **FFI edges**: `plugin_init`, `process_request`\n\n## Key findings\n\n1. `process_request` appears to drive the request parsing path.\n2. Networking likely flows through a `reqwest`\u002F`hyper`-adjacent stack.\n3. A large dispatcher near `...::poll` is a strong async-state-machine candidate.\n\n## Next best move\n\n- break on `process_request`\n- trace the async poll path\n- inspect nearby strings\u002Fxrefs for request routing or serialization formats\n```\n\n## References\n\n- `references\u002Fsetup-guide.md`\n- `references\u002Ftriage-and-fingerprinting.md`\n- `references\u002Frust-patterns.md`\n- `references\u002Fstatic-analysis-workflow.md`\n- `references\u002Fdynamic-analysis-notes.md`\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering",483,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-13 02:16:32",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill rust-reverse-engineering",{"tool":61,"command":62},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill rust-reverse-engineering",{"tool":64,"command":65},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill rust-reverse-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002FSKILL.md",true,[69,75,79,83,87,91,95,101,105,109,113,117,121,125,129,133],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yaml","REFERENCE","参考文档",232,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fagents\u002Fopenai.yaml",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fdynamic-analysis-notes.md",887,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Freferences\u002Fdynamic-analysis-notes.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Frust-patterns.md",1734,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Freferences\u002Frust-patterns.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fsetup-guide.md",2032,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Freferences\u002Fsetup-guide.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fstatic-analysis-workflow.md",1001,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Freferences\u002Fstatic-analysis-workflow.md",{"path":92,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Ftriage-and-fingerprinting.md",1576,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Freferences\u002Ftriage-and-fingerprinting.md",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fcheck-deps.sh","SCRIPT","脚本",1459,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fcheck-deps.sh",{"path":102,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":103,"sourceHtmlUrl":104},"scripts\u002Fcollect-artifacts.sh",14912,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fcollect-artifacts.sh",{"path":106,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fdemangle-symbols.sh",1024,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fdemangle-symbols.sh",{"path":110,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fexport-ghidra-pseudocode.sh",13369,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fexport-ghidra-pseudocode.sh",{"path":114,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Ffind-rust-patterns.sh",3693,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Ffind-rust-patterns.sh",{"path":118,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fghidra-job.sh",9795,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fghidra-job.sh",{"path":122,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002Fghidra\u002FExportRustPseudocode.java",14780,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fghidra\u002FExportRustPseudocode.java",{"path":126,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":127,"sourceHtmlUrl":128},"scripts\u002Finstall-dep.sh",9471,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Finstall-dep.sh",{"path":130,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":131,"sourceHtmlUrl":132},"scripts\u002Fmacho-slice.sh",3694,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Fmacho-slice.sh",{"path":134,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":135,"sourceHtmlUrl":136},"scripts\u002Ftriage.sh",6101,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fjingjing2222\u002Frust-reverse-engineering-skill\u002Fskills\u002Frust-reverse-engineering\u002Fscripts\u002Ftriage.sh",[138,146,153,160,186,211],{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":145},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":145},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":145},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[167,168,169,170,171,172,173,174,175,176,177,25,178,179,180,181,182,183,184,185],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[193,194,195,181,196,197,198,199,200,201,202,203,204,205,172,206,207,208,209,210],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":228,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[217,222,225],{"categoryNo":218,"categoryName":219,"taxonomyType":220,"taxonomyTypeDesc":221},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":223,"categoryName":224,"taxonomyType":220,"taxonomyTypeDesc":221},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":226,"categoryName":227,"taxonomyType":220,"taxonomyTypeDesc":221},"01JBSEEDCAT000000000000010","后端与接口",[213,229,230,231,232,233,234,207,235,173,236,237,238,239,25,240,241,242,243,244],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]