@event4u/agent-config 1.20.0 → 1.21.0

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.

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

@@ -80,7 +80,7 @@ Focus on code paths with high execution frequency or large data volumes:
 - Missing CDN for static assets
 - Missing response caching for read-heavy endpoints
 - Database connection pooling and limits
-- Queue worker concurrency vs database connection limits
+- Queue worker concurrency vs DB connection limits
 
 ## Output format
 
@@ -101,12 +101,12 @@ For each bottleneck:
 - **performance** — complementary: performance is about writing fast code, this is about finding slow code
 - **test-performance** — for test suite speed specifically
 - **bug-analyzer** — some performance issues are actually bugs (N+1, infinite loops)
-- **database** — for deep DB optimization guidance
+- **DB** — for deep DB optimization guidance
 
 ## Gotcha
 
 - Don't present raw numbers without context — "200ms" means nothing without knowing the baseline.
-- The model tends to focus on code-level optimization when the bottleneck is a database query.
+- The model tends to focus on code-level optimization when the bottleneck is a DB query.
 - Profiling in development differs from production — different data volumes, different query plans.
 
 ## Do NOT

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

@@ -53,9 +53,9 @@ For bug fixes and new features, prefer test-driven development:
 
 ### Why test-first matters
 
-Tests written **after** implementation pass immediately. Passing immediately proves nothing:
+Tests written **after** impl pass immediately. Passing immediately proves nothing:
 - The test might test the wrong thing.
-- The test might test implementation, not behavior.
+- The test might test impl, not behavior.
 - You never saw it catch the bug — so you don't know if it would.
 
 ### Bug fix TDD
@@ -120,7 +120,7 @@ The test proves the fix works AND prevents regression.
 - For JSON APIs, assert:
     - exact relevant fields
     - error structure when applicable
-    - database state after the request
+    - DB state after the request
 - Do not only assert `200` — verify meaningful behavior.
 
 ## Validation tests
@@ -258,7 +258,7 @@ When reviewing or auditing existing tests, check for these anti-patterns:
 
 - Do not test private methods directly.
 - Do not over-mock Laravel internals.
-- Do not assert implementation details when behavior assertions are enough.
+- Do not assert impl details when behavior assertions are enough.
 - Do not write brittle tests tied to formatting or irrelevant response noise.
 - Do not create giant tests that cover many behaviors at once.
 - Do not skip authorization or validation coverage for important endpoints.
@@ -285,7 +285,7 @@ When generating Pest tests:
 - Don't use `readonly` or `final` on Pest test helper classes — it breaks mocking.
 - Don't add `use` statements for global classes (`Exception`, `DateTimeImmutable`) in Pest files — they're auto-imported.
 - The model forgets `$this->travel(5)->seconds()` for time-dependent tests — never rely on `now()` differing between lines.
-- Parallel tests share the database — don't assume column values are null unless you explicitly set them.
+- Parallel tests share the DB — don't assume column values are null unless you explicitly set them.
 
 ## Do NOT
 
@@ -297,7 +297,7 @@ When generating Pest tests:
 When generating new tests, focus on:
 - **Business logic**: calculations, status transitions, validation rules, data transformations
 - **Edge cases**: null, empty string, zero, negative numbers, boundary values, max length
-- **Error paths**: invalid input, missing dependencies, exception handling
+- **Error paths**: invalid input, missing deps, exception handling
 - **Different code branches**: if/else, early returns, fallback behavior
 
 What NOT to test:

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

@@ -38,7 +38,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 dependencies — if more, split the service.
+4. Max 4 constructor deps — if more, split the service.
 
 ### Step 2: Implement methods
 
@@ -69,7 +69,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 dependencies are constructor-injected (no `app()` or facades in service).
+- Confirm all deps are constructor-injected (no `app()` or facades in service).
 - Run affected tests — must pass.
 
 ## Output format

package/.agent-src/skills/project-analysis-hypothesis-driven/SKILL.md

@@ -11,7 +11,7 @@ source: package
 Use this skill when:
 
 * There is a concrete issue to explain
-* Multiple root causes are plausible
+* Multiple root → are plausible
 * The system spans several layers
 * A shallow single-explanation answer would be risky
 * `universal-project-analysis` or `bug-analyzer` routes here
@@ -27,7 +27,7 @@ Do NOT use when:
 * Never stop at the first plausible explanation
 * Code, docs, and evidence beat intuition
 * Rejected hypotheses matter
-* Multiple interacting causes are common
+* Multiple interacting → are common
 * Uncertainty must be marked explicitly
 
 ## Procedure
