@event4u/agent-config 2.25.0 → 2.26.0

package/.agent-src/skills/readme-writing-package/SKILL.md

@@ -53,7 +53,7 @@ what it does, whether it fits their stack, how to install it, and how to use it.
 
 Read files that define actual package behavior:
 
-- `composer.json` / `package.json` — name, description, requirements, scripts
+- Manifest: `composer.json`, `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, or `*.gemspec` — name, description, requirements, scripts
 - Source entrypoints — public API surface, main classes/functions
 - Config files — publishable configs, defaults
 - CI workflows — what gets tested, supported versions matrix
@@ -83,32 +83,103 @@ Skip sections that have no real content. Never pad.
 
 ### 4. Write requirements and compatibility
 
-State only what is tested and supported:
+State only what is tested and supported. Pull the values from the package's manifest, not from memory. Examples per stack:
 
 ```
-## Requirements
+## Requirements (PHP)
 
 - PHP ^8.2
-- Laravel 11.x
+- Laravel 11.x (optional integration)
 - ext-json
 ```
 
-Do NOT imply broad compatibility if only tested in narrow range.
-Include framework version, language version, required extensions, services.
+```
+## Requirements (JS / TS)
+
+- Node.js >= 20
+- TypeScript >= 5.4 (for typed consumers)
+- npm / pnpm / yarn / bun
+```
+
+```
+## Requirements (Python)
+
+- Python >= 3.11
+- pip / poetry / uv
+- Optional: `fastapi >= 0.110` for the FastAPI integration
+```
+
+```
+## Requirements (Go)
+
+- Go >= 1.22
+```
+
+```
+## Requirements (Rust)
+
+- Rust >= 1.78 (stable)
+- `cargo` workspace member or standalone crate
+```
+
+```
+## Requirements (Ruby)
+
+- Ruby >= 3.2
+- Bundler >= 2.5
+- Optional: Rails 7.1+ for the Rails integration
+```
+
+Do NOT imply broad compatibility if only tested in a narrow range.
+Include language version, framework version, required extensions, and services.
 
 ### 5. Write installation that actually works
 
-Document the exact install command and any required follow-up:
+Document the exact install command and any required follow-up. Use the
+package manager native to the stack — never edit manifests by hand.
 
 ```bash
+# PHP / Composer
 composer require vendor/package
-
-# If framework integration needed:
+# Optional Laravel integration:
 php artisan vendor:publish --tag=package-config
 ```
 
+```bash
+# JS / TS — pick whichever the consumer uses
+npm install <package>
+pnpm add <package>
+yarn add <package>
+bun add <package>
+```
+
+```bash
+# Python
+pip install <package>
+poetry add <package>
+uv add <package>
+```
+
+```bash
+# Go
+go get github.com/<owner>/<package>@latest
+```
+
+```bash
+# Rust
+cargo add <package>
+```
+
+```bash
+# Ruby
+bundle add <package>
+# or, for a standalone gem:
+gem install <package>
+```
+
 Validate each step against the actual codebase.
-Include post-install steps (publish, register, env setup) if required.
+Include post-install steps (config publish, service / module / provider
+registration, env vars, codegen, migrations) if the package requires them.
 
 ### 6. Write the minimal working example
 
@@ -148,10 +219,10 @@ splitting, duplication between README and `/docs/`).
 
 #### Per-AI catalog pattern (multi-platform AI / CLI packages)
 
-For packages targeting many AI assistants or platforms (CLI installers,
-agent-config tools, language SDKs with 10+ targets), prefer flat per-AI
-catalog over giant matrix. One line per target, install command on left,
-aligned trailing comment naming platform:
+For packages that target many AI assistants or platforms (CLI installers,
+agent-config tools, language SDKs with 10+ targets), prefer a flat per-AI
+catalog over a giant matrix. One line per target, install command on the
+left, aligned trailing comment naming the platform:
 
 ```bash
 npx <package> init --tools=claude-code      # Claude Code
