@mohammadhprp/system-prompt 0.12.2 → 0.12.3

package/framework/skills/laravel-best-practices/references/checklist.md

@@ -0,0 +1,139 @@
+# Detection Checklist
+
+Every dimension here is a genuine fork: Laravel offers two or more valid approaches, the app's choice changes what the next agent writes, and no active project tool can pick for you. Left out on purpose: pure formatting (Pint owns it), any form an installed and enabled Rector rule rewrites to one canonical shape (`$casts` to `casts()`, `$fillable` to attributes, pipe-string rules to arrays, named to anonymous migrations, `$signature` to `#[Signature]`), and framework defaults any agent writes unprompted (`ShouldQueue` jobs, relation return types, `HasFactory`).
+
+Each item gives the fork, then a hint (a grep or dir to spot which side the app takes). Hints are only a start. Read the matched files, never record on a raw count. Apply the ground rules to every verdict: a consistent choice that is a default or a tool's target form is not a pattern. Rows tagged (architecture) are the highest-signal, so record presence and deliberate absence.
+
+---
+
+## A. Validation & HTTP input
+
+1. Validation entry point: inline `$request->validate()` vs Form Request classes vs `Validator::make()`.
+   - Hint: `ls app/Http/Requests`; grep `->validate(` / `Validator::make(` in `app/Http/Controllers`.
+2. Custom rule location: invokable rule objects in `app/Rules` vs inline closures vs `Validator::extend()` in a provider. Rule objects are the default `make:rule` path, so record only if the app leans on closures or `Validator::extend` instead. "No rule objects" alone is just no-signal.
+   - Hint: `ls app/Rules`; grep `Validator::extend` in `app/Providers`.
+3. Typed input retrieval: typed getters (`$request->string()`, `->integer()`, `->enum()`, `->date()`) vs raw `$request->input()` / dynamic properties.
+   - Hint: grep `->string(` / `->integer(` / `->enum(` vs `->input(` in `app/Http`.
+4. Custom messages/attributes: `lang/*/validation.php` vs Form Request `messages()` / `attributes()` methods.
+   - Hint: `ls lang`; grep `function messages`, `function attributes` in `app/Http/Requests`.
+
+## B. Controllers & routing
+
+1. Controller shape: invokable single-action (`__invoke`) vs resource controllers vs plain multi-method.
+   - Hint: grep `__invoke` in controllers; `Route::resource` / `apiResource` vs verb routes.
+2. Business-logic location (architecture): fat controllers vs delegated to Actions / Services / Jobs.
+   - Hint: read a few controller methods; `ls app/Actions app/Services`.
+3. Route handler style: closures in `routes/*.php` vs controller classes.
+   - Hint: count `function ()` vs `::class` in `routes/web.php`, `routes/api.php`.
+4. Middleware assignment: route/group `->middleware()` vs controller `HasMiddleware::middleware()` vs `#[Middleware]` attribute.
+   - Hint: grep `implements HasMiddleware`, `#[Middleware(` in controllers vs `->middleware(` in routes.
+5. Route model binding: implicit (type-hinted models) vs explicit `Route::bind` vs manual `findOrFail`.
+   - Hint: typed model params in signatures vs `findOrFail(` in controllers; grep `Route::bind`.
+6. Rate limiting: named `RateLimiter::for()` + `throttle:name` vs inline `throttle:60,1`.
+   - Hint: grep `RateLimiter::for` in providers vs `throttle:` in route files.
+
+## C. Authorization
+
+1. Authorization home: Gates (`Gate::define`) vs Policy classes in `app/Policies`.
+   - Hint: `ls app/Policies`; grep `Gate::define` in `app/Providers`.
+2. Authorization call site: `$this->authorize()` / `Gate::authorize()` vs `$user->can()` vs `can` middleware vs `#[Authorize]` vs `@can` in Blade.
+   - Hint: grep `authorize(`, `->can(`, `middleware('can:`, `#[Authorize(`, `@can(`.
+
+## D. Eloquent & models
+
+1. Mass assignment: `$fillable` allow-list vs `$guarded` block-list.
+   - Hint: grep `protected $fillable` / `protected $guarded` in `app/Models`.
+2. Accessors/mutators: modern `Attribute` class vs legacy `getXxxAttribute()` / `setXxxAttribute()`. Record a legacy hold, it goes against the tool's grain.
+   - Hint: grep `: Attribute` / `Attribute::make` vs `function get[A-Z].*Attribute` in `app/Models`.
+3. Primary keys: auto-increment vs `HasUuids` vs `HasUlids`.
+   - Hint: grep `HasUuids` / `HasUlids` in `app/Models`; migration `id()` vs `uuid('id')`.
+4. Custom casts: dedicated `CastsAttributes` classes (`app/Casts`) vs inline `Attribute` vs built-in cast strings.
+   - Hint: `ls app/Casts`; grep `Cast::class`, `AsStringable::class` in models.
+5. Data/query layer (architecture): Eloquent directly in controllers vs repositories vs dedicated query objects (e.g. classes exposing `builder(): Builder`).
+   - Hint: `ls app/Repositories app/Queries`; see where non-trivial queries are built.
+6. Query scopes: local `scope`/`#[Scope]` methods vs dedicated builder classes.
+   - Hint: grep `function scope` / `#[Scope]` in models; `ls app/*/Builders`.
+7. Model events: observers (`app/Observers`, `#[ObservedBy]`) vs `booted()` closures vs event classes.
+   - Hint: `ls app/Observers`; grep `booted`, `::observe`, `#[ObservedBy]`.
+8. Eager-load posture: explicit per-query `->with()` vs model-level `$with` defaults. Treat `preventLazyLoading()` separately as a development guard because it can complement either posture.
+   - Hint: grep `protected $with`, `->with(`, and separately `preventLazyLoading` in `app/`.
+
+## E. Architecture & organization
+
+1. Action/Service structure (architecture): Action classes (invoked via `handle` / `execute` / `__invoke`) vs service objects vs neither. Cross-check the Step 0 `app/` map: any `Actions`/`Services`/`Pipelines`/`Jobs`-as-actions folder is this pattern, so record how it is invoked.
+   - Hint: `ls app/` (the whole tree, not just `Actions`/`Services`); grep the invocation method in the folder you find.
+2. DTOs (architecture): spatie/laravel-data vs plain readonly classes vs arrays everywhere.
+   - Hint: `ls app/Data`; grep `extends Data`, `readonly class` in `app/`.
+3. Dependency acquisition: constructor/method injection vs `app()` / `resolve()` / `App::make()` service location.
+   - Hint: grep `app(` / `resolve(` / `::make(` in `app/` vs promoted constructor deps.
+4. Decoupling: events + listeners vs direct service calls.
+   - Hint: `ls app/Events app/Listeners`; grep `event(`, `::dispatch(`.
+5. Helper vs facade idiom: global helpers (`config()`, `auth()`, `response()`) vs facades (`Config::`, `Auth::`, `Response::`).
+   - Hint: ratio of `config(` vs `Config::` (etc.) across `app/`.
+6. Namespace layout (architecture): default `app/` skeleton vs domain/module folders (`app/Domain/**`, modules).
+   - Hint: `ls app/`, look for `Domain/`, `Modules/`, bounded-context folders.
+7. Enums: backed vs pure; case naming; where they live.
+   - Hint: `ls app/Enums`; grep `enum .*: string`, `enum .*: int`.
+
+## F. Frontend & views
+
+This app ships a frontend stack, so the items below apply.
+
+1. Frontend stack: Blade+Livewire vs Inertia (Vue/React/Svelte) vs Blade-only / API + separate SPA.
+   - Hint: `composer.json` + `package.json`; `ls resources/js/pages`, `resources/views`.
+2. Blade composition: class `<x-*>` components vs anonymous components (`@props`) vs `@include` partials.
+   - Hint: `ls app/View/Components`; grep `<x-`, `@include` in `resources/views`.
+3. Livewire component format: Volt functional/class components, native Livewire 4 single-file (SFC), multi-file (MFC), view-based, or class-based components. Evaluate full-page vs nested separately because it is an independent usage choice.
+   - Hint: check the installed Livewire major and `livewire/volt`; inspect `app/Livewire`, `resources/views/livewire`, and Livewire 4 component/page directories for `@volt`, SFC, MFC, view-based, and class-based formats.
+4. Localization: short keys (`lang/*/*.php` + `__('messages.welcome')`) vs JSON string keys (`lang/*.json` + `__('Full sentence')`).
+   - Hint: `ls lang`; grep dotted `__('` vs sentence keys.
+
+## G. Database & migrations
+
+1. Foreign keys: `foreignId()->constrained()` vs `foreignIdFor(Model::class)` vs manual `foreign()->references()->on()`.
+   - Hint: grep `foreignId(`, `foreignIdFor(`, `->foreign(` in `database/migrations`.
+2. `down()` methods: real reverse logic vs omitted / one-way migrations.
+   - Hint: grep `function down` vs the migration count.
+3. Enum storage: DB `enum()` column vs `string()` + PHP-enum cast on the model.
+   - Hint: grep `->enum(` in migrations vs string columns cast to enums.
+4. Transactions: `DB::transaction(fn ...)` closure vs manual `beginTransaction` / `commit` / `rollBack`.
+   - Hint: grep `DB::transaction`, `beginTransaction` in `app/`.
+5. Idempotent writes: `upsert` / `updateOrCreate` / `firstOrCreate` vs find-then-save.
+   - Hint: grep `upsert(`, `updateOrCreate(`, `firstOrCreate(` in `app/`.
+
+## H. Testing
+
+1. Framework: Pest (`it()` / `test()` / `expect()`) vs PHPUnit classes.
+   - Hint: `ls tests/Pest.php`; grep `it(` / `test(` vs `extends TestCase`.
+2. DB reset: `RefreshDatabase` vs `DatabaseTruncation` vs `DatabaseMigrations`.
+   - Hint: grep those trait names in `tests/`.
+3. Fixtures: compare how equivalent test-owned records are created, such as factories vs manual inserts. Track seeders separately for shared reference data because `$this->seed()` commonly and legitimately coexists with factories.
+   - Hint: grep `::factory(` and direct inserts in `tests/`; separately inspect `$this->seed(` calls and what those seeders provide.
+4. Collaborator isolation: how the app doubles its own classes, Mockery `mock()` / `spy()` vs real integration. Ignore facade fakes like `Mail::fake()` here, they isolate framework services by default and are not a fork against Mockery.
+   - Hint: grep `->mock(`, `->spy(`, `Mockery::` in `tests/`.
+5. Endpoint assertions: array `assertJson([...])` / `assertJsonFragment` vs fluent `AssertableJson`.
+   - Hint: grep `AssertableJson`, `assertJsonFragment` in `tests/`.
+
+## I. Responses & API resources
+
+1. Response shape: API Resource classes vs `response()->json()` vs returning models/arrays directly.
+   - Hint: `ls app/Http/Resources`; grep `JsonResource`, `->json(` in controllers.
+2. Resource relationship inclusion: `whenLoaded()` guards vs unconditional relationship access. Do not count ordinary scalar attributes as rivals to conditional relationships, and evaluate general `when()` fields separately.
+   - Hint: compare relationship fields using `whenLoaded(` with unconditional relationship property access in `app/Http/Resources`.
+3. Pagination contracts: within comparable endpoint categories, length-aware `paginate()` vs `simplePaginate()` vs `cursorPaginate()`. These have different totals, navigation, ordering, and performance contracts, so record only a stable path-scoped API policy, never a project-wide majority.
+   - Hint: grep those in `app/`, then group matches by endpoint type and client contract before comparing them.
+4. Web redirects/URLs: `route('name')` vs `url('/path')` vs `action([...])`.
+   - Hint: grep `route('`, `url('/`, `action([` in `app/Http` and views.
+
+## J. Strings, collections & dates
+
+1. Iteration idiom: `collect()->map()->filter()` pipelines vs `array_map` / `foreach`.
+   - Hint: grep `collect(`, `->map(` vs `array_map`, `foreach` density in `app/`.
+2. String API: fluent `Str::of()->...` (Stringable) vs static `Str::` vs native (`trim`, `strtoupper`).
+   - Hint: grep `Str::of(` vs `Str::` vs native string funcs.
+3. Dates: compare equivalent construction call styles (`now()` / `today()` helpers vs `Carbon::`) separately from the application's mutable/immutable date policy. `Date::use(CarbonImmutable::class)` can make helpers return immutable dates, so those signals are complementary rather than conflicting.
+   - Hint: grep `now(` and `Carbon::` for call style; separately inspect `CarbonImmutable` and `Date::use` for mutability policy.
+
+---
+
+Genuine forks only. Every row survived the "no tool can decide this, and it isn't the default" filter. Give each applicable dimension exactly one verdict: pattern, conflict, default, no-signal, tooling-owned, or already-recorded. The rows tagged (architecture) are where the highest-value rules come from.

