@event4u/agent-config 2.24.0 → 2.26.0

package/.agent-src/skills/multi-tenancy/SKILL.md

@@ -3,17 +3,22 @@ name: multi-tenancy
 description: "Use when working with the multi-tenant architecture — customer DB switching, FQDN routing, tenant isolation, or cross-tenant operations."
 source: package
 domain: engineering
+framework: laravel
 ---
 
+<!-- Framework scope: Laravel only. Uses Eloquent model conventions,
+     Laravel Context, and Artisan traits — concepts not portable across
+     frameworks. Other stacks need a stack-native multi-tenancy skill. -->
+
 # multi-tenancy
 
 ## When to use
 
-Use this skill when working with tenant-specific data, customer database connections, or any code that touches the dual-DB architecture.
+Use this skill when working with tenant-specific data, customer database connections, or any code that touches the dual-database architecture.
 
 
 Do NOT use when:
-- Single-DB applications
+- Single-database applications
 - Frontend-only changes
 
 ## Procedure: Work with multi-tenancy
@@ -33,7 +38,7 @@ Request → Identify Tenant (JWT / subdomain / API key)
         → All tenant queries use tenant connection
 ```
 
-### Dual-DB pattern
+### Dual-database pattern
 
 | Connection type | Purpose | Scope |
 |---|---|---|
@@ -49,12 +54,14 @@ Projects may have additional connections for admin operations, provisioning, or
 
 ## Core tenant switching service
 
+**Scope**: Laravel-specific (see frontmatter). For non-Laravel multi-tenant systems, the concepts below still apply but the implementation differs — consult the framework's connection / session / DI conventions.
+
 Search the codebase for the service responsible for tenant switching. Typical responsibilities:
 
 1. Store tenant context (e.g., in Laravel Context or a singleton)
 2. Load tenant configuration
 3. Set monitoring context (tenant ID, name, domain)
-4. Reconfigure the DB connection with tenant credentials
+4. Reconfigure the database connection with tenant credentials
 5. Bind tenant-specific services via the container
 
 ## Model conventions
@@ -90,7 +97,7 @@ Check the project for the actual connection names and namespace conventions.
 ## Testing with tenants
 
 - Tests use dedicated tenant seeders (check `agents/docs/` for seeder conventions).
-- The testing DB may consolidate multiple connections into a single DB for simplicity.
+- The testing database may consolidate multiple connections into a single DB for simplicity.
 - Use `RefreshDatabase` or manual seeding — never assume a specific tenant state from previous tests.
 
 ## Common pitfalls
@@ -112,19 +119,19 @@ Check the project for the actual connection names and namespace conventions.
 
 - multi-tenant
 - tenant isolation
-- customer DB
+- customer database
 - FQDN routing
 
 ## Gotcha
 
-- Always verify which DB connection is active before running queries — cross-tenant data leaks are critical bugs.
+- Always verify which database connection is active before running queries — cross-tenant data leaks are critical bugs.
 - The model forgets to switch back to the main connection after tenant operations.
 - Queue jobs serialize the connection state — ensure the tenant context is restored when the job runs.
 - Don't use `DB::connection()` directly — use the tenant switching helpers.
 
 ## Do NOT
 
-- Do NOT hardcode DB names — always use connection names.
+- Do NOT hardcode database names — always use connection names.
 - Do NOT assume `customer_database` is available in service providers or early boot.
 - Do NOT access tenant data in global middleware that runs before customer identification.
 - Do NOT store tenant DB credentials in code — they come from the `customer_databases` table.

package/.agent-src/skills/pest-testing/SKILL.md

@@ -283,6 +283,24 @@ When generating Pest tests:
 - keep tests readable, isolated, and maintainable
 
 
+### Filter Pest output
+
+When triaging a verbose run, narrow the output with `--filter` (Pest)
+plus targeted `grep`/`rg` instead of re-running the whole suite or
+echoing all logs:
+
+```bash
+# Only run failing tests in one file
+vendor/bin/pest tests/Feature/InvoiceTest.php --filter='creates invoice'
+
+# Scan the test log for failures only
+rg --color=never '^FAIL|Tests:' storage/logs/pest.log
+
+# Inspect JSON output from data-driven tests
+vendor/bin/pest --log-junit=pest.xml && rg '<failure' pest.xml
+```
+
+
 ## Output format
 
 1. Pest test file with descriptive test names and clear assertions

package/.agent-src/skills/php-debugging/SKILL.md

@@ -130,6 +130,20 @@ make console-xdebug    # Enter Xdebug container
 php artisan your:command   # Xdebug connects to IDE automatically
 ```
 