@@ -160,22 +231,22 @@ npx <package> init --tools=windsurf         # Windsurf
 # ... one line per supported target
 ```
 
-Pair catalog with separate "Global install" subsection (same flags plus
-`--global`) and "Other commands" subsection. Reference example:
+Pair the catalog with a separate "Global install" subsection (same flags
+plus `--global`) and an "Other commands" subsection. Reference example:
 [`README.md § Pick specific AIs`](../../../README.md#pick-specific-ais) in
-this repo. Inspiration:
+this repository. Inspiration:
 [`ui-ux-pro-max-skill § Installation`](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill#installation).
 
-Use catalog when package's primary install action varies by platform; use
-matrix table (Tool / Rules / Skills / Commands) for capability comparison.
-Different jobs — install vs. coverage.
+Use the catalog when the package's primary install action varies by
+platform; use a matrix table (Tool / Rules / Skills / Commands) for
+capability comparison. They serve different jobs — install vs. coverage.
 
 README = enough to adopt. Docs = enough to master.
 
 ### 8. Validate
 
 - [ ] Install command is correct and complete
-- [ ] Compatibility/requirements match `composer.json` / `package.json` / CI matrix
+- [ ] Compatibility/requirements match the manifest (`composer.json`, `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `*.gemspec`) and the CI matrix
 - [ ] First example matches real API (verified against source code)
 - [ ] All documented commands exist in repo
 - [ ] No invented features or capabilities
@@ -199,8 +270,8 @@ README = enough to adopt. Docs = enough to master.
 - Model tends to invent compatibility claims or setup steps
 - First example is often too large, too abstract, or uses pseudo-code
 - Model over-explains internals before showing how to use the package
