@event4u/agent-config 1.20.0 → 1.22.0

package/.agent-src/skills/blast-radius-analyzer/SKILL.md

@@ -56,7 +56,7 @@ Run grep/search for the exact symbol, column, or event name. Enumerate:
 | DB references | Foreign keys, indexes, views, triggers on the column |
 | Config / docs | YAML, JSON, Markdown that name the symbol |
 
-### 3. Inspect indirect dependencies
+### 3. Inspect indirect deps
 
 For each direct dependency, identify second-order fan-out:
 
@@ -91,7 +91,7 @@ keys=<changed paths + changed symbol>, limit=5)`. Surface:
   the direct grep had no result.
 
 Memory entries are supplementary, never authoritative: a grep miss is
-still a grep miss. Do not infer dependencies from memory alone.
+still a grep miss. Do not infer deps from memory alone.
 
 ## Validation
 
@@ -102,8 +102,8 @@ Before finalizing the report, confirm:
 3. Second-order fan-out is bounded — any runaway chain is flagged, not expanded
 4. Every `external` reach has at least one named owner hint or an explicit
    "owner unknown — ask"
-5. You have NOT invented dependencies that grep did not find
-6. You have NOT merged direct and indirect dependencies — they are listed separately
+5. You have NOT invented deps that grep did not find
+6. You have NOT merged direct and indirect deps — they are listed separately
 
 ## Output format
 
@@ -143,10 +143,10 @@ Open questions:
 Required fields (ordered):
 
 1. **Skill** and **Change** — one-line edit summary
-2. **Direct dependencies** — grouped by class, each with file:line citations and exact counts
-3. **Indirect dependencies** — 2nd-order only, bounded
+2. **Direct deps** — grouped by class, each with file:line citations and exact counts
+3. **Indirect deps** — 2nd-order only, bounded
 4. **Reach summary** — counts per reach level
-5. **Risk surfaces** — dependencies grouped by risk type
+5. **Risk surfaces** — deps grouped by risk type
 6. **Open questions** — unresolved items with grep evidence
 
 Runtime confirmation (e.g. *"actually run the test suite to see what breaks"*,
@@ -172,7 +172,7 @@ does not execute code, run tests, or touch the network**.
 * NEVER return `safe` out of politeness when external reach exists — mark it clearly
 * NEVER silently fall back to "module-level impact" when grep shows cross-module callers
 * NEVER claim a dependency without a file:line citation from grep output
-* NEVER chase dependencies past 2nd order without explicit scope approval — flag and stop
+* NEVER chase deps past 2nd order without explicit scope approval — flag and stop
 
 ## References
 

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

@@ -2,6 +2,7 @@
 name: bug-analyzer
 description: "Use when the user shares a Sentry error, Jira bug ticket, or error description and wants root cause analysis. Also for proactive bug hunting and code audits for hidden bugs."
 source: package
+council_depth: deep
 ---
 
 # bug-analyzer
@@ -116,7 +117,7 @@ This is especially important for:
 
 - Find **working examples** of similar code paths in the codebase.
 - Compare the broken path against the working reference.
-- Identify the **specific difference** that causes the failure.
+- Identify the **specific difference** that → the failure.
 - Check if the issue is isolated or part of a broader pattern.
 
 ### Phase 3: Hypothesis and Testing
@@ -129,11 +130,11 @@ This is especially important for:
   - Each fix reveals new shared state or coupling in a different place.
   - Fixes require "massive refactoring" to implement.
   - Each fix creates new symptoms elsewhere.
-- Common root causes in this project:
+- Common root → in this project:
   - **Missing validation** on external sync data (CSV, XML, JSON imports).
   - **Null values** from optional DB columns not handled.
   - **Type mismatches** between legacy DB columns and PHP code.
-  - **Race conditions** in multi-tenant database switching.
+  - **Race conditions** in multi-tenant DB switching.
   - **Missing fallbacks** when external services are unavailable.
 
 ### Phase 4: Implementation
@@ -221,10 +222,10 @@ Focus on the "Bug fixes" attack questions: Is this the root cause or a symptom?
 |---|---|
 | "Should work now" | RUN the verification — confidence ≠ evidence |
 | "It's probably X, let me fix that" | "Probably" = guessing. Complete Phase 1 first |
-| "Quick fix for now" | Quick fixes mask root causes and create technical debt |
+| "Quick fix for now" | Quick fixes mask root → and create technical debt |
 | "I'll investigate later" | Later never comes. Investigate now |
 | "One more fix attempt" (after 2+) | 3+ failures = architectural problem. Stop and discuss |
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs |
+| "Issue is simple, don't need process" | Simple issues have root → too. Process is fast for simple bugs |
 | "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing |
 
 ## Output format

package/.agent-src/skills/code-refactoring/SKILL.md

@@ -33,7 +33,7 @@ Do NOT use when:
 - Rename, extract, move, or restructure the target code.
 - Keep the change minimal and focused.
 
-### Step 2: Update all downstream dependencies
+### Step 2: Update all downstream deps
 
 For each affected file (from the impact analysis):
 
@@ -141,9 +141,9 @@ After the code changes are verified, update all affected documentation:
 1. Update controller + request + resource + OpenAPI schemas + route → present test changes →
    update docs (`agents/docs/controller.md`, `agents/docs/api-resources.md`) → run PHPStan → run tests.
 
-### Replace implementation (e.g. switch service)
-1. Create new implementation → update binding → find all direct references → update → present test
-   changes → update docs → run PHPStan → run tests → remove old implementation.
+### Replace impl (e.g. switch service)
+1. Create new impl → update binding → find all direct references → update → present test
+   changes → update docs → run PHPStan → run tests → remove old impl.
 
 ### Move/restructure module
 1. Move files → update namespaces → update `ModuleServiceProvider` if needed → update module routes →

package/.agent-src/skills/code-review/SKILL.md

@@ -113,7 +113,7 @@ When receiving code review feedback, follow this sequence:
 6. **IMPLEMENT** — One item at a time, test each.
 
 If **any item is unclear**, STOP — do not implement anything yet. Items may be related;
-partial understanding leads to wrong implementation.
+partial understanding → wrong impl.
 
 ### No performative agreement
 
@@ -131,7 +131,7 @@ partial understanding leads to wrong implementation.
 **External / Copilot / bot feedback** (less context):
 - Check: Technically correct for THIS codebase?
 - Check: Does it break existing functionality?
-- Check: Is there a reason for the current implementation?
+- Check: Is there a reason for the current impl?
 - Check: Does the reviewer understand the full context?
 - **YAGNI check:** If the reviewer suggests "implementing properly", grep the codebase
   for actual usage. If unused → suggest removing (YAGNI).

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

@@ -114,6 +114,17 @@ Required sections in this order:
 * If the command calls external APIs, list required keys / permissions.
 * If the command edits agent files, target `.agent-src.uncompressed/` only.
 
+### 3b. Path conventions in command body
+
+Body links to guidelines / contracts use the verbatim relative form
+(`../../docs/guidelines/...`, `../../docs/contracts/...`); the
+compress-time rewriter handles depth. Do not pre-rewrite in source. Do
+not write `.agent-src.uncompressed/` in any markdown link target — the
+file ships into `.augment/commands/` and the prefix breaks consumer
+resolution. The only legitimate `.agent-src.uncompressed/` strings in a
+command file are prose mentions and step instructions about where to
+edit (per § 2 above). Canonical reference: `rule-writing` § 3b.
+
 ### 4. Enforce the size budget
 
 Normative source: [`size-enforcement`](../../rules/size-enforcement.md) +

package/.agent-src/skills/composer-packages/SKILL.md

@@ -148,7 +148,7 @@ Packages are published to a private Composer registry. Check the organization's
 ## Output format
 
 1. Package files following standard Composer structure
-2. Updated composer.json with correct autoloading and dependencies
+2. Updated composer.json with correct autoloading and deps
 3. Service provider and config publishing (if Laravel package)
 
 ## Auto-trigger keywords
@@ -167,6 +167,6 @@ Packages are published to a private Composer registry. Check the organization's
 
 - Do NOT use `*` version constraints in library packages.
 - Do NOT require specific patch versions — use `^` or `||` ranges.
-- Do NOT include dev dependencies in `require` — use `require-dev`.
+- Do NOT include dev deps in `require` — use `require-dev`.
 - Do NOT forget to run `composer validate` before publishing.
 - Do NOT publish without updating the changelog and tagging.

package/.agent-src/skills/context-authoring/SKILL.md

@@ -145,6 +145,17 @@ has to confirm or correct, not invent from scratch.
   `tenant-boundaries.md` SHOULD be deleted, not stubbed — the checklist
   explicitly says so at the top of the file.
 
+## Path conventions when a context cites another context
+
+If the context file declares its own `load_context:` (chain reasoning),
+use logical names rooted at the source — `contexts/<area>/<file>.md`
+for package material or `agents/contexts/<file>.md` for project-local
+material. The `.agent-src.uncompressed/` prefix is rejected by the
+schema regex and by `scripts/lint_load_context.py`. Body links to
+`docs/guidelines/...` use the verbatim `../../docs/...` relative form.
+Canonical reference: `rule-writing` § 3b and
+`docs/contracts/load-context-schema.md`.
+
 ## Do NOT
 
 - Do NOT copy content between projects. Every context file is local to its

package/.agent-src/skills/context-document/SKILL.md

@@ -59,7 +59,7 @@ app/Modules/{Module}/agents/contexts/    # Module-scoped contexts
 |---|---|---|
 | **Module** | Single module's structure and purpose | `client-software.md` |
 | **Domain** | Business domain across modules | `import-pipeline.md` |
-| **Service** | Complex service with its dependencies | `customer-service.md` |
+| **Service** | Complex service with its deps | `customer-service.md` |
 | **Integration** | External API/system integration | `probaus-api.md` |
 | **Infrastructure** | DevOps or infrastructure concern | `queue-system.md` |
 

package/.agent-src/skills/copilot-agents-optimization/SKILL.md

@@ -169,10 +169,33 @@ When the drift is severe (whole sections are wrong), recommend
 `/copilot-agents-init` to scaffold a clean replacement rather than
 patching forever.
 
+## agent-config Path Conventions — Preserve, Don't "Fix"
+
+`copilot-instructions.md` ships a "Known False Positives" section that
+tells Copilot Code Review not to flag agent-config path patterns as
+broken. When optimizing, **keep that section intact** — never delete
+it as "redundant" and never trim its bullets. The patterns it covers:
+
+- Relative cross-references inside `.augment/` rules / skills
+  (`../docs/guidelines/foo.md`, `../contexts/bar.md`) — paths resolve
+  from the file's delivered location, not from the symlink in
+  `.claude/rules/` etc. (per `road-to-path-fixes.md` Strategy A).
+- `path_prefix:` triggers containing `.agent-src.uncompressed/` —
+  literal match patterns, not file refs (per Modified Option 1,
+  P2.2).
+- Symlinked rule files under `.claude/rules/`, `.cursor/rules/`,
+  `.clinerules/` — targets resolve into `.augment/rules/`.
+
+If the consumer project's `copilot-instructions.md` is missing the
+section, **add it** during optimization using the canonical block
+from `.augment/templates/copilot-instructions.md`. Surfaces include
+`/copilot-agents init` and `/copilot-agents optimize`.
+
 ## Optimization Checklist
 
 When optimizing either file, check:
 
+- [ ] "Known False Positives" section present and unmodified?
 - [ ] No identifiers from other projects (FORBIDDEN_IDENTIFIERS blocklist)?
 - [ ] Tech stack claims match actual project dependencies?
 - [ ] All referenced commands/targets exist (Makefile, composer scripts, artisan, task)?

package/.agent-src/skills/copilot-config/SKILL.md

@@ -187,7 +187,7 @@ Copilot and Augment complement each other:
 ## Gotcha
 
 - copilot-instructions.md is for GitHub Copilot, NOT for Augment — don't mix audiences.
-- Don't duplicate .augment/ content into copilot-instructions.md — it bloats the file and causes drift.
+- Don't duplicate .augment/ content into copilot-instructions.md — it bloats the file and → drift.
 - Copilot reads the ENTIRE instructions file on every request — keep it under 500 lines.
 
 ## Do NOT

package/.agent-src/skills/dependency-upgrade/SKILL.md

@@ -11,7 +11,7 @@ source: package
 Use this skill when upgrading Composer packages, npm packages, or any project dependency.
 
 Do NOT use when:
-- Installing new dependencies for the first time
+- Installing new deps for the first time
 - Routine code changes unrelated to package versions
 
 ## Procedure: Upgrade a dependency
@@ -164,7 +164,7 @@ npm audit
 |---|---|---|
 | **Known CVEs** | `composer audit` / `npm audit` | Direct vulnerabilities |
 | **Maintenance status** | GitHub: last commit, open issues | Abandoned packages are a risk |
-| **Dependency tree** | `composer show -t vendor/pkg` / `npm ls new-package` | Transitive dependencies may conflict |
+| **Dependency tree** | `composer show -t vendor/pkg` / `npm ls new-package` | Transitive deps may conflict |
 | **License compatibility** | `composer licenses` / check `package.json` | Legal compliance |
 | **Bundle size** (npm) | `npx bundlephobia new-package` | Impact on frontend bundle |
 

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

@@ -18,7 +18,7 @@ Do NOT use when:
 
 1. **Gather context** — read `.devcontainer/devcontainer.json`, check `.devcontainer/` for env files and docs, check `agents/overrides/skills/devcontainer.md` for project-specific overrides.
 2. **Identify change type** — classify: image change, feature addition, secret addition, extension change, or env var change.
-3. **Make the change** — edit `devcontainer.json` (or related files). Follow conventions below for secrets, features, and environment variables.
+3. **Make the change** — edit `devcontainer.json` (or related files). Follow conventions below for secrets, features, and env variables.
 4. **Build and verify** — run `devcontainer build` to confirm the container builds. Check that extensions load and ports forward correctly.
 5. **Document** — if adding a new secret or dependency, update the onboarding docs in `.devcontainer/`.
 
@@ -92,7 +92,7 @@ Read `devcontainer.json` for the actual secret definitions and requirements.
 
 - DevContainer
 - Codespaces
-- dev environment
+- dev env
 - container setup
 
 ### Validate

package/.agent-src/skills/developer-like-execution/SKILL.md

@@ -217,7 +217,7 @@ Never load full output into context when a filter gives you the answer.
 
 Tests are mandatory when behavior changes or bugs are fixed.
 
-Prefer: failing test first → implementation → passing test.
+Prefer: failing test first → impl → passing test.
 
 Test types: unit (isolated logic), feature/integration (behavior), UI (frontend), regression (bugs).
 

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

@@ -227,7 +227,7 @@ RUN --mount=type=cache,target=/root/.npm \
 
 - All PHP commands (artisan, composer, phpunit) must run INSIDE the PHP container — never on the host.
 - The fast container and Xdebug container share the same codebase but have different PHP configs — don't confuse them.
-- `docker compose down -v` destroys volumes including the database — use `down` without `-v` unless you mean it.
+- `docker compose down -v` destroys volumes including the DB — use `down` without `-v` unless you mean it.
 - The model forgets to use `docker compose exec -T` (no TTY) when running in scripts or CI.
 
 ## Do NOT

package/.agent-src/skills/dto-creator/SKILL.md

@@ -101,7 +101,7 @@ Always check `composer.json` for DTO-related packages before choosing the approa
 
 - DTOs must extend `SimpleDto` — don't create plain PHP classes as DTOs.
 - The model forgets to add the model linkage (`$modelClass`) when the DTO maps to an Eloquent model.
-- Attribute names in the DTO must match the database column names (snake_case), not the PHP property names.
+- Attribute names in the DTO must match the DB column names (snake_case), not the PHP property names.
 
 ## Do NOT
 

package/.agent-src/skills/estimate-ticket/SKILL.md

@@ -65,7 +65,7 @@ Before producing numbers, check:
 - Is there a rollback plan implied?
 
 If the ticket scores low on estimability (vague AC, no out-of-scope,
-no mention of dependencies), set `uncertainty = Underspecified` and
+no mention of deps), set `uncertainty = Underspecified` and
 emit a single-line redirect to `/refine-ticket` at the top of the output.
 
 ### 3. Apply sizing heuristics
@@ -166,7 +166,7 @@ copy-paste instructions if missing.
 - Estimators default to optimism. Every size must cite evidence for at least one of the four axes — not "feels like M".
 - `Underspecified` is not a safe default. Use it only when estimability actually fails; otherwise pick a size and state the risk.
 - `Split: Yes` without concrete split points is useless. Name the slices or drop the recommendation.
-- Persona voices drift into general feedback. Each sentence must be about **sizing** — developer talks implementation size, stakeholder talks timeline fit, etc.
+- Persona voices drift into general feedback. Each sentence must be about **sizing** — developer talks impl size, stakeholder talks timeline fit, etc.
 - Story-point mapping (`S=2 / M=3 / L=5 / XL=8`) is the default; projects may override — do NOT hardcode their scale into this skill.
 
 ## Do NOT

package/.agent-src/skills/fe-design/SKILL.md

@@ -40,7 +40,7 @@ Do NOT use this skill to:
 `directives/ui/design.py` produces the design brief (layout, components,
 states, microcopy, a11y). The brief picks heuristics from this reference
 when the audit doesn't already pin a project pattern. Stack-specific
-choices come from the dispatched implementation skill, not from here.
+choices come from the dispatched impl skill, not from here.
 
 ## Component Architecture
 
@@ -203,7 +203,7 @@ When `directives/ui/design.py` (or any caller) cites this skill:
 1. **Confirm the audit ran first** — `state.ui_audit` from [`existing-ui-audit`](../existing-ui-audit/SKILL.md) is mandatory. Stop and request the audit if missing.
 2. **Pick the smallest matching section** — Component Architecture, Form Design, Table Design, Responsive Strategy, Accessibility, or UX Principles. Cite by H2/H3 heading, never paste the whole skill.
 3. **Defer to audit findings** — when the audit pins a project pattern (token, primitive, layout convention), use it. The heuristics here are fallbacks for gaps, not overrides.
-4. **Defer to the stack apply skill** — Blade vs. Livewire vs. Flux vs. React-shadcn choices come from the dispatched implementation skill, never from this reference.
+4. **Defer to the stack apply skill** — Blade vs. Livewire vs. Flux vs. React-shadcn choices come from the dispatched impl skill, never from this reference.
 5. **Surface conflicts** — if a heuristic here contradicts an audit finding or stack convention, name both and let the caller decide; do not silently pick.
 
 ## Output format
@@ -220,8 +220,8 @@ When this skill's content is folded into a design brief or review:
 - **Orchestrator:** [`directives/ui/`](../../templates/scripts/work_engine/directives/ui/) — owns the UI flow
 - **Pre-step (mandatory):** [`existing-ui-audit`](../existing-ui-audit/SKILL.md) — inventory before design
 - **Stack apply skills (dispatched, not standalone):**
-  - [`blade-ui`](../blade-ui/SKILL.md) — Blade template implementation
-  - [`livewire`](../livewire/SKILL.md) — Livewire component implementation
+  - [`blade-ui`](../blade-ui/SKILL.md) — Blade template impl
+  - [`livewire`](../livewire/SKILL.md) — Livewire component impl
   - [`flux`](../flux/SKILL.md) — Flux component library usage
   - [`react-shadcn-ui`](../react-shadcn-ui/SKILL.md) — React + shadcn primitives
 - **Adjacent reference:** [`dashboard-design`](../dashboard-design/SKILL.md) — monitoring dashboard design (different domain)

package/.agent-src/skills/feature-planning/SKILL.md

@@ -100,7 +100,7 @@ Discovery → Exploration → Questions → Architecture → Implementation →
 - **Wait for answers before proceeding.**
 
 #### Phase 4: Architecture Design
-- Design 2-3 implementation approaches with different tradeoffs:
+- Design 2-3 impl approaches with different tradeoffs:
   - **Minimal changes** — smallest change, maximum reuse.
   - **Clean architecture** — maintainability, elegant abstractions.
   - **Pragmatic balance** — speed + quality.
@@ -114,7 +114,7 @@ Discovery → Exploration → Questions → Architecture → Implementation →
 - Track progress via task list or roadmap.
 
 #### Phase 6: Quality Review
-- Review the implementation for:
+- Review the impl for:
   - Simplicity, DRY, elegance.
   - Bugs and correctness.
   - Convention adherence.
@@ -183,7 +183,7 @@ module's `agents/` directory:
 Before creating a feature plan, always:
 1. **Search the codebase** for related code, existing patterns, and affected areas.
 2. **Read module docs** if the feature touches a specific module.
-3. **Check existing features** in `agents/features/` for overlap or dependencies.
+3. **Check existing features** in `agents/features/` for overlap or deps.
 
 ### Be collaborative
 
@@ -194,7 +194,7 @@ Before creating a feature plan, always:
 
 ### Keep it navigational
 
-Feature plans are decision documents, not implementation guides.
+Feature plans are decision documents, not impl guides.
 Implementation details belong in roadmaps.
 
 ## Output format
@@ -221,6 +221,6 @@ Implementation details belong in roadmaps.
 
 - Do NOT create feature plans without user input — always collaborate.
 - Do NOT skip codebase research — always check what exists.
-- Do NOT put implementation steps in the feature plan — that's the roadmap's job.
+- Do NOT put impl steps in the feature plan — that's the roadmap's job.
 - Do NOT commit or push without permission.
 - Do NOT duplicate information from `AGENTS.md` or module docs.

package/.agent-src/skills/funnel-analysis/SKILL.md

@@ -97,4 +97,4 @@ Do NOT use for ranking features, valuation, or OKR decomposition (see Related Sk
 
 1. **`funnel-table.md`** — 5-stage funnel with cohort rates, 95% CI, and 12-week trend (sparkline or compact ASCII). One row per cohort week or month.
 2. **`segment-breakdown.md`** — table of the broken stage segmented by channel · device · plan · geo. Rates with CIs. Suspect segments highlighted.
-3. **`hypothesis-list.md`** — top 3 causes for the broken segment-stage with cheapest-falsification experiment per cause and an explicit prediction for the next measurement.
+3. **`hypothesis-list.md`** — top 3 → for the broken segment-stage with cheapest-falsification experiment per cause and an explicit prediction for the next measurement.

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

@@ -123,7 +123,7 @@ Then add these **Laravel-specific** checks:
 ## Config and environment
 
 - Read configuration from config files, not directly from `env()` outside config files.
-- Do not introduce new environment variables unless necessary.
+- Do not introduce new env variables unless necessary.
 - Reuse existing config structure and naming patterns.
 
 ## Database interaction

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

@@ -9,7 +9,7 @@ source: package
 ## When to use
 
 Use this skill when sending notifications to users or external systems:
-- Email, Slack, SMS, or database notifications
+- Email, Slack, SMS, or DB notifications
 - Custom notification channels
 - On-demand notifications (to non-user recipients)
 - Notification preferences and opt-out logic
@@ -19,7 +19,7 @@ For **Mailables** (complex email templates, attachments), see [laravel-mail](../
 ## Procedure: Create a notification
 
 1. **Generate class** — `php artisan make:notification InvoiceCreated`.
-2. **Choose channels** — Mail, database, Slack, or custom. Implement `via()`.
+2. **Choose channels** — Mail, DB, Slack, or custom. Implement `via()`.
 3. **Build content** — Implement `toMail()`, `toArray()`, etc. for each channel.
 4. **Queue it** — Add `ShouldQueue` interface for non-blocking delivery.
 5. **Verify** — Send test notification, confirm delivery on all channels.
@@ -154,15 +154,15 @@ public function via(object $notifiable): array
 - Notifiable
 - MailMessage
 - SlackMessage
-- database notification
+- DB notification
 
 ## Gotcha
 
 - Don't send notifications synchronously in request lifecycle — always queue them.
-- The model forgets to implement `toArray()` for database notifications — it throws silently.
+- The model forgets to implement `toArray()` for DB notifications — it throws silently.
 - `via()` method must return an array even for a single channel — `return ['mail']`, not `return 'mail'`.
 
 ## Do NOT
 
-- Do NOT store large objects in database notification `data` — use IDs and fetch on read.
+- Do NOT store large objects in DB notification `data` — use IDs and fetch on read.
 - Do NOT use notifications for complex emails — use [Mailables](../laravel-mail/SKILL.md) instead.

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

@@ -176,7 +176,7 @@ Feature::for($users)->load(['new-dashboard', 'advanced-reporting']);
 
 ## Gotcha
 
-- Feature flags in database driver require migration — don't forget `php artisan pennant:purge` for cleanup.
+- Feature flags in DB driver require migration — don't forget `php artisan pennant:purge` for cleanup.
 - The model tends to check flags without a scope — always pass the authenticated user or a default scope.
 - Don't nest feature flag checks — it makes the logic impossible to reason about.
 

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

@@ -126,9 +126,9 @@ Pulse::record('api_call', 'stripe', 250)  // type, key, value
 
 ## Core rules
 
-- **Trim old data** — configure retention to prevent database bloat.
+- **Trim old data** — configure retention to prevent DB bloat.
 - **Use sample rates** in production — not every request needs recording.
-- **Separate database** — consider a dedicated DB connection for Pulse data.
+- **Separate DB** — consider a dedicated DB connection for Pulse data.
 - **Restrict access** — always gate the dashboard behind authentication.
 - **Monitor what matters** — don't enable all recorders if you don't need them.
 
@@ -148,7 +148,7 @@ Pulse::record('api_call', 'stripe', 250)  // type, key, value
 
 ## Gotcha
 
-- Pulse stores data in the same database by default — configure a separate connection for production.
+- Pulse stores data in the same DB by default — configure a separate connection for production.
 - The model forgets that Pulse data is sampled, not exact — don't use it for billing or exact counts.
 - Custom recorders must be registered in a service provider — they don't auto-discover.
 
@@ -157,4 +157,4 @@ Pulse::record('api_call', 'stripe', 250)  // type, key, value
 - Do NOT expose the Pulse dashboard without authentication.
 - Do NOT set sample rate to 1.0 on high-traffic production — use 0.1 or lower.
 - Do NOT forget to run `pulse:check` for server metrics.
-- Do NOT store Pulse data in the main application database on large apps.
+- Do NOT store Pulse data in the main application DB on large apps.

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

@@ -20,7 +20,7 @@ and Laravel Echo client setup, see the [websocket](../websocket/SKILL.md) skill.
 ## Procedure: Set up Reverb
 
 1. **Install** — `php artisan install:broadcasting` or manual setup (see below).
-2. **Configure** — Set environment variables for Reverb host, port, app credentials.
+2. **Configure** — Set env 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.
@@ -194,7 +194,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` environment variables.
+- The model forgets to configure the `REVERB_HOST` and `REVERB_PORT` env variables.
 - WebSocket connections bypass middleware — don't rely on session auth for channel authorization.
 
 ## Do NOT

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