+### Verifying CLI fixes
+
+After a fix, verify the command without re-attaching the debugger:
+
+```bash
+# Run the command, capture exit code + command output
+php artisan your:command; echo "exit code: $?"
+
+# Pest CLI assertion — expectsOutput / artisan test
+vendor/bin/pest --filter='ProcessInvoicesCommand'
+```
+
+Assert on the **exit code** and **command output**; never trust "looks fine" from breakpoint inspection alone.
+
 ## Troubleshooting
 
 | Problem | Solution |
@@ -151,6 +165,20 @@ make rebuild-php-xdebug   # Rebuild Xdebug container only
 make rebuild-php-all      # Rebuild both PHP containers
 ```
 
+### Filter noisy debug output
+
+`tail -f /tmp/xdebug.log` and `docker logs` produce far too much
+data to read line-by-line. Filter with `rg`/`grep` for the relevant
+event:
+
+```bash
+# Only connection / breakpoint events
+rg --color=never 'Connect|Step|breakpoint' /tmp/xdebug.log
+
+# Only this request's frames in the laravel log
+docker compose logs php-xdebug | rg --color=never "$REQUEST_ID"
+```
+
 ## What NOT to do
 
 - Do not leave Xdebug enabled in production containers.

package/.agent-src/skills/php-service/SKILL.md

@@ -13,7 +13,7 @@ Use when creating a new service, extracting business logic from a controller, or
 
 Do NOT use when:
 - Controllers (use `laravel` skill)
-- DTOs (use `dto-creator` skill)
+- DTOs (use `laravel-dto` skill for Laravel/PHP; framework-native skill for other stacks)
 - Models (use `eloquent` skill)
 
 ## When to create a service
@@ -39,7 +39,7 @@ Do NOT use when:
 1. Location: `app/Services/{Domain}/` or `app/Modules/{Module}/App/Services/`.
 2. `declare(strict_types=1)`, proper namespace.
 3. Constructor inject dependencies (repositories, other services).
-4. Max 4 constructor deps — if more, split the service.
+4. Max 4 constructor dependencies — if more, split the service.
 
 ### Step 2: Implement methods
 
@@ -70,7 +70,7 @@ public function __invoke(
 
 - Run PHPStan on the service — must pass at level 9.
 - Verify single responsibility: service does one thing, no mixed concerns.
-- Confirm all deps are constructor-injected (no `app()` or facades in service).
+- Confirm all dependencies are constructor-injected (no `app()` or facades in service).
 - Run affected tests — must pass.
 
 ## Output format

package/.agent-src/skills/pixar-storyteller/SKILL.md

@@ -1,18 +1,19 @@
 ---
 name: pixar-storyteller
 description: "Use when turning an idea into a Pixar-style animation prompt — character sheet, scene, image, video — anchored in emotional beat, want, obstacle. Triggers 'Pixar prompt', 'animated scene'."
-personas:
-  - pixar-storyboard-artist
 source: package
 domain: product
 ---
 
 # pixar-storyteller
 
-> Turn an animation beat into the **four-block storyboard** the
-> `pixar-storyboard-artist` persona ships: CHARACTER SHEET · SCENE
-> PROMPT · IMAGE PROMPT · VIDEO PROMPT. Output is provider-agnostic;
-> provider tuning is [`motion-choreographer`](../motion-choreographer/SKILL.md).
+> Turn an animation beat into the **four-block storyboard**:
+> CHARACTER SHEET · SCENE PROMPT · IMAGE PROMPT · VIDEO PROMPT.
+> Output is provider-agnostic; provider tuning is
+> [`motion-choreographer`](../motion-choreographer/SKILL.md).
+>
+> The acting / storyboard lens is enforced inline by the procedure
+> and self-review below.
 
 ## When to use
 
@@ -105,3 +106,15 @@ Any "no" → revise that block.
 - Do NOT emit provider-specific tokens — that is `motion-choreographer`.
 - Do NOT cite "Pixar-style" without a specific film + year.
 - Do NOT compound emotional beats ("sad but hopeful and tired").
+
+## Policies
+
+The Pixar-storyteller skill anchors prompts to named films and studios by design — the policy surface is the largest in the video cluster:
+
+- [`agents/policies/media/style.md`](../../../agents/policies/media/style.md) — naming a film + year as the *primary* anchor crosses the "in the style of [STUDIO]" trigger; surface and refuse without a transformative-intent rationale.
+- [`agents/policies/media/likeness.md`](../../../agents/policies/media/likeness.md) — when a beat references a named animator's signature character (real-person extension of style).
+- [`agents/policies/media/public-figures.md`](../../../agents/policies/media/public-figures.md) — when the storyteller's character is a recognised public figure rendered in Pixar shape.
+- [`agents/policies/media/disclosure.md`](../../../agents/policies/media/disclosure.md) — every Pixar-style output ships with the AI-generation disclosure; parody / commentary cases are flagged for human review.
+
+Refuse-and-surface when style ⇒ primary signature, not one influence among several.
+

package/.agent-src/skills/playwright-testing/SKILL.md

@@ -18,7 +18,6 @@ Use this skill when:
 - Configuring Playwright for CI/CD
 
 **Guideline:** `../../../docs/guidelines/e2e/playwright.md` — full conventions, config templates, CI setup.
-**Rule:** `.augment/rules/e2e-testing.md` — constraints enforced during E2E test work.
 **Mobile:** for native iOS/Android or React Native E2E, do NOT reuse Playwright — see the `mobile-e2e-strategy` skill for framework selection.
 
 ## Procedure: Write Playwright tests
@@ -164,6 +163,22 @@ npx playwright show-report
 npx playwright test -g "should login"
 ```
 
