@mohammadhprp/system-prompt 0.12.2 → 0.12.4

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/framework/skills/merge-request/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: merge-request
+description: Create a GitLab merge request (MR) for the current branch using the glab CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitLab MR or merge request.
+---
+
+# `merge-request` skill instructions
+
+Create a merge request for the current branch.
+
+## Process
+
+1. **Collect information**
+   - Get the current branch name: `git branch --show-current`
+   - Read the MR template from `.gitlab/merge_request_templates/default.md` if it exists.
+
+2. **Format MR title**
+   - Take the branch name, replace all `-` with spaces, and capitalize the first character.
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `develop`: `git log develop..HEAD --oneline`
+   - Read each commit message and convert it to a bullet list summarizing user-facing changes.
+   - Merge/squash related commits (for example, multiple commits for the same change).
+   - Keep the summary concise, with one bullet per logical change.
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3.
+   - Keep the Checklist section as-is.
+
+5. **Present plan and confirm** - Show the source branch, target branch (`develop`), title, and filled description. Ask: "Shall I create this MR?" Push the changes if the user says yes.
+
+6. **Create upon confirmation** - Use `glab mr create` with:
+   - `--source-branch`: Current branch
+   - `--target-branch`: `develop`
+   - `--title`: Prepend `Draft: ` to the formatted branch name
+   - `--description`: Filled template content
+   - `--assignee`: `1`
+   - `--squash`
+   - `--remove-source-branch`
+
+7. **Show the resulting URL.**

package/framework/skills/merge-request/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Read the GitLab MR template and current branch history before drafting the request.
+- Summarize related commits into concise user-facing bullets while leaving the checklist unchanged.
+- Display the complete MR plan and wait for approval before pushing or invoking `glab mr create`.

package/framework/skills/pull-request/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: pull-request
+description: Create or update a GitHub pull request (PR) for the current branch using the gh CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitHub PR or pull request.
+---
+
+# `pull-request` skill instructions
+
+Create or update a pull request for the current branch using `gh` CLI.
+
+## Process
+
+1. **Collect information**
+   - Get the current branch name: `git branch --show-current`
+   - Read the PR template from `.github/pull_request_template.md` if it exists.
+
+2. **Format PR title**
+   - Take the branch name, replace all `-` with spaces, and capitalize the first character.
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `develop`: `git log develop..HEAD --oneline`
+   - Read each commit message and convert it to a bullet list summarizing user-facing changes.
+   - Merge/squash related commits (for example, multiple commits for the same change).
+   - Keep the summary concise, with one bullet per logical change.
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3.
+   - Keep the Checklist section as-is.
+
+5. **Present plan and confirm** - Show the source branch, target branch (`develop`), title, and filled description. Ask: "Shall I create this PR?" Push the changes if the user says yes.
+
+6. **Create upon confirmation** - Use `gh pr create --title "<title>" --body "<body>" --base <target>` and show the resulting URL.

package/framework/skills/pull-request/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Build a PR title and concise summary from the current branch and commits, then show the complete body before asking for confirmation.
+- Preserve an existing `.github/pull_request_template.md` checklist while replacing only its summary content.
+- Push and create the GitHub PR only after the user approves the displayed plan.

package/framework/skills/release/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: release
+description: Create a software release by reviewing commits, determining the semantic version, updating the changelog and package versions, committing release metadata, and tagging the result. Use this skill whenever the user asks to cut, prepare, publish, or tag a release.
+---
+
+# `release` skill instructions
+
+Create a release from the current branch state.
+
+## Process
+
+1. **Review recent commits** - Run `git fetch --tags`, `git describe --tags --abbrev=0` to find the latest tag. Run `git log <latest-tag>..HEAD --oneline --format="%s"` to collect all conventional commits since the last release. Read any existing `CHANGELOG.md`.
+2. **Categorize commits** - Group commits by conventional commit type:
+   - `feat!:` or `BREAKING CHANGE:` → breaking change
+   - `feat:` → minor feature
+   - `fix:` → patch fix
+   - `perf:`, `refactor:`, `test:` → patch (if no features)
+   - `chore:`, `docs:`, `ci:` → filtered from changelog
+3. **Determine next version** - Based on the [`commit` skill](../commit/SKILL.md) semver convention:
+   - Breaking changes → increment major version (e.g., `1.2.3` → `2.0.0`)
+   - New features → increment minor version (e.g., `1.2.3` → `1.3.0`)
+   - Only fixes/refactors → increment patch version (e.g., `1.2.3` → `1.2.4`)
+   - If no previous tag exists, propose `0.1.0`
+4. **Present release plan** - Show the current version, new version, categorized changelog entries, and ask: "Shall I create this release (tag vX.Y.Z and update CHANGELOG.md)?"
+5. **Execute on confirmation**:
+   - Update `CHANGELOG.md`: create a new `## [vX.Y.Z]` section under `## Unreleased`, move categorized entries (excluding chore/docs/ci) into it, add the release date, and keep the `## Unreleased` section empty for future work.
+   - Update project version metadata such as `package.json` and `package-lock.json` when present.
+   - Run `git add CHANGELOG.md package.json package-lock.json` for files that exist and commit with `chore: release vX.Y.Z`.
+   - Run `git tag -a vX.Y.Z -m "vX.Y.Z"`.
+6. **Verify** - Run `git log --oneline -n 3` and `git tag --list --sort=-v:refname -n5` to confirm the release tag and commit are in place.

