Add Laravel 13 support and build on the laravel package skeleton

.agents/skills/package-compatibility/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: package-compatibility
+description: "Use this skill when reviewing Laravel package compatibility across composer constraints, PHP versions, Laravel versions, Testbench versions, dependency stability lanes, Windows CI, or matrix-sensitive code and workflow changes."
+license: MIT
+metadata:
+  author: laravel
+---
+
+# Package Compatibility
+
+## Primary Goal
+
+Keep package code, dependencies, and workflows compatible with the supported Laravel 12/13 and PHP 8.3+ matrix.
+
+## Workflow
+
+1. Read `composer.json` first to determine PHP, Laravel, and Testbench constraints.
+2. Check changed code against Laravel 12/13 APIs and PHP 8.3+ syntax before adopting newer framework or language features.
+3. Review `.github/workflows/tests.yml` for dependency stability lanes, prefer-lowest coverage, prefer-stable coverage, and Windows concerns.
+4. When changing dependencies, confirm constraints still allow the intended Laravel and Testbench versions.
+5. Validate with the smallest local command available, then rely on CI for full OS and dependency matrix coverage.
+
+## References
+
+- `composer.json`
+- `.github/workflows/tests.yml`
+- `phpstan.neon.dist`
+- `tests/`
+- `workbench/`
+
+## Examples
+
+- Review a new Laravel API call by checking whether it exists in Laravel 12 and Laravel 13 before merging it into shared package code.
+- Review a dependency bump by checking Composer constraints, Testbench constraints, prefer-lowest behavior, and Windows path assumptions.
+
+## Anti-Patterns
+
+- Assuming the latest local dependency version represents the whole support matrix.
+- Adding PHP syntax or Laravel APIs that exceed `composer.json` constraints.
+- Ignoring Windows path separators, executable assumptions, or shell-only syntax in tests and workflows.
+- Removing dependency stability lanes because they are slower than a single happy path.

.agents/skills/package-generate-skill/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: package-generate-skill
+description: "Use this skill when creating or updating the bundled Laravel Boost skill under resources/boost/skills from the package implementation and package documentation. Trigger after public APIs, commands, config, routes, views, publish tags, README content, or examples change."
+license: MIT
+metadata:
+  author: laravel
+---
+
+# Package Generate Skill
+
+## Primary Goal
+
+Keep the package's bundled Boost skill accurate, concise, and focused on helping Laravel applications adopt the package.
+
+## Workflow
+
+1. Inspect the package implementation before editing the Boost skill: service provider, facades, public classes, commands, config, routes, migrations, events, views, publish tags, and tests.
+2. Inspect package documentation: `README.md`, contributing docs, examples, and changelog entries that describe user-facing behavior.
+3. Identify the public integration surface only. Include install, configure, publish, command, route, facade, helper, middleware, event, and testing guidance only when the package actually exposes it.
+4. Update `resources/boost/skills/*/SKILL.md` with practical adoption steps, references, examples, and anti-patterns for Laravel app developers using the package.
+5. Preserve front matter, package metadata, and the Boost skill structure: description, primary goal, workflow, references, examples, and anti-patterns.
+6. Validate that the Boost skill does not describe internals as public API and does not document features that are not implemented.
+
+## Writing Rules
+
+- Write for consumers installing the package in a Laravel application, not for maintainers changing package internals.
+- Prefer short, task-oriented steps over broad explanations.
+- Point to concrete files only when they help the consumer understand package adoption.
+- Keep examples runnable and aligned with documented package names, config keys, commands, and publish tags.
+- Keep the skill small enough for an agent to load and apply quickly.
+
+## References
+
+- `resources/boost/skills/`
+- `src/*ServiceProvider.php`
+- `src/Facades/`
+- `src/Console/Commands/`
+- `config/*.php`
+- `routes/*.php`
+- `database/migrations/`
+- `README.md`
+- `tests/Feature/` and `tests/Unit/`
+
+## Examples
+
+- After adding a new Artisan command, update the Boost skill with when to run it, required options, expected output, and any related config.
+- After adding config and publish tags, update the Boost skill with publish commands and the minimum config keys users need to set.
+- After adding a facade or public class, update the Boost skill with one practical integration example and the test assertion a consuming app should use.
+
+## Anti-Patterns
+
+- Regenerating the Boost skill from documentation alone without checking implementation.
+- Documenting private classes, test helpers, workbench-only routes, or implementation details as consumer API.
+- Adding speculative examples for features the package does not provide.
+- Removing package metadata that consuming agents need to identify and apply the skill.

