build-review-dependency-hygiene
Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-11
- Stars
- ★ 7
- Forks
- 2
01 前言 Front Matter
- name
- build-review-dependency-hygiene
- phase
- build
- description
- Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.
- enforcement
- gating
- disable-model-invocation
- true
02 资源文件 1
- 参考文档agents/openai.yaml43 B
03 SKILL.md 正文
Purpose
Judge one engine-managed build_review dependency-hygiene rubric branch. This is a
provider-neutral, judgement-only policy: the engine owns scope selection, evidence assembly,
finding identity, and the outer gate verdict.
Judgement
Judge only dependency additions or version changes introduced by the feature diff. Report one finding per independent concern, anchored to the changed manifest or lockfile hunk that introduces it. Use on-disk evidence only for dependency and license facts.
necessity— when an added dependency's purpose is already served by an existing declared dependency or an existing in-repo module, report a finding of at leastmajorseverity that names the added dependency and the existing equivalent's path.pinning— report a finding of at leastmajorseverity when an added or upgraded dependency uses*,latest, or an unbounded>=range, or with a manifest change and no matching committed lockfile update. Name the dependency and the manifest location.license— compare on-disk dependency license metadata with the project's declared license. If the dependency license is incompatible with the project's declared license, report a finding of at leastmajorseverity that names both licenses and the evidence location. If no on-disk evidence can determine the dependency license, report alicensefinding with severitynitthat states the license is unverifiable.
Non-findings
Report no finding when an added dependency has no existing equivalent, uses a bounded specifier, has a matching committed lockfile update, and has a compatible license. Report no finding for a lockfile-only change limited to integrity or resolution metadata, with no added, removed, or version-changed dependency.
Report no pinning finding for a library manifest's caret range on a peer or runtime dependency
when that ecosystem's library convention requires no lockfile change.
Vulnerability, CVE, and maintenance-activity claims are outside its vocabulary and are never reported.
Recommended paths
Configure manifest and lockfile paths appropriate to the project's ecosystems:
- npm:
**/package.json,**/package-lock.json - Yarn:
**/package.json,**/yarn.lock - pnpm:
**/package.json,**/pnpm-lock.yaml - Bundler:
**/Gemfile,**/Gemfile.lock - pip:
**/requirements*.txt,**/requirements*.lock - Poetry:
**/pyproject.toml,**/poetry.lock - uv:
**/pyproject.toml,**/uv.lock - Go modules:
**/go.mod,**/go.sum - Cargo:
**/Cargo.toml,**/Cargo.lock - Maven:
**/pom.xml,**/.mvn/dependency-locks/** - Gradle:
**/build.gradle*,**/gradle.lockfile
04 同仓库更多 Skills
writing-system-tests
Use BEFORE implementing any feature that has stories in .docs/stories/ — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP/request-level acceptance tests for headless/API projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.
verify-claims
Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.
tdd
Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.
stories
Use only within active engineer/conduct DECIDE after architecture approval, when a committed `.docs/stories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.
stack-land
Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.
simplify
Use only at an active pipeline batch boundary after code has changed. Reviews current-batch duplication, complexity, over-engineering, and domain-modelling defects; do not invoke for ordinary refactors, code review, or requests that merely ask for simpler prose or code.