package/framework/skills/release/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Inspect tags and conventional commits, propose the next semantic version, and show the release plan before changing files.
+- Move categorized entries from `Unreleased` into a dated version section while leaving a clean `Unreleased` section.
+- Update available package version metadata, commit the release files, create the annotated tag, and verify both afterward.

package/framework/skills/review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: review
+description: Perform a comprehensive code quality review of changes. Use this skill whenever the user asks to review code, inspect a diff, find bugs, assess production readiness, or perform a code review.
+---
+
+# `review` skill instructions
+
+Perform comprehensive code quality review.
+
+## Process
+
+1. **Review conversation and diff** - Read conversation history, run `git diff` for staged/unstaged changes, identify the problem being solved and the behavior being modified. Read related standards: [`references/standards/naming.md`](../../references/standards/naming.md), [`references/standards/testing.md`](../../references/standards/testing.md), [`references/standards/security.md`](../../references/standards/security.md), [`references/standards/performance.md`](../../references/standards/performance.md).
+2. **Check correctness** - Edge cases, concurrency, error handling, state transitions, and backward compatibility. Read contracts and interfaces before implementation.
+3. **Check maintainability** - Naming reflects business meaning, structure matches project conventions, and comments explain why rather than what.
+4. **Check testing** - Do tests prove the behavior change? Identify missing edge cases or failure paths. Tests should verify behavior, not mirror implementation.
+5. **Check performance** - Look for N+1 queries, unbounded loops, unnecessary allocations, and caching opportunities.
+6. **Check security** - Check input validation, authentication enforcement, secrets exposure, and least privilege.
+7. **Present findings** - Distinguish blockers from suggestions, explain the reasoning for each, and summarize overall risk and production readiness.

package/framework/skills/review/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Review the staged and unstaged diff, then report findings ordered by severity with file and line references.
+- Check correctness, tests, performance, security, and maintainability rather than only formatting.
+- End with an overall risk and production-readiness summary.

package/framework/skills/tdd/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: tdd
+description: "Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested."
+disable-model-invocation: true
+---
+
+# TDD Bug Fix
+
+When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
+
+Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.
+
+## Workflow
+
+1. **Understand the bug.** Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
+2. **Choose the narrowest executable check.** Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.
+3. **Write the failing test first.** Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.
+4. **Run the new test before fixing.** Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.
+5. **Fix the bug.** Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
+6. **Rerun the regression test.** Confirm the test now passes.
+7. **Run nearby validation.** Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.
+
+## If a Failing Test Is Impractical
+
+Do not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.
+
+Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.
+
+## Guardrails
+
+- Do not change tests merely to match a wrong implementation.
+- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
+- Keep the regression test focused on the bug; avoid broad fixture churn or unrelated coverage expansion.
+- Do not add tests when the practical signal is weak; use manual or scripted verification and say why.
+- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
+- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
+
+## Final Response
+
+Report the evidence, not just the outcome:
+
+- Name the failing-before test or executable check and the failure it produced.
+- Name the passing-after test run and any nearby validation performed.
+- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.

package/framework/skills/tdd/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Reproduce a bug with a focused failing regression test before changing the implementation.
+- Use the narrowest practical test path, then run the regression test and relevant nearby validation after the fix.
+- Explain why a failing test is impractical and use the closest reliable executable check instead.