.agents/skills/package-release/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: package-release
+description: "Use this skill when preparing Laravel package releases: CHANGELOG.md updates, generated release notes, GitHub release workflows, version checks, tags, release validation, or release automation changes. Never publish autonomously."
+license: MIT
+metadata:
+  author: laravel
+---
+
+# Package Release
+
+## Primary Goal
+
+Prepare a safe package release checklist and implementation without tagging, pushing, or publishing unless the user explicitly approves that action.
+
+## Workflow
+
+1. Review `CHANGELOG.md`, generated release notes config, GitHub release workflows, open diff, and pending package changes.
+2. Validate the release state with `composer test` before recommending a release.
+3. Confirm whether version metadata needs to change; many Laravel packages rely on Git tags rather than a hardcoded package version.
+4. Review tag naming, release branch, and GitHub release workflow behavior before any release command.
+5. Do not tag, push, or publish without explicit user approval.
+
+## References
+
+- `CHANGELOG.md`
+- `.github/release.yml`
+- `.github/workflows/update-changelog.yml`
+- `.github/workflows/tests.yml`
+- `composer.json`
+
+## Examples
+
+- Prepare a release by checking changelog coverage, confirming generated release notes categories, running `composer test`, and drafting the tag command for user approval.
+- Update release notes grouping in `.github/release.yml` when a new label convention is added.
+
+## Anti-Patterns
+
+- Creating tags, pushing branches, or publishing releases without explicit approval.
+- Skipping `composer test` before a release recommendation.
+- Treating generated release notes as a replacement for meaningful `CHANGELOG.md` entries.
+- Changing release workflows without checking the supported matrix in `.github/workflows/tests.yml`.

.agents/skills/package-scaffold/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: package-scaffold
+description: "Use this skill when adding Laravel package capabilities or wiring them through the service provider: commands, migrations, routes, config merges, views, translations, assets, middleware, publish tags, workbench files, or console-only behavior."
+license: MIT
+metadata:
+  author: laravel
+---
+
+# 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 `simplepay-*` 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 `simplepay-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 `simplepay-*`.
+
+## 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.

.agents/skills/package-testing/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: package-testing
+description: "Use this skill when writing, editing, fixing, or reviewing package tests with Pest 4/5 and Orchestra Testbench, including TDD, feature tests, unit tests, type coverage, arch tests, workbench behavior, commands, routes, config, migrations, and publishable resources."
+license: MIT
+metadata:
+  author: laravel
+---
+
+# Package Testing
+
+## Primary Goal
+
+Prove package behavior with Pest 4/5, Orchestra Testbench, and the local `tests/TestCase.php` setup before or alongside implementation.
+
+## Workflow
+
+1. Start with TDD: write the smallest failing package test for the requested behavior, then implement the smallest change that makes it pass.
+2. Cover happy-path, unhappy-path, and edge-case behavior when the feature has meaningful failure modes.
+3. Prefer focused feature tests for package integration behavior and arch tests for broad constraints.
+4. Use `composer test:unit -- --filter ...` while iterating, `composer test:types` when type-sensitive tests or code changed, and `composer test` before finishing.
+5. Keep real package tests in the suite and remove only throwaway tests that were explicitly created for local scaffolding experiments.
+
+## References
+
+- `tests/TestCase.php`
+- `tests/Pest.php`
+- `tests/Feature/`
+- `tests/Unit/`
+- `tests/ArchTest.php`
+- `composer.json` scripts
+
+## Examples
+
+- Test config merge and config override by asserting default package config, then overriding the host config value in the Testbench app.
+- Test publishable assets, migrations, views, lang files, or config by invoking vendor publish behavior and asserting the target path exists.
+- Test routes with Testbench HTTP requests, commands with Artisan assertions, migrations with a SQLite test database, and workbench behavior after `composer build` when needed.
+
+## Anti-Patterns
+
+- Deleting real package tests because they are inconvenient.
+- Relying only on smoke tests when behavior needs assertions.
+- Testing implementation details when observable package behavior is available.
+- Keeping throwaway scaffolding experiment tests in the package test suite.

