@event4u/agent-config 2.25.0 → 2.26.0

package/.agent-src/skills/laravel-reverb/SKILL.md

@@ -16,12 +16,12 @@ Use this skill for anything specific to **Laravel Reverb** as the WebSocket serv
 - Pusher protocol compatibility questions
 
 For **general WebSocket patterns**, broadcasting events, channel authorization,
-and Laravel Echo client setup, see the [websocket](../websocket/SKILL.md) skill.
+and Laravel Echo client setup, see the [laravel-websocket](../laravel-websocket/SKILL.md) skill.
 
 ## Procedure: Set up Reverb
 
 1. **Install** — `php artisan install:broadcasting` or manual setup (see below).
-2. **Configure** — Set env variables for Reverb host, port, app credentials.
+2. **Configure** — Set environment variables for Reverb host, port, app credentials.
 3. **Start server** — `php artisan reverb:start`.
 4. **Connect client** — Configure Laravel Echo with Reverb credentials.
 5. **Verify** — Confirm WebSocket connection in browser console, test event delivery.
@@ -195,7 +195,7 @@ location /app {
 ## Gotcha
 
 - Reverb requires a persistent process — it's not compatible with serverless deployments.
-- The model forgets to configure the `REVERB_HOST` and `REVERB_PORT` env variables.
+- The model forgets to configure the `REVERB_HOST` and `REVERB_PORT` environment variables.
 - WebSocket connections bypass middleware — don't rely on session auth for channel authorization.
 
 ## Do NOT

package/.agent-src/skills/{websocket → laravel-websocket}/SKILL.md

@@ -1,11 +1,12 @@
 ---
-name: websocket
-description: "Use when building real-time features — WebSocket broadcasting, live updates, presence channels, connection state — even when the user just says 'push this to the client live'."
+name: laravel-websocket
+description: "Use when building Laravel real-time features — Broadcasting events, ShouldBroadcast, private/presence channels, Echo client. For non-Laravel WebSockets, use the stack-native skill."
 source: package
 domain: engineering
+framework: laravel
 ---
 
-# websocket
+# laravel-websocket
 
 ## When to use
 

package/.agent-src/skills/learning-to-rule-or-skill/SKILL.md

@@ -79,7 +79,7 @@ Before proceeding, the learning MUST pass all gates:
 | Minimal | Update existing preferred over creation? |
 
 If ANY gate fails → **stop**. Do not create or update anything.
-→ See `capture-learnings` rule for rejection criteria.
+Memory-entry rejection criteria live in `/memory:add` (see § "When to skip").
 
 ### 1. State the learning clearly
 

package/.agent-src/skills/merge-conflicts/SKILL.md

@@ -51,19 +51,29 @@ For each conflicted file:
 | Auto-generated files (OpenAPI spec, baselines) | **Regenerate** — resolve source, then regenerate the output |
 | Formatting-only conflicts | **Accept either** — then run quality tools to normalize |
 
-### 4. File-type specific rules
+### 4. File-type specific rules (stack-aware)
 
-#### PHP files
+#### Source files (any language)
 
-- After resolving, check that `use` statements are correct (no duplicates, no missing imports).
-- Verify the resolved code compiles: `php -l filename.php`
-- Run PHPStan on the file: `vendor/bin/phpstan analyse` (see `quality-tools` skill)
+- After resolving, check that import statements are correct (no duplicates, no missing imports). Applies to PHP `use`, JS/TS `import`, Python `import`, Go `import`, Rust `use`.
+- Verify the resolved file parses with the project's type-checker / linter on just the touched file:
+  - PHP: `php -l filename.php` then `vendor/bin/phpstan analyse path/to/file.php`
+  - TypeScript: `tsc --noEmit` (full project) or `eslint path/to/file.ts`
+  - Python: `python -m py_compile path/to/file.py` then `mypy path/to/file.py`
+  - Go: `go vet ./path/to/pkg/...`
+  - Rust: `cargo check`
 
-#### Migrations
+#### Database migrations
 
 - Never merge two migrations that modify the same table into one.
-- If both branches added migrations, keep both — adjust timestamps if they collide.
-- After resolving, run migrations to verify: `php artisan migrate --env=testing`
+- If both branches added migrations, keep both — adjust timestamps / ordering to avoid collision.
+- After resolving, run migrations against a disposable database to verify:
+  - Laravel: `php artisan migrate --env=testing`
+  - Symfony / Doctrine: `php bin/console doctrine:migrations:migrate --env=test --no-interaction`
+  - Node / Prisma: `pnpm prisma migrate dev --schema=...`
+  - Node / Knex: `pnpm knex migrate:latest --env test`
+  - Python / Alembic: `alembic upgrade head` (against a test DB URL)
+  - Go / golang-migrate: `migrate -path ./migrations -database "$TEST_DATABASE_URL" up`
 
 #### Config files
 
@@ -95,18 +105,40 @@ For each conflicted file:
 After resolving ALL conflicts:
 
 ```bash
-# 1. Check no conflict markers remain
-grep -rn "<<<<<<< \|======= \|>>>>>>> " --include="*.php" --include="*.js" --include="*.ts" .
+# 1. Check no conflict markers remain (stack-agnostic — no --include filter)
+grep -rn "<<<<<<< \|======= \|>>>>>>> " . \
+  --exclude-dir=node_modules --exclude-dir=vendor --exclude-dir=.git
+```
 
-# 2. Syntax check PHP files
-find . -name "*.php" -newer .git/MERGE_HEAD -exec php -l {} \;
+```bash
+# 2. Syntax-check changed files (stack-dependent — pick the row that matches the project)
+# PHP:    find . -name "*.php" -newer .git/MERGE_HEAD -exec php -l {} \;
+# TS:     tsc --noEmit
+# Python: python -m compileall -q .
+# Go:     go build ./...
+# Rust:   cargo check
+```
 
-# 3. Run quality tools
-vendor/bin/phpstan analyse
+```bash
+# 3. Run the project's quality tools — resolve via the quality-tools skill, Taskfile,
+#    package.json scripts, composer.json scripts, or Makefile. Examples per stack:
+# PHP:    vendor/bin/phpstan analyse
+# TS:     pnpm lint
+# Python: ruff check && mypy
+# Go:     golangci-lint run
+# Rust:   cargo clippy
+```
 
-# 4. Run tests
-php artisan test
+```bash
+# 4. Run tests — full suite, not just the touched files
+# PHP:    php artisan test    (or vendor/bin/pest)
+# TS:     pnpm test
+# Python: pytest
+# Go:     go test ./...
+# Rust:   cargo test
+```
 
+```bash
 # 5. Complete the merge/rebase
 git add .
 # Don't commit — let the user decide when to commit
@@ -156,4 +188,4 @@ git add .
 
 - Do NOT rebase or force-push without explicit permission.
 - Do NOT leave conflict markers (`<<<<<<<`) in any file.
-- Do NOT skip verification (PHPStan + tests) after resolving.
+- Do NOT skip verification (project type-checker + tests) after resolving.

package/.agent-src/skills/migration-architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: migration-architect
-description: "Use when shaping a non-trivial migration — rollout phases, dual-write windows, cutover sequencing, deprecation cycles — hands off to `migration-creator` for DDL once locked."
+description: "Use when shaping a non-trivial migration — rollout phases, dual-write windows, cutover sequencing, deprecation cycles — hands off to the framework-specific migration skill for DDL once locked."
 personas:
   - backend-architect
   - senior-engineer
@@ -13,8 +13,8 @@ domain: process
 > Shape the **rollout strategy** for a migration before any DDL or
 > code is written. Plans phases, dual-write windows, cutover
 > sequencing, deprecation cycles, and cross-service coordination.
-> Hands off to [`migration-creator`](../migration-creator/SKILL.md)
-> for tactical DDL once the plan is locked.
+> Hands off to [`laravel-migration`](../laravel-migration/SKILL.md)
+> (or the framework-native equivalent) for tactical DDL once the plan is locked.
 
 ## When to use
 
@@ -28,7 +28,7 @@ domain: process
 Do NOT use when:
 
 - The change is a single additive migration safe in one deploy →
-  route to [`migration-creator`](../migration-creator/SKILL.md).
+  route to [`laravel-migration`](../laravel-migration/SKILL.md) (or framework-native equivalent).
 - The decision is *whether* to migrate at all → route to
   [`decision-record`](../decision-record/SKILL.md) first.
 - The concern is data correctness during the migration → route to
@@ -100,7 +100,7 @@ Phases:
 Deprecation cycle (if any):
   Announce <duration>  →  soft-fail <duration>  →  hard-fail <duration>  →  remove
 
-Next: /migration-creator for the DDL of phase 1
+Next: /laravel-migration (or framework-native equivalent) for the DDL of phase 1
 ```
 
 ## Gotcha
@@ -112,7 +112,7 @@ Next: /migration-creator for the DDL of phase 1
 
 ## Do NOT
 
-- Do NOT write DDL — that is `migration-creator`'s job.
+- Do NOT write DDL — that is the framework-specific migration skill's job (`laravel-migration` for Laravel).
 - Do NOT collapse phases to "ship it" because the user is impatient;
   surface the risk and let the user decide.
 - Do NOT skip the deprecation cycle because nobody is using the old

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

@@ -3,6 +3,7 @@ name: module-management
 description: "Use when the user says "create module", "explore module", or works within app/Modules/. Understands module structure, auto-loading, route registration, and namespace conventions."
 source: package
 domain: process
+framework: laravel
 ---
 
 # module

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/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