Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
audit-package-version
audit-package-version
alizharb/agent-skills
claude-code
package-audit
versioning
dependency-management
deprecations
testing
architecture

Use when checking whether a Laravel package or feature should be used and which version-specific APIs are safe.

Install
php artisan boost:add-skill alizharb/agent-skills

Save this content to: .claude/skills/audit-package-version/SKILL.md

# Audit Package Version

## When To Use

Use this skill before using or documenting a package feature, especially after a framework or package major upgrade.

## Inputs Needed

- Package name, installed version, feature area, and the code path that will consume it.

## Workflow

1. Inspect installed versions and current project usage.
2. Read version-specific docs before copying examples.
3. Check for deprecated or removed APIs.
4. Prefer native framework options if they solve the same problem.
5. Add the package only when it is clearly justified and already approved.
6. Document the dependency on the package in the relevant guideline or skill.

## Files That May Be Created

- Architecture notes, guidelines, skills, or tests.

## Files That May Be Modified

- Package-consuming code, panel providers, resources, requests, and tests.

## Architecture Rules

- Use the installed package version, not a nearby major version.
- Keep package usage narrow and intentional.

## Testing Requirements

- Add tests that cover the integration point.

## Review Checklist

- Is this the correct version?
- Is there a simpler native option?
- Did we avoid deprecated APIs?

## Common Mistakes to Avoid

- Copying code from the wrong package version.
- Using a package feature without checking whether it exists in this app.

Audit Package Version

When To Use

Use this skill before using or documenting a package feature, especially after a framework or package major upgrade.

Inputs Needed

  • Package name, installed version, feature area, and the code path that will consume it.

Workflow

  1. Inspect installed versions and current project usage.
  2. Read version-specific docs before copying examples.
  3. Check for deprecated or removed APIs.
  4. Prefer native framework options if they solve the same problem.
  5. Add the package only when it is clearly justified and already approved.
  6. Document the dependency on the package in the relevant guideline or skill.

Files That May Be Created

  • Architecture notes, guidelines, skills, or tests.

Files That May Be Modified

  • Package-consuming code, panel providers, resources, requests, and tests.

Architecture Rules

  • Use the installed package version, not a nearby major version.
  • Keep package usage narrow and intentional.

Testing Requirements

  • Add tests that cover the integration point.

Review Checklist

  • Is this the correct version?
  • Is there a simpler native option?
  • Did we avoid deprecated APIs?

Common Mistakes to Avoid

  • Copying code from the wrong package version.
  • Using a package feature without checking whether it exists in this app.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console