@@ -89,7 +89,7 @@ Ask:
 
 * does this fully explain the behavior?
 * what remains unexplained?
-* could multiple causes interact?
+* could multiple → interact?
 * does contradictory evidence exist?
 
 If anything major remains unexplained: continue analysis, do not present a final conclusion yet.

package/.agent-src/skills/project-analysis-react/SKILL.md

@@ -107,7 +107,7 @@ Check:
 ## Gotcha
 
 * React bugs often come from stale state, not broken logic.
-* Missing dependencies in hooks are one of the most common root causes.
+* Missing deps in hooks are one of the most common root causes.
 * Overusing memoization can make code harder to reason about without solving real problems.
 
 ## Do NOT

package/.agent-src/skills/project-analysis-symfony/SKILL.md

@@ -34,7 +34,7 @@ Do NOT use when:
 ### 1. Confirm Symfony version and app shape
 
 Check: `composer.lock`, `composer.json`, Symfony packages/components, PHP version, environment config structure.
-Validate: Symfony version is explicit, major bundles/components are identified, environment-specific config layout is known.
+Validate: Symfony version is explicit, major bundles/components are identified, env-specific config layout is known.
 
 ### 2. Analyze kernel and container boot
 

package/.agent-src/skills/project-analysis-zend-laminas/SKILL.md

@@ -44,7 +44,7 @@ Check:
 
 * merge order surprises
 * missing overrides
-* environment config mismatches
+* env config mismatches
 * heavy bootstrap logic
 
 ### 3. Analyze ServiceManager behavior
@@ -96,7 +96,7 @@ Check:
 ## Gotcha
 
 * Many Zend/Laminas issues are caused by config order and service resolution, not controller code.
-* Shared services and legacy migration remnants can create cross-request or environment-specific bugs.
+* Shared services and legacy migration remnants can create cross-request or env-specific bugs.
 * Old project behavior may depend on historical bootstrap side effects that are easy to miss.
 
 ## Do NOT

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

@@ -233,7 +233,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 database schema: tables, foreign keys, indexes
+- Map DB schema: tables, foreign keys, indexes
 - Document multi-tenant split (which tables in which DB)
 - **Output:** `agents/analysis/models/api-database.md`, `customer-database.md`
 
@@ -242,7 +242,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 dependencies
+- Document inter-domain deps
 - **Output:** `agents/analysis/domains/{domain}.md` (one per domain)
 
 ### Phase 5: API surface
@@ -254,7 +254,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 ### Phase 6: Service map
 
-- List all services with purpose, key methods, and dependencies
+- List all services with purpose, key methods, and deps
 - Map service → repository → model relationships
 - Identify God services (too many responsibilities)
 - **Output:** `agents/analysis/services/service-map.md`
@@ -315,7 +315,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 dependencies
+2. Tech stack inventory with versions and deps
 3. Architecture diagram or module map
 
 ## Auto-trigger keywords