-- Existing README may be outdated — verify against actual `composer.json` / source, not old text
-- Model forgets post-install steps (config publish, service provider, env vars)
+- Existing README may be outdated — verify against the actual manifest (`composer.json`, `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `*.gemspec`) and source, not the old prose
+- Model forgets post-install steps (config publish, service / module / provider registration, env vars, codegen, migrations) — list whichever the stack requires
 
 ## Frugality Standards
 

package/.agent-src/skills/roadmap-management/SKILL.md

@@ -93,7 +93,7 @@ Every roadmap follows this structure:
 ## Acceptance Criteria
 
 - [ ] {Observable, testable criterion}
-- [ ] All quality gates pass (PHPStan, Rector, tests)
+- [ ] All quality gates pass — the project's type-checker, auto-fixer, linter, and full test suite (see the `quality-tools` skill for stack-specific invocations)
 
 ## Notes
 

package/.agent-src/skills/rtk-output-filtering/SKILL.md

@@ -37,12 +37,22 @@ rtk npm test          # same for JS/TS
 rtk docker compose ps # compact container status
 ```
 
-## Procedure: Wrap commands with rtk
+## Procedure: Analyze, then wrap commands with rtk
 
-1. Read `personal.rtk_installed` from `.agent-settings.yml`.
-2. **If `true`** → prefix commands with `rtk` when output >30 lines expected.
-3. **If `false` or missing** → use plain commands. Do not prompt the user.
-4. After wrapping: verify output is useful (not truncated on completeness-critical commands).
+### 1. Analyze the current setup
+
+- Read `personal.rtk_installed` from `.agent-settings.yml`.
+- Review the command about to run: estimated output size, whether
+  completeness matters (e.g. diff review), and whether a project-local
+  filter exists in `.rtk/filters.toml`.
+
+### 2. Wrap (or skip)
+
+1. **If `personal.rtk_installed: true`** → prefix commands with `rtk`
+   when output >30 lines expected.
+2. **If `false` or missing** → use plain commands. Do not prompt the user.
+3. After wrapping: verify output is useful (not truncated on
+   completeness-critical commands).
 
 Installation and one-time setup are owned by
 [`/onboard`](../../commands/onboard.md). If the user asks to install rtk
@@ -153,10 +163,15 @@ When debugging or reviewing diffs, **always run the raw command** without rtk.
 
 ## Project-Local Filters
 
-Custom filters for the project's PHP/Laravel toolchain live in `.rtk/filters.toml`
-(project root, versioned in Git). These override global filters for matching commands.
+Project-local custom filters live in `.rtk/filters.toml` (project root, versioned in Git). These override global filters for matching commands. Add entries for whatever tools the project actually runs.
 
-Covered: PHPStan, Pest, ECS, Rector, Docker Compose, Artisan, Composer.
+Coverage shipped with this package (extend per project):
+- PHP / Laravel: PHPStan, Pest, PHPUnit, ECS, Rector, Composer, Artisan
+- JS / TS: tsc, eslint, prettier, vitest, jest, playwright, pnpm/npm/yarn install + run
+- Python: ruff, mypy, pyright, pytest, pip / poetry / uv
+- Go: `go test`, `go build`, `go vet`, `golangci-lint`
+- Rust: `cargo build`, `cargo test`, `cargo clippy`, `cargo fmt`
+- Infra / runtime: Docker Compose, Terraform, kubectl
 
 To generate or update project-local filters → use the `/optimize-rtk-filters` command.
 

package/.agent-src/skills/rule-refactor/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: rule-refactor
+description: "Use when the rule set is over the Augment budget, when a new rule would breach it, or when asked to audit / merge / prune rules — runs the audit pipeline and proposes a verdict per rule."
+source: package
+domain: process
+---
+
+<!-- cloud_safe: degrade -->
+
+# rule-refactor
+
+## When to use
+
+* `measure_augment_budget --check` fails (utilisation ≥ 0.95)
+* A new rule would push the budget over 0.95 — caught by the budget
+  gate in [`rule-writing`](../rule-writing/SKILL.md)
+* User says "audit rules", "rule cleanup", "rules over budget",
+  "prune rules", "merge rules", "rule system review"
+* Periodic governance pass after a batch of rule additions
+
+Do NOT use this skill for:
+
+* Editing a single rule's content → [`rule-writing`](../rule-writing/SKILL.md)
+* Picking always vs auto for one new rule → [`rule-writing`](../rule-writing/SKILL.md)
+
+## Iron Law
+
+**Threshold-lift is forbidden.** When the budget breaches, the
+content must shrink — not the gate. Loosening `FAIL_THRESHOLD` in
+`scripts/measure_augment_budget.py` to make CI pass is an explicit
+anti-pattern. The only valid budget-growth move is an ADR that
+raises `TOTAL_CAP`.
+
+## Procedure
+
+### 1. Inspect the current budget state
+
+```bash
+python3 scripts/measure_augment_budget.py --json > /tmp/budget-before.json
+python3 scripts/measure_rule_budget.py --json > /tmp/rule-budget-before.json
+```
+
+### 2. Run the audit pipeline
+
+The audit infrastructure already exists — compose it:
+
+```bash
+python3 scripts/audit_auto_rules.py      # → agents/reports/auto-rules-audit.{json,md}
+python3 scripts/audit_overlap.py         # → appends overlap pairs to the MD
+python3 scripts/audit_likelihood.py      # → agents/reports/auto-rules-likelihood.json
+```
+
+Then read `agents/reports/auto-rules-audit.md` end-to-end.
+
+### 3. Categorise every flagged rule
+
+For each rule the audit surfaces (overlap pair, low-likelihood, oversized,
+or the new addition that triggered this skill), assign exactly one verdict:
+
+| Verdict | Test |
+|---|---|
+| **keep** | Iron-Law / always-on safety net, no overlap, fires often |
+| **merge** | ≥ 2 rules same domain, near-identical triggers, overlap ≥ 0.4 |
+| **delete** | Never fires (low-likelihood + no path/keyword hit in 30 days), or fully subsumed by a skill |
+| **move-to-context** | Body is reference material (tables, mechanics, examples) — the obligation is short, the rest is lookup |
+| **promote-to-skill** | Body has numbered steps / a workflow — not a constraint |
+
+### 4. Present the verdict table to the user
+
+One Markdown table, one row per flagged rule, **before** any file
+change. User approves the list. No silent edits.
+
+### 5. Apply approved changes
+
+For each approved verdict:
+
+* **merge** → rewrite the surviving rule to cover both domains;
+  delete the absorbed one; update any `routes_to:` references.
+* **delete** → remove the file from `.agent-src.uncompressed/rules/`
+  and the corresponding `.agent-src/rules/` projection.
+* **move-to-context** → extract the body into
+  `.agent-src.uncompressed/contexts/<area>/<name>.md`, replace the
+  rule body with the obligation + a `load_context:` pointer.
+* **promote-to-skill** → create
+  `.agent-src.uncompressed/skills/<name>/SKILL.md`, replace the rule
+  with an auto-trigger stub that routes to it (or delete the rule
+  entirely if the skill's own trigger suffices).
+
+### 6. Re-validate
+
+```bash
+bash scripts/compress.sh --sync
+python3 scripts/compress.py --generate-tools
+python3 scripts/measure_augment_budget.py --check   # must exit 0
+python3 scripts/skill_linter.py --all               # 0 FAIL
+```
+
+Then run your package's full CI pipeline (see `Taskfile.yml` for the
+canonical sequence) before pushing.
+
+### 7. Record the delta
+
+Append a snapshot to `agents/.augment-budget-history.jsonl`:
+
+```bash
+python3 scripts/measure_augment_budget.py --trend-append
+```
+
+Commit the cleanup as a separate chunk from any rule-add commits so
+the history shows "added X" + "cleaned up Y" as distinct steps.
+
+## Output format
+
+1. Verdict table (approved by user) at the top of the cleanup PR description
+2. Per-verdict commits (one per merge / delete / move / promote group)
+3. Final `measure_augment_budget --check` output showing utilisation < 0.95
+4. Trend snapshot recorded
+
+## Gotchas
+
+* Do NOT raise `FAIL_THRESHOLD` to dodge the audit
+* Do NOT delete a rule that has a `routes_to:` pointer without
+  updating the pointer's source
+* Do NOT merge rules across tier boundaries (e.g. tier-1 always
+  with a tier-3 stub) without surfacing the tier collapse to the user
+* Do NOT skip the trend-append — the history is what tells future
+  agents how the cap was managed
+
+## Do NOT
+
+* Do NOT loosen the budget gate
+* Do NOT touch the cap (`TOTAL_CAP`) without an ADR
+* Do NOT apply changes before user approves the verdict table
+* Do NOT delete the rule-refactor audit reports — they're the
+  artifact reviewers cite
+
+## Cloud Behavior
+
+On cloud surfaces, the audit scripts are not reachable. The skill
+still applies — prose-only:
+
+* Inspect the rule list (frontmatter + descriptions) and propose the
+  verdict table from reading alone.
+* Tell the user to run the audit scripts locally before applying.
+* Do not attempt to call any script.

package/.agent-src/skills/rule-writing/SKILL.md

@@ -129,12 +129,38 @@ the PR or split by responsibility.
 * Run the full CI pipeline locally (see `Taskfile.yml` in this repo for
   the script list) — must exit 0 except for tolerated warnings.
 
+### 5b. Budget-discipline gate — hard stop
+
+After validation, before declaring the rule done, run:
+
+```bash
+python3 scripts/measure_augment_budget.py --check
+```
+
+If utilisation is `≥ 0.95` (or the check exits non-zero), **STOP** and
+invoke [`rule-refactor`](../rule-refactor/SKILL.md). Do NOT:
+
+* Trim the new rule further to "just fit" — if it needs that body to
+  do its job, the rule is right and the rule set around it is wrong.
+* Raise `FAIL_THRESHOLD` in `scripts/measure_augment_budget.py` —
+  threshold-lift is explicitly forbidden (see the
+  [`validation-budget`](../../rules/validation-budget.md) rule and
+  the `rule-refactor` Iron Law).
+* Promote an always-rule to auto to dodge the cap if the rule's
+  semantics require always-on visibility — that breaks the rule, not
+  the budget.
+
+The discipline: budget pressure is the signal that the rule **set**
+needs a cleanup pass, not that the new rule needs to be smaller. The
+`rule-refactor` skill runs the audit and proposes merge / delete /
+move-to-context / promote-to-skill so the new rule earns its space.
+
 ### 6. Governance baseline (when introducing a new linter check)
 
 **Advisory, reviewer-checked — no CI gate.** When the same PR adds a
-new check to `scripts/skill_linter.py` (or strengthens an existing one)
-such that previously-clean rules now warn, the PR body MUST record the
-pre-existing violations on `main` in a Markdown table:
+new check to `scripts/skill_linter.py` (or strengthens an existing
+one) such that previously-clean rules now warn, the PR body MUST
+record the pre-existing violations on `main` in a Markdown table:
 
 ```markdown
 ### Pre-existing baseline (informational)
@@ -144,11 +170,11 @@ pre-existing violations on `main` in a Markdown table:
 | {new_code} | N | (a) genuine fix · (b) accept · (c) check too aggressive |
 ```
 
-Forward-only: the new check applies to **the rule under review** and to
-**future** edits. The baseline table is informational so reviewers can
-distinguish genuine debt from acceptable carry-overs without diffing the
-full lint output. See `agents/analysis/lint-warning-triage.md` for the
-3-bucket reference.
+Forward-only: the new check applies to **the rule under review** and
+to **future** edits. The baseline table is informational so reviewers
+can distinguish genuine debt from acceptable carry-overs without
+diffing the full lint output. See
+`agents/analysis/lint-warning-triage.md` for the 3-bucket reference.
 
 ## Frontmatter shape
 

package/.agent-src/skills/security/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security
-description: "Use when applying security best practices — authentication, authorization via Policies, CSRF protection, input sanitization, rate limiting, or secure coding."
+description: "Use when applying security best practices — authentication, authorization, CSRF protection, input sanitization, rate limiting, or secure coding — stack-agnostic."
 source: package
 domain: quality
 ---
@@ -13,65 +13,74 @@ Use when implementing authentication, authorization, or any security-sensitive f
 
 Do NOT use when:
 
-* Validation logic only — route to [`laravel-validation`](../laravel-validation/SKILL.md)
-* Full security audit — route to [`security-audit`](../security-audit/SKILL.md)
-* You need a pre-implementation threat model — route to
-  [`threat-modeling`](../threat-modeling/SKILL.md)
-* You need end-to-end authorization analysis — route to
-  [`authz-review`](../authz-review/SKILL.md)
+* Validation logic only — route to the project's validation carve-out ([`laravel-validation`](../laravel-validation/SKILL.md) for Laravel; otherwise the framework-native primitive — Zod / class-validator, Pydantic, struct-tag validators).
+* Full security audit — route to [`security-audit`](../security-audit/SKILL.md).
+* You need a pre-implementation threat model — route to [`threat-modeling`](../threat-modeling/SKILL.md).
+* You need end-to-end authorization analysis — route to [`authz-review`](../authz-review/SKILL.md).
 
-## Procedure: Implement security for a feature
+## Stack-specific carve-outs
+
+The procedure below is stack-agnostic. For framework-specific primitives (Laravel Policies / Gates / FormRequests, Symfony voters, NestJS guards, Next.js middleware), defer to:
+
+| Stack | Carve-out |
+|---|---|
+| Laravel | [`laravel`](../laravel/SKILL.md), [`laravel-validation`](../laravel-validation/SKILL.md), [`laravel-middleware`](../laravel-middleware/SKILL.md) |
+| Symfony | [`symfony-workflow`](../symfony-workflow/SKILL.md) |
+| Next.js / TS | [`nextjs-patterns`](../nextjs-patterns/SKILL.md) |
+
+## Procedure: Implement security for a feature (stack-neutral)
 
 ### Step 0: Inspect
 
-1. Read `agents/authentication.md` for auth flow.
-2. Read `agents/gates.md` for gate/policy patterns.
-3. Check existing policies in `app/Policies/`.
+1. Read the project's auth doc (`agents/authentication.md`, `docs/auth.md`, or framework docs).
+2. Read the project's authorization doc (gates / policies / voters / guards).
+3. Locate existing authorization rules in the project's idiomatic location (Laravel `app/Policies/`, Symfony `src/Security/Voter/`, NestJS `*.guard.ts`).
 
 ### Step 1: Authentication
 
-- Check auth setup: `tymon/jwt-auth` or `laravel/sanctum`.
-- Check `config/auth.php` for guards and providers.
-- Customer identification happens after auth — see `multi-tenancy` skill.
+- Identify the auth mechanism in use (session, JWT, OAuth, API token) — read the framework's auth config (`config/auth.php`, `next-auth.config.ts`, Symfony `security.yaml`, FastAPI dependency).
+- Check guard / strategy / provider configuration.
+- Multi-tenant identification happens **after** authentication — see [`multi-tenancy`](../multi-tenancy/SKILL.md).
 
 ### Step 2: Authorization
 
-1. Create policy in `app/Policies/` if needed.
-2. Use in FormRequest `authorize()` or controller `$this->authorize()`.
-3. Check `agents/gates.md` for non-model gates.
+1. Create / locate the authz rule in the framework's idiomatic primitive (Policy, voter, guard, middleware, route dependency).
+2. Apply it at the request boundary (FormRequest `authorize()`, controller / route-handler dependency, middleware chain).
+3. Cover non-model gates (cross-aggregate rules) — keep them centralised, not scattered across handlers.
 
 ### Step 3: Review for adversarial
 
-For security-sensitive changes, run `adversarial-review` skill.
+For security-sensitive changes, run [`adversarial-review`](../adversarial-review/SKILL.md).
 Focus on: attack surface, trusting user input, authorization gaps.
 
 ## Conventions
 
-→ See guideline `php/security.md` for auth, SQL injection, XSS, CSRF, headers, session, mass assignment.
+→ For PHP / Laravel specifics (auth helpers, mass assignment, Blade escaping, CSRF middleware): see guideline `docs/guidelines/php/security.md`.
+→ For other stacks, follow the framework's hardening guide and the carve-outs above.
 
 ### Validate
 
-- Verify all user input is validated via FormRequest before use.
-- Confirm authorization check exists (Policy or Gate) for every state-changing action.
-- Check that no raw user input reaches SQL, HTML output, or shell commands.
-- Run PHPStan — must pass (catches type-safety issues that enable injection).
+- Verify all user input is validated at the boundary via the framework's primitive — never trust raw request data.
+- Confirm an authorization check exists for every state-changing action.
+- Check that no raw user input reaches SQL, HTML output, shell commands, or template renderers without escaping.
+- Run the project's type-checker — must pass (catches type-safety issues that enable injection).
 
 ## Output format
 
-1. Security-hardened code with auth, validation, and sanitization
-2. Policy class for authorization if needed
+1. Security-hardened code with auth, input validation at the boundary, and output encoding.
+2. Authorization rule (Policy / voter / guard / middleware) co-located with the route.
 
 ## Gotcha
 
 - Validation ensures format, not intent — don't trust input after validation alone.
-- `Gate::authorize()` throws, `Gate::allows()` returns bool — choose based on error handling.
-- Rate limiting: ALL public endpoints, not just login.
+- "Throw" vs "boolean" authz APIs behave differently (`Gate::authorize()` throws vs `Gate::allows()` returns bool in Laravel; `CanActivate` in NestJS throws; FastAPI dependencies throw `HTTPException`). Pick based on how the framework expects failure to surface.
+- Rate-limit ALL public endpoints, not just login.
 - Never log passwords, tokens, or API keys.
 
 ## Do NOT
 
-- Do NOT bypass FormRequest validation in controllers.
-- Do NOT use `$request->all()` for mass assignment — use `$request->validated()`.
+- Do NOT bypass the framework's request-validation primitive inside handlers.
+- Do NOT bulk-bind raw request payloads to ORM entities without an explicit allow-list (`$fillable` / `$guarded`, DTO mapping, Pydantic model).
 - Do NOT store plaintext passwords or secrets in the database.
 - Do NOT expose internal error details in production API responses.
 

package/.agent-src/skills/skill-reviewer/SKILL.md

@@ -193,7 +193,7 @@ Before scoring the 5 Killers, verify structure:
 ```markdown
 | Skill | K1 Desc | K2 Over | K3 Obvious | K4 Gotcha | K5 Size | K6 Pointer | K7 Analysis | Verdict |
 |---|---|---|---|---|---|---|---|---|
-| dto-creator | ❌ | ✅ | ✅ | ⚠️ | ✅ | ✅ | ✅ | Fix description |
+| laravel-dto | ❌ | ✅ | ✅ | ⚠️ | ✅ | ✅ | ✅ | Fix description |
 ```
 
 ## Output format

package/.agent-src/skills/test-driven-development/SKILL.md

@@ -172,7 +172,7 @@ For mock-isolation failure modes (separate concern), see
 
 ## Examples
 
-### PHP / Pest
+### Example A — PHP / Pest
 
 ```php
 // tests/Unit/EmailValidatorTest.php — RED
@@ -203,7 +203,7 @@ final class EmailValidator
 Run the filter again → passes. No additional rules (format, MX, length)
 until a next failing test drives them.
 
-### JS / Vitest
+### Example B — TypeScript / Vitest
 
 ```ts
 // src/retry.test.ts — RED
@@ -270,8 +270,8 @@ wait for their own failing tests.
 
 ## When to hand over to another skill
 
-* Quality tools, PHPStan, ECS, Rector → [`quality-tools`](../quality-tools/SKILL.md)
-* Full Pest conventions, Laravel testing helpers → [`pest-testing`](../pest-testing/SKILL.md)
+* Project type-checker / linter / formatter (PHPStan, ECS, Rector for PHP — tsc / eslint / prettier for TS — ruff / mypy for Python) → [`quality-tools`](../quality-tools/SKILL.md)
+* Full Pest conventions and Laravel test helpers → [`pest-testing`](../pest-testing/SKILL.md)
 * Running tests inside Docker → [`tests-execute`](../tests-execute/SKILL.md)
 * Investigating why a test is failing for non-obvious reasons →
   [`systematic-debugging`](../systematic-debugging/SKILL.md)

package/.agent-src/skills/test-performance/SKILL.md

@@ -3,6 +3,7 @@ name: test-performance
 description: "Use when optimizing test suite performance — database setup, seeder optimization, parallel testing, CI pipeline efficiency, or RefreshDatabase alternatives."
 source: package
 domain: quality
+framework: laravel
 ---
 
 # test-performance
@@ -16,7 +17,7 @@ Use this skill when:
 - Parallel testing needs optimization
 - Seeders need performance analysis
 - CI pipeline test jobs need to be faster
-- Investigating flaky tests caused by DB state
+- Investigating flaky tests caused by database state
 
 ## Procedure: Analyze test performance
 
@@ -56,7 +57,7 @@ Check these areas in order of typical impact:
 | **Migration count** | How many CREATE TABLE statements? | High if >20 |
 | **Schema dump** | Is `database/schema/` used? | High if missing |
 | **Seeder INSERT method** | Individual `save()` vs bulk insert? | Medium |
-| **Truncation** | Per-seeder truncate vs centralized? | Low (but → correctness issues) |
+| **Truncation** | Per-seeder truncate vs centralized? | Low (but causes correctness issues) |
 | **Connection discovery** | Dynamic `getPdo()` probing? | Low |
 | **Parallel worker setup** | Does each worker re-migrate? | High |
 
@@ -77,7 +78,7 @@ php artisan schema:dump --database=api_database
 #### B. Template DB Cloning (high ROI for parallel tests)
 
 Instead of each parallel worker running migrate+seed independently:
-1. Prepare ONE template DB (migrate + seed)
+1. Prepare ONE template database (migrate + seed)
 2. Clone template for each worker via mysqldump
 
 ```bash
@@ -93,7 +94,7 @@ mysqldump template_db | mysql worker_db_test_1
 
 #### C. Skip Migrate+Seed Flag (high ROI for local dev)
 
-Add a config flag to skip DB setup when DB is already prepared:
+Add a config flag to skip database setup when DB is already prepared:
 
 ```php
 // config/testing.php
@@ -159,7 +160,7 @@ Replace dynamic `getPdo()` probing with explicit config:
 ## Gotcha
 
 - Don't use RefreshDatabase when DatabaseTransactions suffices — full refresh is 10x slower.
-- The model forgets that parallel tests share the DB — use unique identifiers in test data.
+- The model forgets that parallel tests share the database — use unique identifiers in test data.
 - Seeder optimization has the highest ROI — a 2s seeder running 100 times = 200s wasted.
 - Don't add indexes to test databases just for test performance — the real fix is better test design.