[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPYSDT5TCXTJDGPFQ20MS8":3,"skill-same:01M6JPYSDT5TCXTJDGPFQ20MS8":81},{"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":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6JPYSDT5TCXTJDGPFQ20MS8","dependency-management",null,"Evaluate, audit, and upgrade dependencies — whether a library is needed at all or an own module beats it, adoption vetting, CVE audits, major upgrades, conflicts. Run before naming any new library in a plan, ADR or install.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Fdependency-management\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],"dependency","management","dependency management","at","packages","lock","which","upgrade dependencies","upgrade","do","conflicts","install","write","adr","plan","vulnerability","cve","audit","library","run","2026-11-10 10:12:30",false,"---\nname: dependency-management\ndescription: \"Evaluate, audit, and upgrade dependencies — whether a library is needed at all or an own module beats it, adoption vetting, CVE audits, major upgrades, conflicts. Run before naming any new library in a plan, ADR or install.\"\nwhen_to_use: \"Triggers: should I use this library, which packages do we need, write our own instead, we use a small part of it, npm audit, dependency vulnerability, upgrade dependencies, outdated packages, lock file, breaking changes in upgrade, is this library maintained, dependency conflict, slopsquatting, does this package exist, AI suggested this library.\"\n---\n\n# Dependency Management\n\nHelp make disciplined decisions about project dependencies. Every dependency is a trade-off: functionality gained vs. maintenance burden, security surface, and coupling accepted.\n\n## Core Rule\n\n**Every dependency should earn its place.** Before adding a dependency, ask: \"Is this worth the ongoing cost of maintaining, updating, and trusting someone else's code in my project?\"\n\n## Workflow: Evaluating a New Dependency\n\n### Step 1: Do You Need It?\n\nRun this for every library you are about to name: one the user asks about, and one you are about to put in a plan, an ADR, or an install command. A candidate list someone hands you (an ADR, a plan, a teammate's pick) is the input to this step, not its result. Compare each candidate with **an own module**, not only with other libraries. Checking that a package exists and is maintained (Steps 2–3) does not answer whether you need it.\n\nFor each candidate, fill one row:\n\n| Field | What to write |\n|---|---|\n| **Used** | The functions or features we would call, against what it ships |\n| **Pulls in** | Transitive packages, native builds, and maintainer groups (count groups, not packages) |\n| **Already covered** | By the standard library, the platform, or a dependency we already have |\n| **Own module** | What it would be, rough line count, and how it is tested |\n| **Grows into** | Planned features (roadmap, PRD, open issues) that would use more of it. An own module that would have to regrow the library is not small |\n| **Gives beyond code** | Portability, an abstraction, spec conformance, a security track record. Check the claim: one vendor's SDK is not an abstraction over many vendors |\n\nThen give each row a verdict:\n\n- **Own module, or nothing:** we'd use a sliver of it, the own module is small, and nothing planned grows it. Same when the standard library or a current dependency already covers it.\n- **Adopt:** we'd use a substantial part of it, or correctness is specialized and costly to get right (cryptographic primitives, timezone math, database drivers, a parser for hostile input). Continue to Steps 2–4.\n- **Ask the user:** the rows don't decide it. That covers a mid-size own module, security-critical code, or a call that hinges on the roadmap or on how much code the team is willing to maintain, which you can't see. Present both options with your recommendation and what each costs, and get the user's choice before installing the library or writing the module. This is not a gate on the rest of the answer: deliver the table and the other verdicts in the same response, with the question beside them.\n\n**Security-critical code:** never write your own cryptographic primitives. Thin protocol code over a crypto library you already ship can be owned, for example TOTP, a request signer, or a WebAuthn check that only accepts `none` attestation. Own it only when the user chooses to (ask), with a test per spec step, and with differential tests against the library kept as a dev-only dependency.\n\n**Exit condition:** the table with a verdict per row, written in your reply, in the same response. Steps 2–4 apply only to rows marked Adopt.\n\n- **The table goes in the message, not in a question.** A choice dialog shows only its own text, so a question whose option labels carry the comparison hides the table. Write the table and your recommendation first; the question that follows only names the options.\n- **A registry page fills no row.** The package existing, its licence and its last release are Steps 2–3. A verdict reached from them has skipped this step.\n- **Size the own module with the hard part in it.** If our version would have to rebuild what makes the library worth having (its typing, its protocol or OAuth flow, its parser), count that part, or the own module looks smaller than it is.\n\n### Step 2: Verify the Package Exists (anti-slopsquatting)\n\nBefore evaluating anything else, confirm the package is real and is the one you think it is. AI assistants hallucinate plausible package names at a measurable rate (~20% of AI package recommendations reference packages that don't exist), and attackers register those exact names to deliver malware — **slopsquatting**. A hallucinated name passes every traditional typo filter because it collides with nothing.\n\n- **Confirm the exact name exists in the registry** (`npm view \u003Cpkg>`, the PyPI project page) and that the registry entry's repository link points to the project you expect.\n- **Check adoption history over time** — steady downloads across months, not a package registered last week. A brand-new package with a burst of installs matching an AI-suggested name is the attack signature.\n- **Check typo-distance from a popular package.** Hallucinations often shadow a real name (e.g. `unused-imports` vs the real `eslint-plugin-unused-imports`). If a more popular near-neighbor exists, you probably want the neighbor.\n- **Treat any AI-suggested package name as unverified input.** Verify it the same way you'd verify a URL from an untrusted source — before it reaches `npm install`.\n\n### Step 3: Evaluate the Library\n\nFor any library under consideration, assess these dimensions:\n\n**Maintenance health:**\n- Last commit date (stale > 1 year is a yellow flag)\n- Open issues and PR response time\n- Number of maintainers (bus factor — 1 maintainer is risky)\n- Release frequency and changelog quality\n\n**Adoption signals:**\n- Weekly downloads \u002F GitHub stars (not definitive, but signals community trust)\n- Used by known projects (check dependents)\n- Ecosystem maturity (plugins, integrations, documentation)\n\n**Technical fit:**\n- TypeScript support (if applicable)\n- Bundle size impact — check on bundlephobia.com or similar\n- API quality — is it intuitive, well-documented, consistent?\n- Compatibility with your runtime, framework version, and other dependencies\n\n**Security and legal:**\n- License compatibility with your project (MIT, Apache-2.0 are permissive; GPL is viral)\n- Known vulnerabilities (check npm audit advisory, Snyk, or GitHub advisories)\n- Does it have excessive transitive dependencies?\n\n**Alternatives comparison:**\n- Identify 2-3 alternatives, including Step 1's own module, and compare on the dimensions above\n- A slightly less popular library that's better maintained may be the better choice\n\nSee [references\u002Fevaluation-checklist.md](references\u002Fevaluation-checklist.md) for the structured assessment template.\n\n### Step 4: Present the Recommendation\n\nFor the user, summarize:\n- **Recommendation**: Use \u002F Own module \u002F Don't use \u002F Consider alternative. When Step 1 marked the row Ask the user, give your recommendation and ask; don't install until they answer\n- **Primary reason**: The most compelling argument\n- **Risks accepted**: What you're trading off\n- **Alternatives considered**: when you compare two or more libraries, a table with one column per candidate covering the Step 3 dimensions. Give numbers: bundle or install size, transitive dependency count, weekly downloads. Then show the same small task (one schema, one call) written in each library, so the ergonomics can be compared rather than asserted\n\n## Workflow: Auditing Existing Dependencies\n\n### Step 1: Run Vulnerability Scanners\n\n```bash\n# JavaScript\u002FTypeScript\nnpm audit\n# For more detail:\nnpx better-npm-audit audit\n\n# Python\npip audit\n# or\nsafety check\n\n# Go\ngovulncheck .\u002F...\n\n# Ruby\nbundle audit check --update\n```\n\n### Step 2: Triage Results\n\nNot all vulnerabilities require action. For each finding:\n\n1. **Is the vulnerable code path actually used in your project?** Many CVEs affect specific features you may not use.\n2. **What's the severity?** Start with Critical and High, which need immediate action. Many Moderate and Low findings sit in dev-only tooling or in code paths you never call. Those are acceptable risk: say so, record the decision with its reason, and recheck at the next upgrade instead of fixing everything. Fix the rest of the Moderate findings within a sprint.\n3. **Is a patched version available?** If yes, upgrade. If no, assess mitigation or replacement.\n4. **Is it a transitive dependency?** You may need to upgrade the parent package, or use overrides\u002Fresolutions.\n\n### Step 3: Find Unused Dependencies\n\nDead dependencies add attack surface and bloat for zero value.\n\n```bash\n# JavaScript — find unused packages\nnpx depcheck\n\n# Python — find unused imports (suggests unused packages)\npip install vulture\nvulture src\u002F --min-confidence 80\n```\n\nRemove unused dependencies. If unsure, comment it out, run tests, and deploy to staging.\n\nThen run Step 1's table on each remaining direct dependency to find the ones used for only a sliver. Fill **Grows into** before proposing a replacement: a library we use lightly today can be the right choice for a feature on the roadmap.\n\n### Step 4: Produce the Report\n\nSummarize: N vulnerabilities found (X critical, Y high), N unused packages, N used for a sliver (with own-module alternatives and sizes), N significantly outdated.\n\n## Workflow: Major Version Upgrades\n\n### Step 1: Read the Changelog\n\nRead the changelog and migration guide for the new major version. Identify:\n- **Breaking changes**: What will break in your code?\n- **Deprecations resolved**: What deprecated APIs were removed?\n- **New features**: Anything that simplifies your code?\n- **Peer dependency changes**: Does this force other upgrades?\n\n### Step 2: Plan the Upgrade\n\nFor low-risk upgrades (well-documented, small surface area):\n- Create a branch, bump the version, run tests, fix failures.\n\nFor high-risk upgrades (framework major version, ORM, auth library):\n- Before starting, make sure the tests cover the surface the upgrade touches. Write characterization tests where coverage is thin, because the suite is how you will know the upgrade broke nothing\n- Create a detailed task list of changes needed\n- Changes that work on both the old and the new version can merge to main as they land. The version bump itself runs in isolation (a branch through the full suite, then staging) before it merges\n- Consider running old and new versions in parallel temporarily (expand-contract)\n- Suggest using the `feature-planning` skill to break the upgrade into tasks\n\n### Step 3: Validate\n\n- [ ] All tests pass\n- [ ] No deprecation warnings from the upgraded package\n- [ ] No new vulnerabilities introduced by the upgrade\n- [ ] Lock file is committed and clean\n- [ ] Bundle size has not increased unexpectedly\n\n## Quick Reference: Lock File Hygiene\n\n- **Always commit lock files** (`package-lock.json`, `yarn.lock`, `poetry.lock`, `go.sum`)\n- **Never edit lock files manually** — let the package manager manage them\n- **Use `npm ci` (not `npm install`) in CI** — installs from lock file exactly\n- **Review lock file diffs in PRs** — large unexpected changes signal problems\n- **Regenerate periodically** if the lock file becomes stale or conflicted\n\n## Principles Applied\n\n- **YAGNI**: Don't add a library for a feature you *might* need. Add it when the need is real and proven.\n- **KISS**: Prefer libraries with small, focused APIs over Swiss-army-knife frameworks.\n- **DRY**: A well-chosen dependency eliminates duplication across projects — but a bad choice creates maintenance debt across projects.\n- **Functional Independence**: Prefer libraries that don't deeply couple to your application architecture. You should be able to swap them out.\n- **Boundaries**: Wrap third-party APIs with thin adapter layers — depend on your own abstractions, not on library specifics. This limits blast radius when a dependency changes or is replaced, and keeps your business logic free of third-party types. Only skip wrapping for pervasive infrastructure (e.g., your web framework, your ORM) where the cost of wrapping exceeds the cost of coupling.\n","# Dependency Management\n\nHelp make disciplined decisions about project dependencies. Every dependency is a trade-off: functionality gained vs. maintenance burden, security surface, and coupling accepted.\n\n## Core Rule\n\n**Every dependency should earn its place.** Before adding a dependency, ask: \"Is this worth the ongoing cost of maintaining, updating, and trusting someone else's code in my project?\"\n\n## Workflow: Evaluating a New Dependency\n\n### Step 1: Do You Need It?\n\nRun this for every library you are about to name: one the user asks about, and one you are about to put in a plan, an ADR, or an install command. A candidate list someone hands you (an ADR, a plan, a teammate's pick) is the input to this step, not its result. Compare each candidate with **an own module**, not only with other libraries. Checking that a package exists and is maintained (Steps 2–3) does not answer whether you need it.\n\nFor each candidate, fill one row:\n\n| Field | What to write |\n|---|---|\n| **Used** | The functions or features we would call, against what it ships |\n| **Pulls in** | Transitive packages, native builds, and maintainer groups (count groups, not packages) |\n| **Already covered** | By the standard library, the platform, or a dependency we already have |\n| **Own module** | What it would be, rough line count, and how it is tested |\n| **Grows into** | Planned features (roadmap, PRD, open issues) that would use more of it. An own module that would have to regrow the library is not small |\n| **Gives beyond code** | Portability, an abstraction, spec conformance, a security track record. Check the claim: one vendor's SDK is not an abstraction over many vendors |\n\nThen give each row a verdict:\n\n- **Own module, or nothing:** we'd use a sliver of it, the own module is small, and nothing planned grows it. Same when the standard library or a current dependency already covers it.\n- **Adopt:** we'd use a substantial part of it, or correctness is specialized and costly to get right (cryptographic primitives, timezone math, database drivers, a parser for hostile input). Continue to Steps 2–4.\n- **Ask the user:** the rows don't decide it. That covers a mid-size own module, security-critical code, or a call that hinges on the roadmap or on how much code the team is willing to maintain, which you can't see. Present both options with your recommendation and what each costs, and get the user's choice before installing the library or writing the module. This is not a gate on the rest of the answer: deliver the table and the other verdicts in the same response, with the question beside them.\n\n**Security-critical code:** never write your own cryptographic primitives. Thin protocol code over a crypto library you already ship can be owned, for example TOTP, a request signer, or a WebAuthn check that only accepts `none` attestation. Own it only when the user chooses to (ask), with a test per spec step, and with differential tests against the library kept as a dev-only dependency.\n\n**Exit condition:** the table with a verdict per row, written in your reply, in the same response. Steps 2–4 apply only to rows marked Adopt.\n\n- **The table goes in the message, not in a question.** A choice dialog shows only its own text, so a question whose option labels carry the comparison hides the table. Write the table and your recommendation first; the question that follows only names the options.\n- **A registry page fills no row.** The package existing, its licence and its last release are Steps 2–3. A verdict reached from them has skipped this step.\n- **Size the own module with the hard part in it.** If our version would have to rebuild what makes the library worth having (its typing, its protocol or OAuth flow, its parser), count that part, or the own module looks smaller than it is.\n\n### Step 2: Verify the Package Exists (anti-slopsquatting)\n\nBefore evaluating anything else, confirm the package is real and is the one you think it is. AI assistants hallucinate plausible package names at a measurable rate (~20% of AI package recommendations reference packages that don't exist), and attackers register those exact names to deliver malware — **slopsquatting**. A hallucinated name passes every traditional typo filter because it collides with nothing.\n\n- **Confirm the exact name exists in the registry** (`npm view \u003Cpkg>`, the PyPI project page) and that the registry entry's repository link points to the project you expect.\n- **Check adoption history over time** — steady downloads across months, not a package registered last week. A brand-new package with a burst of installs matching an AI-suggested name is the attack signature.\n- **Check typo-distance from a popular package.** Hallucinations often shadow a real name (e.g. `unused-imports` vs the real `eslint-plugin-unused-imports`). If a more popular near-neighbor exists, you probably want the neighbor.\n- **Treat any AI-suggested package name as unverified input.** Verify it the same way you'd verify a URL from an untrusted source — before it reaches `npm install`.\n\n### Step 3: Evaluate the Library\n\nFor any library under consideration, assess these dimensions:\n\n**Maintenance health:**\n- Last commit date (stale > 1 year is a yellow flag)\n- Open issues and PR response time\n- Number of maintainers (bus factor — 1 maintainer is risky)\n- Release frequency and changelog quality\n\n**Adoption signals:**\n- Weekly downloads \u002F GitHub stars (not definitive, but signals community trust)\n- Used by known projects (check dependents)\n- Ecosystem maturity (plugins, integrations, documentation)\n\n**Technical fit:**\n- TypeScript support (if applicable)\n- Bundle size impact — check on bundlephobia.com or similar\n- API quality — is it intuitive, well-documented, consistent?\n- Compatibility with your runtime, framework version, and other dependencies\n\n**Security and legal:**\n- License compatibility with your project (MIT, Apache-2.0 are permissive; GPL is viral)\n- Known vulnerabilities (check npm audit advisory, Snyk, or GitHub advisories)\n- Does it have excessive transitive dependencies?\n\n**Alternatives comparison:**\n- Identify 2-3 alternatives, including Step 1's own module, and compare on the dimensions above\n- A slightly less popular library that's better maintained may be the better choice\n\nSee [references\u002Fevaluation-checklist.md](references\u002Fevaluation-checklist.md) for the structured assessment template.\n\n### Step 4: Present the Recommendation\n\nFor the user, summarize:\n- **Recommendation**: Use \u002F Own module \u002F Don't use \u002F Consider alternative. When Step 1 marked the row Ask the user, give your recommendation and ask; don't install until they answer\n- **Primary reason**: The most compelling argument\n- **Risks accepted**: What you're trading off\n- **Alternatives considered**: when you compare two or more libraries, a table with one column per candidate covering the Step 3 dimensions. Give numbers: bundle or install size, transitive dependency count, weekly downloads. Then show the same small task (one schema, one call) written in each library, so the ergonomics can be compared rather than asserted\n\n## Workflow: Auditing Existing Dependencies\n\n### Step 1: Run Vulnerability Scanners\n\n```bash\n# JavaScript\u002FTypeScript\nnpm audit\n# For more detail:\nnpx better-npm-audit audit\n\n# Python\npip audit\n# or\nsafety check\n\n# Go\ngovulncheck .\u002F...\n\n# Ruby\nbundle audit check --update\n```\n\n### Step 2: Triage Results\n\nNot all vulnerabilities require action. For each finding:\n\n1. **Is the vulnerable code path actually used in your project?** Many CVEs affect specific features you may not use.\n2. **What's the severity?** Start with Critical and High, which need immediate action. Many Moderate and Low findings sit in dev-only tooling or in code paths you never call. Those are acceptable risk: say so, record the decision with its reason, and recheck at the next upgrade instead of fixing everything. Fix the rest of the Moderate findings within a sprint.\n3. **Is a patched version available?** If yes, upgrade. If no, assess mitigation or replacement.\n4. **Is it a transitive dependency?** You may need to upgrade the parent package, or use overrides\u002Fresolutions.\n\n### Step 3: Find Unused Dependencies\n\nDead dependencies add attack surface and bloat for zero value.\n\n```bash\n# JavaScript — find unused packages\nnpx depcheck\n\n# Python — find unused imports (suggests unused packages)\npip install vulture\nvulture src\u002F --min-confidence 80\n```\n\nRemove unused dependencies. If unsure, comment it out, run tests, and deploy to staging.\n\nThen run Step 1's table on each remaining direct dependency to find the ones used for only a sliver. Fill **Grows into** before proposing a replacement: a library we use lightly today can be the right choice for a feature on the roadmap.\n\n### Step 4: Produce the Report\n\nSummarize: N vulnerabilities found (X critical, Y high), N unused packages, N used for a sliver (with own-module alternatives and sizes), N significantly outdated.\n\n## Workflow: Major Version Upgrades\n\n### Step 1: Read the Changelog\n\nRead the changelog and migration guide for the new major version. Identify:\n- **Breaking changes**: What will break in your code?\n- **Deprecations resolved**: What deprecated APIs were removed?\n- **New features**: Anything that simplifies your code?\n- **Peer dependency changes**: Does this force other upgrades?\n\n### Step 2: Plan the Upgrade\n\nFor low-risk upgrades (well-documented, small surface area):\n- Create a branch, bump the version, run tests, fix failures.\n\nFor high-risk upgrades (framework major version, ORM, auth library):\n- Before starting, make sure the tests cover the surface the upgrade touches. Write characterization tests where coverage is thin, because the suite is how you will know the upgrade broke nothing\n- Create a detailed task list of changes needed\n- Changes that work on both the old and the new version can merge to main as they land. The version bump itself runs in isolation (a branch through the full suite, then staging) before it merges\n- Consider running old and new versions in parallel temporarily (expand-contract)\n- Suggest using the `feature-planning` skill to break the upgrade into tasks\n\n### Step 3: Validate\n\n- [ ] All tests pass\n- [ ] No deprecation warnings from the upgraded package\n- [ ] No new vulnerabilities introduced by the upgrade\n- [ ] Lock file is committed and clean\n- [ ] Bundle size has not increased unexpectedly\n\n## Quick Reference: Lock File Hygiene\n\n- **Always commit lock files** (`package-lock.json`, `yarn.lock`, `poetry.lock`, `go.sum`)\n- **Never edit lock files manually** — let the package manager manage them\n- **Use `npm ci` (not `npm install`) in CI** — installs from lock file exactly\n- **Review lock file diffs in PRs** — large unexpected changes signal problems\n- **Regenerate periodically** if the lock file becomes stale or conflicted\n\n## Principles Applied\n\n- **YAGNI**: Don't add a library for a feature you *might* need. Add it when the need is real and proven.\n- **KISS**: Prefer libraries with small, focused APIs over Swiss-army-knife frameworks.\n- **DRY**: A well-chosen dependency eliminates duplication across projects — but a bad choice creates maintenance debt across projects.\n- **Functional Independence**: Prefer libraries that don't deeply couple to your application architecture. You should be able to swap them out.\n- **Boundaries**: Wrap third-party APIs with thin adapter layers — depend on your own abstractions, not on library specifics. This limits blast radius when a dependency changes or is replaced, and keeps your business logic free of third-party types. Only skip wrapping for pervasive infrastructure (e.g., your web framework, your ORM) where the cost of wrapping exceeds the cost of coupling.\n",{"name":5,"description":7,"when_to_use":49},"Triggers: should I use this library, which packages do we need, write our own instead, we use a small part of it, npm audit, dependency vulnerability, upgrade dependencies, outdated packages, lock file, breaking changes in upgrade, is this library maintained, dependency conflict, slopsquatting, does this package exist, AI suggested this library.","main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fsecurity\u002Fskills\u002Fdependency-management","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill dependency-management",{"tool":63,"command":64},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill dependency-management",{"tool":66,"command":67},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill dependency-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Fdependency-management\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fevals.json","REFERENCE","参考文档",8679,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Fdependency-management\u002Fevals\u002Fevals.json",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fevaluation-checklist.md",5320,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Fdependency-management\u002Freferences\u002Fevaluation-checklist.md",[82,122,147,171,204,233],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":103,"publishedAt":44},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[88,91,94,95,100],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":101,"categoryName":102,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000040","财务",[104,105,106,107,36,108,109,110,111,42,112,113,114,115,116,117,118,119,120,121],"writing","writing skills","testing","eval","edit","Budget","authoring","new skill","frontmatter","editing","triggers","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":44},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,133,134,135,136,137,138,139,140,43,141,142,143,33,144,145,114,146],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","sync","status","live","README","session","routines",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":44},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[153],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[155,156,157,158,159,160,104,161,133,162,163,164,136,165,140,166,167,168,169,170],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":184,"publishedAt":44},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[177,180,181],{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":182,"categoryName":183,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000032","设计师",[185,186,187,188,189,190,191,192,193,194,195,196,138,197,198,199,200,201,202,203],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":214,"publishedAt":44},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[210,211],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000030","开发工程师",[215,216,217,218,219,220,185,221,222,223,224,225,226,41,227,228,229,230,231,232],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","security-audit","secure","config","go","security","trust",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":244,"publishedAt":44},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[239,240,241,242,243],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":98,"taxonomyTypeDesc":99},{"categoryNo":182,"categoryName":183,"taxonomyType":98,"taxonomyTypeDesc":99},[185,245,246,247,248,249,106,250,251,161,224,252,38,36,253,254,33,255,256,114],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]