+### Filter noisy Playwright output
+
+Use `--grep`, `--reporter=json`, plus `jq`/`rg` to keep diagnosis scoped:
+
+```bash
+# Targeted run — only matching specs
+npx playwright test --grep '@smoke'
+
+# JSON report, narrowed to failures via jq
+npx playwright test --reporter=json > pw.json
+jq '.suites[].specs[] | select(.tests[].results[].status=="failed")' pw.json
+
+# Scan trace logs for one selector
+rg --color=never 'getByRole.*Submit' test-results/
+```
+
 ## Avoiding flaky tests
 
 | Problem | Solution |

package/.agent-src/skills/project-analyzer/SKILL.md

@@ -171,47 +171,73 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 ## Detection checklist
 
-### Framework & language
-
-| Check                 | How to detect                                 |
-|-----------------------|-----------------------------------------------|
-| PHP version           | `composer.json` → `require.php`               |
-| Laravel version       | `composer.json` → `require.laravel/framework` |
-| Laravel or standalone | `artisan` file exists → Laravel               |
-| Node.js               | `package.json` exists                         |
-| Frontend framework    | `package.json` → Vue, React, etc.             |
-| TypeScript            | `tsconfig.json` exists                        |
+### Framework & language (multi-stack)
+
+| Check                  | How to detect                                                                |
+|------------------------|------------------------------------------------------------------------------|
+| PHP runtime + version  | `composer.json` → `require.php`                                              |
+| Laravel application    | `artisan` file at repo root + `laravel/framework` in `composer.json`         |
+| Symfony application    | `bin/console` + `symfony/framework-bundle` in `composer.json`                |
+| Composer package       | `composer.json` without `artisan` / `bin/console`                            |
+| Node.js runtime        | `package.json` exists                                                        |
+| TypeScript             | `tsconfig.json` exists                                                       |
+| Frontend framework     | `package.json` → `react`, `vue`, `svelte`, `solid`, `astro`, `@angular/core` |
+| Meta-framework         | `package.json` → `next`, `nuxt`, `remix`, `sveltekit`, `astro`               |
+| Python runtime         | `pyproject.toml`, `requirements.txt`, `setup.py`, or `Pipfile`               |
+| Python framework       | `pyproject.toml` / `requirements.txt` → `django`, `fastapi`, `flask`         |
+| Go module              | `go.mod` exists                                                              |
+| Rust crate / workspace | `Cargo.toml` exists                                                          |
+| Ruby app               | `Gemfile` → `rails`, `sinatra`                                               |
+| .NET project           | `*.csproj`, `*.fsproj`, or `global.json`                                     |
+| Java / Kotlin          | `pom.xml`, `build.gradle`, or `build.gradle.kts`                             |
+
+After detecting **any** match, record the stack in the analysis output and select the matching `project-analysis-*` sub-skill (Laravel, Symfony, Next.js, React, Node/Express, Zend/Laminas) — fall back to `project-analysis-core` if no framework-specific sub-skill applies.
 
 ### Project type
 
