$npx -y skills add rstackjs/agent-skills --skill rsdoctor-analysisUse when analyzing Rspack/Webpack bundles from local rsdoctor-data.json and producing evidence-based optimization recommendations.
| 1 | # Rsdoctor Analysis Assistant Skill |
| 2 | |
| 3 | Use the globally installed `rsdoctor-agent` CLI from `@rsdoctor/agent-cli` only after a real `rsdoctor-data.json` path exists. Keep analysis read-only unless the user explicitly asks for install/config setup. |
| 4 | |
| 5 | Response order (required): High-Priority Issues -> Proposed Solutions -> Optional Reference-Chain Follow-up Choices -> Next Deep-Dive Issue Categories (Not commands). |
| 6 | |
| 7 | ## Core Workflow |
| 8 | |
| 9 | 1. Reuse current-session results and valid `.rsdoctor-analysis-cache.json` entries before doing new work. |
| 10 | 2. Locate `rsdoctor-data.json` fast: user-provided path, then `dist/rsdoctor-data.json`, `output/rsdoctor-data.json`, `static/rsdoctor-data.json`, `.rsdoctor/rsdoctor-data.json`, then one bounded `rg --files` search excluding `node_modules` and `.git`. Treat `manifest.json` only as an index. |
| 11 | 3. If data exists, skip all plugin version/config/build generation logic. Update cache when useful. |
| 12 | 4. If data is missing, stop analysis: do not run `rsdoctor-agent` analysis commands, do not run the Analysis Gate, and either ask for the data path or run the Generation Gate below only when setup/generation is required. |
| 13 | 5. After a real data file exists, run Analysis Gate at most once before the first `rsdoctor-agent` data-fetch command: verify global `@rsdoctor/agent-cli` with `npm view @rsdoctor/agent-cli version` and `rsdoctor-agent --version`; install latest only if missing/outdated, a version-related error occurs, or the user asks to refresh. |
| 14 | 6. Fetch only the Default Evidence Set first; run independent fetches in parallel when possible. |
| 15 | 7. Run the ROI Triage Gate below before selecting deep-dive commands or recommendations. Use it to rank issue categories by measured impact, then synthesize findings in the required response order. |
| 16 | |
| 17 | Performance rules: parallelize independent checks, cache only derived facts (`dataFile`, `dataFileMtime`, `pluginName`, `pluginVersion`, dependency/config/plugin modification times), and invalidate cache when paths disappear, modification times change, the user asks to refresh, or cached values fail. Speculative plugin checks must not trigger generation; use them only after confirming the data file is missing. |
| 18 | |
| 19 | ## ROI Triage Gate |
| 20 | |
| 21 | Before recommending fixes, classify the current build into broad cost buckets and choose the highest-ROI lever from evidence, not intuition. This gate is generic for Rspack/Webpack projects; do not use framework-specific runtime layers unless the user's project exposes them in the data. |
| 22 | |
| 23 | | Cost bucket | Evidence source | First lever | |
| 24 | | -------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | |
| 25 | | Assets/media | `assetsTop`, `assets media`, `chunkGraph.assets` | Compress, convert, deduplicate, subset, or lazy-load large assets | |
| 26 | | Large packages/modules | `packagesTop`, module/package size fields | Replace heavy packages, use deep imports, split non-critical code, or review direct dependency choices | |
| 27 | | Duplicate/cross-chunk cost | E1001/E1002, `packages duplicates`, cross-chunk package summaries | Deduplicate versions, tune package resolution, or adjust `splitChunks`/cache groups | |
| 28 | | Tree-shaking waste | `retainedModulesTop`, retained CJS/barrel/side-effects modules | Fix CJS/barrel imports, sideEffects declarations, or package entrypoints | |
| 29 | | Build-time cost | `buildCost`, loaders/plugins/directories cost data | Optimize loaders/plugins, cache, watcher, or source-map/dev settings; prioritize only when the user asks about build performance | |
| 30 | |
| 31 | Decision rules: |
| 32 | |
| 33 | - Report the measured breakdown first when it changes recommendation priority. |
| 34 | - Start with the largest bucket that maps to a practical fix; a smaller issue should not outrank a larger one unless the larger one is expected or intentionally unavoidable. |
| 35 | - Treat issuer/reference-chain tracing as second-pass work. Run it only when a high-impact candidate needs ownership evidence, or when the user asks "why" / "who imported this". |
| 36 | - Do not present aggregate rule output as sufficient evidence for a fix that requires a concrete file, package, chunk, size, or dependency path. |
| 37 | - If the largest bucket is structural or intentionally required, say that it is a wall and name the external ch |