[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DA7AMHSDTKWJVX07967KGE":3,"skill-same:01M6DA7AMHSDTKWJVX07967KGE":86},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M6DA7AMHSDTKWJVX07967KGE","diet-assess-risk",null,"Deep-dive security risk analysis for a dependency flagged by uzomuzo diet","future-architect\u002Fuzomuzo-oss","future-architect","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F14890632?v=4","01M6DA6C4A1ESW410NS3Y424QR","Future Corp","01M6DA6C8ET9B0110HVZD8DCZB",45,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fdiet-assess-risk\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"risk","diet assess risk","assess","diet","security","risk analysis","analysis","dependency","deep","module","purl","top","path","for","2026-11-10 10:12:30",false,"---\nname: diet-assess-risk\ndescription: \"Deep-dive security risk analysis for a dependency flagged by uzomuzo diet\"\nargument-hint: \"\u003CPURL or module path, or 'top N'>\"\n---\n\n# Diet Risk Assessment: $ARGUMENTS\n\nAnalyze the security risk of keeping a dependency identified by `uzomuzo diet`. This command performs deep data-flow analysis that diet's automated scoring cannot do.\n\n**When to use**: After `uzomuzo diet` flags a dependency as EOL\u002FStalled\u002FArchived\u002FReview Needed, or scan flags a malicious or dormant-release version. Dependencies diet reports as unused (`is_unused: true`, with coupling actually measured) usually just need removing; a \"trivial\" label alone is not enough, because it is also what unmeasured coupling looks like.\n\n**Relationship to diet skills**:\n- `uzomuzo diet` tells you **what** to remove and **how hard** (automated, broad)\n- `\u002Fdiet-assess-risk` tells you **how dangerous it is to keep** (LLM-powered, deep) -- **this skill**\n- `\u002Fdiet-evaluate-removal` tells you **whether removal is worth it** and **how to replace** (LLM-powered, per-dep)\n- `\u002Fdiet-remove` **executes the removal** (issue or PR)\n\nDo NOT assess replacement options or removal feasibility here -- that is `\u002Fdiet-evaluate-removal`'s job. This skill answers one question: **\"If we keep this dependency unchanged for the next 12 months, what is the realistic security exposure?\"**\n\n## Phase 0: Input normalization\n\nDetermine input mode and normalize to a diet entry before analysis.\n\n### Mode A: Diet JSON available\n\nExtract the target dependency's entry from the diet JSON:\n\n```bash\nuzomuzo diet --sbom bom.json --source . --format json | jq '.dependencies[] | select(.name == \"TARGET\")'\n```\n\nOr read from a saved diet JSON file. All fields are available.\n\n### Mode B: PURL only (no diet JSON)\n\nRun `uzomuzo scan \u003Cpurl>` to get health signals. Mark coupling fields (`import_file_count`, `call_site_count`, `api_breadth`, `symbols`, `import_files`) as \"unavailable\". Proceed with Phase 1 Steps 1-2 and Phase 3 only. Skip Phase 1 Steps 3-4 (no coupling data to filter) and Phase 2 (no source code). When classifying threat profile in Step 2, treat absent `import_file_count` as \"assume > 0\" (conservative — do not default to SUPPLY-CHAIN-ONLY). In the verdict, omit the \"Security-relevant coupling\" line and note \"Source coupling data unavailable\" in Limitations.\n\n### Mode C: \"top N\"\n\nSort diet entries by `health_risk * (1 - coupling_effort)` descending (both fields are 0.0-1.0 normalized). This prioritizes dependencies that are both unhealthy and actionable — high health risk combined with lower coupling effort gives the best risk-reduction ROI. Run Phase 0-3 for each of the top N entries (N is user-specified, default 5), then produce the summary table.\n\nIf coupling was not measured -- every entry without a `scope` has `import_file_count = 0` and `is_unused = false`. That happens when source analysis is skipped, fails, or matches no import because `--source` points at the wrong directory; the top-level `source_root` cannot tell you, because the CLI fills it with `.` by default. Then every `coupling_effort` is 0 and this sort degenerates to `health_risk` alone. Say so above the summary table, and treat each entry as Mode B for coupling.\n\nEach entry's assessment is independent. If your environment can run subagents, assess the N entries in parallel, one subagent per dependency, each returning only its verdict block; then build the summary table from the returned blocks. Separate contexts also stop one dependency's data flows from leaking into another's scenarios.\n\n### Signals that are not in diet JSON (all modes)\n\nDiet JSON does not carry the OSV malicious-package check or the npm dormant-release marker, and its vulnerability fields describe the package's latest release (including advisories in that release's own dependencies) rather than the version you ship. Before the early exits, fetch these for the exact version in the SBOM:\n\n```bash\nuzomuzo scan \"pkg:npm\u002Fexample@1.2.3\" --format json \\\n  | jq '.packages[0] | {lifecycle, reason, stable_version, malicious, malicious_check, dormant_release,\n                       direct_advisory_count, transitive_advisory_count, max_cvss3_score}'\n```\n\nuzomuzo runs the malicious-package check only for npm, PyPI, crates.io, Go, and Maven. For other ecosystems (NuGet, GitHub Actions, ...) neither `malicious` nor `malicious_check` appears, which means \"not checked\", not \"clean\".\n\nThen check the pinned version's advisories with an OSV-backed tool (`osv-scanner`, `govulncheck`, `npm audit`, `pip-audit`). Record both: \"advisories on the pinned version\" and \"advisories still present on the latest release\" (diet's `vulnerability_count`, split by scan into `direct_advisory_count` and `transitive_advisory_count`). Direct advisories on the latest release mean upgrading does not help; transitive-only ones live in a package this one depends on, and the data-flow analysis below should target that package's role, not this one's.\n\n### Early exits\n\n- If scan returns a `malicious` object: **Stop the normal flow.** Report \"Malicious version (advisory {advisory_id}) -- Remove urgently.\" Data-flow analysis is the wrong question here: malicious packages usually act when installed or imported, not through the call sites diet counts. Instead list where this version was installed (developer machines, CI runners, build images, production) and which secrets those environments hold, because those are what to rotate. With `scope: \"package\"`, every version is affected; with `scope: \"version\"`, moving to an unaffected version is enough. Link the advisory.\n- If `is_unused` is `true` (and not malicious): `is_unused` only means diet found no import. Dependencies loaded through configuration, plugins, reflection, ServiceLoader, or build commands still show as unused unless diet knows them (it recognizes Go `tool` directives and a fixed list of Java runtime libraries such as JDBC drivers and logging backends). Before treating an unused dependency as removable, search for its name in the source -- including `import type` \u002F `export type ... from` lines, which diet ignores, and places diet does not read (a `build\u002F`, `dist\u002F`, or `target\u002F` directory next to the manifest of a tool that writes there, such as `dist\u002F` next to `package.json` or `target\u002F` next to `pom.xml`; in files over 1 MiB, call sites and any import after the first 64 KiB; file types it does not parse) -- and in configuration and build files (`*.yml`, `*.properties`, `META-INF\u002Fservices\u002F*`, `spring.factories`, `package.json` scripts and config files, `Makefile`, CI workflows). If the search finds wiring, do not stop: treat the dependency as `scope: \"runtime\"` from here on and read the wiring files in Phase 2. If it finds nothing, report \"Unused in source -- no call-site data flow. Remove it.\" Add one line on install-time exposure (the first bullet of Scenario B) -- an installed but unused package can still run code on every machine that installs it, which is a reason to remove it rather than to ignore it. Then stop.\n- If `lifecycle` is `Active`, `has_vulnerabilities` is `false`, the pinned version has no advisories, scan shows no `malicious` and no `dormant_release`, `malicious_check` is not `\"unknown\"`, the ecosystem is one the malicious check covers, and the pinned version did not come out after a long silence: **Stop.** (The `dormant_release` marker is shown only for 7 days after publication, so for an older pin compare its publish date with the previous release's yourself.) Report \"Maintained, no known vulnerabilities. No immediate risk.\" This skill is for unhealthy dependencies.\n\n## Phase 1: Threat surface inventory\n\nThis phase uses **only diet JSON fields** -- no code reading. It classifies the threat surface and produces scoping decisions for Phase 2.\n\n### Step 1: Record diet facts\n\nExtract the full diet entry. These fields will appear verbatim in the verdict's \"Diet Facts\" section:\n\n| Field | JSON key | Use |\n|-------|----------|-----|\n| Identity | `purl`, `name`, `version`, `ecosystem` | Package identification |\n| Ranking | `rank`, `priority_score`, `overall_score` | Diet's automated ranking (`rank` is position among direct deps) |\n| Health | `health_risk`, `lifecycle`, `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` | Maintenance status; vulnerability fields are for the latest release and include its dependencies' advisories |\n| Graph | `graph_impact`, `exclusive_transitive`, `total_transitive` | Blast radius |\n| Coupling | `coupling_effort`, `difficulty`, `import_file_count`, `call_site_count`, `api_breadth` | Integration depth |\n| Coupling detail | `symbols`, `import_files` | Specific APIs used and files importing them (Phase 2 starting points) |\n| Persistence | `stays_as_indirect`, `indirect_via` | Whether risk is eliminable |\n| Import style | `has_blank_import`, `has_dot_import`, `has_wildcard_import` | Coupling accuracy caveats |\n| Scope | `scope` | `\"tool\"` = build-time only (Go `tool` directive); `\"runtime\"` = loaded by reflection, ServiceLoader, or classpath resources rather than imported (JDBC drivers, logging backends); absent for normal deps |\n| From scan | `malicious`, `malicious_check`, `dormant_release`, `reason` | Fetched in Phase 0; not part of diet JSON |\n\nNote: Only `scope`, `indirect_via`, and `import_files` may be absent from a diet entry. Numeric and boolean fields are always present, so `0` and `false` are real values -- except when coupling was not measured (see Mode C), where the zeros mean \"unknown\".\n\n### Step 2: Classify threat profile\n\nAssign a threat profile based on diet data:\n\nRows are evaluated top to bottom; the first match wins. \"Vulnerable\" below means advisories on the pinned version or on the latest stable release.\n\n| Profile | Criteria | Phase 2 strategy |\n|---------|----------|-----------------|\n| **COMPROMISED** | scan returned `malicious` | Handled by the early exit in Phase 0 |\n| **SUSPECT-RELEASE** | `dormant_release` present (shown for 7 days after publication), OR scan's `reason` starts with `Possible hijacked release`, OR you found from the release history that the pinned version came out after a year or more without releases and its publisher and contents are not yet verified | Phase 2 on security-critical files; Scenario B is the primary scenario. For npm, check who published the version (`npm view \u003Cpackage>@\u003Cversion> _npmUser`) against earlier releases and diff the package contents against the release before the silence. If `dormant_release.removed` is `true`, the version was unpublished, so `npm view \u003Cpackage>@\u003Cversion>` fails; compare against the release before the silence and plan to stay on it |\n| **WITHDRAWN** | scan's `reason` starts with `All releases yanked on` | Not a takeover signal: the registry offers no version to normal resolution, so a fresh install or lockfile update can break. Phase 2 is optional; the verdict is about what stops building, plus any advisories |\n| **CRITICAL-EXPOSURE** | Vulnerable AND `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND (`import_file_count > 0` OR `scope = \"runtime\"`) | Full Phase 2 on all security-critical files |\n| **LATENT-RISK** | `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND (`import_file_count > 0` OR `scope = \"runtime\"`) AND not vulnerable | Phase 2 on security-critical files only |\n| **SUPPLY-CHAIN-ONLY** | `is_unused = true` AND the Phase 0 search found nothing, OR `scope = \"tool\"` AND no production file imports it | Skip Phase 2 call-site reading -- but still assess install-time and build-time execution in Scenario B |\n| **MONITORING** | `lifecycle` is Active, Legacy-Safe, or Review Needed (lack of data), but vulnerable | Phase 2 optional -- assess known CVE impact |\n| **INCOMPLETE** | `malicious_check = \"unknown\"`, or the ecosystem is not covered by the malicious check, or `lifecycle = Review Needed` because data is missing (`Insufficient data for assessment`, `Commit data missing`), or the pinned version's advisories could not be checked, and nothing above matched | Do not call the package healthy. Report what could not be checked and re-run the failed lookup before deciding |\n| **LOW-RISK** | Any combination not matching above | Produce minimal assessment noting the dependency is healthy or benign |\n\nWhen coupling was not measured (see Mode C), `is_unused` is `false` and `import_file_count` is 0 for every entry. Do not read those zeros as \"no data flow\"; treat the dependency as Mode B (coupling unavailable, assume > 0).\n\nLifecycle values produced by diet: `Active`, `Stalled`, `Legacy-Safe`, `EOL-Confirmed`, `EOL-Effective`, `EOL-Scheduled`, `Archived`, `Review Needed`. Two of them need care:\n\n- `Archived` is diet's own label for \"the source repository is archived\"; it overrides the lifecycle label. `uzomuzo scan` reports the same package as `Stalled` unless the registry also signals end of life ([ADR-0020](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0020-archived-registry-liveness.md)). Check scan's `stable_version` and its release date: packages that moved into a monorepo keep publishing while the old repository is archived. Archived alone does not mean the code is known bad.\n- `Review Needed` covers three different situations, told apart by scan's `reason`: too little data to classify (`Insufficient data for assessment`, `Commit data missing`); every release yanked ([ADR-0022](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0022-all-releases-yanked-is-not-eol.md)); or, on npm, a release burst across release lines after a long silence -- how past takeovers of quiet npm packages have looked ([ADR-0026](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0026-dormant-release-burst.md)).\n\n### Step 3: Scope Phase 2 targets\n\nFilter `symbols[]` and `import_files[]` to identify security-relevant subsets.\n\n**Security-relevant symbol patterns** (language-neutral, case-insensitive substring match):\n\n```\nAuth, Cred, Secret, Token, Key, Encrypt, Decrypt, Sign, Verify, Cert,\nTLS, SSL, Hash, Password, Session, Cookie, Policy, ACL, Permission,\nRole, Assume, Identity, Provider, IAM, STS,\nConnect, Dial, Transport, Listen, Serve, Client, Request, Response,\nSQL, Query, Exec, Database, Store, Cache, Write, Put, Delete,\nMarshal, Unmarshal, Decode, Encode, Parse, Deserialize\n```\n\n**Security-critical file path patterns** (substring match on `import_files[]`):\n\n```\nauth\u002F, credential\u002F, secret\u002F, crypto\u002F, security\u002F, acl\u002F, policy\u002F,\nlogical\u002F, secrets\u002F, iam\u002F, rotation\u002F, roles\u002F, permission\u002F,\ntransport\u002F, client\u002F, server\u002F, handler\u002F, middleware\u002F, gateway\u002F,\nstorage\u002F, database\u002F, physical\u002F, cache\u002F, session\u002F, login\u002F,\napi\u002F, endpoint\u002F, route\u002F, grpc\u002F, http\u002F\n```\n\nThese patterns are **heuristics for prioritization, not hard filters**. A file that matches no pattern is not \"safe\" — it is merely lower priority. Any file in `import_files[]` could contain security-relevant code regardless of its path name.\n\nRecord:\n- **Priority 1 (high-confidence security)**: files matching path patterns above\n- **Priority 2 (remaining)**: all other files in `import_files[]`\n\nWhen the security-relevant subset exceeds 50% of `api_breadth`, the dependency is likely an infrastructure\u002Fsecurity SDK where nearly the entire API is security-relevant. In that case, treat all symbols as in-scope (do not filter by name) and rely solely on file prioritization for Phase 2 ordering.\n\n### Step 4: Note coupling accuracy caveats\n\nIf any of these flags are set, note them -- they affect Phase 2 accuracy:\n\n| Flag | Implication |\n|------|------------|\n| `has_dot_import` | Symbols used without package prefix -- `symbols[]` may be **undercounted**. Actual API surface is likely broader. |\n| `has_wildcard_import` | Same: `from x import *` \u002F `import static x.*` means undercounted symbols. |\n| `has_blank_import` | Import for its side effect (Go `import _ \"pkg\"`, JS `import 'pkg'`), usually to register something -- a SQL driver, codec, or handler -- that then receives data through other APIs (a registered SQL driver sees every query and the database credentials). Trace where the registered component is used instead of assuming data flow is limited. The flag can also appear next to ordinary calls. |\n\nIf `scope` is `\"tool\"`: diet sets this when the module appears in a Go `tool` directive. That proves tooling use, not the absence of runtime use: another package of the same module can still be imported by production code (e.g. `golang.org\u002Fx\u002Ftools\u002Fcmd\u002Fstringer` as a tool and `golang.org\u002Fx\u002Ftools\u002Fgo\u002Fpackages` in `main`). If `import_files` lists production files, assess them as runtime imports. Otherwise supply chain risk applies at build time (a compromised tool could inject code into the build), but there is no runtime data flow.\n\nIf `scope` is `\"runtime\"`: The dependency is loaded without a static import -- a JDBC driver named in a connection URL, a logging backend found on the classpath, a Spring auto-configuration. `import_files` will be empty, but the code runs in production and often sees sensitive data (a JDBC driver sees every query and the database password). For Phase 2, find where it is wired: configuration files (`application.yml`, `*.properties`, `META-INF\u002Fservices\u002F*`, `spring.factories`), connection strings, and `Class.forName` calls.\n\n## Phase 2: Targeted code inspection\n\n**Skip this phase entirely if:**\n- Threat profile is SUPPLY-CHAIN-ONLY. Skip Steps 1-2 and the call-site bullets of Step 3, but still write the install-time bullet of Scenario B (Step 3) and Step 4\n- No source code is available (Mode B input)\n- `import_file_count` is 0 and `scope` is not `\"runtime\"` (for `\"runtime\"`, read the wiring found in Phase 1 Step 4 instead of `import_files`)\n\nFor each skip case, add a \"Limitations\" note to the verdict explaining what could not be assessed and why.\n\n### Scoping strategy\n\nRead files in priority order (Priority 1 first, then Priority 2). **Stop when you have enough evidence to construct credible attack scenarios for both Scenario A and Scenario B** (see Step 3 below). You have enough evidence when you can answer all four questions in Step 2 (Data IN, Data OUT, Security boundary, Failure mode) for at least the most security-critical call sites.\n\n**Reading order:**\n1. Priority 1 files (from Phase 1 Step 3) — read these first\n2. Priority 2 files — read in order until you have enough evidence, or all files are read\n3. For any files not read, produce a statistical summary: \"N files in auth paths, M in infrastructure, K in tests\"\n\n**Stopping criteria — you have enough evidence when:**\n- You can name the concrete data types flowing IN and OUT of the dependency\n- You can describe at least one realistic attack scenario grounded in observed data flows\n- Reading more files would add volume but not change the risk verdict\n\nIf you stop before reading all files, record which files were read and which were not in the verdict's \"Limitations\" section. This is not a failure — it is an explicit scope decision.\n\n### Step 1: Classify import sites by security impact\n\nFor each file read, classify it:\n\n- **Security-critical**: handles auth, credentials, secrets, crypto, storage of sensitive data, network transport, policy\u002FACL decisions\n- **Infrastructure**: config loading, logging, metrics, CLI argument parsing, build tooling\n- **Peripheral**: tests, documentation, examples, code generation, benchmarks\n\n### Step 2: Trace data flows at security-critical sites\n\nFor each security-critical import location, determine:\n\n1. **Data IN**: What data is passed TO this dependency? (credentials, secrets, user input, config values, plaintext?)\n2. **Data OUT**: What data comes FROM this dependency? (connections, sessions, decoded secrets, query results?)\n3. **Security boundary**: Is there encryption, validation, or auth gating around the call site?\n4. **Failure mode**: If this dependency silently returned wrong data, what would break? Would anyone notice?\n\nQuote specific file paths and line numbers. Do not speculate -- if you cannot determine something from the code, say \"undetermined from static analysis.\"\n\n### Step 3: Construct attack scenarios\n\nBuild scenarios from the actual data flows observed in Step 2, not from generic templates.\n\n**Scenario A -- Unpatched vulnerability**:\n- Does the dependency have known CVEs? (check `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` from diet)\n- If known CVEs exist: What specific data flows are exposed by them?\n- If no known CVEs: Given the data flows observed, what category of vulnerability (RCE, data leak, auth bypass, DoS) would have the highest impact if discovered?\n\n**Scenario B -- Supply chain compromise** (a malicious version is published, typically through a stolen maintainer account):\n- **Install-time and build-time execution**: Does the package get to run code before any of your call sites do? npm `preinstall`\u002F`install`\u002F`postinstall` scripts, Python source distributions that run `setup.py`, Maven\u002FGradle plugins, Go `tool` directives and `go generate`. Some recent npm compromises, such as the self-spreading Shai-Hulud worm in 2025, did all their work in an install script, stealing npm tokens, GitHub tokens, and cloud keys from developer machines and CI runners. This applies even when `import_file_count = 0`. Name the environments that install this package and what secrets they hold.\n- If this package **exfiltrated data via IN flows**: What could an attacker steal? (Based on actual Data IN from Step 2)\n- If this package **altered OUT flows**: What would break? What would be silent?\n- Is the attack **detectable?** A crash is detectable. Subtly wrong auth decisions or silently leaked credentials are not.\n- **Takeover likelihood**: An unmaintained package with a single maintainer is easier to take over than an active one, and a takeover after a long silence is what scan's dormant-release marker watches for. Use `lifecycle`, `overall_score`, and `dormant_release` here; do not invent a probability.\n\n### Step 4: Identify mitigating factors\n\nThese factors affect **risk severity** (how dangerous is keeping this dependency), not removal feasibility (how hard is it to remove). Removal planning belongs in `\u002Fdiet-evaluate-removal`.\n\nFor each applicable factor, cite the evidence from the code:\n\n- Upstream encryption before data reaches this package\n- Downstream validation after data leaves this package\n- Package pinned by lockfile integrity (go.sum, package-lock.json, pip --require-hashes). This stops a swapped artifact for the same version; it does not stop a new malicious version from arriving through a routine lockfile update\n- Install scripts disabled where it is installed (`npm ci --ignore-scripts`, pnpm 10 or later, which does not run dependency build scripts unless allowed -- check the pnpm version and `onlyBuiltDependencies` before counting this, `pip install --only-binary :all:`). Removes the install-time part of Scenario B\n- Dependency updates held back by a minimum release age or manual review (e.g., Renovate `minimumReleaseAge`, pnpm `minimumReleaseAge`). Most malicious versions are named in an advisory within days of publication, though not all are removed from the registry\n- Provenance on the pinned version. npm provenance records which repository and workflow built the package; PyPI's default publish attestations record which trusted publisher uploaded it, which is not the same as where it was built. Read the attestation actually present. Either kind it does not prove the code is benign, and it does not help when the attacker can run the release workflow itself (e.g., with a stolen GitHub token). A version that lacks provenance when earlier ones had it is a warning sign\n- Package is small enough to audit -- judged from the package's own code and dependencies after reading them, not from `api_breadth`, which only counts the symbols your code uses (one call into a large SDK gives `api_breadth` 1)\n- Usage is behind a build tag \u002F feature flag that limits exposure\n- Test-only usage (files in `*_test.go`, `test\u002F`, `__tests__\u002F`, `tests\u002F`)\n- `scope: \"tool\"` with no production file importing it -- build-time only, no runtime exposure\n\n## Phase 3: Risk verdict\n\n### Single dependency verdict\n\n```\n### {package_name} -- Risk: {CRITICAL|HIGH|MEDIUM|LOW}\n\n#### Diet Facts (from automated analysis)\n\n| Metric | Value |\n|--------|-------|\n| PURL | `{purl}` ({name} {version}, {ecosystem}) |\n| Rank | #{rank} of {summary.total_direct} direct deps |\n| Lifecycle | {lifecycle} ([registry link]) |\n| Known CVEs (latest release) | {vulnerability_count} ({direct_advisory_count} direct, {transitive_advisory_count} via its dependencies) {(max CVSS: {max_cvss_score}) if present, else \"(CVSS unavailable)\"} |\n| Known CVEs (pinned version) | {count and IDs from OSV, or \"not checked\"} |\n| Malicious check | {clean \u002F flagged: {advisory_id} ({scope}) \u002F unknown -- lookup failed} |\n| Dormant release | {none \u002F {silent_days} days of silence, published {published_at}} *(npm only; omit row otherwise)* |\n| Priority \u002F Overall | {priority_score} \u002F {overall_score} |\n| Difficulty | {difficulty} (coupling_effort: {coupling_effort}) |\n| Coupling | {import_file_count} files, {call_site_count} calls, {api_breadth} APIs |\n| Graph impact | {graph_impact} (exclusive: {exclusive_transitive}, total: {total_transitive}) |\n| Health risk | {health_risk} |\n| Stays as indirect | {stays_as_indirect} {-- via {indirect_via} if true} |\n| Import caveats | {list any true flags: has_dot_import, has_wildcard_import, has_blank_import} *(omit row if all false)* |\n| Scope | {scope} *(omit row if absent)* |\n\n#### New Findings (from this assessment)\n\n**Threat profile**: {SUSPECT-RELEASE | WITHDRAWN | INCOMPLETE | CRITICAL-EXPOSURE | LATENT-RISK | SUPPLY-CHAIN-ONLY | MONITORING | LOW-RISK}\n\n**Files inspected**: {N} of {import_file_count} files read ({M} Priority 1, {K} Priority 2)\n\n**Data flow summary**:\n\n| Direction | Data type | Security relevance |\n|-----------|-----------|-------------------|\n| IN | {concrete data observed} | {impact if compromised} |\n| OUT | {concrete data observed} | {impact if tampered} |\n\n**Scenario A (Unpatched vulnerability)**: {concrete scenario based on observed data flows}\n\n**Scenario B (Supply chain compromise)**: {concrete scenario -- what could be stolen or altered}\n\n**Mitigating factors**:\n- {factor with code evidence}\n\n**Limitations**: {what could not be assessed -- e.g., \"51+ files; sampled 10 security-critical files only\"}\n\n**Verdict**: {1-2 sentence risk summary}\n**Recommended posture**: {one of the following}\n```\n\n#### Posture definitions\n\n| Posture | Meaning |\n|---------|---------|\n| **Remove urgently** | Malicious version, active exploitation risk, or critical data exposure. Run `\u002Fdiet-remove` now (for a malicious version: move off it first, then rotate the secrets listed in the verdict). |\n| **Plan removal** | Significant risk that grows over time. Run `\u002Fdiet-evaluate-removal` to plan. |\n| **Monitor** | Low current risk but degrading health. Re-assess quarterly. |\n| **Accept with documentation** | Risk is understood and mitigated. Document the decision and rationale. |\n\n### Multiple dependencies summary table (top N mode)\n\nAfter individual verdicts, produce a summary:\n\n| Package | Lifecycle | Diet Priority | Difficulty | Threat Profile | Risk | CVEs | Posture |\n|---------|-----------|--------------|------------|---------------|------|------|---------|\n\n## Primary Source Links\n\nThe verdict MUST include verifiable primary source links. Never claim \"EOL\", \"Archived\", or \"has CVEs\" without evidence.\n\n### Required links\n\n| Claim | Required link |\n|-------|--------------|\n| Lifecycle status | Package registry page (see PURL-to-URL table below) |\n| Known CVEs | NVD (`nvd.nist.gov\u002Fvuln\u002Fdetail\u002F\u003CCVE>`), GitHub Advisory (`github.com\u002Fadvisories\u002F\u003CGHSA>`), or OSV (`osv.dev\u002Fvulnerability\u002F\u003CID>`) |\n| Malicious version | The advisory scan names (`malicious.reference`), or `osv.dev\u002Fvulnerability\u002F\u003CMAL-ID>` |\n| Dormant release | The npm version page (`https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F\u003Cname>\u002Fv\u002F\u003Cversion>`) and the previous release's date |\n| Scorecard | `https:\u002F\u002Fscorecard.dev\u002Fviewer\u002F?uri=github.com\u002F\u003Corg>\u002F\u003Crepo>` |\n| Repository archived | GitHub repo URL (shows archived banner) |\n| Last commit date | `https:\u002F\u002Fgithub.com\u002F\u003Corg>\u002F\u003Crepo>\u002Fcommits\u002F\u003Cbranch>` |\n\n### PURL-to-registry URL\n\n| Ecosystem | URL pattern |\n|-----------|-------------|\n| `pkg:npm` | `https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F\u003Cname>` |\n| `pkg:golang` | `https:\u002F\u002Fpkg.go.dev\u002F\u003Cnamespace\u002Fname>` |\n| `pkg:pypi` | `https:\u002F\u002Fpypi.org\u002Fproject\u002F\u003Cname>` |\n| `pkg:maven` | `https:\u002F\u002Fcentral.sonatype.com\u002Fartifact\u002F\u003Cnamespace>\u002F\u003Cname>` |\n| `pkg:cargo` | `https:\u002F\u002Fcrates.io\u002Fcrates\u002F\u003Cname>` |\n| `pkg:nuget` | `https:\u002F\u002Fwww.nuget.org\u002Fpackages\u002F\u003Cname>` |\n| `pkg:githubactions` | `https:\u002F\u002Fgithub.com\u002F\u003Cnamespace>\u002F\u003Cname>` |\n\n## Language-specific reference\n\nThe core analysis (Phases 0-3) is language-neutral. Use this table for language-specific details:\n\n| Aspect | Go | Python | JavaScript\u002FTypeScript | Java |\n|--------|-----|--------|----------------------|------|\n| Build constraints | `\u002F\u002Fgo:build` tags | N\u002FA | N\u002FA | Maven profiles |\n| Side-effect imports | `import _ \"pkg\"` | `try\u002Fexcept ImportError` | `import 'pkg'` (no binding), `require('pkg')` | Static initializer blocks |\n| Wildcard imports | `import . \"pkg\"` | `from x import *` | N\u002FA (namespace `import * as ns` -- symbols tracked via `ns.` prefix) | `import static x.*` |\n| Lockfile integrity | `go.sum` hash verification | `pip --require-hashes` | `package-lock.json` integrity field | No standard lockfile: pinned versions plus checksum verification you configure explicitly (`maven-enforcer-plugin` alone does not verify artifact hashes) |\n| Vulnerability scanner | `govulncheck` | `pip-audit`, `safety` | `npm audit` | `dependency-check`, OWASP |\n| Test file patterns | `*_test.go` | `test_*.py`, `tests\u002F` | `*.test.js`, `__tests__\u002F` | `*Test.java`, `src\u002Ftest\u002F` |\n\n## Important rules\n\n- **Start from diet's output.** Do not re-discover what diet already computed. The `symbols[]` and `import_files[]` fields are your starting points for Phase 2.\n- **Fill diet's gaps from scan.** Malicious-version and dormant-release signals, and the advisories on the pinned version, are not in diet JSON. A verdict that skipped them must say so.\n- **Install time counts.** \"Zero imports\" removes call-site data flows, not the package's chance to run code on every machine that installs it.\n- **Read in priority order, stop when you have enough.** Phase 1 Step 3 gives you the reading order. Stop when you can construct credible attack scenarios — not when you hit an arbitrary file count.\n- **Be precise.** Quote specific file paths and line numbers. \"The auth module uses this\" is too vague.\n- **Do not speculate.** If you cannot determine something from the code, say \"undetermined from static analysis.\"\n- **Do not overstate risk.** If data is encrypted before reaching the package, the supply chain scenario changes. Say so.\n- **Focus on silent attacks.** Crashes are detectable. Subtle behavior changes (wrong auth decisions, leaked credentials, altered responses) are the real threat.\n- **Do not assess replacement options.** That is `\u002Fdiet-evaluate-removal`'s job. This skill assesses the risk of the status quo.\n- **Always include primary source links.** Every lifecycle claim, CVE reference, and scorecard score must have a clickable URL.\n- **State limitations explicitly.** If you sampled 10 of 51 files, or skipped Phase 2 because no source was available, say so in the verdict.\n- **`stays_as_indirect` matters.** If the dependency remains as an indirect dep after removal, note that removing direct usage reduces but does not eliminate the risk.\n","# Diet Risk Assessment: $ARGUMENTS\n\nAnalyze the security risk of keeping a dependency identified by `uzomuzo diet`. This command performs deep data-flow analysis that diet's automated scoring cannot do.\n\n**When to use**: After `uzomuzo diet` flags a dependency as EOL\u002FStalled\u002FArchived\u002FReview Needed, or scan flags a malicious or dormant-release version. Dependencies diet reports as unused (`is_unused: true`, with coupling actually measured) usually just need removing; a \"trivial\" label alone is not enough, because it is also what unmeasured coupling looks like.\n\n**Relationship to diet skills**:\n- `uzomuzo diet` tells you **what** to remove and **how hard** (automated, broad)\n- `\u002Fdiet-assess-risk` tells you **how dangerous it is to keep** (LLM-powered, deep) -- **this skill**\n- `\u002Fdiet-evaluate-removal` tells you **whether removal is worth it** and **how to replace** (LLM-powered, per-dep)\n- `\u002Fdiet-remove` **executes the removal** (issue or PR)\n\nDo NOT assess replacement options or removal feasibility here -- that is `\u002Fdiet-evaluate-removal`'s job. This skill answers one question: **\"If we keep this dependency unchanged for the next 12 months, what is the realistic security exposure?\"**\n\n## Phase 0: Input normalization\n\nDetermine input mode and normalize to a diet entry before analysis.\n\n### Mode A: Diet JSON available\n\nExtract the target dependency's entry from the diet JSON:\n\n```bash\nuzomuzo diet --sbom bom.json --source . --format json | jq '.dependencies[] | select(.name == \"TARGET\")'\n```\n\nOr read from a saved diet JSON file. All fields are available.\n\n### Mode B: PURL only (no diet JSON)\n\nRun `uzomuzo scan \u003Cpurl>` to get health signals. Mark coupling fields (`import_file_count`, `call_site_count`, `api_breadth`, `symbols`, `import_files`) as \"unavailable\". Proceed with Phase 1 Steps 1-2 and Phase 3 only. Skip Phase 1 Steps 3-4 (no coupling data to filter) and Phase 2 (no source code). When classifying threat profile in Step 2, treat absent `import_file_count` as \"assume > 0\" (conservative — do not default to SUPPLY-CHAIN-ONLY). In the verdict, omit the \"Security-relevant coupling\" line and note \"Source coupling data unavailable\" in Limitations.\n\n### Mode C: \"top N\"\n\nSort diet entries by `health_risk * (1 - coupling_effort)` descending (both fields are 0.0-1.0 normalized). This prioritizes dependencies that are both unhealthy and actionable — high health risk combined with lower coupling effort gives the best risk-reduction ROI. Run Phase 0-3 for each of the top N entries (N is user-specified, default 5), then produce the summary table.\n\nIf coupling was not measured -- every entry without a `scope` has `import_file_count = 0` and `is_unused = false`. That happens when source analysis is skipped, fails, or matches no import because `--source` points at the wrong directory; the top-level `source_root` cannot tell you, because the CLI fills it with `.` by default. Then every `coupling_effort` is 0 and this sort degenerates to `health_risk` alone. Say so above the summary table, and treat each entry as Mode B for coupling.\n\nEach entry's assessment is independent. If your environment can run subagents, assess the N entries in parallel, one subagent per dependency, each returning only its verdict block; then build the summary table from the returned blocks. Separate contexts also stop one dependency's data flows from leaking into another's scenarios.\n\n### Signals that are not in diet JSON (all modes)\n\nDiet JSON does not carry the OSV malicious-package check or the npm dormant-release marker, and its vulnerability fields describe the package's latest release (including advisories in that release's own dependencies) rather than the version you ship. Before the early exits, fetch these for the exact version in the SBOM:\n\n```bash\nuzomuzo scan \"pkg:npm\u002Fexample@1.2.3\" --format json \\\n  | jq '.packages[0] | {lifecycle, reason, stable_version, malicious, malicious_check, dormant_release,\n                       direct_advisory_count, transitive_advisory_count, max_cvss3_score}'\n```\n\nuzomuzo runs the malicious-package check only for npm, PyPI, crates.io, Go, and Maven. For other ecosystems (NuGet, GitHub Actions, ...) neither `malicious` nor `malicious_check` appears, which means \"not checked\", not \"clean\".\n\nThen check the pinned version's advisories with an OSV-backed tool (`osv-scanner`, `govulncheck`, `npm audit`, `pip-audit`). Record both: \"advisories on the pinned version\" and \"advisories still present on the latest release\" (diet's `vulnerability_count`, split by scan into `direct_advisory_count` and `transitive_advisory_count`). Direct advisories on the latest release mean upgrading does not help; transitive-only ones live in a package this one depends on, and the data-flow analysis below should target that package's role, not this one's.\n\n### Early exits\n\n- If scan returns a `malicious` object: **Stop the normal flow.** Report \"Malicious version (advisory {advisory_id}) -- Remove urgently.\" Data-flow analysis is the wrong question here: malicious packages usually act when installed or imported, not through the call sites diet counts. Instead list where this version was installed (developer machines, CI runners, build images, production) and which secrets those environments hold, because those are what to rotate. With `scope: \"package\"`, every version is affected; with `scope: \"version\"`, moving to an unaffected version is enough. Link the advisory.\n- If `is_unused` is `true` (and not malicious): `is_unused` only means diet found no import. Dependencies loaded through configuration, plugins, reflection, ServiceLoader, or build commands still show as unused unless diet knows them (it recognizes Go `tool` directives and a fixed list of Java runtime libraries such as JDBC drivers and logging backends). Before treating an unused dependency as removable, search for its name in the source -- including `import type` \u002F `export type ... from` lines, which diet ignores, and places diet does not read (a `build\u002F`, `dist\u002F`, or `target\u002F` directory next to the manifest of a tool that writes there, such as `dist\u002F` next to `package.json` or `target\u002F` next to `pom.xml`; in files over 1 MiB, call sites and any import after the first 64 KiB; file types it does not parse) -- and in configuration and build files (`*.yml`, `*.properties`, `META-INF\u002Fservices\u002F*`, `spring.factories`, `package.json` scripts and config files, `Makefile`, CI workflows). If the search finds wiring, do not stop: treat the dependency as `scope: \"runtime\"` from here on and read the wiring files in Phase 2. If it finds nothing, report \"Unused in source -- no call-site data flow. Remove it.\" Add one line on install-time exposure (the first bullet of Scenario B) -- an installed but unused package can still run code on every machine that installs it, which is a reason to remove it rather than to ignore it. Then stop.\n- If `lifecycle` is `Active`, `has_vulnerabilities` is `false`, the pinned version has no advisories, scan shows no `malicious` and no `dormant_release`, `malicious_check` is not `\"unknown\"`, the ecosystem is one the malicious check covers, and the pinned version did not come out after a long silence: **Stop.** (The `dormant_release` marker is shown only for 7 days after publication, so for an older pin compare its publish date with the previous release's yourself.) Report \"Maintained, no known vulnerabilities. No immediate risk.\" This skill is for unhealthy dependencies.\n\n## Phase 1: Threat surface inventory\n\nThis phase uses **only diet JSON fields** -- no code reading. It classifies the threat surface and produces scoping decisions for Phase 2.\n\n### Step 1: Record diet facts\n\nExtract the full diet entry. These fields will appear verbatim in the verdict's \"Diet Facts\" section:\n\n| Field | JSON key | Use |\n|-------|----------|-----|\n| Identity | `purl`, `name`, `version`, `ecosystem` | Package identification |\n| Ranking | `rank`, `priority_score`, `overall_score` | Diet's automated ranking (`rank` is position among direct deps) |\n| Health | `health_risk`, `lifecycle`, `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` | Maintenance status; vulnerability fields are for the latest release and include its dependencies' advisories |\n| Graph | `graph_impact`, `exclusive_transitive`, `total_transitive` | Blast radius |\n| Coupling | `coupling_effort`, `difficulty`, `import_file_count`, `call_site_count`, `api_breadth` | Integration depth |\n| Coupling detail | `symbols`, `import_files` | Specific APIs used and files importing them (Phase 2 starting points) |\n| Persistence | `stays_as_indirect`, `indirect_via` | Whether risk is eliminable |\n| Import style | `has_blank_import`, `has_dot_import`, `has_wildcard_import` | Coupling accuracy caveats |\n| Scope | `scope` | `\"tool\"` = build-time only (Go `tool` directive); `\"runtime\"` = loaded by reflection, ServiceLoader, or classpath resources rather than imported (JDBC drivers, logging backends); absent for normal deps |\n| From scan | `malicious`, `malicious_check`, `dormant_release`, `reason` | Fetched in Phase 0; not part of diet JSON |\n\nNote: Only `scope`, `indirect_via`, and `import_files` may be absent from a diet entry. Numeric and boolean fields are always present, so `0` and `false` are real values -- except when coupling was not measured (see Mode C), where the zeros mean \"unknown\".\n\n### Step 2: Classify threat profile\n\nAssign a threat profile based on diet data:\n\nRows are evaluated top to bottom; the first match wins. \"Vulnerable\" below means advisories on the pinned version or on the latest stable release.\n\n| Profile | Criteria | Phase 2 strategy |\n|---------|----------|-----------------|\n| **COMPROMISED** | scan returned `malicious` | Handled by the early exit in Phase 0 |\n| **SUSPECT-RELEASE** | `dormant_release` present (shown for 7 days after publication), OR scan's `reason` starts with `Possible hijacked release`, OR you found from the release history that the pinned version came out after a year or more without releases and its publisher and contents are not yet verified | Phase 2 on security-critical files; Scenario B is the primary scenario. For npm, check who published the version (`npm view \u003Cpackage>@\u003Cversion> _npmUser`) against earlier releases and diff the package contents against the release before the silence. If `dormant_release.removed` is `true`, the version was unpublished, so `npm view \u003Cpackage>@\u003Cversion>` fails; compare against the release before the silence and plan to stay on it |\n| **WITHDRAWN** | scan's `reason` starts with `All releases yanked on` | Not a takeover signal: the registry offers no version to normal resolution, so a fresh install or lockfile update can break. Phase 2 is optional; the verdict is about what stops building, plus any advisories |\n| **CRITICAL-EXPOSURE** | Vulnerable AND `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND (`import_file_count > 0` OR `scope = \"runtime\"`) | Full Phase 2 on all security-critical files |\n| **LATENT-RISK** | `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND (`import_file_count > 0` OR `scope = \"runtime\"`) AND not vulnerable | Phase 2 on security-critical files only |\n| **SUPPLY-CHAIN-ONLY** | `is_unused = true` AND the Phase 0 search found nothing, OR `scope = \"tool\"` AND no production file imports it | Skip Phase 2 call-site reading -- but still assess install-time and build-time execution in Scenario B |\n| **MONITORING** | `lifecycle` is Active, Legacy-Safe, or Review Needed (lack of data), but vulnerable | Phase 2 optional -- assess known CVE impact |\n| **INCOMPLETE** | `malicious_check = \"unknown\"`, or the ecosystem is not covered by the malicious check, or `lifecycle = Review Needed` because data is missing (`Insufficient data for assessment`, `Commit data missing`), or the pinned version's advisories could not be checked, and nothing above matched | Do not call the package healthy. Report what could not be checked and re-run the failed lookup before deciding |\n| **LOW-RISK** | Any combination not matching above | Produce minimal assessment noting the dependency is healthy or benign |\n\nWhen coupling was not measured (see Mode C), `is_unused` is `false` and `import_file_count` is 0 for every entry. Do not read those zeros as \"no data flow\"; treat the dependency as Mode B (coupling unavailable, assume > 0).\n\nLifecycle values produced by diet: `Active`, `Stalled`, `Legacy-Safe`, `EOL-Confirmed`, `EOL-Effective`, `EOL-Scheduled`, `Archived`, `Review Needed`. Two of them need care:\n\n- `Archived` is diet's own label for \"the source repository is archived\"; it overrides the lifecycle label. `uzomuzo scan` reports the same package as `Stalled` unless the registry also signals end of life ([ADR-0020](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0020-archived-registry-liveness.md)). Check scan's `stable_version` and its release date: packages that moved into a monorepo keep publishing while the old repository is archived. Archived alone does not mean the code is known bad.\n- `Review Needed` covers three different situations, told apart by scan's `reason`: too little data to classify (`Insufficient data for assessment`, `Commit data missing`); every release yanked ([ADR-0022](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0022-all-releases-yanked-is-not-eol.md)); or, on npm, a release burst across release lines after a long silence -- how past takeovers of quiet npm packages have looked ([ADR-0026](https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fdocs\u002Fadr\u002F0026-dormant-release-burst.md)).\n\n### Step 3: Scope Phase 2 targets\n\nFilter `symbols[]` and `import_files[]` to identify security-relevant subsets.\n\n**Security-relevant symbol patterns** (language-neutral, case-insensitive substring match):\n\n```\nAuth, Cred, Secret, Token, Key, Encrypt, Decrypt, Sign, Verify, Cert,\nTLS, SSL, Hash, Password, Session, Cookie, Policy, ACL, Permission,\nRole, Assume, Identity, Provider, IAM, STS,\nConnect, Dial, Transport, Listen, Serve, Client, Request, Response,\nSQL, Query, Exec, Database, Store, Cache, Write, Put, Delete,\nMarshal, Unmarshal, Decode, Encode, Parse, Deserialize\n```\n\n**Security-critical file path patterns** (substring match on `import_files[]`):\n\n```\nauth\u002F, credential\u002F, secret\u002F, crypto\u002F, security\u002F, acl\u002F, policy\u002F,\nlogical\u002F, secrets\u002F, iam\u002F, rotation\u002F, roles\u002F, permission\u002F,\ntransport\u002F, client\u002F, server\u002F, handler\u002F, middleware\u002F, gateway\u002F,\nstorage\u002F, database\u002F, physical\u002F, cache\u002F, session\u002F, login\u002F,\napi\u002F, endpoint\u002F, route\u002F, grpc\u002F, http\u002F\n```\n\nThese patterns are **heuristics for prioritization, not hard filters**. A file that matches no pattern is not \"safe\" — it is merely lower priority. Any file in `import_files[]` could contain security-relevant code regardless of its path name.\n\nRecord:\n- **Priority 1 (high-confidence security)**: files matching path patterns above\n- **Priority 2 (remaining)**: all other files in `import_files[]`\n\nWhen the security-relevant subset exceeds 50% of `api_breadth`, the dependency is likely an infrastructure\u002Fsecurity SDK where nearly the entire API is security-relevant. In that case, treat all symbols as in-scope (do not filter by name) and rely solely on file prioritization for Phase 2 ordering.\n\n### Step 4: Note coupling accuracy caveats\n\nIf any of these flags are set, note them -- they affect Phase 2 accuracy:\n\n| Flag | Implication |\n|------|------------|\n| `has_dot_import` | Symbols used without package prefix -- `symbols[]` may be **undercounted**. Actual API surface is likely broader. |\n| `has_wildcard_import` | Same: `from x import *` \u002F `import static x.*` means undercounted symbols. |\n| `has_blank_import` | Import for its side effect (Go `import _ \"pkg\"`, JS `import 'pkg'`), usually to register something -- a SQL driver, codec, or handler -- that then receives data through other APIs (a registered SQL driver sees every query and the database credentials). Trace where the registered component is used instead of assuming data flow is limited. The flag can also appear next to ordinary calls. |\n\nIf `scope` is `\"tool\"`: diet sets this when the module appears in a Go `tool` directive. That proves tooling use, not the absence of runtime use: another package of the same module can still be imported by production code (e.g. `golang.org\u002Fx\u002Ftools\u002Fcmd\u002Fstringer` as a tool and `golang.org\u002Fx\u002Ftools\u002Fgo\u002Fpackages` in `main`). If `import_files` lists production files, assess them as runtime imports. Otherwise supply chain risk applies at build time (a compromised tool could inject code into the build), but there is no runtime data flow.\n\nIf `scope` is `\"runtime\"`: The dependency is loaded without a static import -- a JDBC driver named in a connection URL, a logging backend found on the classpath, a Spring auto-configuration. `import_files` will be empty, but the code runs in production and often sees sensitive data (a JDBC driver sees every query and the database password). For Phase 2, find where it is wired: configuration files (`application.yml`, `*.properties`, `META-INF\u002Fservices\u002F*`, `spring.factories`), connection strings, and `Class.forName` calls.\n\n## Phase 2: Targeted code inspection\n\n**Skip this phase entirely if:**\n- Threat profile is SUPPLY-CHAIN-ONLY. Skip Steps 1-2 and the call-site bullets of Step 3, but still write the install-time bullet of Scenario B (Step 3) and Step 4\n- No source code is available (Mode B input)\n- `import_file_count` is 0 and `scope` is not `\"runtime\"` (for `\"runtime\"`, read the wiring found in Phase 1 Step 4 instead of `import_files`)\n\nFor each skip case, add a \"Limitations\" note to the verdict explaining what could not be assessed and why.\n\n### Scoping strategy\n\nRead files in priority order (Priority 1 first, then Priority 2). **Stop when you have enough evidence to construct credible attack scenarios for both Scenario A and Scenario B** (see Step 3 below). You have enough evidence when you can answer all four questions in Step 2 (Data IN, Data OUT, Security boundary, Failure mode) for at least the most security-critical call sites.\n\n**Reading order:**\n1. Priority 1 files (from Phase 1 Step 3) — read these first\n2. Priority 2 files — read in order until you have enough evidence, or all files are read\n3. For any files not read, produce a statistical summary: \"N files in auth paths, M in infrastructure, K in tests\"\n\n**Stopping criteria — you have enough evidence when:**\n- You can name the concrete data types flowing IN and OUT of the dependency\n- You can describe at least one realistic attack scenario grounded in observed data flows\n- Reading more files would add volume but not change the risk verdict\n\nIf you stop before reading all files, record which files were read and which were not in the verdict's \"Limitations\" section. This is not a failure — it is an explicit scope decision.\n\n### Step 1: Classify import sites by security impact\n\nFor each file read, classify it:\n\n- **Security-critical**: handles auth, credentials, secrets, crypto, storage of sensitive data, network transport, policy\u002FACL decisions\n- **Infrastructure**: config loading, logging, metrics, CLI argument parsing, build tooling\n- **Peripheral**: tests, documentation, examples, code generation, benchmarks\n\n### Step 2: Trace data flows at security-critical sites\n\nFor each security-critical import location, determine:\n\n1. **Data IN**: What data is passed TO this dependency? (credentials, secrets, user input, config values, plaintext?)\n2. **Data OUT**: What data comes FROM this dependency? (connections, sessions, decoded secrets, query results?)\n3. **Security boundary**: Is there encryption, validation, or auth gating around the call site?\n4. **Failure mode**: If this dependency silently returned wrong data, what would break? Would anyone notice?\n\nQuote specific file paths and line numbers. Do not speculate -- if you cannot determine something from the code, say \"undetermined from static analysis.\"\n\n### Step 3: Construct attack scenarios\n\nBuild scenarios from the actual data flows observed in Step 2, not from generic templates.\n\n**Scenario A -- Unpatched vulnerability**:\n- Does the dependency have known CVEs? (check `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` from diet)\n- If known CVEs exist: What specific data flows are exposed by them?\n- If no known CVEs: Given the data flows observed, what category of vulnerability (RCE, data leak, auth bypass, DoS) would have the highest impact if discovered?\n\n**Scenario B -- Supply chain compromise** (a malicious version is published, typically through a stolen maintainer account):\n- **Install-time and build-time execution**: Does the package get to run code before any of your call sites do? npm `preinstall`\u002F`install`\u002F`postinstall` scripts, Python source distributions that run `setup.py`, Maven\u002FGradle plugins, Go `tool` directives and `go generate`. Some recent npm compromises, such as the self-spreading Shai-Hulud worm in 2025, did all their work in an install script, stealing npm tokens, GitHub tokens, and cloud keys from developer machines and CI runners. This applies even when `import_file_count = 0`. Name the environments that install this package and what secrets they hold.\n- If this package **exfiltrated data via IN flows**: What could an attacker steal? (Based on actual Data IN from Step 2)\n- If this package **altered OUT flows**: What would break? What would be silent?\n- Is the attack **detectable?** A crash is detectable. Subtly wrong auth decisions or silently leaked credentials are not.\n- **Takeover likelihood**: An unmaintained package with a single maintainer is easier to take over than an active one, and a takeover after a long silence is what scan's dormant-release marker watches for. Use `lifecycle`, `overall_score`, and `dormant_release` here; do not invent a probability.\n\n### Step 4: Identify mitigating factors\n\nThese factors affect **risk severity** (how dangerous is keeping this dependency), not removal feasibility (how hard is it to remove). Removal planning belongs in `\u002Fdiet-evaluate-removal`.\n\nFor each applicable factor, cite the evidence from the code:\n\n- Upstream encryption before data reaches this package\n- Downstream validation after data leaves this package\n- Package pinned by lockfile integrity (go.sum, package-lock.json, pip --require-hashes). This stops a swapped artifact for the same version; it does not stop a new malicious version from arriving through a routine lockfile update\n- Install scripts disabled where it is installed (`npm ci --ignore-scripts`, pnpm 10 or later, which does not run dependency build scripts unless allowed -- check the pnpm version and `onlyBuiltDependencies` before counting this, `pip install --only-binary :all:`). Removes the install-time part of Scenario B\n- Dependency updates held back by a minimum release age or manual review (e.g., Renovate `minimumReleaseAge`, pnpm `minimumReleaseAge`). Most malicious versions are named in an advisory within days of publication, though not all are removed from the registry\n- Provenance on the pinned version. npm provenance records which repository and workflow built the package; PyPI's default publish attestations record which trusted publisher uploaded it, which is not the same as where it was built. Read the attestation actually present. Either kind it does not prove the code is benign, and it does not help when the attacker can run the release workflow itself (e.g., with a stolen GitHub token). A version that lacks provenance when earlier ones had it is a warning sign\n- Package is small enough to audit -- judged from the package's own code and dependencies after reading them, not from `api_breadth`, which only counts the symbols your code uses (one call into a large SDK gives `api_breadth` 1)\n- Usage is behind a build tag \u002F feature flag that limits exposure\n- Test-only usage (files in `*_test.go`, `test\u002F`, `__tests__\u002F`, `tests\u002F`)\n- `scope: \"tool\"` with no production file importing it -- build-time only, no runtime exposure\n\n## Phase 3: Risk verdict\n\n### Single dependency verdict\n\n```\n### {package_name} -- Risk: {CRITICAL|HIGH|MEDIUM|LOW}\n\n#### Diet Facts (from automated analysis)\n\n| Metric | Value |\n|--------|-------|\n| PURL | `{purl}` ({name} {version}, {ecosystem}) |\n| Rank | #{rank} of {summary.total_direct} direct deps |\n| Lifecycle | {lifecycle} ([registry link]) |\n| Known CVEs (latest release) | {vulnerability_count} ({direct_advisory_count} direct, {transitive_advisory_count} via its dependencies) {(max CVSS: {max_cvss_score}) if present, else \"(CVSS unavailable)\"} |\n| Known CVEs (pinned version) | {count and IDs from OSV, or \"not checked\"} |\n| Malicious check | {clean \u002F flagged: {advisory_id} ({scope}) \u002F unknown -- lookup failed} |\n| Dormant release | {none \u002F {silent_days} days of silence, published {published_at}} *(npm only; omit row otherwise)* |\n| Priority \u002F Overall | {priority_score} \u002F {overall_score} |\n| Difficulty | {difficulty} (coupling_effort: {coupling_effort}) |\n| Coupling | {import_file_count} files, {call_site_count} calls, {api_breadth} APIs |\n| Graph impact | {graph_impact} (exclusive: {exclusive_transitive}, total: {total_transitive}) |\n| Health risk | {health_risk} |\n| Stays as indirect | {stays_as_indirect} {-- via {indirect_via} if true} |\n| Import caveats | {list any true flags: has_dot_import, has_wildcard_import, has_blank_import} *(omit row if all false)* |\n| Scope | {scope} *(omit row if absent)* |\n\n#### New Findings (from this assessment)\n\n**Threat profile**: {SUSPECT-RELEASE | WITHDRAWN | INCOMPLETE | CRITICAL-EXPOSURE | LATENT-RISK | SUPPLY-CHAIN-ONLY | MONITORING | LOW-RISK}\n\n**Files inspected**: {N} of {import_file_count} files read ({M} Priority 1, {K} Priority 2)\n\n**Data flow summary**:\n\n| Direction | Data type | Security relevance |\n|-----------|-----------|-------------------|\n| IN | {concrete data observed} | {impact if compromised} |\n| OUT | {concrete data observed} | {impact if tampered} |\n\n**Scenario A (Unpatched vulnerability)**: {concrete scenario based on observed data flows}\n\n**Scenario B (Supply chain compromise)**: {concrete scenario -- what could be stolen or altered}\n\n**Mitigating factors**:\n- {factor with code evidence}\n\n**Limitations**: {what could not be assessed -- e.g., \"51+ files; sampled 10 security-critical files only\"}\n\n**Verdict**: {1-2 sentence risk summary}\n**Recommended posture**: {one of the following}\n```\n\n#### Posture definitions\n\n| Posture | Meaning |\n|---------|---------|\n| **Remove urgently** | Malicious version, active exploitation risk, or critical data exposure. Run `\u002Fdiet-remove` now (for a malicious version: move off it first, then rotate the secrets listed in the verdict). |\n| **Plan removal** | Significant risk that grows over time. Run `\u002Fdiet-evaluate-removal` to plan. |\n| **Monitor** | Low current risk but degrading health. Re-assess quarterly. |\n| **Accept with documentation** | Risk is understood and mitigated. Document the decision and rationale. |\n\n### Multiple dependencies summary table (top N mode)\n\nAfter individual verdicts, produce a summary:\n\n| Package | Lifecycle | Diet Priority | Difficulty | Threat Profile | Risk | CVEs | Posture |\n|---------|-----------|--------------|------------|---------------|------|------|---------|\n\n## Primary Source Links\n\nThe verdict MUST include verifiable primary source links. Never claim \"EOL\", \"Archived\", or \"has CVEs\" without evidence.\n\n### Required links\n\n| Claim | Required link |\n|-------|--------------|\n| Lifecycle status | Package registry page (see PURL-to-URL table below) |\n| Known CVEs | NVD (`nvd.nist.gov\u002Fvuln\u002Fdetail\u002F\u003CCVE>`), GitHub Advisory (`github.com\u002Fadvisories\u002F\u003CGHSA>`), or OSV (`osv.dev\u002Fvulnerability\u002F\u003CID>`) |\n| Malicious version | The advisory scan names (`malicious.reference`), or `osv.dev\u002Fvulnerability\u002F\u003CMAL-ID>` |\n| Dormant release | The npm version page (`https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F\u003Cname>\u002Fv\u002F\u003Cversion>`) and the previous release's date |\n| Scorecard | `https:\u002F\u002Fscorecard.dev\u002Fviewer\u002F?uri=github.com\u002F\u003Corg>\u002F\u003Crepo>` |\n| Repository archived | GitHub repo URL (shows archived banner) |\n| Last commit date | `https:\u002F\u002Fgithub.com\u002F\u003Corg>\u002F\u003Crepo>\u002Fcommits\u002F\u003Cbranch>` |\n\n### PURL-to-registry URL\n\n| Ecosystem | URL pattern |\n|-----------|-------------|\n| `pkg:npm` | `https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F\u003Cname>` |\n| `pkg:golang` | `https:\u002F\u002Fpkg.go.dev\u002F\u003Cnamespace\u002Fname>` |\n| `pkg:pypi` | `https:\u002F\u002Fpypi.org\u002Fproject\u002F\u003Cname>` |\n| `pkg:maven` | `https:\u002F\u002Fcentral.sonatype.com\u002Fartifact\u002F\u003Cnamespace>\u002F\u003Cname>` |\n| `pkg:cargo` | `https:\u002F\u002Fcrates.io\u002Fcrates\u002F\u003Cname>` |\n| `pkg:nuget` | `https:\u002F\u002Fwww.nuget.org\u002Fpackages\u002F\u003Cname>` |\n| `pkg:githubactions` | `https:\u002F\u002Fgithub.com\u002F\u003Cnamespace>\u002F\u003Cname>` |\n\n## Language-specific reference\n\nThe core analysis (Phases 0-3) is language-neutral. Use this table for language-specific details:\n\n| Aspect | Go | Python | JavaScript\u002FTypeScript | Java |\n|--------|-----|--------|----------------------|------|\n| Build constraints | `\u002F\u002Fgo:build` tags | N\u002FA | N\u002FA | Maven profiles |\n| Side-effect imports | `import _ \"pkg\"` | `try\u002Fexcept ImportError` | `import 'pkg'` (no binding), `require('pkg')` | Static initializer blocks |\n| Wildcard imports | `import . \"pkg\"` | `from x import *` | N\u002FA (namespace `import * as ns` -- symbols tracked via `ns.` prefix) | `import static x.*` |\n| Lockfile integrity | `go.sum` hash verification | `pip --require-hashes` | `package-lock.json` integrity field | No standard lockfile: pinned versions plus checksum verification you configure explicitly (`maven-enforcer-plugin` alone does not verify artifact hashes) |\n| Vulnerability scanner | `govulncheck` | `pip-audit`, `safety` | `npm audit` | `dependency-check`, OWASP |\n| Test file patterns | `*_test.go` | `test_*.py`, `tests\u002F` | `*.test.js`, `__tests__\u002F` | `*Test.java`, `src\u002Ftest\u002F` |\n\n## Important rules\n\n- **Start from diet's output.** Do not re-discover what diet already computed. The `symbols[]` and `import_files[]` fields are your starting points for Phase 2.\n- **Fill diet's gaps from scan.** Malicious-version and dormant-release signals, and the advisories on the pinned version, are not in diet JSON. A verdict that skipped them must say so.\n- **Install time counts.** \"Zero imports\" removes call-site data flows, not the package's chance to run code on every machine that installs it.\n- **Read in priority order, stop when you have enough.** Phase 1 Step 3 gives you the reading order. Stop when you can construct credible attack scenarios — not when you hit an arbitrary file count.\n- **Be precise.** Quote specific file paths and line numbers. \"The auth module uses this\" is too vague.\n- **Do not speculate.** If you cannot determine something from the code, say \"undetermined from static analysis.\"\n- **Do not overstate risk.** If data is encrypted before reaching the package, the supply chain scenario changes. Say so.\n- **Focus on silent attacks.** Crashes are detectable. Subtle behavior changes (wrong auth decisions, leaked credentials, altered responses) are the real threat.\n- **Do not assess replacement options.** That is `\u002Fdiet-evaluate-removal`'s job. This skill assesses the risk of the status quo.\n- **Always include primary source links.** Every lifecycle claim, CVE reference, and scorecard score must have a clickable URL.\n- **State limitations explicitly.** If you sampled 10 of 51 files, or skipped Phase 2 because no source was available, say so in the verdict.\n- **`stays_as_indirect` matters.** If the dependency remains as an indirect dep after removal, note that removing direct usage reduces but does not eliminate the risk.\n",{"name":5,"description":7,"argument-hint":38},"\u003CPURL or module path, or 'top N'>","main","fd5444486365ae1d00d222e0d1779c1023d12f72","claude-skills\u002Fdiet-assess-risk",7,"https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss","https:\u002F\u002Fgithub.com\u002Ffuture-architect","https:\u002F\u002Fwww.future.co.jp\u002F","Future's official open source repositories","2026-11-15 01:28:54",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add future-architect\u002Fuzomuzo-oss --skill diet-assess-risk",{"tool":54,"command":55},"bunx","bunx skills add future-architect\u002Fuzomuzo-oss --skill diet-assess-risk",{"tool":57,"command":58},"pnpm","pnpm dlx skills add future-architect\u002Fuzomuzo-oss --skill diet-assess-risk","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fdiet-assess-risk\u002FSKILL.md",true,[62,68,72,78,82],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"assets\u002Fmodule-help.csv","ASSET","资产文件",2890,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Fbmad-bmb-setup\u002Fassets\u002Fmodule-help.csv",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Fmodule.yaml",886,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Fbmad-bmb-setup\u002Fassets\u002Fmodule.yaml",{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"scripts\u002Fcleanup-legacy.py","SCRIPT","脚本",7743,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Fbmad-bmb-setup\u002Fscripts\u002Fcleanup-legacy.py",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"scripts\u002Fmerge-config.py",14139,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Fbmad-bmb-setup\u002Fscripts\u002Fmerge-config.py",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"scripts\u002Fmerge-help-csv.py",6607,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002F.kiro\u002Fskills\u002Fbmad-bmb-setup\u002Fscripts\u002Fmerge-help-csv.py",[87,120,134,150,178,198],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":33},"01M6DA7MGD29HB8B7PD74AP302","scan-before-add","Use when selecting, comparing, or recommending third-party libraries, and before adding a new dependency (go.mod, package.json, pyproject.toml, requirements.txt, Cargo.toml, pom.xml, *.csproj, Gemfile, composer.json). Applies both when you choose the candidates and when the user names a package. Runs uzomuzo scan on the candidates and leaves a record of what was checked and who decided.","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fscan-before-add\u002FSKILL.md",[],[94,95,96,97,98,99,100,101,102,103,104,26,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"scan","scan before add","add","go","libraries","package","xml","json","choose","user","use","record","requirements","toml","third-party","cargo","composer","with","you","pom","gemfile","pyproject.toml","csproj","candidate","when","new",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":33},"01M6DA7H2JJBKD8535AN2XRDWQ","diet-remove","Remove a dependency identified by uzomuzo diet — analysis + issue (default) or direct PR","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fdiet-remove\u002FSKILL.md",[],[127,128,22,129,25,130,131,26,132,133,28,29,31],"remove","diet remove","pr","direct","repo","issue","default",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":33},"01M6DA7DV99JKQ623GX67913X7","diet-evaluate-removal","Data-driven deep evaluation of whether a dependency is worth removing","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fdiet-evaluate-removal\u002FSKILL.md",[],[141,22,142,143,144,145,26,27,146,147,148,149],"diet evaluate removal","evaluate","github","Evaluation","data","driven","name","errors","data-driven",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":33},"01M6DA77R43KS673EP8B9RMNY5","review-until-clean","1-shot to merge-ready (local-only) — Phase A (5-agent local review iteration) → Phase B (push + self-driven Copilot re-review iteration) → Phase C (reply+resolve all threads). One invocation drives a PR from local agent review through Copilot review convergence to merge-ready state. Runs from your own machine; there is no CI auto-fix.","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview-until-clean\u002FSKILL.md",[],[157,158,159,160,161,129,162,163,164,165,166,167,168,169,170,171,172,173,146,174,175,176,177],"review","clean","review until clean","merge","copilot","state","push","ci","copilot review","fix","auto","only","ready","reply","self","local","iteration","machine","re","auto-fix","phase",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":33},"01M6DA74ZDFXWN62XKMDQ94689","review-diff","Pre-push diff review by the local GitHub Copilot CLI (gpt-5.6-sol, a separate-vendor LLM). Usage: \u002Freview-diff [BASE_REF | --cached] (default base=origin\u002Fmain)","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview-diff\u002FSKILL.md",[],[157,185,186,187,143,188,161,189,163,190,191,133,39,192,172,193,194,195,196,197],"diff","review diff","cli","github copilot","copilot cli","gpt","vendor","base","origin","diff review","github copilot cli","usage","sol",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":33},"01M6DA72JCYB5EE77NWGWJ4JRY","plan-review","Have the local GitHub Copilot CLI (gpt-5.6-sol, a separate-vendor LLM) critique the latest plan-mode plan file before ExitPlanMode — a sanity check. Usage: \u002Fplan-review [\u003Cplan-path>]","https:\u002F\u002Fgithub.com\u002Ffuture-architect\u002Fuzomuzo-oss\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplan-review\u002FSKILL.md",[],[157,205,206,187,143,188,161,189,190,207,208,209,191,172,210,195,196,211,212,197,213],"plan","plan review","file","critique","check","sanity","latest","mode","plan-mode"]