@@ -164,4 +164,4 @@ Schedule::command('reports:weekly')->weeklyOn(1, '07:00');
 - Do NOT add multiple cron entries — use Laravel's scheduler for everything.
 - Do NOT schedule heavy work directly — dispatch a queued job instead.
 - Do NOT forget `withoutOverlapping()` for tasks that may run longer than their interval.
-- Do NOT hardcode times — use environment-based config when schedules vary per environment.
+- Do NOT hardcode times — use environment-based config when schedules vary per env.

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

@@ -26,9 +26,9 @@ Use this skill when the user asks to create a database migration, add a column,
 
 ## Laravel projects
 
-### Multi-database architecture
+### Multi-DB architecture
 
-Some projects use multiple database connections. Check `config/database.php` for connections.
+Some projects use multiple DB connections. Check `config/database.php` for connections.
 
 | Check | How |
 |---|---|
@@ -36,9 +36,9 @@ Some projects use multiple database connections. Check `config/database.php` for
 | Migration directories | `database/migrations/` (default), check for additional directories |
 | Custom migrate commands | `php artisan list migrate` — look for project-specific commands |
 
-**Always determine which database the table belongs to before creating a migration.**
+**Always determine which DB the table belongs to before creating a migration.**
 
-### API database migration
+### API DB migration
 
 ```bash
 php artisan make:migration create_example_table
@@ -72,13 +72,13 @@ return new class extends Migration {
 };
 ```
 
