القائمة
Review package.json for completeness and best practices. Use when auditing metadata, checking dependency versions, or validating peerDependencies.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | docs-review-package |
| description | Review package.json for completeness and best practices. Use when auditing metadata, checking dependency versions, or validating peerDependencies. |
| allowed-tools | Read, Glob, Grep, WebSearch |
| context | fork |
| agent | user-docs |
Reviews a module's package.json for completeness, best practices, and potential improvements.
package.json is your package's identity and contract.
A well-configured package.json:
NEVER modify the version field. Version management is handled by
changesets. The review should only report on version-related issues, not fix
them.
This skill reviews package.json by:
Review a module's package.json:
/design-docs:docs-review-package my-package
Review with dependency update check:
/design-docs:docs-review-package my-package --check-updates
Review all packages in monorepo:
/design-docs:docs-review-package --all
module: Module name to review [REQUIRED unless --all]--check-updates: Check npm for newer dependency versions--all: Review all packages in monorepo--fix: Apply safe fixes (metadata only, never version)Required fields:
| Field | Purpose |
|---|---|
name | Package identifier (scoped recommended) |
version | Current version (DO NOT MODIFY) |
description | Brief description for npm search |
license | SPDX license identifier |
Recommended fields:
| Field | Purpose |
|---|---|
repository | Source code location |
homepage | Documentation/landing page |
bugs | Issue tracker URL |
author | Package maintainer |
keywords | npm search keywords |
engines | Node.js version requirement |
Publishing fields (if publishable):
| Field | Purpose |
|---|---|
files | Files to include in package |
main / exports | Entry points |
types | TypeScript declarations |
publishConfig | npm registry settings |
Version range guidelines:
| Range | Use Case |
|---|---|
^x.y.z | Default for most deps (minor updates OK) |
~x.y.z | Patch updates only (conservative) |
x.y.z | Exact version (avoid unless necessary) |
>=x.y.z | Minimum version (use sparingly) |
* | Any version (never use in production) |
Dependency placement:
| Location | Contents |
|---|---|
dependencies | Runtime requirements |
devDependencies | Build/test tools |
peerDependencies | Host-provided deps |
optionalDependencies | Nice-to-have features |
Best practices:
^x.0.0 or >=x.y.zpeerDependenciesMeta for optional peersCommon issues:
If --check-updates flag:
DO NOT automatically update versions. Report findings only.
Output a structured review:
## Package Review: @scope/package
### Metadata
- ✅ name: @scope/package
- ✅ description: Present
- ⚠️ homepage: Missing
- ⚠️ bugs: Missing
- ✅ repository: Present
### Dependencies
- ✅ 12 dependencies with appropriate ranges
- ⚠️ lodash@^3.0.0 - Consider updating (latest: 4.17.21)
### peerDependencies
- ✅ react: ^17.0.0 || ^18.0.0 (appropriate range)
- ⚠️ typescript: ^4.0.0 (consider adding ^5.0.0)
### Recommendations
1. Add homepage field pointing to documentation
2. Add bugs field pointing to issue tracker
3. Consider updating lodash to v4
Load these files for detailed guidance:
instructions.md - Detailed review checklistA package.json review is successful when:
package.json from module pathdesign-docs:user-docs agent for review/design-docs:user-docs-create-readme - Generate package README/design-docs:docs-generate-contributing - Generate CONTRIBUTING.md/design-docs:docs-sync - Sync docs with package.json changesGenerate cross-reference graph showing relationships between design documents. Use when visualizing doc dependencies, finding related docs, or understanding documentation structure.
Validate design doc structure and frontmatter. Use when checking design docs for compliance, ensuring proper formatting, or verifying metadata before commits.
Comprehensive quality audit for CLAUDE.md context files. Use when performing thorough quality checks, preparing for releases, ensuring context efficiency, or verifying token optimization.
Style rules for LLM context files (CLAUDE.md, AGENTS.md and their .local variants). Fires automatically when these files are opened. Enforces on-demand loading patterns, proper @-reference syntax and lean context structure.
Split large CLAUDE.md into child files. Use when context files exceed word limits, are too verbose, or cover multiple distinct topics that should be separate.
Validate CLAUDE.md structure, formatting, and quality. Use when checking context files for compliance, ensuring proper structure, or verifying before commits.