GitHub profilePlugins by Yicheng-Mark
15 plugins by Yicheng-Mark in the catalog, most-starred first.
Yicheng-Markhermes-dpapi-secretsResolve Hermes environment variables at startup from a single secret file encrypted with the Windows Data Protection API, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.dpapi.map, an ENV_VAR -> store-name mapping (bare names or dpapi:// names) plus an optional file path (default <HERMES_HOME>/secrets.dpapi). The file is one DPAPI blob keyed by the current Windows user profile, so it is unreadable by another Windows account and worthless off the machine; it is written by the bundled CLI (python -m hermes_dpapi_secrets set NAME, value read from a prompt or stdin, never from argv) and only read at runtime. Mapped names that are missing or empty are skipped with a warning; a file that is not ours, a blob this user cannot decrypt, or a payload that is not a flat string map is reported as an error with nothing injected. Disclosure - this source decrypts a file for every Hermes process that enables it: resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. User-scope encryption only (the machine-wide flag is never used and is not exposed), and the at-rest protection is a bar for backups, cloud sync and dotfiles, not a boundary against code already running as the same user. Stdlib-only (ctypes): no Python dependencies, no subprocesses, no network calls, no self-update. Windows only. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — decrypts a DPAPI-encrypted secret file (default <HERMES_HOME>/secrets.dpapi) at startup for every Hermes process that enables it, and the resolved values become environment variables of Hermes and its child processes like `.env` entries; the encryption is per Windows user and protects backups, cloud sync and copied files, not against other code running as the same user. Local only: no network calls, no subprocesses.CommunitytoolsYicheng-Markhermes-wincredResolve Hermes environment variables from the current user's Windows Credential Manager at startup, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.wincred.map, an ENV_VAR -> generic-credential-target mapping (bare names or wincred:// names); each value is read with CredReadW in the current user's vault and handed to the secret-source orchestrator, which applies it with the usual precedence, provenance and conflict rules. Values may be UTF-8 or UTF-16LE (cmdkey and the Credential UI write UTF-16); anything that does not decode to text, or that contains interior NULs, is skipped with a warning instead of being injected as a mangled key. Disclosure - this source reads your Windows Credential Manager: only the generic credentials named in the map, with no enumeration of the vault. Resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. The package is read-only and stdlib-only (ctypes): it never creates, updates or deletes credentials, writes no files, starts no subprocesses, makes no network calls and does not self-update. Windows only. Credential Manager is user-scoped, so this raises the at-rest bar for backups, cloud sync and dotfiles; it is not a boundary against code already running as the same user. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — when enabled, reads only the Windows Credential Manager generic credentials named in secrets.wincred.map (no vault enumeration) and injects them as environment variables of the Hermes process and its children, exactly like .env entries; read-only, stdlib ctypes, no subprocesses, no network, no file writes; user-scoped at-rest protection, not a boundary against code already running as the same user.CommunitytoolsYicheng-Markhermes-windows-appsAnswer "what is installed on this Windows machine": the software inventory behind Apps & Features, swept straight from the four Uninstall registry keys (the machine's 64-bit and 32-bit views plus the user's), so a program is found even when the Settings page hides it - a per-user install that never shows on the machine page came from the user view on the writing machine. Each row carries version, publisher, size in MB, install date and which view it lives in; the same DisplayName in two views is a 32/64-bit dual install, marked instead of listed twice. Entries the publisher asked to hide (runtime packages, update rollups) are filtered out unless asked for. Details one program with every field its publisher wrote and a reading of the uninstall command (MSI product code, setup executable, appx, script) so the next step is known before anything is run; the install folder is checked against disk. Use it for "what did that installer actually register", for inventory before a cleanup, and for "which of the two installs does uninstalling remove". Read-only: registry keys are enumerated and uninstall strings are reported, never run; no network, no file writes, no elevation. The sweep is pure registry - 102 entries in seven milliseconds on the writing machine, the whole table in ten, no PowerShell, no WMI. The plugin declares no Python dependencies. Windows only. Disclosure - the tools report program names, versions, publishers, sizes, install folders and uninstall commands, and what is hidden from Apps & Features, to the model; treat the output like the machine's own Apps & Features page.CommunitytoolsYicheng-Markhermes-windows-devicesAnswer "which device on this Windows machine is unhappy, and what does it need" on Windows: win_device_table lists every present PnP device with its class (System, Net, HIDClass, Display), its status, its manufacturer, its stable device id, and its problem code in words - 28 is one with no driver installed, 10 one that cannot start, 43 one Windows stopped after it reported a failure, 22 one the person switched off on purpose and is not broken - filtering by name or id substring, by class, or to the devices that need attention; devices no longer plugged in are history, left out unless asked for. win_device_detail takes one device by id or name substring and adds the driver behind it from the signed-driver table - name, version, date, provider, signer, INF file, signed or not - or the absence of one, which for code 28 is the same fact said twice; a disabled device gets a note saying it is on purpose, not an alarm. Use it for the Device Manager yellow-mark question without opening Device Manager, for finding what an uninstalled program left behind, and for what changed after an update. Read-only: nothing is enabled, disabled, updated or reinstalled. Both answers come from CIM (Win32_PnPEntity and Win32_PnPSignedDriver, joined by device id), whose property names, enum values and ids do not change with the display language; the human-facing device names localize and are carried through as data, never parsed. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure — the tools report device names, manufacturers, device ids and driver versions to the model, and those reveal the machine's hardware inventory and what is plugged into it; treat the output like a Device Manager window opened on their machine.CommunitytoolsYicheng-Markhermes-windows-disksAnswer "are this machine's disks healthy, and which volume is filling up" on Windows: one table of every physical disk (model, serial, SSD/HDD/SCM, bus - nvme, sata, usb -, size, the storage stack's health word, GPT or MBR, boot/system flags, partition count) and every volume (drive letter, label, file system, capacity, free space with its percentage and a verdict, fixed/removable/network/cd-rom, the disk a volume lives on, the UNC path behind a mapped drive); volumes without a drive letter (EFI, recovery) are hidden unless asked for. win_disk_detail reads one disk or volume - by drive letter, label, model, serial or disk number - with the health in words (warning, unhealthy, and "unknown", which the storage stack reports on a perfectly healthy NVMe while OperationalStatus says ok - both are shown), the partition layout decoded from its GUID type (efi system, microsoft reserved, basic data, windows recovery), each partition's size, offset and letter, the largest contiguous free extent, and a plain-word free-space verdict (under 5 percent critical, under 10 percent low). Use it for "why is the disk slow", "will this drive fail", "where did the space go". Read-only: the storage classes are queried in one PowerShell CIM session, nothing is defragmented, formatted, resized, checked or repaired; no writes, no elevation, no network calls of its own. Enum values arrive as numbers and are decoded in the plugin - a Chinese-language Windows 11 was verified never to reach the answer; the whole table answers in about two thirds of a second. The plugin declares no Python dependencies. Windows only. Disclosure - the tools report disk models, serial numbers, sizes, health words, partition layouts, volume labels, capacities and free space, and the UNC paths behind mapped drives, to the model; treat the output like the machine's own Disk Management page.CommunitytoolsYicheng-Markhermes-windows-eventlogAnswer "why did this process die" on Windows: three read-only tools over the Windows Event Log. win_crash_events reads Application Error / Application Hang / Windows Error Reporting / .NET Runtime records for a time window, decodes the exception code (0xC0000005 -> ACCESS_VIOLATION and the other codes a debugger would name), reports the faulting module, its path and the fault offset, and groups repeated crashes by app and signature. Records are classified by provider as well as by event id, so unrelated providers that reuse ids 1000 and 1001 for informational events are not reported as crashes. win_shutdown_events reads the System log for Kernel-Power 41 unexpected restarts, bugchecks decoded to names (0x9F -> DRIVER_POWER_STATE_FAILURE, accepting the decimal form some providers emit), EventLog 6008 dirty shutdowns, 1074 operator-initiated restarts with the process and comment, and the 6005/6006/12/13 start and stop markers. win_eventlog_query is the general case: any channel, filtered by event ids, levels, an exact provider name or a payload substring, returning structured records instead of raw XML. Queries read newest-first and stop at the window start or at a 5000-record scan cap; a call returns at most 200 records and marks truncated payload text. Channel names, provider names and numeric filters are validated before anything is interpolated into the query. Disclosure - this plugin reads the local Windows event logs and hands what it finds to the model: application and faulting-module paths, exception codes and offsets, report ids, service names and provider message text, which routinely includes user and machine paths (C:\Users\<name>\...). Treat tool output like any other local diagnostic dump when sharing it. It reads only the channels the current account may read - Security and some operational logs answer with an access-denied error rather than any attempt to obtain elevation - and it never writes to a log, clears one or configures a channel. Stdlib-only (ctypes wevtapi plus xml.etree): no Python dependencies, no child processes, no network calls, no file writes, no self-update. Windows only. Disclosure — reads the local Windows event logs and hands what it finds to the model: application and faulting-module paths, exception codes and offsets, report ids, service names and provider message text, which routinely include user and machine paths (C:\Users\<name>\...); win_eventlog_query reads any channel the account running Hermes may read, so an unelevated account gets access-denied on Security and some operational logs while an elevated Hermes can return Security-log records (logon events with account names and source addresses). It never requests elevation, never writes to, clears or configures a log, and has no Python dependencies, child processes, network calls, file writes or self-update. Windows only.CommunitytoolsYicheng-Markhermes-windows-opsWindows and WSL triage skills for Hermes: processes that survive a quit (orphaned stdio MCP trees, lingering python/uv/node children), WSL-to-Windows interop where an argument reaches cmd.exe as shell syntax, config and encoding traps (UTF-8 BOM, legacy console code pages), and long-path or reserved-name errors. One skill plus a copy-paste command reference; the process, argv and job-object failure modes are pinned to reports #131561, #132069 and #61059 and re-verified against current main. Disclosure — instructions only: no tools, hooks, middleware, network calls or credentials, and the destructive diagnostics are marked and gated on asking the user first.CommunitytoolsYicheng-Markhermes-windows-portsAnswer "who holds this port" on Windows. win_port_owners reads the TCP and UDP owner tables through iphlpapi (the same rows netstat -ano prints, with the owning PID attached) and resolves each PID to its image name and path, returning one structured record per endpoint. Filters cover one port, several ports, a process substring, the protocol (tcp, udp or both), the TCP state (listen, established, any state name, or all; UDP rows report bound) and IPv6 inclusion, with a record cap and a per-process summary of the rows returned. Built for the failure mode that stalls agents on Windows: a gateway, backend or bridge that cannot bind, where the error names a port but not the process holding it. netstat -ano prints columns, not fields, and its PID still needs a second command (tasklist, or a PowerShell round-trip) to become an image name; this tool is one in-process call instead of a shell parse plus a join, with no child process and no dependency on PowerShell being installed or allowed by execution policy. A protected process whose image cannot be queried keeps its PID and reports a null process name instead of failing the call. Disclosure - the tool reports the local and remote addresses, ports, PIDs and process image paths that netstat -ano and Task Manager already show, and those values reach the model; treat the output like any other local diagnostic listing. Read-only: no socket is opened, bound or connected, the only process access is QueryFullProcessImageName with PROCESS_QUERY_LIMITED_INFORMATION to read an image name, and there is no memory reading, no handle inheritance and no injection. Stdlib-only (ctypes): no Python dependencies, no child processes, no network calls, no file writes, no self-update. Windows only.CommunitytoolsYicheng-Markhermes-windows-processAnswer "what is still running, and who started it" on Windows: win_process_table reads the process table (PID, parent PID, image name) and adds each process's image path and creation time, then marks every row with whether its recorded parent is still the process that spawned it. Windows stores a parent PID rather than a handle, so a child that outlived its parent points at a PID that is either unused or reused by a newer process; a parent that started after its child cannot have spawned it, so both cases are reported as gone or reused instead of a plausible but wrong parent name. Filters cover one PID, several PIDs, a name or path substring, a parent PID, and an orphans-only view of what outlived its parent, with a result cap and an option to leave out Windows session processes. Use it for leftover gateway/backend/server children after a quit, for telling thirty python.exe rows apart by start time, and for checking whether a process started before or after the thing being debugged. Read-only: processes are opened with PROCESS_QUERY_LIMITED_INFORMATION for QueryFullProcessImageName and GetProcessTimes only - no memory reads (command lines are deliberately out of scope), no handle duplication, no writes, no child processes. Stdlib-only (ctypes): no Python dependencies, no network calls, no file writes, no self-update. Windows only. Disclosure - the tool reports image names, image paths and start times to the model, and those routinely include the user and machine name (C:\Users\<name>\...) and reveal which editor, shell or agent started which process; treat the output like a Task Manager screenshot.CommunitytoolsYicheng-Markhermes-windows-servicesAnswer "what runs as a service on this machine, why did one fail, and what does it depend on" on Windows: win_service_table lists every service with its state (Running, Stopped, Paused), its start mode (Auto, Manual, Disabled, with the delayed flag folded in as "Auto, delayed"), the pid it runs under, the account and binary it runs as, the dependency edges both ways, and what its exit code means - 1077 is one that has not tried to start since the last boot, 1053 one that did not answer in time, 1075 one whose dependency failed first, 2 one whose binary is gone. win_service_detail takes one service and gives what Windows does when it fails (the FailureActions blob decoded: restart the service, restart the computer, run a command, after how many seconds, and when the count resets), whether the registered binary is still on disk, and the Service Control Manager's own event-log record behind the failure - 7000 failed to start, 7009 a start request that timed out, 7024 a service-specific error, 7031 an unexpected end, 7045 an install. Use it for what died after the last update, for finding what an uninstalled program left registered, and for the dependency order before a restart. Read-only: nothing is started, stopped, reconfigured or deleted. The listing comes from one Get-CimInstance Win32_Service call because its property names and enum values do not change with the display language while sc.exe localizes both; dependencies and failure actions are read from the registry, because CIM's DependOnService property is never populated and the failure policy exists nowhere in CIM at all. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report service names, display names, command lines, logon accounts and the event-log history to the model, and those reveal what the person has installed, what runs as their machine's system accounts, and the paths under C:\Program Files and C:\Users\<name>; treat the output like a Services window opened on their machine.CommunitytoolsYicheng-Markhermes-windows-startupAnswer "what launches itself on this machine" on Windows: win_startup_table lists every autostart entry across the six Run/RunOnce registry keys (HKCU and HKLM, plus the 32-bit views) and the two Startup folders, with where each one comes from, whether it is machine- or user-scoped, and whether the person switched it off in Task Manager - Explorer's StartupApproved verdict, with the date it was last changed, a state Win32_StartupCommand has no field for; approval records uninstalled programs left behind are reported as leftovers, their unknown state bytes surfaced as-is rather than guessed into verdicts. win_startup_detail takes one entry and resolves its command the way the loader does - quoting, arguments, environment variables, and unquoted paths with spaces resolved by longest existing prefix - and says whether the binary is still on disk, plus a folder file's size and last change. Use it for what added itself since last month, for slimming a slow sign-in, and for a launcher whose program is already gone. Read-only: nothing is enabled, disabled or deleted; the Startup folders are read through Explorer's User Shell Folders values so OneDrive-redirected folders are found. The sweep is registry and directory reads only - about a millisecond for three Run values and two folders on the machine it was written on, no PowerShell, no WMI. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report program names, launch commands, binary paths under C:\Program Files and C:\Users\<name>, and what the person chose to keep from starting, to the model; treat the output like the Startup tab of the person's own Task Manager.CommunitytoolsYicheng-Markhermes-windows-tasksAnswer "what does this machine run on its own, and did it work" on Windows: win_scheduled_tasks lists the Task Scheduler's tasks with their state (Ready, Running, Disabled), the account each runs as, its first action's command line, its triggers in words (at logon, daily, weekly, at a time, on event), its last and next run with the machine's offset, its missed runs, and what its last result code means - 0x80070002 is a program that is no longer there, 0x800710E0 a task that needed a desktop it did not have, 0x40010004 one that was stopped, 0x80040154 a COM class that is not registered. win_scheduled_task_detail takes one task and gives its triggers with start boundaries and repetition, its actions with arguments and working directory, its principal and the settings that decide whether it runs on battery or when late; a task with no triggers but MaintenanceSettings runs during automatic maintenance and the notes say so rather than leaving an empty list. Use it for why a logon task keeps failing, for finding what an uninstalled program left behind at logon, for telling a disabled task from a broken one, and for reading a task's command line before trusting it. Read-only: nothing is created, started, changed or deleted. Reads through the ScheduledTasks cmdlets rather than the store on disk, because the TaskCache registry tree and C:\Windows\System32\Tasks both answer access denied without elevation, and rather than schtasks /Query /FO CSV, which is localized and interleaves error lines for tasks whose definitions are gone. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report task paths, command lines, working directories, account names and SIDs to the model, and those reveal what the person has installed, what starts at their logon, and the paths under C:\Users\<name>; treat the output like a Task Scheduler window opened on their machine.CommunitytoolsYicheng-Markhermes-windows-updatesAnswer "what did Windows install lately, and did it work" on Windows: the update history the Settings app shows - Windows updates, Defender signature and platform updates, driver updates - newest first, with each entry's outcome in words (in progress, succeeded, succeeded with errors, failed, aborted) and, when an entry did not end clean, the failure's error code in 0x form (the agent hands codes over signed; -2145124300 is shown as its unsigned spelling). Filter to the ones that did not end clean, or search titles. The hotfix list (KB numbers, security updates, install dates, newest first) answers "when was this machine last patched" at a glance; it carries OS-level updates only, which the notes say. Use it for "why does it say pending forever", for "did the update that broke something actually install", and for a patch report before assuming a machine is current. Read-only: the history is queried through the Windows Update Agent's session interface and CIM, and nothing else - no update search is run, nothing is downloaded, installed or uninstalled, no elevation. On the writing machine a 723-entry history returns the newest 500 in about a tenth of a second; the first call also starts the COM session, about a quarter of a second. The plugin declares no Python dependencies; there is no network call of its own and no file write. Windows only. Disclosure — each tool call runs one hidden powershell.exe with a fixed read-only script (Windows Update Agent history through COM, Win32_QuickFixEngineering through CIM; no update search, download or install); the tools report update titles, dates, outcomes, failure codes and support links, and hotfix ids, descriptions, install dates and the account that installed them, to the model; treat the output like the Settings app's own update history page.CommunitytoolsYicheng-Markhermes-wsl-terminalRun Hermes' terminal tools inside an existing WSL distro on Windows: one bash -c per command as the distro's default user, over the same files Windows sees at /mnt/<drive>, with no Docker Desktop, no image and no container to start or tear down. A host cwd is translated (C:\Users\me\proj becomes /mnt/c/Users/me/proj, \\wsl.localhost paths become the distro's own paths) and the mount root is asked once with wslpath, so a distro that moved its automount point still gets correct paths. cwd persists across commands, stdin and exit codes ride through wsl.exe, and hermes doctor / setup and the dashboard picker get real rows (wsl.exe path, WSL version, distros present, selected distro). HERMES_WSL_DISTRO and HERMES_WSL_USER select the distro and the user. Disclosure — this is a full-access backend, not a sandbox: when it is the selected backend, everything the terminal tool runs executes as your user inside your distro, with that distro's files, permissions and network access, so dangerous-command approval stays on and Hermes never stops the distro. The plugin itself reads no credentials, stores nothing and makes no network calls; it spawns wsl.exe per command and wslpath once per distro. It rewrites one core-produced string, the trailing cwd marker, because under WSL a command substitution is handed the directory wsl.exe started in rather than the shell's current one (measurements in the repo's VALIDATION.md); nothing in Hermes is patched or rebound at runtime.CommunitytoolsYicheng-Markhermes-wslc-sandboxRun Hermes' terminal, file and execute_code tools in a Linux container on Microsoft's WSL Containers (wslc) runtime, so Windows users who run WSL Containers get a sandbox without Docker Desktop. Disclosure — the plugin spawns the wslc CLI (one short-lived process per command, plus one long-lived container per environment) and every call runs inside that container; containers have outbound network access unless docker_network is false; persistent sandboxes are left stopped on disk until removed; host environment variables enter the container only when named in docker_forward_env, and only paths listed in docker_volumes are bind-mounted. wslc rejects --cap-drop, --security-opt, --pids-limit, --init and --storage-opt, so this sandbox is not capability-dropped the way the Docker backend's is, container_disk is reported but not enforced, and dangerous-command approval deliberately stays enabled for this backend. The plugin reads no credentials, stores none, and makes no network calls of its own.Communitytools