-### Customer database migration
+### Customer DB migration
 
 ```bash
 php artisan make:migration:customer AddWeatherColumn --table=cl_lv_weather
 ```
 
-Customer database tables use the `cl_` prefix (e.g. `cl_user`, `cl_lv_weather`).
+Customer DB tables use the `cl_` prefix (e.g. `cl_user`, `cl_lv_weather`).
 
 ### Adding a column (with explicit connection)
 
@@ -152,7 +152,7 @@ Focus on the "Database migrations" attack questions: Can this destroy data? Is r
 
 ## Auto-trigger keywords
 
-- database migration
+- DB migration
 - create migration
 - table prefix
 - column naming

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

@@ -8,11 +8,11 @@ source: package
 
 ## When to use
 
-Use this skill when working with tenant-specific data, customer database connections, or any code that touches the dual-database architecture.
+Use this skill when working with tenant-specific data, customer database connections, or any code that touches the dual-DB architecture.
 
 
 Do NOT use when:
-- Single-database applications
+- Single-DB applications
 - Frontend-only changes
 
 ## Procedure: Work with multi-tenancy
@@ -32,7 +32,7 @@ Request → Identify Tenant (JWT / subdomain / API key)
         → All tenant queries use tenant connection
 ```
 
-### Dual-database pattern
+### Dual-DB pattern
 
 | Connection type | Purpose | Scope |
 |---|---|---|
@@ -53,7 +53,7 @@ Search the codebase for the service responsible for tenant switching. Typical re
 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 database connection with tenant credentials
+4. Reconfigure the DB connection with tenant credentials
 5. Bind tenant-specific services via the container
 
 ## Model conventions
@@ -89,7 +89,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 database may consolidate multiple connections into a single DB for simplicity.
+- The testing DB 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
@@ -111,19 +111,19 @@ Check the project for the actual connection names and namespace conventions.
 
 - multi-tenant
 - tenant isolation
-- customer database
+- customer DB
 - FQDN routing
 
 ## Gotcha
 
-- Always verify which database connection is active before running queries — cross-tenant data leaks are critical bugs.
+- Always verify which DB 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 database names — always use connection names.
+- Do NOT hardcode DB 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.