package/.agent-src/skills/prompt-optimizer/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: prompt-optimizer
+description: "Use when the user wants a prompt optimized for ChatGPT, Claude, Gemini, or another AI — 'make this prompt better', 'optimize for ChatGPT', 'rewrite my prompt' — even without saying 'optimize'."
+source: package
+---
+
+# prompt-optimizer
+
+> Persona: **Lyra** — a master-level prompt-optimization specialist. Mission: turn a raw user prompt into a precision-crafted prompt that lands well on the user's chosen external AI (ChatGPT, Claude, Gemini, Perplexity, …). Sibling of [`refine-prompt`](../refine-prompt/SKILL.md) which is engine-inbound; this skill is engine-outbound (the polished prompt is text the user will paste elsewhere).
+
+## When to use
+
+- The user pastes a rough prompt and asks for it to be optimized, rewritten, sharpened, or "made better".
+- The user mentions a target AI (ChatGPT, Claude, Gemini, Perplexity, Copilot) and wants their prompt tuned for it.
+- The user invokes [`/optimize-prompt`](../../commands/optimize-prompt.md).
+- The user describes a goal ("I need a marketing-email prompt for ChatGPT") and the deliverable is a prompt, not the email itself.
+
+## When NOT to use (near-misses)
+
+| Phrasing | Route to |
+|---|---|
+| "refine this ticket / prompt for the engine" | [`refine-prompt`](../refine-prompt/SKILL.md) |
+| "make this skill description pushier" | [`description-assist`](../description-assist/SKILL.md) |
+| "write the marketing email itself" | direct execution — the user wants the artifact, not a prompt |
+| "review my code / commit" | [`review-changes`](../../commands/review-changes.md) and friends |
+
+## The 4-D Methodology
+
+1. **Deconstruct** — extract core intent, key entities, output shape, constraints; map what's provided vs missing.
+2. **Diagnose** — audit clarity gaps, ambiguity, missing specificity, missing structure; flag unstated assumptions.
+3. **Develop** — pick techniques by request type:
+   - *Creative* → multi-perspective + tone anchoring
+   - *Technical* → constraint-based + precision focus
+   - *Educational* → few-shot examples + clear structure
+   - *Complex* → chain-of-thought + systematic framing
+   - Assign an AI role/expertise; layer context; add logical structure.
+4. **Deliver** — output the optimized prompt + a short "what changed" + (DETAIL only) techniques applied + one pro-tip.
+
+## Modes — BASIC vs DETAIL
+
+**Auto-detect on first turn:**
+
+| Signal | Mode |
+|---|---|
+| User wrote "BASIC" or "DETAIL" verbatim | honor it |
+| One-line ask, common task (resume help, casual email, summary) | BASIC |
+| Multi-paragraph context, professional/technical scope, named audience, named tone | DETAIL |
+| Target AI not named AND request implies platform-sensitive output | DETAIL |
+| **Tiebreaker** — both BASIC and DETAIL signals fire | DETAIL (safer default) |
+
+**BASIC** — apply core 4-D fixes silently, return optimized prompt + 3-bullet "what changed". No questions.
+
+**DETAIL** — gather missing context **one question per turn** (Iron Law from `ask-when-uncertain`). Stop asking once Deconstruct + Diagnose are clean. Then deliver.
+
+**Always inform mode + override**: first reply names the chosen mode and offers the other in one numbered-options block. Re-pick is silent on subsequent turns.
+
+## Procedure
+
+### 1. Receive input
+
+Capture: (a) the rough prompt, (b) target AI if named, (c) explicit BASIC/DETAIL marker if present. If the user pasted only a topic ("marketing email"), treat it as the prompt seed.
+
+### 2. Auto-detect mode + announce
+
+Apply the table above. State: *"Running in BASIC — say `DETAIL` to switch."* (or vice-versa). Use a single numbered-options block only if the user has not signalled a mode and the heuristic is genuinely 50/50.
+
+### 3. Inspect + Diagnose (Deconstruct)
+
+Identify each slot in the rough prompt: intent · entities · output shape · constraints · target AI · tone · audience. List every missing slot. Check for ambiguity, unstated assumptions, and contradictory requirements.
+
+### 4a. BASIC path
+
+Fill missing slots with safe defaults (general audience, neutral tone, the named AI or "any modern LLM"). Skip to step 5.
+
+### 4b. DETAIL path
+
+Ask **one** question for the highest-leverage missing slot. Order: target AI → output shape → audience → tone → constraints. Stop asking once the prompt would land cleanly. Never batch. Hard cap: **3 question turns**; after that, fill remaining slots with safe defaults and deliver — note the assumptions in § What changed.
+
+### 5. Develop
+
+Pick techniques per request type (see § 4-D step 3). Assign role ("You are a senior X…"), layer context, add structure (numbered steps, bullet headers, output format spec, length cap), and inject specificity (concrete numbers, named formats, explicit success criteria — replace "good", "professional", "high-quality" with measurable criteria).
+
+### 6. Deliver
+
+Format per § Output format. Do **not** execute the optimized prompt yourself unless the user explicitly says "and run it" — this skill produces a prompt, not the answer to it.
+
+## Output format
+
+1. **Optimized prompt** — fenced code block, ready to copy. Top line names the target AI if known.
+2. **What changed** — 3-5 bullets, each ≤ 12 words.
+3. **Techniques applied** *(DETAIL only)* — bullet list naming the techniques (e.g. "few-shot", "chain-of-thought", "role assignment").
+4. **Pro tip** — one sentence, platform-specific when target AI is known (e.g. "Claude responds well to XML tags"; "ChatGPT honors length caps in the system message").
+
+## Gotcha
+
+- The model tends to **execute** the rough prompt instead of optimizing it — when the user pastes "write a marketing email", treat the whole line as the *seed*, not the *task*. Confirm by asking "optimize this prompt, or write the email?" if genuinely ambiguous.
+- The model tends to ask **multiple** clarifying questions in DETAIL mode — Iron Law is one per turn. Pick the highest-leverage missing slot and stop.
+- The model tends to invent platform tips that aren't true — only emit a pro-tip when the technique is well-known for the named AI; otherwise omit the section.
+- The model tends to over-engineer BASIC mode — for a one-line ask, the optimized prompt should still be short. No 800-word system prompts for "help with my resume".
+- Don't drift into German welcome text. The optimized prompt mirrors the user's source-language preference; the skill's own scaffolding stays English (per `language-and-tone` for `.md`).
+- The model tends to **mix languages** in the optimized prompt when the user wrote in German but named an English-speaking target audience — pick one language for the whole optimized prompt body (default: source-language of the rough prompt unless the user explicitly named the target audience's language).
+
+## Do NOT
+
+- Do NOT execute the optimized prompt and return its answer unless the user explicitly asks for both.
+- Do NOT ask more than one clarifying question per turn (`ask-when-uncertain` Iron Law).
+- Do NOT add an "I'm Lyra" preamble on every turn — the welcome belongs to the command entry point, not every reply.
+- Do NOT modify project files — this skill is conversational, no file writes, no commits.

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

@@ -54,7 +54,7 @@ Inspect truth-defining files:
 - Config files, tests, existing docs
 
 Verify: install steps exist, commands work, features are implemented,
-dependencies are real.
+deps are real.
 
 ### 3. Validate installation and setup
 

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

@@ -82,6 +82,29 @@ no silent edits, max two rounds.
 * No numbered procedures — if you need steps, it is a skill.
 * Link out to guidelines for deep reference instead of inlining them.
 
+### 3b. Path conventions in frontmatter and body — load-bearing
+
+Three different surfaces, three different rules. Mixing them up will
+either fail the schema (`python3 scripts/validate_frontmatter.py`) or
+fail `python3 scripts/lint_load_context.py`. Canonical reference:
+[`templates/rule.md`](../../templates/rule.md) § Path conventions and
+[`docs/contracts/load-context-schema.md`](../../../docs/contracts/load-context-schema.md).
+
+| Field | Form | Example |
+|---|---|---|
+| `load_context:` / `load_context_eager:` | **Logical name** rooted at the source — never `.agent-src.uncompressed/` | `contexts/execution/verification-mechanics.md` |
+| `triggers[].path_prefix:` | **Literal match pattern** the host evaluates against the file the agent is editing — not rewritten | `.agent-src.uncompressed/skills/` (source-of-truth rules) or `agents/`, `app/`, `.augment/` |
+| Body links to guidelines / contracts | **Verbatim relative form** — `../../docs/...` works in any markdown viewer; rewriter handles depth | `[guideline](../../docs/guidelines/<group>/<name>.md)` |
+
+The compress-time rewriter (`scripts/compress.py::_rewrite_paths`) is
+idempotent and depth-aware — it resolves logical names and body links
+to the deployment-correct relative path at compress time, leaving
+`path_prefix:` literally as written. The schema regex
+(`scripts/schemas/rule.schema.json`) and `scripts/lint_load_context.py`
+both reject the `.agent-src.uncompressed/` prefix in `load_context:` /
+`load_context_eager:` with an error pointing at the canonical logical
+name.
+
 ### 4. Enforce the size budget
 
 Normative source: [`size-enforcement`](../../rules/size-enforcement.md) +
@@ -113,9 +136,19 @@ type: "auto"              # or "always"
 description: "Trigger-shaped sentence — domain + symptoms — soft cap 200 chars"
 alwaysApply: false        # true only if type: always
 source: package           # or project for consumer-local rules
+load_context:             # logical names only — `contexts/<area>/<file>.md`
+  - contexts/execution/verification-mechanics.md
+triggers:                 # path_prefix is literal, not rewritten
+  - path_prefix: ".agent-src.uncompressed/rules/"
+routes_to:
+  - "skill:related-skill"
 ---
 ```
 
+See § 3b above for the load-bearing distinction between `load_context:`
+(logical, rewritten), `triggers[].path_prefix:` (literal, verbatim),
+and body links (relative `../../docs/...`, rewriter handles depth).
+
 ## Output format
 
 1. Complete rule file at `.agent-src.uncompressed/rules/{name}.md`

package/.agent-src/skills/sentry-integration/SKILL.md

@@ -152,7 +152,7 @@ search_events(organizationSlug='my-org', naturalLanguageQuery='count of database
 
 ## Gotcha
 
-- Sentry groups errors by stacktrace — different root causes may appear as the same issue. Check multiple events.
+- Sentry groups errors by stacktrace — different root → may appear as the same issue. Check multiple events.
 - The model tends to analyze only the latest event — check the "Events" tab for patterns across time.
 - Don't use Sentry MCP tools for simple lookups — use the Sentry web UI link instead (saves tokens).
 

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

@@ -258,6 +258,20 @@ Example:
 * Validation must be concrete
 * One skill = one job
 
+### Cross-references and paths
+
+* Body links to guidelines / contracts use the verbatim relative form
+  (`../../docs/guidelines/<group>/<name>.md`,
+  `../../docs/contracts/<name>.md`). The compress-time rewriter
+  resolves them to depth-aware single-up form — do not pre-rewrite in
+  source.
+* Skills do **not** declare `load_context:` / `load_context_eager:`;
+  those frontmatter keys are rule-only. If a skill needs to point at a
+  context, link to it inline (`[context-name](../../contexts/<area>/<file>.md)`).
+* Never write `.agent-src.uncompressed/` in any skill body link or
+  example — it ships into `.augment/skills/` and breaks consumer
+  resolution. See `rule-writing` § 3b for the canonical reference.
+
 ### Execution metadata (optional)
 
 Skills may declare an `execution` frontmatter block (`type`, `handler`,

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

@@ -106,8 +106,8 @@ Used for workers and schedulers:
 
 ### GitHub OIDC IAM role
 
-Each environment has a GitHub IAM role with:
-- OIDC trust policy (scoped to repo + environment)
+Each env has a GitHub IAM role with:
+- OIDC trust policy (scoped to repo + env)
 - Policies for ECR push/pull, ECS deployment, Secrets Manager read, CloudWatch logs
 
 ## Output format

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

@@ -12,7 +12,7 @@ Use this skill when working with Terragrunt configurations (`.hcl` files), manag
 
 ## Procedure: Write Terragrunt config
 
-1. Read the `root.hcl` in the target environment (`environments/pro/root.hcl` or `environments/sta/root.hcl`).
+1. Read the `root.hcl` in the target env (`environments/pro/root.hcl` or `environments/sta/root.hcl`).
 2. Check existing `terragrunt.hcl` files in sibling directories for patterns.
 3. Read the target module's `variables.tf` to understand required inputs.
 
@@ -36,7 +36,7 @@ environments/
 
 ## Root configuration (`root.hcl`)
 
-The root HCL defines shared settings for all modules in an environment:
+The root HCL defines shared settings for all modules in an env:
 
 ### Environment variables
 
@@ -50,9 +50,9 @@ locals {
 }
 ```
 
-- `.env.yaml` — committed, shared environment config
+- `.env.yaml` — committed, shared env config
 - `.env.local.yaml` — gitignored, local overrides (AWS profiles, etc.)
-- Real environment variables take precedence over file values.
+- Real env variables take precedence over file values.
 
 ### Remote state
 
@@ -101,7 +101,7 @@ Each module directory contains a `terragrunt.hcl` that:
 1. **Loads module-specific variables** from a YAML file
 2. **Includes the root config** for backend and providers
 3. **Points to the Terraform module source**
-4. **Declares dependencies** on other modules
+4. **Declares deps** on other modules
 5. **Passes inputs** by merging dependency outputs with local variables
 
 ### Example pattern
@@ -183,19 +183,19 @@ devbox run d           # terragrunt destroy
 
 ## Output format
 
-1. Terragrunt HCL files with DRY environment configuration
+1. Terragrunt HCL files with DRY env configuration
 2. Dependency graph and remote state references
 
 ## Auto-trigger keywords
 
 - Terragrunt
-- multi-environment
+- multi-env
 - DRY config
 - remote state
 
 ## Gotcha
 
-- Terragrunt `dependency` blocks create implicit ordering — circular dependencies cause cryptic errors.
+- Terragrunt `dependency` blocks create implicit ordering — circular deps cause cryptic errors.
 - Don't duplicate Terraform variables in terragrunt.hcl — use `inputs` to pass them through.
 - The model tends to hardcode values that should come from `include` blocks — use DRY patterns.
 

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

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

package/.agent-src/skills/threat-modeling/SKILL.md

@@ -6,7 +6,7 @@ source: package
 
 # threat-modeling
 
-> You are a reviewer specialized in **pre-implementation threat analysis**.
+> You are a reviewer specialized in **pre-impl threat analysis**.
 > Your only job is to produce a compact threat model for a planned change —
 > actors, assets, trust boundaries, abuse cases, and the minimum controls
 > the implementer must add. You do **not** audit existing code end-to-end,
@@ -186,4 +186,4 @@ run tests**.
 - [`authz-review`](../authz-review/SKILL.md),
   [`data-exposure-review`](../data-exposure-review/SKILL.md),
   [`security`](../security/SKILL.md),
-  [`security-audit`](../security-audit/SKILL.md) — sibling review / implementation skills.
+  [`security-audit`](../security-audit/SKILL.md) — sibling review / impl skills.