.claude

@@ -0,0 +1 @@
+.agents

.editorconfig

@@ -0,0 +1,15 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+indent_size = 4
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.md]
+trim_trailing_whitespace = false
+
+[*.{yml,yaml,json}]
+indent_size = 2

.gitattributes

@@ -0,0 +1,18 @@
+* text=auto eol=lf
+
+/.github            export-ignore
+/.gitattributes     export-ignore
+/.gitignore         export-ignore
+/.editorconfig      export-ignore
+/tests              export-ignore
+/phpunit.xml.dist   export-ignore
+/phpstan.neon.dist  export-ignore
+/pint.json          export-ignore
+/testbench.yaml     export-ignore
+/workbench          export-ignore
+/.claude            export-ignore
+/.agents            export-ignore
+/CLAUDE.md          export-ignore
+/AGENTS.md          export-ignore
+/art                export-ignore
+/official-docs      export-ignore

.github/CONTRIBUTING.md

@@ -0,0 +1,43 @@
+# Contribution Guide
+
+Thank you for considering contributing to SimplePay for Laravel! Please review the following guidelines before submitting a pull request.
+
+For significant changes, please open an issue first so we can discuss the approach.
+
+## Process
+
+1. Fork the project
+2. Create a new branch
+3. Code, test, commit, and push
+4. Open a pull request detailing your changes
+
+## Guidelines
+
+- Ensure the coding style passes by running `composer lint`.
+- Send a coherent commit history, making sure each commit in your pull request is meaningful.
+- You may need to [rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) to avoid merge conflicts.
+- Please remember that we follow [SemVer](http://semver.org/).
+
+## Setup
+
+Clone your fork, then install the dev dependencies:
+
+```bash
+composer install
+```
+
+## Lint
+
+Lint your code:
+
+```bash
+composer lint
+```
+
+## Tests
+
+Run all tests:
+
+```bash
+composer test
+```

.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,69 @@
+name: Bug Report
+description: Report something that is not working as expected.
+title: "[Bug]: "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug. Please complete the fields below so we can reproduce the issue quickly.
+
+  - type: input
+    id: package-version
+    attributes:
+      label: Package Version
+      description: Provide the package version that you are using.
+      placeholder: 1.0.0
+    validations:
+      required: true
+
+  - type: input
+    id: laravel-version
+    attributes:
+      label: Laravel Version
+      description: Provide the Laravel version that you are using.
+      placeholder: 13.0.0
+    validations:
+      required: true
+
+  - type: input
+    id: php-version
+    attributes:
+      label: PHP Version
+      description: Provide the PHP version that you are using.
+      placeholder: 8.3.0
+    validations:
+      required: true
+
+  - type: input
+    id: operating-system
+    attributes:
+      label: Operating System
+      description: If relevant, provide the operating system and version where this occurs.
+      placeholder: macOS 15.0, Ubuntu 24.04, Windows 11
+    validations:
+      required: false
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: Provide a clear description of the issue you are facing.
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps-to-reproduce
+    attributes:
+      label: Steps To Reproduce
+      description: Provide detailed steps to reproduce the issue. A minimal reproduction repository is helpful when possible.
+    validations:
+      required: true
+
+  - type: textarea
+    id: notes
+    attributes:
+      label: Notes
+      description: Add any other context that might help diagnose the issue.
+    validations:
+      required: false