-| Signal                             | Type                           |
-|------------------------------------|--------------------------------|
-| `artisan` + `laravel/framework`    | Laravel application            |
-| `composer.json` without `artisan`  | Composer package or legacy PHP |
-| Module system (`app/Modules/`)     | Modular Laravel                |
-| Multi-tenant (`customer_database`) | Multi-tenant SaaS              |
-
-### Legacy indicators
-
-| Signal                                     | Meaning                   |
-|--------------------------------------------|---------------------------|
-| No `declare(strict_types=1)` in most files | Legacy codebase           |
-| No typed properties / return types         | Legacy PHP (< 7.4)        |
-| `var_dump()` / `print_r()` in code         | Legacy debugging patterns |
-| No tests or very few tests                 | Low test coverage         |
-| No PHPStan / Rector config                 | No static analysis        |
-| Mixed naming conventions                   | Inconsistent standards    |
-
-### Build & tooling
-
-| Check         | How to detect                                             |
-|---------------|-----------------------------------------------------------|
-| Task runner   | `Makefile` or `Taskfile.yml`                              |
-| Docker        | `docker-compose.yml` or `compose.yaml`                    |
-| CI/CD         | `.github/workflows/`                                      |
-| Quality tools | `phpstan.neon`, `ecs.php`, `rector.php`, or `config-dev/` |
-| Editor config | `.editorconfig`                                           |
-| Code review   | `CODEOWNERS`, PR templates                                |
+| Signal                                                                | Type                                  |
+|-----------------------------------------------------------------------|---------------------------------------|
+| `artisan` + `laravel/framework`                                       | Laravel application                   |
+| `bin/console` + `symfony/framework-bundle`                            | Symfony application                   |
+| `composer.json` without `artisan` / `bin/console`                     | Composer package or legacy PHP        |
+| `package.json` with `next` / `nuxt` / `remix` / `sveltekit` / `astro` | Meta-framework SSR/SSG app            |
+| `package.json` with `express` / `fastify` / `koa` / `hapi`            | Node HTTP service                     |
+| `package.json` with `@nestjs/core`                                    | NestJS application                    |
+| `pyproject.toml` with `django` / `fastapi` / `flask`                  | Python web app                        |
+| `go.mod` with `gin-gonic/gin` / `labstack/echo` / `gofiber/fiber`     | Go HTTP service                       |
+| Module system (`app/Modules/`, `src/modules/`, `packages/*`)          | Modular monolith / monorepo           |
+| Multi-tenant signal (`customer_database`, tenant middleware, `RLS`)   | Multi-tenant SaaS                     |
+| `apps/*` + `packages/*` + `turbo.json` / `nx.json` / `pnpm-workspace` | Monorepo                              |
+
+### Legacy indicators (stack-aware)
+
+| Signal                                                                       | Meaning                       |
+|------------------------------------------------------------------------------|-------------------------------|
+| PHP: no `declare(strict_types=1)` in most files                              | Pre-modern PHP style          |
+| PHP: no typed properties / return types                                      | Legacy PHP (< 7.4)            |
+| PHP: no `phpstan.neon` / `rector.php`                                        | No static analysis            |
+| TS: `// @ts-ignore` / `// @ts-nocheck` density; `any` widespread             | Untyped TypeScript            |
+| TS: no `tsconfig.json` `strict: true`                                        | Loose TypeScript              |
+| JS: no ESLint config or `eslint.config.*`                                    | No linting                    |
+| Python: no type hints in most signatures; no `py.typed`                      | Untyped Python                |
+| Python: no `mypy.ini` / `pyrightconfig.json` / `ruff.toml`                   | No static analysis            |
+| Go: no `golangci.yml`                                                        | No lint pipeline              |
+| Rust: no `clippy.toml` and warnings ignored                                  | No lint hygiene               |
+| `var_dump()` / `console.log()` / `print()` / `fmt.Println()` left in code   | Legacy debugging patterns     |
+| No tests or very few tests                                                   | Low test coverage             |
+| Mixed naming conventions across the same module                              | Inconsistent standards        |
+
+### Build & tooling (stack-agnostic)
+
+| Check         | How to detect                                                                                                                                                       |
+|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Task runner   | `Makefile`, `Taskfile.yml`, `justfile`, `package.json scripts`, `composer.json scripts`                                                                             |
+| Docker        | `docker-compose.yml`, `compose.yaml`, `Dockerfile`                                                                                                                  |
+| CI/CD         | `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/config.yml`, `azure-pipelines.yml`                                                                               |
+| Quality tools | PHP: `phpstan.neon`, `ecs.php`, `rector.php`. TS/JS: `eslint.config.*`, `.prettierrc*`, `tsconfig.json`. Python: `ruff.toml`, `mypy.ini`. Go: `.golangci.yml`. Rust: `clippy.toml` |
+| Editor config | `.editorconfig`                                                                                                                                                     |
+| Code review   | `CODEOWNERS`, PR templates (`.github/pull_request_template.md`)                                                                                                     |
+| Dependencies  | Lockfile presence: `composer.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `poetry.lock`, `uv.lock`, `go.sum`, `Cargo.lock`                            |
 
 ## Analysis phases
 
@@ -234,7 +260,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 ### Phase 3: Data layer
 
 - List all models with their connections, tables, and key relationships
-- Map DB schema: tables, foreign keys, indexes
+- Map database schema: tables, foreign keys, indexes
 - Document multi-tenant split (which tables in which DB)
 - **Output:** `agents/analysis/models/api-database.md`, `customer-database.md`
 
@@ -243,7 +269,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 - Identify domains from models, services, routes, and directory structure
 - For each domain: map models → services → controllers → jobs → events
 - Document business rules and data flows
-- Document inter-domain deps
+- Document inter-domain dependencies
 - **Output:** `agents/analysis/domains/{domain}.md` (one per domain)
 
 ### Phase 5: API surface
@@ -255,7 +281,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 ### Phase 6: Service map
 
-- List all services with purpose, key methods, and deps
+- List all services with purpose, key methods, and dependencies
 - Map service → repository → model relationships
 - Identify God services (too many responsibilities)
 - **Output:** `agents/analysis/services/service-map.md`
@@ -316,7 +342,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 ## Output format
 
 1. Structured analysis document in agents/analysis/
-2. Tech stack inventory with versions and deps
+2. Tech stack inventory with versions and dependencies
 3. Architecture diagram or module map
 
 ## Auto-trigger keywords

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/roadmap-writing/SKILL.md

@@ -137,6 +137,16 @@ to every roadmap you author.
   user (`commit-policy` Iron Law). A roadmap is "implementation-complete"
   once its checkboxes are ticked and verification has been run — merge
   timing is tracked outside the roadmap.
+* Schedule full-pipeline CI literals (`task ci`, `task ci-fast`,
+  `task ci-strict`, `make ci`, `make test`, `npm/pnpm run check`,
+  `yarn check`, `composer test`, whole-suite `vendor/bin/phpunit`,
+  whole-suite `php artisan test`) as checkbox steps when
+  `quality.local_auto_run: false` — blocked by
+  `task lint-roadmap-ci-steps` per
+  [`roadmap-ci-steps-policy`](../../rules/roadmap-ci-steps-policy.md).
+  Reword as narrow verifications, or mark with
+  `<!-- carve-out: new-gate-verification -->` when it verifies a NEW
+  gate this roadmap introduces.
 * Use ALL-CAPS Iron-Law fenced blocks — those belong in
   [`kernel-membership`](../../../docs/contracts/kernel-membership.md)-listed
   rules, not roadmaps.

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.