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

# Package Scaffold

## Primary Goal

Add package features in the right place and wire them through the service provider using explicit Laravel APIs, keeping package names, namespaces, config keys, and publish tags consistent.

## Workflow

1. Inspect the existing package structure, sibling examples, README setup notes, and the current service provider before creating files.
2. Identify whether the request touches commands, migrations, routes, config, views, translations, assets, middleware, tests, README/contributing docs, compatibility, or release flow.
3. Create the capability files under Laravel-native package paths and use the configured package names, namespaces, publish tags, URLs, and badges consistently.
4. Wire the capability through the service provider using the patterns in *Provider wiring* below.
5. Use `package-testing` for coverage, update README or contributing documentation when user-facing behavior changes, use `package-compatibility` for matrix-sensitive changes, and use `package-release` for release tasks.
6. Add only the files needed for the requested capability and validate with the narrowest relevant command before broader checks.

## Provider Wiring

1. Keep provider wiring in `register()` or `boot()` unless extracting a method makes a real repeated concern clearer.
2. Put container bindings and `mergeConfigFrom` calls in `register()` when the host app must be able to override configuration.
3. Put resource loading in boot-time methods with Laravel-native APIs such as `loadRoutesFrom`, `loadViewsFrom`, and `loadTranslationsFrom`.
4. Guard console-only publishing and command registration with `runningInConsole()` before calling `publishes`, `publishesMigrations`, or `commands`.
5. Name publish tags with the `sbi-epay-*` convention so consumers can target individual resource groups.
6. Add tests for the observable provider behavior: merged config, loaded routes, publish tags, or command registration.

Provider wiring anti-patterns:

- Loading host app state too early during provider registration.
- Calling `env()` outside config files; use config values after `mergeConfigFrom` instead.
- Registering web-only concerns unconditionally when the package can run in console contexts.
- Replacing explicit provider methods with `spatie/laravel-package-tools` by default.

## References

- `src/*ServiceProvider.php`
- `config/*.php`
- `routes/*.php`
- `resources/views/`
- `lang/`
- `database/migrations/`
- `public/`
- `src/Console/Commands/`
- `tests/Feature/` and `tests/Unit/`

## Examples

- Add an Artisan command: create the command class under `src/Console/Commands`, register it in the `commands` array inside the `runningInConsole()` guard, add a feature test for observable console output, and document the command if it is user-facing.
- Add a publishable migration: place the migration in `database/migrations`, wire it through a console-guarded `publishesMigrations` call with a `sbi-epay-migrations` tag, and test publish behavior with Testbench.
- Wire a new publish tag by adding a `publishes` map inside the existing console-guarded publishing method and naming the tag with `sbi-epay-*`.

## Anti-Patterns

- Adding unused files because a package might need them later.
- Mixing package names, namespaces, config keys, or publish tags.
- Changing dependencies without approval.
- Replacing explicit Laravel package code with a helper abstraction when one feature-specific change would do.