package/framework/skills/laravel-best-practices/references/eloquent.md

@@ -30,7 +30,8 @@ $articles = Article::whereHas('user', function ($q) {
 
 Correct:
 ```php
-public function scopeActive(Builder $query): Builder
+#[Scope]
+protected function active(Builder $query): Builder
 {
     return $query->where('verified', true)->whereNotNull('activated_at');
 }
@@ -58,7 +59,8 @@ class PublishedScope implements Scope
 
 Correct (local scope you opt into):
 ```php
-public function scopePublished(Builder $query): Builder
+#[Scope]
+protected function published(Builder $query): Builder
 {
     return $query->where('published', true);
 }

package/framework/skills/laravel-best-practices/references/infer-conventions.md

@@ -0,0 +1,97 @@
+
+# Infer Conventions
+
+Learn how this application writes Laravel, then record what you learn as durable, path-scoped rules other agents will read. You are documenting reality, not improving it.
+
+## Ground Rules (read before you start)
+
+- Consistency first. The codebase's majority style is the convention. Never judge it, never propose a "better" pattern, never record what the code should do. If the app validates inline everywhere, that is the rule, even if Form Requests would be nicer.
+- Skip what an active tool produces, keep what a tool would fight. Inspect the project's Pint and Rector configuration first; a Rector transformation is tooling-owned only when its package and relevant rule or set are installed and enabled. Active tools may rewrite code toward one canonical form: `$casts` to `casts()`, `$fillable` to attributes, magic accessors to the `Attribute` class, pipe-string rules to arrays, `$signature` to `#[Signature]`, named migrations to anonymous, and many more. When the app already sits at an active tool's target form, the tool owns it, so record nothing. But when the app deliberately holds a form an active tool would refactor away, such as legacy `getXxxAttribute()` accessors the `Attribute` class would replace, no tool can reproduce that choice and an agent defaults the other way. That against-the-grain hold is exactly what to record.
+- Record decisions, not defaults. A consistent pattern earns a rule only when it reflects a choice: the app took one valid option where the framework or common practice offered others, or the pattern would surprise a competent agent. Framework defaults steer nothing, so skip them: anonymous migrations, `$signature` commands, `ShouldQueue` jobs, `casts()` on Laravel 11+, named routes, Rule objects in `app/Rules`, and `Mail::fake()` or `Bus::fake()` to isolate framework services. A real fork is not enough on its own. Weigh the side the app took, and record only the side an agent would not reach for by itself: inline closures everywhere, legacy accessors, a bespoke query layer. Watch for the false fork too. "No Mockery" next to facade fakes is not a choice against Mockery, because they double different things. The test for every candidate: without this rule, would the next agent plausibly write it differently? Only "yes" earns a rule.
+- Architecture choices are the gold. Record presence and deliberate absence. The structural pattern the app commits to is the highest-signal convention and the one no tool can decide: Action classes and how they are invoked (`handle` / `execute` / `__invoke`), service objects, dedicated query objects exposing `builder()`, DTOs (spatie/laravel-data vs readonly classes), Form Request validation vs inline, an events and listeners spine vs direct calls, and domain or module folders. Also record a consistent non-pattern, such as "query Eloquent directly in controllers, no repository layer", so the next agent matches the app's altitude instead of over-engineering.
+- Never duplicate `.ai/rules`. Read `.ai/rules/index.md` and the area files before the sweep. A dimension already covered there is marked done and skipped.
+- Evidence or silence. A convention needs at least 3 consistent examples and no meaningful rival to become a candidate. Every Step 1 verdict applies this bar.
+- The recorded rule states the convention, nothing else. One or two imperative lines: this project does X, so do X here. Keep detection evidence out. No counts, ratios, current usage, file lists, or example paths, because that is proof for the confirm step, not part of the rule. One short syntax fragment at most, and point to `search-docs` for API details.
+
+## Process
+
+Each step ends on a checkable completion criterion. Do not advance until it holds.
+
+Fan out when you can. The sweep is embarrassingly parallel. If your environment can spawn subagents (a Task, dispatch, or equivalent tool), do Step 0 yourself, then hand each checklist group (A to J) and the architecture map to its own subagent. Each subagent runs the greps, reads a few representative files, and returns structured verdicts (dimension, verdict, evidence, proposed glob / title / note). You aggregate, dedupe, then run Steps 3 to 5. It is far faster on a real app. No subagents available? Run the steps in sequence, with the same bar and the same output.
+
+### Step 0: Orient
+
+Read `composer.json` (installed packages tell you which checklist groups apply), the `pint.json` / PHPStan / Rector config, `.ai/rules/index.md` if present, and most important, map the `app/` tree. List every directory under `app/` (and any `Modules/`, `src/`, `packages/`, or domain root). Every folder beyond Laravel's default skeleton (`Http`, `Models`, `Providers`, `Console`, `Exceptions`) is a structural pattern the app committed to and a high-value rule waiting to be written: `Actions`, `Services`, `Data` or DTOs, `Queries`, `Repositories`, `ViewModels`, `Pipelines`, `Support`, `Enums`, `Contracts`, `Observers`, or `Domain` and module roots. Note each one. You will confirm how it is used in Step 2.
+
+This app ships a frontend stack, so the frontend checklist group applies. Sweep it.
+
+Done when: you have the applicable checklist groups, the dimensions already recorded in `.ai/rules`, and a list of every non-default `app/` directory mapped to the pattern it represents.
+
+### Step 1: Predefined sweep
+
+Open `references/checklist.md` and work every applicable dimension using its search hints. Give each exactly one verdict:
+
+- Pattern. Clears the bar, rival under ~20% of sites, and reflects a real choice (passes the decisions-not-defaults test). A recording candidate. Cite 2 to 3 example files.
+- Conflict. Both styles present in meaningful numbers. Report the split with counts and example files. Never record a preferred winner while the code remains mixed, even in yolo, because that would describe an aspiration rather than reality. Record only if the user identifies a stable path or context boundary that explains both styles; otherwise defer until the code is reconciled.
+- Default. Consistent, but a framework or common-practice default the agent already writes unprompted. Skip it as a no-op, not a convention.
+- No signal. Under the bar: feature unused, or too few examples. Skip silently (one summary line at most).
+- Tooling-owned or Already-recorded. Skip per the ground rules.
+
+Done when: every applicable dimension carries exactly one of those verdicts.
+
+### Step 2: Open-ended pass
+
+First, close out the architecture map from Step 0. For every non-default `app/` directory you listed, confirm how the pattern is used and apply the same evidence and decisions-not-defaults tests as Step 1. Generator-standard or sparsely used directories such as `Rules`, `Observers`, `Mail`, and `Notifications` are signals to inspect, not automatic conventions. Make genuine structural patterns candidates: Action classes invoked via `handle` / `execute` / `__invoke`, Services constructor-injected, `Queries` objects exposing `builder(): Builder`, DTOs as readonly classes or spatie/laravel-data, module or domain folders as the unit of organization. Scope each qualifying pattern to its own directory glob. Also record a consistent deliberate absence, such as "no repository layer, controllers query Eloquent directly", so the next agent matches the app's altitude.
+
+Then find what else makes this codebase itself: base or abstract classes most code extends, traits used everywhere, tenancy or authorization scoping woven through queries, naming schemes, and custom helpers. Same evidence bar, cite files. Record every genuine structural pattern, and cap the other house findings at ~5 so the pass stays high-signal.
+
+Done when: every non-default `app/` directory from Step 0 has a verdict, and the pass has produced its cited house findings (or concluded there are none).
+
+### Step 3: Confirm
+
+Present every candidate in one batch. Per item: dimension, verdict, evidence (counts and files), and the exact proposed `glob` or `globs` / `title` / `note`. Conflicts are presented as questions about an existing context boundary or deferred cleanup, not as a choice of future style.
+
+Default mode is confirm: record only what the user approves. Switch to yolo only when the invocation said so ("yolo", "don't ask", "just record them"), then record all pattern candidates without asking. Conflicts still go to the user in yolo.
+
+Done when: every candidate is approved, rejected, or (conflicts) decided.
+
+### Step 4: Record
+
+Make one `record-rule` call for each glob an approved convention applies to. Choose the most specific globs that cover the cited evidence from the mapping table below; if a convention spans models and migrations, record it under both domains so agents discover it from either path. The `note` is the bare convention: strip every trace of detection (see the ground rule). If `record-rule` is unavailable (rules disabled), report the full rule text so the user can enable `BOOST_RULES_ENABLED` or add it by hand.
+
+Record this:
+
+> Accessors and mutators: use the legacy magic-method style (`getXxxAttribute()` / `setXxxAttribute()`), not the `Attribute` class. Match it in models.
+
+Not this:
+
+> Accessors/mutators use the legacy magic-method style; the `Attribute`-class style is not used anywhere (13 legacy, 0 Attribute-class), e.g. `app/Models/Post.php`. Match the legacy style in existing models.
+
+Done when: every approved item has a successful tool response, and any failure is reported with its rule text.
+
+### Step 5: Summarize
+
+List recorded rules (file and title), conflicts the user deferred, notable no-signals, and remind the user to commit `.ai/rules` so their team and agents share the conventions.
+
+## Glob mapping
+
+Attach each rule to the most specific path that covers its evidence. Never a lazy `app/**` when a subtree fits. Match the glob to where the code actually lives, which is not the same in a default skeleton and in a modular or DDD layout. Use the Step 0 `app/` map to pick the real path.
+
+Examples:
+
+- Models: `app/Models/**` in a default app, or `app/Modules/Blog/Models/**` / `src/Domain/Blog/**` in a modular one.
+- Controllers, routing, validation, responses: `app/Http/**`, or `app/Modules/*/Http/**` when each module owns its HTTP layer.
+- Actions, Services, DTOs: `app/Actions/**`, `app/Services/**`, `app/Data/**`, or the module path the app actually uses.
+- Tests: `tests/**`.
+- Migrations and database: `database/migrations/**`.
+- Truly app-wide (rare, e.g. auth retrieval): `app/**`.
+
+`record-rule` takes one glob. When a convention genuinely spans two domains (e.g. UUID keys touch models and migrations), call it once per domain with the same title and note; mentioning another path in the note does not make the rule discoverable there.
+
+## Edge cases
+
+- Rules disabled or `record-rule` missing: detection is read-only, so Steps 0 to 3 still run, and recording falls back to the manual path in Step 4.
+- Tiny or fresh app: most dimensions land on no-signal. Say so honestly ("not enough code to infer conventions yet") and record nothing.
+- Huge app: each dimension is a bounded grep plus a handful of file reads. Sample representative files, do not read everything.
+- Re-runs: reading `.ai/rules` in Step 0 makes re-runs incremental, so only new or undecided dimensions surface.
+- Non-standard layout (modules, DDD): the open-ended pass catches the layout itself as convention #1. Adapt the globs in the mapping table to the observed paths.

package/framework/skills/laravel-best-practices/references/pest-testing.md

@@ -1,16 +1,8 @@
----
-name: pest-testing
-description: "Use this skill for Pest PHP testing in Laravel projects only. Trigger whenever any test is being written, edited, fixed, or refactored — including fixing tests that broke after a code change, adding assertions, converting PHPUnit to Pest, adding datasets, and TDD workflows. Always activate when the user asks how to write something in Pest, mentions test files or directories (tests/Feature, tests/Unit, tests/Browser), or needs browser testing, smoke testing multiple pages for JS errors, or architecture tests. Covers: test()/it()/expect() syntax, datasets, mocking, browser testing (visit/click/fill), smoke testing, arch(), Livewire component tests, RefreshDatabase, and all Pest 4 features. Do not use for factories, seeders, migrations, controllers, models, or non-test PHP code."
-license: MIT
-metadata:
-  author: laravel
----
-
-# Pest Testing 4
+# Pest Testing 5
 
 ## Documentation
 
-Use `search-docs` for detailed Pest 4 patterns and documentation.
+Use `search-docs` for detailed Pest 5 patterns and documentation.
 
 ## Basic Usage
 
@@ -46,6 +38,7 @@ it('is true', function () {
 - Run minimal tests with filter before finalizing: `php artisan test --compact --filter=testName`.
 - Run all tests: `php artisan test --compact`.
 - Run file: `php artisan test --compact tests/Feature/ExampleTest.php`.
+- Run only tests affected by recent changes (Tia): `./vendor/bin/pest --parallel --tia`.
 
 ## Assertions
 
@@ -82,16 +75,58 @@ it('has emails', function (string $email) {
 ]);
 ```
 
-## Pest 4 Features
+## Pest 5 Features
 
 | Feature | Purpose |
 |---------|---------|
+| Tia (Test Impact Analysis) | Rerun only tests affected by recent changes |
+| Time-Balanced Sharding | Split tests across CI shards by execution time |
+| New Validation Expectations | `toBeEmail()`, `toBeUlid()`, `toBeIpAddress()`, and more |
 | Browser Testing | Full integration tests in real browsers |
 | Smoke Testing | Validate multiple pages quickly |
 | Visual Regression | Compare screenshots for visual changes |
-| Test Sharding | Parallel CI runs |
 | Architecture Testing | Enforce code conventions |
 
+### Tia (Test Impact Analysis)
+
+Tia reruns only tests affected by recent changes and replays cached results for the rest, dramatically reducing suite duration:
+
+<!-- Tia Example -->
+```shell
+./vendor/bin/pest --parallel --tia
+```
+
+- Replayed tests are not skipped — cached tests store everything they produced, including covered lines and branches.
+- Detects Laravel, Symfony, Livewire, and Inertia automatically.
+
+### New Validation Expectations
+
+Pest 5 ships eight new validation matchers, all supporting `.not` negation:
+
+<!-- Pest 5 Validation Expectations -->
+```php
+expect('nuno@pestphp.com')->toBeEmail();
+expect('01ARZ3NDEKTSV4RRFFQ69G5FAV')->toBeUlid();
+expect('192.168.1.1')->toBeIpAddress();
+expect('00:1a:2b:3c:4d:5e')->toBeMacAddress();
+expect('example.com')->toBeHostname();
+expect('example.co.uk')->toBeDomain();
+expect('Zm9vYmFy')->toBeBase64();
+expect('deadbeef')->toBeHexadecimal();
+```
+
+### Time-Balanced Sharding
+
+Distribute tests across CI shards by execution time rather than count:
+
+<!-- Pest Sharding Example -->
+```shell
+./vendor/bin/pest --update-shards
+./vendor/bin/pest --shard=1/4
+```
+
+Commit `tests/.pest/shards.json` to the repository so CI shards stay consistent.
+
 ### Browser Test Example
 
 Browser tests run in real browsers for full integration testing:
@@ -140,14 +175,8 @@ $pages->assertNoJavaScriptErrors()->assertNoConsoleLogs();
 
 Capture and compare screenshots to detect visual changes.
 
-### Test Sharding
-
-Split tests across parallel processes for faster CI runs.
-
 ### Architecture Testing
 
-Pest 4 includes architecture testing (from Pest 3):
-
 <!-- Architecture Test Example -->
 ```php
 arch('controllers')

package/framework/skills/laravel-best-practices/references/security.md

@@ -90,7 +90,7 @@ Correct:
 
 ## CSRF Protection
 
-Include `@csrf` in all POST/PUT/DELETE Blade forms. In Inertia apps, the `@csrf` directive is automatically applied.
+Include `@csrf` in all POST/PUT/DELETE Blade forms. Inertia doesn't use `@csrf`; its HTTP client sends the `XSRF-TOKEN` cookie back as the `X-XSRF-TOKEN` header, which Laravel accepts in place of the `_token` field.
 
 Incorrect:
 ```blade

package/framework/skills/laravel-best-practices/references/style.md

@@ -44,7 +44,7 @@ Strings — use `Str` and fluent `Str::of()` over raw PHP:
 // Incorrect
 $slug = strtolower(str_replace(' ', '-', $title));
 $short = substr($text, 0, 100) . '...';
-$class = substr(strrchr('App\Models\User', '\'), 1);
+$class = substr(strrchr('App\Models\User', '\\'), 1);
 
 // Correct
 $slug = Str::slug($title);

package/framework/skills/laravel-best-practices/references/tailwindcss.md

@@ -1,4 +1,3 @@
-
 # Tailwind CSS Development
 
 ## Documentation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohammadhprp/system-prompt",
-  "version": "0.12.2",
+  "version": "0.12.3",
   "description": "AI Coding Agent Framework — interactive bootstrap CLI",
   "keywords": [
     "ai",

package/src/catalog.js

@@ -6,34 +6,23 @@ export const categories = {
     items: [
       { id: 'agent-browser', name: 'Agent Browser', description: 'Automate browser and Electron workflows for navigation, testing, screenshots, and data extraction' },
       { id: 'backend-best-practices', name: 'Backend Best Practices', description: 'Consolidated backend engineering practices across API, data, security, testing, and operations' },
-      { id: 'brainstorming', name: 'Brainstorming', description: 'Turn ideas into fully formed designs through dialogue' },
-      { id: 'code-review', name: 'Code Review', description: 'Review backend changes for correctness and maintainability' },
-      { id: 'codenavi', name: 'CodeNavi', description: 'Navigate unknown codebases with precision, a persistent .notebook knowledge base, and surgical implementation' },
-      { id: 'create-adr', name: 'Create ADR', description: 'Create Architecture Decision Records documenting significant architectural choices and rationale' },
-      { id: 'design', name: 'Design Like Damien', description: 'Premium UI design philosophy and Lovable prompting' },
       { id: 'diagram-design', name: 'Diagram Design', description: 'Create technical and product diagrams as standalone HTML with inline SVG' },
       { id: 'docs-writer', name: 'Docs Writer', description: 'Write, review, and edit documentation files with consistent structure, tone, and technical accuracy' },
       { id: 'effective-html', name: 'Effective HTML', description: 'Create self-contained HTML artifacts with routed guidance for design, wireframes, prototypes, plans, and diagrams' },
       { id: 'find-skills', name: 'Find Skills', description: 'Discover, evaluate, and install agent skills for specialized tasks' },
       { id: 'frontend-design', name: 'Frontend Design', description: 'Distinctive, intentional visual design for new UI or reshaping existing UI' },
       { id: 'glab', name: 'Glab', description: 'Work with GitLab via the glab CLI for MRs, issues, and pipelines' },
-      { id: 'great-interface', name: 'Great Interface', description: 'Build, explain, review, and refine product interfaces across accessibility, layout, writing, typography, color, and UI polish' },
       { id: 'humanizer', name: 'Humanizer', description: 'Remove signs of AI-generated writing to make text sound more natural and human' },
       { id: 'improve', name: 'Improve', description: 'Audit repositories and produce prioritized, read-only implementation plans for another agent' },
       { id: 'jira-cli', name: 'Jira CLI', description: 'Work with Jira via the jira CLI for issues, sprints, and epics' },
       { id: 'laravel-best-practices', name: 'Laravel Best Practices', description: 'Laravel patterns for Eloquent, validation, testing' },
-      { id: 'learning-opportunities', name: 'Learning Opportunities', description: 'Facilitate deliberate skill development during AI-assisted coding with short, interactive exercises' },
-      { id: 'notion-mcp', name: 'Notion MCP', description: 'Work with Notion MCP for pages, databases, search' },
       { id: 'perf-web-optimization', name: 'Web Performance Optimization', description: 'Optimize web performance: bundle size, images, caching, lazy loading, and overall page speed' },
       { id: 'security-best-practices', name: 'Security Best Practices', description: 'Language and framework specific security best-practice reviews and secure-by-default coding help' },
       { id: 'sentry', name: 'Sentry', description: 'Inspect Sentry issues, summarize production errors, and pull health data via the Sentry API' },
       { id: 'show-me', name: 'Show Me', description: 'Explain the current topic visually with diagrams, code-shape sketches, and focused HTML artifacts' },
       { id: 'skill-creator', name: 'Skill Creator', description: 'Create and evaluate new agent skills' },
-      { id: 'spec-driven-eval', name: 'Spec-Driven Eval', description: 'Score how completely an implementation fulfills a PRD/spec, case by case, into a single comparable grade' },
-      { id: 'technical-design-doc-creator', name: 'Technical Design Doc Creator', description: 'Create comprehensive Technical Design Documents with mandatory and optional sections through interactive discovery' },
       { id: 'taste', name: 'Taste', description: 'Unified design-quality skill spanning anti-slop frontend, image generation and image-to-code, brand kits, minimalist and industrial UI, and Google Stitch design systems' },
-      { id: 'tlc-spec-driven', name: 'TLC Spec-Driven', description: 'Feature planning and implementation with adaptive phases, EARS testable requirements, atomic commits, and independent verification' },
-      { id: 'web-design-guidelines', name: 'Web Design Guidelines', description: 'Review UI code for Web Interface Guidelines compliance: accessibility, interaction patterns, and design best practices' }
+      { id: 'tlc-spec-driven', name: 'TLC Spec-Driven', description: 'Feature planning and implementation with adaptive phases, EARS testable requirements, atomic commits, and independent verification' }
     ],
   },
 
@@ -72,7 +61,6 @@ export const categories = {
       { id: 'excalidraw', name: 'Excalidraw MCP', description: 'Stream hand-drawn diagrams with interactive editing' },
       { id: 'figma-mcp-go', name: 'Figma MCP Go', description: 'Read/write access to Figma designs via plugin bridge' },
       { id: 'laravel-boost', name: 'Laravel Boost MCP', description: 'Laravel application context and ecosystem docs' },
-      { id: 'notion-mcp', name: 'Notion MCP', description: 'Search, read, and write Notion content' },
       { id: 'playwright-mcp', name: 'Playwright MCP', description: 'Cross-browser automation with accessibility snapshots' },
       { id: 'supabase-mcp', name: 'Supabase MCP', description: 'Manage Supabase projects, SQL, Edge Functions, Auth, Storage, and Realtime' },
     ],

package/framework/mcps/notion-mcp/README.md

@@ -1,57 +0,0 @@
-# Notion MCP
-
-## Overview
-
-Notion MCP is a hosted, officially maintained MCP server by Notion that lets AI agents search, read, and write content in a Notion workspace. It uses OAuth authentication and communicates over Streamable HTTP — no API tokens or local infrastructure required.
-
-Official source:
-
-- [Notion MCP get-started guide](https://developers.notion.com/guides/mcp/get-started-with-mcp)
-- [Tool reference](https://developers.notion.com/guides/mcp/mcp-supported-tools)
-- [GitHub: makenotion/notion-mcp-server](https://github.com/makenotion/notion-mcp-server) (open-source server, no longer actively maintained)
-
-## Features
-
-- Search across Notion workspace and connected tools (Slack, Google Drive, Jira).
-- Fetch page and database content by URL or ID.
-- Create, update, move, and duplicate pages.
-- Create and update databases, data sources, and views (table, board, list, calendar, timeline, gallery, form, chart, map, dashboard).
-- Query databases with SQL or using pre-defined views.
-- Query meeting notes for the current user.
-- Add and list comments and discussions.
-- Get workspace teams and users.
-- Async support for long-running create and update operations.
-- OAuth authentication — no manual token management.
-
-## Supported AI Clients
-
-Notion MCP officially documents setup for Claude Code, Cursor, VS Code (GitHub Copilot), Claude Desktop, Windsurf, ChatGPT, Codex, and Antigravity.
-
-- OpenCode
-
-## When to Use
-
-Use Notion MCP when an AI coding agent needs to read or write content in a Notion workspace.
-
-Good fits:
-
-- Creating project documentation pages from code context.
-- Searching for existing notes, specs, or meeting notes.
-- Updating task statuses, tracking work, or filing bugs.
-- Querying databases for structured data.
-- Managing comments and discussions on pages.
-- Fetching user and team information from the workspace.
-
-Avoid using it for fully automated or headless workflows — Notion MCP requires interactive OAuth authentication.
-
-## Requirements
-
-- A Notion workspace with appropriate permissions.
-- An MCP-compatible AI client that supports remote HTTP (Streamable HTTP or SSE) MCP servers.
-- For some tools (search, query, meeting notes): a Business plan or higher with Notion AI.
-
-## Related Skills
-
-Relevant skills in this repository:
-
-- [`backend-best-practices`](../../skills/backend-best-practices/SKILL.md): backend best practices for API design, testing, and debugging.

package/framework/mcps/notion-mcp/capabilities.md

@@ -1,118 +0,0 @@
-# Notion MCP Capabilities
-
-## What It Can Do
-
-18 tools for searching, reading, and writing content in a Notion workspace.
-
-### Search & Fetch
-
-| Tool | Description |
-| --- | --- |
-| `notion-search` | Search across workspace and connected tools (Slack, Drive, Jira); requires Notion AI for cross-tool search |
-| `notion-fetch` | Fetch content from a page, database, or data source by URL or ID; pass `self` to get workspace and user identity |
-
-### Create
-
-| Tool | Description |
-| --- | --- |
-| `notion-create-pages` | Create one or more pages with properties, content, icons, and covers; supports database templates and async mode |
-| `notion-create-database` | Create a new database with specified properties, initial data source, and initial view |
-| `notion-create-view` | Create a view on a database (table, board, list, calendar, timeline, gallery, form, chart, map, dashboard) |
-| `notion-create-comment` | Add a comment to a page, block-level content, or reply to an existing discussion |
-
-### Update
-
-| Tool | Description |
-| --- | --- |
-| `notion-update-page` | Update page properties, content, icon, or cover; supports database templates and async mode |
-| `notion-update-data-source` | Update a data source's properties, name, description |
-| `notion-update-view` | Update a view's name, filters, sorts, display configuration |
-
-### Move & Duplicate
-
-| Tool | Description |
-| --- | --- |
-| `notion-move-pages` | Move one or more pages or databases to a new parent |
-| `notion-duplicate-page` | Duplicate a page within the workspace (async) |
-
-### Query
-
-| Tool | Description |
-| --- | --- |
-| `notion-query-data-sources` | Query data sources with SQL across multiple databases; requires Business plan or higher with Notion AI |
-| `notion-query-database-view` | Query a database using a pre-defined view's filters and sorts; requires Business plan or higher with Notion AI |
-| `notion-query-meeting-notes` | Query the current user's meeting notes; requires Business plan or higher with Notion AI |
-
-### Comments
-
-| Tool | Description |
-| --- | --- |
-| `notion-get-comments` | List all comments and discussions on a page, including resolved threads |
-
-### Workspace
-
-| Tool | Description |
-| --- | --- |
-| `notion-get-teams` | List teams (teamspaces) in the current workspace |
-| `notion-get-users` | List workspace members and guests with search by name or email; pass `self` for current user |
-
-### Async Tasks
-
-| Tool | Description |
-| --- | --- |
-| `notion-get-async-task` | Check the status of an async task (duplicate, large create/update) |
-
-### OpenAI Client Note
-
-When connecting from an OpenAI-based client (ChatGPT), `notion-fetch` and `notion-search` appear without the `notion-` prefix as `fetch` and `search`.
-
-## What It Cannot Do
-
-- It cannot work without interactive OAuth authentication — no PAT or bearer token support.
-- It cannot upload images or file attachments (on the roadmap).
-- It cannot access Notion content outside the authenticated user's permissions.
-- Some tools require a Business plan or higher with Notion AI (search, query tools).
-- It cannot operate fully headless or automated — a human must complete the OAuth flow.
-- It cannot be self-hosted (use the deprecated open-source server for that).
-
-## Best Practices
-
-- Use `notion-fetch` with `self` to verify the workspace and user identity after connecting.
-- Use `notion-fetch` with a page URL to understand its structure before making changes.
-- Use `notion-search` first to find relevant pages, then `notion-fetch` to read details.
-- Use `allow_async: true` for large page create/update operations, then poll with `notion-get-async-task`.
-- Fetch a database first to see available templates before creating pages with them.
-- Use `notion-get-users` to look up user IDs before assigning or mentioning users.
-- Stay within rate limits: 180 requests/min average (shared across all tools), 30 requests/min for search.
-
-## Common Workflows
-
-### Search and read content
-
-1. Call `notion-search` to find pages matching a topic.
-2. Call `notion-fetch` with a page URL to read its full content.
-3. Call `notion-get-comments` to see discussions on the page.
-
-### Create a page from a template
-
-1. Call `notion-fetch` on a database to see available templates.
-2. Call `notion-create-pages` with the template reference and desired properties.
-3. Optionally set an icon and cover image.
-
-### Update a task status
-
-1. Call `notion-fetch` with the page URL to get the current properties.
-2. Call `notion-update-page` to change the status property.
-3. Call `notion-create-comment` to leave a note about the change.
-
-### Query a database
-
-1. Call `notion-fetch` on the database URL to see its schema and views.
-2. Call `notion-query-database-view` with a view name to get filtered results.
-3. Or call `notion-query-data-sources` with SQL for custom queries.
-
-### Duplicate and populate a template
-
-1. Call `notion-duplicate-page` on a template page.
-2. Poll with `notion-get-async-task` until complete.
-3. Call `notion-update-page` on the new copy to fill in properties.

package/framework/mcps/notion-mcp/configs/opencode.json

@@ -1,9 +0,0 @@
-{
-  "mcp": {
-    "notion": {
-      "type": "remote",
-      "enabled": true,
-      "url": "https://mcp.notion.com/mcp"
-    }
-  }
-}