@event4u/agent-config 1.19.0 → 1.21.0

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/md-language-check/SKILL.md

@@ -32,7 +32,7 @@ Do NOT use when:
 
 - Editing project content outside the trees listed above (READMEs of
   consumer projects, application docs that follow a different policy)
-- Reviewing chat history files (`.agent-chat-history` is JSONL, not `.md`)
+- Reviewing chat history files (`agents/.agent-chat-history` is JSONL, not `.md`)
 - Inspecting non-`.md` files — the checker rejects them with a warning
 
 ## Procedure

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/okr-tree-modeling/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: okr-tree-modeling
+description: "Use when decomposing a company objective into team OKRs, auditing a draft OKR tree, or stress-testing an existing one for measurability and laddering."
+status: active
+tier: senior
+source: package
+---
+
+# okr-tree-modeling
+
+## When to use
+
+- A leadership team wrote a quarterly objective and needs three measurable KRs that actually move it.
+- A draft OKR tree needs review for orphan KRs, vanity metrics, or KRs that ladder to two parents.
+- A team-level OKR set needs to be checked against the company objective it claims to serve.
+
+Do NOT use for ranking competing initiatives within one OKR — that's prioritization, not decomposition (route elsewhere — see Related Skills).
+
+## Procedure
+
+### Step 0: Inspect
+
+1. Identify the cognition cluster. OKR-as-strategy lives near the CEO/COO; OKR-as-PM-tool lives near the head of product. The decomposition mechanic is the same; the ladder-up target differs.
+2. Confirm timeframe (quarter / half / year) — KR cadence depends on it.
+
+### Step 1: Lock the parent objective
+
+1. Restate the parent in one sentence with **a verb of change** (grow, reduce, ship, win) and an outcome — not an output.
+2. Bad: "Improve onboarding." Good: "Reduce time-to-first-value for new accounts to under 7 days."
+3. If the parent has no verb of change or no outcome, the tree is built on sand. Stop and rewrite the parent.
+
+### Step 2: Decompose into 3 KRs
+
+1. Each KR must satisfy four tests: (a) measurable end-state, (b) the team owns the lever, (c) achievable iff the parent is achieved, (d) failing it should be visibly bad.
+2. Three is the floor and the ceiling. One KR makes the objective brittle; five dilutes ownership.
+3. Anti-pattern: "ship X feature" as a KR. Shipping is an output. The KR is what changes when the feature lands.
+
+### Step 3: Cascade to team-level
+
+1. For each company KR, define 2–3 team-level KRs that, taken together, achieve the parent KR — not duplicate it.
+2. Anti-pattern: copy-paste the parent KR with a smaller number ("60% of company KR is 30% for our team"). Real cascades change shape — input metrics for some teams, leading indicators for others.
+3. Mark each team KR as **trailing** (lagging outcome — revenue, retention) or **leading** (input the team controls — activation rate, response time). A tree that is all-trailing is unactionable.
+
+### Step 4: Cadence + check-ins
+
+1. Weekly check-in: leading KRs only. Trailing KRs are reviewed monthly.
+2. End of period: confidence score (0.0–1.0) per KR, written 3× across the period to surface drift.
+
+### Step 5: Validate
+
+1. Walk the tree top-down: does every leaf KR ladder cleanly to exactly one parent KR?
+2. Walk it bottom-up: if every team hits 0.7 confidence, does the company objective land?
+3. Count vanity metrics — KRs that move but don't matter. If more than zero, rewrite.
+
+## Gotcha
+
+- "100% of teams adopt X" is a participation metric, not an outcome KR. The model loves to write these.
+- A KR owned by two teams is owned by no team. Single accountability is non-negotiable.
+- Stretch goals that nobody believes are achievable produce sandbagging on the OKR after, not stretch.
+- "Customer happiness" + NPS is a sentiment proxy, not an outcome metric. Tie KRs to behavior (renewal, expansion, usage), not feeling.
+
+## Do NOT
+
+- Do NOT write more than 3 KRs per objective — focus is the entire point.
+- Do NOT use "achieve $X revenue" as a KR for a team that doesn't own pricing or pipeline; that's setting them up to fail blameably.
+- Do NOT cascade by simple percentage allocation — different teams contribute different mechanisms, not different fractions.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The ask is decomposition of an objective into measurable KRs.
+- A draft OKR tree needs structural review (cascade integrity, leading/trailing balance).
+
+**WHEN NOT to use this**
+
+- Prioritization of competing features inside one KR — route to [`rice-prioritization`](../rice-prioritization/SKILL.md).
+- Conversion-rate diagnosis on a funnel KR — route to [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Valuation-impact modeling of strategic objectives — route to [`dcf-modeling`](../dcf-modeling/SKILL.md).
+
+## When the agent should load this
+
+- "Help me write OKRs for next quarter."
+- "Review this OKR tree — does it ladder up?"
+- "What KRs would actually move our retention objective?"
+- "Are these team OKRs measurable?"
+- "We have 8 KRs per team — too many?"
+
+## Output
+
+1. **`okr-tree.md`** — markdown tree: company objective → 3 company KRs → 2–3 team KRs each. Each leaf carries owner, measure, target, trailing/leading tag, check-in cadence.
+2. **`cascade-audit.md`** — orphans (KRs with no parent), oversubscribed parents (KR with >3 children), vanity metrics flagged with a one-line replacement suggestion.
+3. **`confidence-template.md`** — empty 3-column table (start / mid / end) per KR, ready for the period's confidence updates.

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/rice-prioritization/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: rice-prioritization
+description: "Use when ranking competing initiatives for a roadmap, breaking a tie between two features, or auditing a backlog for hidden low-value work via Reach × Impact × Confidence ÷ Effort."
+status: active
+tier: senior
+source: package
+---
+
+# rice-prioritization
+
+## When to use
+
+- A backlog has more candidates than capacity for the next quarter and someone has to pick.
+- A PM and an engineering lead disagree on what ships first and need a shared framework.
+- A draft roadmap reads like a wish list — no transparency on **why** these and not those.
+
+Do NOT use for valuation, OKR decomposition, or funnel-stage diagnosis (see Related Skills).
+
+## Procedure
+
+### Step 0: Inspect
+
+1. Confirm there are at least 5 candidates. RICE on 2 items is theatre; just argue the merits.
+2. Confirm there is a shared definition of the **target user** for "Reach" — RICE breaks if two scorers count different populations.
+
+### Step 1: Score Reach
+
+1. Reach = number of users / events / requests **per fixed time window** (per quarter is the default).
+2. Use absolute counts pulled from analytics or product DB, not percentages — percentages hide tiny denominators.
+3. If the data isn't there, write the query you'd run and say so. Do not invent numbers.
+
+### Step 2: Score Impact
+
+1. Use the canonical 5-point scale: 0.25 (minimal) · 0.5 (low) · 1 (medium) · 2 (high) · 3 (massive).
+2. Anchor each level with a concrete past shipped feature ("medium = like the search filter we shipped Q2"). Without anchors, scorers drift.
+3. Impact is **per affected user**, not aggregate. Aggregate is what RICE produces, not what you input.
+
+### Step 3: Score Confidence
+
+1. Confidence is a **percentage** — 100 / 80 / 50 / "low and we should not score this yet".
+2. Anything below 50 means: stop, do a spike or a research week, then re-score. RICE does not rescue ignorance.
+3. Confidence multiplies — it is the model's discount for unknown unknowns.
+
+### Step 4: Score Effort
+
+1. Effort = person-months for the smallest viable shippable slice. Not the fantasy version.
+2. Engineering owns this number. PMs scoring effort is the most common process failure.
+3. Effort < 0.5 person-months almost always means scope is underestimated — surface and ask.
+
+### Step 5: Compute and rank
+
+1. RICE = `(Reach × Impact × Confidence) / Effort`.
+2. Rank descending. The score is the artefact, not the answer — read the top 5 with a critical eye.
+3. Anti-pattern: treating RICE rank as a contract. It is a structured argument, not a verdict.
+
+### Step 6: Audit the bottom
+
+1. Look at the bottom quartile. If a strategic must-have lives there, the model has a calibration error — usually Reach or Impact.
+2. Look at the top item. If it is obviously absurd (e.g. one ad-hoc admin tool above a strategic platform play), the input scoring is uncalibrated.
+
+## Gotcha
+
+- Reach in percentages hides "this feature affects 100% of … 12 users."
+- Impact inflation: every PM thinks every feature is a 2 or 3. Force at least 30% of items to score 0.5 or below.
+- Confidence is the only multiplier that punishes uncertainty — do not let it default to 80 for everything.
+- Effort discrepancy between PM and engineering on the same row is itself the signal — investigate, do not average.
+
+## Do NOT
+
+- Do NOT rank fewer than 5 candidates with RICE — overhead exceeds value.
+- Do NOT mix strategic bets and BAU tickets in the same RICE table; their effort scales differ by 10×.
+- Do NOT ship a roadmap that is exactly the RICE-sorted top-N — you need at least one strategic outlier with a written rationale.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Ranking is the actual question.
+- The team needs a shared, auditable scoring frame.
+
+**WHEN NOT to use this**
+
+- Decomposing an objective into KRs — route to [`okr-tree-modeling`](../okr-tree-modeling/SKILL.md).
+- Diagnosing why a funnel stage drops — route to [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Modelling whether an investment is worth its capital cost — route to [`dcf-modeling`](../dcf-modeling/SKILL.md).
+- CAC / LTV / payback questions — route to [`unit-economics-modeling`](../unit-economics-modeling/SKILL.md).
+
+## When the agent should load this
+
+- "Help me prioritize the backlog for Q3."
+- "RICE-score these features."
+- "Why is X above Y on the roadmap?"
+- "We have 30 ideas and 6 engineers — what ships?"
+- "Audit our roadmap for low-value work."
+
+## Output
+
+1. **`rice-table.md`** — markdown table: Item · Reach · Impact · Confidence · Effort · RICE · Owner · Notes. Sorted descending by RICE.
+2. **`calibration-notes.md`** — one paragraph per anchor (what "Impact = 2" means with a named past feature) plus a list of items with confidence < 50 marked for spike-first.
+3. **`top-5-critique.md`** — one paragraph per top-5 item: is the rank defensible, and what would change it.