package/framework/skills/unslop/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: unslop
+description: Cut AI tells from any writing. Must always apply.
+disable-model-invocation: true
+---
+
+# Unslop
+
+Edit text to remove AI patterns and add human voice.
+
+## Process
+
+1. Scan for the patterns below.
+2. Rewrite. Preserve meaning, match intended tone.
+3. Add soul (see next section).
+4. Self-audit: "What makes this obviously AI generated?" Fix remaining tells.
+
+## Adding soul
+
+Removing patterns is half the job. Sterile, voiceless writing is just as obvious.
+
+- **Have opinions.** React to facts instead of neutrally listing pros and cons.
+- **Vary rhythm.** Short sentences. Then longer ones that take their time. Mix it up.
+- **Acknowledge complexity.** "Impressive but also kind of unsettling" beats "impressive."
+- **Use "I" when it fits.** First person isn't unprofessional.
+- **Let some mess in.** Perfect structure looks machine-made.
+- **Be specific.** Not "this is concerning" but "there's something unsettling about agents churning away at 3am."
+
+## Patterns to detect and fix
+
+### Content
+
+1. **Puffery.** "pivotal moment", "testament to", "evolving landscape", "setting the stage for", "indelible mark", "deeply rooted". Cut puffery, state what happened.
+2. **Name-dropping.** Listing media outlets without context. Pick one, say what was said.
+3. **Superficial -ing phrases.** "highlighting...", "ensuring...", "reflecting...", "showcasing...", "fostering...". Delete or expand with real sources.
+4. **Promotional language.** "nestled", "vibrant", "breathtaking", "groundbreaking", "renowned", "stunning", "must-visit". Use neutral descriptions.
+5. **Vague attributions.** "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete.
+6. **Formulaic challenges.** "Despite challenges... continues to thrive." Replace with specific facts.
+
+### Language
+
+7. **AI vocabulary.** Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant. Replace with plain words.
+8. **Fancy ways to say "is".** "serves as", "stands as", "boasts", "features". Just say "is" or "has".
+9. **"Not just X, but Y."** State the point directly instead.
+10. **Rule of three.** Forcing ideas into groups of three. Use the natural number.
+11. **Synonym cycling.** Protagonist, main character, central figure, hero all in one paragraph. Pick one, repeat it.
+12. **False ranges.** "from X to Y" where X and Y aren't on a meaningful scale. List topics directly.
+
+### Style
+
+13. **Em dash overuse.** Avoid em dashes entirely. Use periods or commas only (no parentheses, no en dashes, no hyphen-as-dash substitutes). Em dashes are an AI tell, and reaching for parentheses instead just trades one tell for another. If a thought needs separation, end the sentence or use a comma.
+14. **Colon overuse.** Colons are fine before a list or example. Not as mid-sentence connectors. "If you're coming from traditional automation: instead of registering event handlers, you describe conditions" adds nothing with the colon. Rewrite to let the point stand on its own without comparison framing. "Describing when the scheduler should fire works best as plain English." Same meaning, no crutch punctuation.
+15. **Boldface overuse.** Don't bold every proper noun or acronym.
+16. **Inline-header lists.** The tell is a bold label and colon that restates the line: "**Performance:** Performance improved...". Convert those to prose. A bold lead-in that ends in a period, names the item, and is followed by genuinely new detail ("**Schema in TypeScript.** Tables live in one file.") is fine, not a tell.
+17. **Title case headings.** Use sentence case.
+18. **Decorative emojis.** Remove from headings and bullets.
+19. **Curly quotes.** Replace with straight quotes.
+
+### Communication artifacts
+
+20. **Chatbot phrases.** "I hope this helps!", "Let me know if...", "Of course!", "Certainly!", "Found the smoking gun!" Remove.
+21. **Cutoff disclaimers.** "While specific details are limited..." Find sources or remove.
+22. **Sycophantic tone.** "Great question! You're absolutely right!" Respond directly.
+
+### Filler
+
+23. **Filler phrases.** "In order to" becomes "To". "Due to the fact that" becomes "Because". "It is important to note that" gets deleted.
+24. **Excessive hedging.** "could potentially possibly be argued that it might" becomes "may".
+25. **Generic conclusions.** "The future looks bright." State specific plans or facts.
+
+### Jargon
+
+26. **Abstract metaphor nouns.** Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel. These read as technical but usually have a plainer concrete word. "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "way" or "method". "Gold-plating" becomes "more than the job needs". "Ratchet" becomes the mechanism's real name or "a limit that only tightens". "Evacuate" becomes "move out". "Endgame" becomes "the last phase". Pick the concrete word.
+
+### Plain speech
+
+27. **Say what it does, not how it feels.** "the database stays close at hand", "SQL you can read", "types that follow your schema" name a feeling. The fix names the mechanism or a number: "`.toSQL()` returns the exact string sent to the database", "a column rename fails the build". Ask what the sentence tells the reader to do or know, then write that. If you can't restate it as a concrete instruction, fact, or number, cut it. One more check: if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.
+28. **Shorten or split dense sentences.** If the reader has to backtrack to parse a sentence, break it in two or drop clauses. One idea per sentence.
+29. **Active voice.** Prefer it. Catch "is/are/was/were + past participle" and name the actor: "queries are validated" becomes "the compiler validates queries", "the file is parsed by the loader" becomes "the loader parses the file". Passive is fine only when the actor is unknown or genuinely doesn't matter.
+30. **Cut adverbs, or use a stronger verb.** "runs quickly" becomes "is fast" or the number. "significantly improves" becomes the measured delta. An adverb propping up a weak verb means the verb is wrong.
+31. **Prefer the plain word.** "utilize" becomes "use", "leverage" becomes "use", "facilitate" becomes "help", "numerous" becomes "many", "in the event that" becomes "if". The fancier synonym is rarely clearer.

package/framework/skills/unslop/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Rewrite release notes to remove inflated claims, filler, and generic AI phrasing while preserving meaning.
+- Edit technical prose for plain language, varied rhythm, active voice, and a natural human tone.
+- Scan a document for em-dash overuse, formulaic transitions, vague claims, and unnecessary jargon before rewriting it.