[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C7N3R2TBP7E75W90WWHWS":3,"skill-same:01M71C7N3R2TBP7E75W90WWHWS":71},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71C7N3R2TBP7E75W90WWHWS","mcp-stdio-liveness-audit-macos",null,"Verify stdio MCP server liveness\u002Fattachment on macOS without inferring from age or fd state - five lsof\u002Fawk methodology traps, when fd-join is the wrong tool, the global-orphan host-recognition gap, the Codex MCP-duplication mechanism tiers, and the fd-not-idle \u002F alive-not-legitimate \u002F recommendation-not-authorization \u002F absence-not-absence discipline","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-stdio-liveness-audit-macos\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"macos","mcp stdio liveness audit macos","audit","MCP","awk","when","lsof","recommendation","join","host","gap","fd","mcp server","age","orphan","discipline","tool","server","codex","state","2026-11-10 10:12:30",false,"---\nname: mcp-stdio-liveness-audit-macos\ndescription: \"Verify stdio MCP server liveness\u002Fattachment on macOS without inferring from age or fd state - five lsof\u002Fawk methodology traps, when fd-join is the wrong tool, the global-orphan host-recognition gap, the Codex MCP-duplication mechanism tiers, and the fd-not-idle \u002F alive-not-legitimate \u002F recommendation-not-authorization \u002F absence-not-absence discipline\"\n---\n\n# MCP stdio liveness audit (macOS)\n\nUse when auditing whether stdio MCP server processes are live\u002Fattached vs orphaned\u002Fleaked - e.g. duplicate `npm exec` MCP servers under one Codex\u002FOMP\u002FClaude host.\n\n## The five traps\n\n### 1. lsof PIPE peer is in `$NF`, not `$9`\nmacOS `lsof` PIPE rows have a **blank NODE column**, so whitespace-collapse puts the peer pointer (`->0x...`) in the trailing NAME field, not column 9. Parsing `peer=$9` silently yields empty and every join returns 0.\n```awk\nlocal=$6; peer=$NF; sub(\u002F^->\u002F,\"\",peer)\n```\n\n### 2. Don't iterate `total[]` - seed the known leaf set\n`for (p in total)` only visits PIDs that had at least 1 PIPE row at fd 0\u002F1\u002F2. A fully-detached leaf (stdio to \u002Fdev\u002Fnull, no PIPE fds) **vanishes** instead of printing `0\u002FN`, hiding orphans. Seed awk with the enumerated descendant list and iterate THAT:\n```awk\nBEGIN { n=split(leaves,a,\",\"); for(i=1;i\u003C=n;i++) known[a[i]]=1 }\n$5==\"PIPE\" { pid=$2; fd=$4; local=$6; peer=$NF; sub(\u002F^->\u002F,\"\",peer);\n  if (pid==ROOT) root[local]=1;\n  if (fd==\"0\"||fd==\"1\"||fd==\"2\") { total[pid]++; if (peer in root) hit[pid]++; }\n}\nEND { for (p in known) printf \"%d %d\u002F%d\\n\", p, hit[p]+0, total[p]+0 }   # 0\u002F0 = no stdio PIPE at all\n```\n\n### 3. Classification: require `t==3 && h==3` for \"fully attached\"\nDo NOT use `h==t` - it miscounts a leaf with only 1\u002F1 or 2\u002F2 matching PIPE fds as fully attached. \"Fully attached\" across stdin\u002Fstdout\u002Fstderr requires exactly 3 PIPE-type stdio fds AND all 3 peers in the root set. Report `t\u003C3` and `t==0` as separate categories (a `t==0` leaf has stdio redirected to CHR\u002Funix, not PIPE). NOTE: \"fully fd-attached\" establishes the pipe is open; it does NOT establish \"idle\" or \"active\" - protocol activity \u002F which set is in use is a separate, fd-invisible question (see Discipline).\n\n### 4. fd-join only works for DIRECT-stdio hosts - OMP transport is UNRESOLVED\nThe leaf-stdio-peer to root-pipe-node join proves attachment **only when the host itself holds stdio PIPEs**. True for **Codex** (`codex resume`). For **OMP** (`bun omp --auto-approve`), a root-only PIPE fd-join returns 0\u002FN - **method-insufficient, NOT a detachment verdict**. OMP MCP transport is **UNRESOLVED**: a `bun __omp_worker_daemon_broker` child + unix sockets were observed, mcpvault stdio was confirmed to be a **unix socketpair** (not PIPE), but no leaf socket peer has been matched to a specific intermediary, and the broker holds ZERO pipe fds. Do **not** claim broker-mediation or any specific OMP mechanism as fact. Treat 0\u002FN OMP result as \"method-insufficient, topology unresolved,\" never \"detached.\" To settle: trace socketpair inodes \u002F KQUEUE peers, or read OMP internal state.\n\n### 5. Global orphan scan: recognize ALL MCP-owning hosts, not just codex-resume\u002Fomp\nA descendant-scoped audit (`getdesc \u003Croot>`) covers ONE tree; a launchd-reparented MCP process from a dead session is invisible. For a GLOBAL orphan verdict, enumerate ALL MCP-type procs system-wide and walk each one's ancestry. BUT the walk must recognize EVERY MCP-owning host pattern, not just `codex resume` and `bun omp`. Observed live: **ChatGPT.app runs its own MCP servers via `codex -c features.code_mode_host=true`** (a different codex invocation); Claude Code, IDE extensions, and Electron apps (Obsidian, ChatGPT.app) can also own MCP servers. A walkroot matching only codex-resume\u002Fomp will **MISLABEL** those as \"orphan to launchd\" when they are actually under a live (different) host. Distinguish: (a) **TRUE orphan** = chain reaches launchd with NO live app\u002Fhost in the chain (dead session); (b) **live non-canonical host** = chain reaches launchd THROUGH a live app. Label the top ancestor explicitly; do not collapse both into \"orphan.\" (Live finding: PID 1553 obsidian-mcp-tools scanned as orphan-to-launchd but was actually under ChatGPT.app\u002F668 via codex code-mode-host 1301.)\n\n## Codex MCP-duplication signature (mechanism tiers)\nWhen N complete MCP sets appear as direct children of one `codex resume` session, all fd-ATTACHED (no orphans WITHIN the tree; protocol activity \u002F which set is in active use UNKNOWN - fd-attachment does NOT establish idle or active):\n\n- **CONFIRMED (observed):** the duplication is CORRELATED with subagent `thread_spawn` - one parent startup + one MCP set per spawned subagent thread (observed with named MURE role threads Lagrange\u002FVolta\u002FSartre), each fork adding +6-7 MCP procs parented to the main codex ppid. The ps\u002Flsof process-tree evidence shows the duplication tracks the forks.\n- **NOT EVIDENCED (not \"ruled out\"):** MCP-layer reconnect\u002FEOF. The inspected `connection_manager` logs show NO reconnect\u002FEOF entries, so reconnect is NOT EVIDENCED by that surface - but absence in ONE logger is not absence of the thing. A reconnect on a different log surface or an unlogged retry remains POSSIBLE. Do not harden \"no reconnect logged\" into \"reconnect ruled out.\"\n- **PLAUSIBLE (inferred, not code-proven):** the internal mechanism \"Codex rollouts do not share stdio handles across forks\" - inferred from process-tree + lsof evidence, NOT from source. Keep it PLAUSIBLE until code inspection confirms.\n- **Config:** has NO respawn\u002Fwatch\u002Frestart\u002Fauto-reconnect directives - so the duplication is not config-driven from the inspected files.\n- **OPEN (leak vs expected overhead):** are the spawned subagents STILL ACTIVE (per-subagent MCP sets in use = legitimate MURE fan-out overhead) or FINISHED-with-unreaped-MCPs (persistent ppid-codex sets = teardown leak)? The all-attached fd-join is consistent with EITHER (it cannot distinguish in-use from unreaped). Settle by querying codex `logs_*.sqlite` for per-thread `thread.status` transitions and mapping to wave ps-pids.\n- **Wave-1 npm ENOENT asymmetry** (a server present in waves 2-N but absent in wave 1): PLAUSIBLE cause is npx `_npx` cache eviction, NOT verified; do not assume \"config changed between launches\" without a config-mtime or spawn-log check.\n\nCleanup: **restart the codex session** tears down all per-subagent MCP sets regardless of leak-vs-expected. Do NOT surgically kill old-wave leaves while the host holds their pipes (restart is a RECOMMENDED boundary, not authorization - read-only audits recommend; only the owner authorizes the mutation). Structural fix: HTTP-transport MCPs eliminate per-fork duplication at the source. Resident set grows over time (observed 23 to 33 leaves in ~50min) while staying all-attached; re-run the fd-join at cleanup time.\n\n## Discipline (every audit)\n- **fd-attachment is not active JSON-RPC use - and not \"idle\" either.** An open pipe proves the host still holds it; it proves NEITHER active use NOR idleness. Protocol activity \u002F which set is in use is fd-invisible; label it UNKNOWN or NEEDS-VERIFICATION. Do not write \"fd-attached-but-idle\" - \"idle\" is the same unproven inference as \"active,\" just inverted.\n- **Alive + owned is NOT legitimate \u002F intended \u002F unsuperseded.** A live parent proves ownership and aliveness only; it does not prove the host is intended, active, or not a stale duplicate. For live-vs-superseded classification (often the audit's actual purpose), each host's session and activity must be independently checked. Do not call a host \"legitimate\" from aliveness alone.\n- **Recommendation is NOT authorization.** A read-only audit task (constraint: \"do not stop\u002Fedit\u002Fdelete\") produces a recommended remediation boundary (e.g. \"restart session X\"); peer agent acceptance does not authorize the mutation, and the read-only constraint binds until the OWNER separately grants it. Frame recommendations as \"recommended boundary,\" never as authorized\u002Fin-progress\u002Fcompleted.\n- **Absence-of-evidence is not evidence-of-absence.** \"No X logged in the inspected surface\" supports \"X not evidenced,\" NOT \"X ruled out.\" Hardening the former into the latter is a recurring overclaim failure mode.\n- Each claim tier (CONFIRMED \u002F PLAUSIBLE \u002F NEEDS-VERIFICATION) needs its OWN evidence. Never promote inference from age, PPID, process count, or partial fd evidence to CONFIRMED.\n- **Scope claims explicitly.** \"Zero detached descendants in tree X\" is descendant-scoped, NOT \"zero orphaned MCP servers system-wide.\" A global orphan verdict requires a system-wide scan with full host taxonomy (trap 5), and even then is bounded by the regex of server types scanned - state the scanned-type boundary and defer unconditional completeness to an independent critic.\n- State churns: rerun scans at report time. Observed 23 to 33 leaves under one codex session in ~50min while staying all-attached; processes die\u002Frespawn across the audit window.\n- Secrets: config files (`~\u002F.codex\u002Fconfig.toml`, `.mcp.json`) carry inline tokens. Grep TOML headers (`^\\[mcp_servers\\.`) for KEY names only; `jq -r '.mcpServers|keys[]'` for JSON keys; never cat\u002Fdump values.\n\n## Scout delegation caution\nA weak scout will misuse `read(bash:\u002F\u002F...)`, `write(\u002Fdev\u002Fstdin)`, and `hub(start)` as shell-execution paths and loop without yielding. If a scout stalls on tool errors, cancel and run the check inline. Liveness config-reads and fd-joins are small enough to own directly; reserve scouts for genuinely independent broad sweeps and adversarial cross-checks (e.g. a completeness critic that re-runs the global scan with an independent host taxonomy).\n","# MCP stdio liveness audit (macOS)\n\nUse when auditing whether stdio MCP server processes are live\u002Fattached vs orphaned\u002Fleaked - e.g. duplicate `npm exec` MCP servers under one Codex\u002FOMP\u002FClaude host.\n\n## The five traps\n\n### 1. lsof PIPE peer is in `$NF`, not `$9`\nmacOS `lsof` PIPE rows have a **blank NODE column**, so whitespace-collapse puts the peer pointer (`->0x...`) in the trailing NAME field, not column 9. Parsing `peer=$9` silently yields empty and every join returns 0.\n```awk\nlocal=$6; peer=$NF; sub(\u002F^->\u002F,\"\",peer)\n```\n\n### 2. Don't iterate `total[]` - seed the known leaf set\n`for (p in total)` only visits PIDs that had at least 1 PIPE row at fd 0\u002F1\u002F2. A fully-detached leaf (stdio to \u002Fdev\u002Fnull, no PIPE fds) **vanishes** instead of printing `0\u002FN`, hiding orphans. Seed awk with the enumerated descendant list and iterate THAT:\n```awk\nBEGIN { n=split(leaves,a,\",\"); for(i=1;i\u003C=n;i++) known[a[i]]=1 }\n$5==\"PIPE\" { pid=$2; fd=$4; local=$6; peer=$NF; sub(\u002F^->\u002F,\"\",peer);\n  if (pid==ROOT) root[local]=1;\n  if (fd==\"0\"||fd==\"1\"||fd==\"2\") { total[pid]++; if (peer in root) hit[pid]++; }\n}\nEND { for (p in known) printf \"%d %d\u002F%d\\n\", p, hit[p]+0, total[p]+0 }   # 0\u002F0 = no stdio PIPE at all\n```\n\n### 3. Classification: require `t==3 && h==3` for \"fully attached\"\nDo NOT use `h==t` - it miscounts a leaf with only 1\u002F1 or 2\u002F2 matching PIPE fds as fully attached. \"Fully attached\" across stdin\u002Fstdout\u002Fstderr requires exactly 3 PIPE-type stdio fds AND all 3 peers in the root set. Report `t\u003C3` and `t==0` as separate categories (a `t==0` leaf has stdio redirected to CHR\u002Funix, not PIPE). NOTE: \"fully fd-attached\" establishes the pipe is open; it does NOT establish \"idle\" or \"active\" - protocol activity \u002F which set is in use is a separate, fd-invisible question (see Discipline).\n\n### 4. fd-join only works for DIRECT-stdio hosts - OMP transport is UNRESOLVED\nThe leaf-stdio-peer to root-pipe-node join proves attachment **only when the host itself holds stdio PIPEs**. True for **Codex** (`codex resume`). For **OMP** (`bun omp --auto-approve`), a root-only PIPE fd-join returns 0\u002FN - **method-insufficient, NOT a detachment verdict**. OMP MCP transport is **UNRESOLVED**: a `bun __omp_worker_daemon_broker` child + unix sockets were observed, mcpvault stdio was confirmed to be a **unix socketpair** (not PIPE), but no leaf socket peer has been matched to a specific intermediary, and the broker holds ZERO pipe fds. Do **not** claim broker-mediation or any specific OMP mechanism as fact. Treat 0\u002FN OMP result as \"method-insufficient, topology unresolved,\" never \"detached.\" To settle: trace socketpair inodes \u002F KQUEUE peers, or read OMP internal state.\n\n### 5. Global orphan scan: recognize ALL MCP-owning hosts, not just codex-resume\u002Fomp\nA descendant-scoped audit (`getdesc \u003Croot>`) covers ONE tree; a launchd-reparented MCP process from a dead session is invisible. For a GLOBAL orphan verdict, enumerate ALL MCP-type procs system-wide and walk each one's ancestry. BUT the walk must recognize EVERY MCP-owning host pattern, not just `codex resume` and `bun omp`. Observed live: **ChatGPT.app runs its own MCP servers via `codex -c features.code_mode_host=true`** (a different codex invocation); Claude Code, IDE extensions, and Electron apps (Obsidian, ChatGPT.app) can also own MCP servers. A walkroot matching only codex-resume\u002Fomp will **MISLABEL** those as \"orphan to launchd\" when they are actually under a live (different) host. Distinguish: (a) **TRUE orphan** = chain reaches launchd with NO live app\u002Fhost in the chain (dead session); (b) **live non-canonical host** = chain reaches launchd THROUGH a live app. Label the top ancestor explicitly; do not collapse both into \"orphan.\" (Live finding: PID 1553 obsidian-mcp-tools scanned as orphan-to-launchd but was actually under ChatGPT.app\u002F668 via codex code-mode-host 1301.)\n\n## Codex MCP-duplication signature (mechanism tiers)\nWhen N complete MCP sets appear as direct children of one `codex resume` session, all fd-ATTACHED (no orphans WITHIN the tree; protocol activity \u002F which set is in active use UNKNOWN - fd-attachment does NOT establish idle or active):\n\n- **CONFIRMED (observed):** the duplication is CORRELATED with subagent `thread_spawn` - one parent startup + one MCP set per spawned subagent thread (observed with named MURE role threads Lagrange\u002FVolta\u002FSartre), each fork adding +6-7 MCP procs parented to the main codex ppid. The ps\u002Flsof process-tree evidence shows the duplication tracks the forks.\n- **NOT EVIDENCED (not \"ruled out\"):** MCP-layer reconnect\u002FEOF. The inspected `connection_manager` logs show NO reconnect\u002FEOF entries, so reconnect is NOT EVIDENCED by that surface - but absence in ONE logger is not absence of the thing. A reconnect on a different log surface or an unlogged retry remains POSSIBLE. Do not harden \"no reconnect logged\" into \"reconnect ruled out.\"\n- **PLAUSIBLE (inferred, not code-proven):** the internal mechanism \"Codex rollouts do not share stdio handles across forks\" - inferred from process-tree + lsof evidence, NOT from source. Keep it PLAUSIBLE until code inspection confirms.\n- **Config:** has NO respawn\u002Fwatch\u002Frestart\u002Fauto-reconnect directives - so the duplication is not config-driven from the inspected files.\n- **OPEN (leak vs expected overhead):** are the spawned subagents STILL ACTIVE (per-subagent MCP sets in use = legitimate MURE fan-out overhead) or FINISHED-with-unreaped-MCPs (persistent ppid-codex sets = teardown leak)? The all-attached fd-join is consistent with EITHER (it cannot distinguish in-use from unreaped). Settle by querying codex `logs_*.sqlite` for per-thread `thread.status` transitions and mapping to wave ps-pids.\n- **Wave-1 npm ENOENT asymmetry** (a server present in waves 2-N but absent in wave 1): PLAUSIBLE cause is npx `_npx` cache eviction, NOT verified; do not assume \"config changed between launches\" without a config-mtime or spawn-log check.\n\nCleanup: **restart the codex session** tears down all per-subagent MCP sets regardless of leak-vs-expected. Do NOT surgically kill old-wave leaves while the host holds their pipes (restart is a RECOMMENDED boundary, not authorization - read-only audits recommend; only the owner authorizes the mutation). Structural fix: HTTP-transport MCPs eliminate per-fork duplication at the source. Resident set grows over time (observed 23 to 33 leaves in ~50min) while staying all-attached; re-run the fd-join at cleanup time.\n\n## Discipline (every audit)\n- **fd-attachment is not active JSON-RPC use - and not \"idle\" either.** An open pipe proves the host still holds it; it proves NEITHER active use NOR idleness. Protocol activity \u002F which set is in use is fd-invisible; label it UNKNOWN or NEEDS-VERIFICATION. Do not write \"fd-attached-but-idle\" - \"idle\" is the same unproven inference as \"active,\" just inverted.\n- **Alive + owned is NOT legitimate \u002F intended \u002F unsuperseded.** A live parent proves ownership and aliveness only; it does not prove the host is intended, active, or not a stale duplicate. For live-vs-superseded classification (often the audit's actual purpose), each host's session and activity must be independently checked. Do not call a host \"legitimate\" from aliveness alone.\n- **Recommendation is NOT authorization.** A read-only audit task (constraint: \"do not stop\u002Fedit\u002Fdelete\") produces a recommended remediation boundary (e.g. \"restart session X\"); peer agent acceptance does not authorize the mutation, and the read-only constraint binds until the OWNER separately grants it. Frame recommendations as \"recommended boundary,\" never as authorized\u002Fin-progress\u002Fcompleted.\n- **Absence-of-evidence is not evidence-of-absence.** \"No X logged in the inspected surface\" supports \"X not evidenced,\" NOT \"X ruled out.\" Hardening the former into the latter is a recurring overclaim failure mode.\n- Each claim tier (CONFIRMED \u002F PLAUSIBLE \u002F NEEDS-VERIFICATION) needs its OWN evidence. Never promote inference from age, PPID, process count, or partial fd evidence to CONFIRMED.\n- **Scope claims explicitly.** \"Zero detached descendants in tree X\" is descendant-scoped, NOT \"zero orphaned MCP servers system-wide.\" A global orphan verdict requires a system-wide scan with full host taxonomy (trap 5), and even then is bounded by the regex of server types scanned - state the scanned-type boundary and defer unconditional completeness to an independent critic.\n- State churns: rerun scans at report time. Observed 23 to 33 leaves under one codex session in ~50min while staying all-attached; processes die\u002Frespawn across the audit window.\n- Secrets: config files (`~\u002F.codex\u002Fconfig.toml`, `.mcp.json`) carry inline tokens. Grep TOML headers (`^\\[mcp_servers\\.`) for KEY names only; `jq -r '.mcpServers|keys[]'` for JSON keys; never cat\u002Fdump values.\n\n## Scout delegation caution\nA weak scout will misuse `read(bash:\u002F\u002F...)`, `write(\u002Fdev\u002Fstdin)`, and `hub(start)` as shell-execution paths and loop without yielding. If a scout stalls on tool errors, cancel and run the check inline. Liveness config-reads and fd-joins are small enough to own directly; reserve scouts for genuinely independent broad sweeps and adversarial cross-checks (e.g. a completeness critic that re-runs the global scan with an independent host taxonomy).\n",{"name":5,"description":7},"main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794","skills\u002Fmcp-stdio-liveness-audit-macos",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-11-11 16:42:59",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill mcp-stdio-liveness-audit-macos",{"tool":63,"command":64},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill mcp-stdio-liveness-audit-macos",{"tool":66,"command":67},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill mcp-stdio-liveness-audit-macos","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-stdio-liveness-audit-macos\u002FSKILL.md",true,[],[72,94,118,146,175,194],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":44},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[79,80,81,82,83,84,85,86,87,88,89,29,90,91,92,93],"zoom out","zoom","with","harness","how","section","re","true","understand","use","perspective","you","code","it","context",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":44},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[101,102,82,103,104,105,106,107,108,109,110,88,111,29,112,113,114,115,116,117],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":127,"publishedAt":44},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",[128,129,130,131,132,133,134,135,136,29,137,138,139,140,141,142,143,105,144,145],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"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":160,"publishedAt":44},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[152,155],{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[161,91,162,128,82,163,164,165,105,166,167,168,169,170,171,172,173,174,88,29],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":44},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[182,183,184,185,186,187,188,189,190,29,191,112,192,193],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":210,"publishedAt":44},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[200,203,206,207],{"categoryNo":201,"categoryName":202,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":204,"categoryName":205,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":208,"categoryName":209,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000036","内容创作者",[211,212,213,29,112,214,82,215,106,88,216],"writing","writing skills","new","work","editing","Existing"]