@event4u/agent-config 1.19.0 → 1.21.0

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/subagent-orchestration/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: subagent-orchestration
-description: "Use when orchestrating implementer/judge subagents — five modes (do-and-judge, do-in-steps, do-in-parallel, do-competitively, judge-with-debate) — models from .agent-settings.yml."
+description: "Use when orchestrating implementer/judge subagents — six modes (do-and-judge, do-in-steps, do-in-parallel, do-competitively, judge-with-debate, do-in-worktrees) — models from .agent-settings.yml."
 source: package
 ---
 
@@ -44,7 +44,7 @@ judge is a fresh pair of eyes. If `.agent-settings.yml` resolves to
 identical implementer and judge models, surface the mismatch before
 running — do not silently continue.
 
-## The five modes
+## The six modes
 
 Each mode has a decision row: when to use, when not, and the expected
 model pairing. Defaults come from
@@ -100,6 +100,38 @@ migration, public API) where a single judge is too easy to fool.
 |---|---|---|
 | Security, data integrity, public API change | Routine internal refactor | judges = same tier (2x); meta-judge = one tier up |
 
+### 6. do-in-worktrees
+
+Cross-wing or cross-skill chain executed across isolated git
+worktrees — each handoff in the chain runs in its own worktree, so
+the workspace state of one step never leaks into the next. Operationalizes
+the worktree boundary clause in
+[`docs/contracts/cross-wing-handoff.md`](../../../docs/contracts/cross-wing-handoff.md)
+§ 3. State-machine layer only — worktree creation/destruction lives
+in [`using-git-worktrees`](../using-git-worktrees/SKILL.md) and
+[`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md).
+
+| When to use | When not | Model pairing |
+|---|---|---|
+| Multi-step cross-wing chain (≥2 senior skills, each ≥30 min) where one step's open files / branch state would confuse the next | Fast iteration where each step < 30 min — worktree overhead exceeds isolation benefit | implementers = same tier per step; judge = one tier up at chain end |
+
+**Handoff shape:** initiator-skill emits the typed output declared in
+its `## Output` block → control passes to delegated-skill in a fresh
+worktree → delegated-skill consumes the input shape declared in its
+`## Input` (or `## When the agent should load this`) block. The
+handoff is auditable; `lint_handoffs.py` validates the chain.
+
+**Example chain (W3 launch):** `positioning` (worktree A) →
+`messaging-architecture` (worktree B, consumes positioning's
+`positioning-statement.md`) → `gtm-launch` (worktree C, consumes
+both prior artifacts). Each worktree carries one branch; the chain
+end produces a single integration PR.
+
+**Anti-pattern:** do not use for fast iteration loops where each
+step is under ~30 minutes. The branch-creation, context-switch, and
+worktree-cleanup cost dominates. Stick with mode 1 (do-and-judge)
+or mode 2 (do-in-steps) for those.
+
 ## Procedure
 
 ### 1. Inspect the task shape

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.

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

@@ -0,0 +1,110 @@
+---
+name: token-optimizer
+description: "Use BEFORE any verbose CLI run, large file read, doc conversion, or near-context handoff — single decision tree keyed by intent that cites the canonical token-saving asset. Consult before the action."
+source: package
+execution:
+  type: assisted
+  handler: shell
+  allowed_tools: []
+---
+
+# Token Optimizer — decision tree + catalog
+
+## Iron Law
+
+```
+CONSULT THIS SKILL BEFORE THE ACTION, NOT AFTER.
+THE TREE NAMES THE CANONICAL ASSET — DO NOT RESTATE OR DUPLICATE IT.
+```
+
+## When to use
+
+Proactively, BEFORE you:
+
+- Run a verbose CLI command (tests, linters, build, git log, large `grep`)
+- Read or paste a large document, log, or tool dump
+- Repeat the same tool call across many files / records
+- Approach the context-window limit and need to hand off
+- Make a cost-aware decision (which model, which budget, when to stop)
+
+Reactively when output already burned tokens — record the lesson, do
+not re-explore. Cite the leaf, move on.
+
+## Procedure
+
+1. **Classify intent** — match the situation to one branch of the tree below.
+2. **Cite the leaf** — name the canonical asset (rule, skill, or upstream link).
+3. **Apply** — execute the cited asset's contract; do NOT inline its content.
+4. **Verify** — output respects the cited Iron Law (redirect, wrap, batch, etc.).
+
+### Decision tree
+
+```
+INTENT
+├── Verbose CLI output incoming
+│     → cite [cli-output-handling](../../rules/cli-output-handling.md)
+│       (Iron Law: redirect / tail / grep / wrap)
+│     → cite [rtk-output-filtering](../rtk-output-filtering/SKILL.md)
+│       (rtk wrapper, 60-90% savings on tests/linters/git)
+│
+├── Large document or paste (PDF, DOCX, HTML, transcript)
+│     → cite markitdown (upstream: https://github.com/microsoft/markitdown)
+│       Convert FIRST, then read the markdown — never paste raw binary.
+│
+├── Repeated tool-call across N targets
+│     → cite [token-efficiency](../../rules/token-efficiency.md)
+│       (batch, parallelize, prune; one tool call > many)
+│
+├── Near context limit, work not finished
+│     → cite [agent-handoff](../../../.claude/skills/agent-handoff/SKILL.md)
+│       (structured handoff envelope; resume in fresh chat)
+│
+└── Cost-aware decision (model pick, budget, stop-criterion)
+      → cite /cost:report (when shipped) — until then, fall back to
+        [token-efficiency](../../rules/token-efficiency.md) and
+        [direct-answers § Brevity by Default](../../rules/direct-answers.md)
+```
+
+## Catalog
+
+| Asset | Path | Trigger keywords | What it does |
+|---|---|---|---|
+| `cli-output-handling` | `.agent-src.uncompressed/rules/cli-output-handling.md` | `verbose`, `tail`, `grep`, `CLI` | Wrap-tail-grep contract for any verbose command |
+| `rtk-output-filtering` | `.agent-src.uncompressed/skills/rtk-output-filtering/SKILL.md` | `rtk`, `verbose`, `filter`, `wrap` | Project-local rtk filters; wrapper command |
+| `token-efficiency` | `.agent-src.uncompressed/rules/token-efficiency.md` | `redirect`, `verbose`, `concise`, `tool` | Batch + parallelize tool calls; brevity floor |
+| `agent-handoff` | `.claude/skills/agent-handoff/SKILL.md` | `handoff`, `fresh`, `chat`, `context` | Context envelope for fresh-chat continuation |
+| `direct-answers` | `.agent-src.uncompressed/rules/direct-answers.md` | `brevity`, `flattery`, `severity`, `tiered` | Iron-Law brevity floor (kernel) |
+| `markitdown` | upstream: github.com/microsoft/markitdown | `PDF`, `DOCX`, `HTML`, `convert` | Document → markdown converter (authoritative-link only) |
+| `/cost:report` | TBD — `road-to-ruflo-adoption.md § P1.2` | `cost`, `model spend`, `budget` | Per-session cost telemetry (planned) |
+
+## Output format
+
+1. Name the cited asset by its leaf id (e.g. `cli-output-handling`, `rtk-output-filtering`).
+2. State the Iron Law in one line; do NOT inline the asset's body.
+3. If multiple branches match, cite all relevant leaves (no merge, no rewrite).
+4. End with the action you take next, citing the asset that authorizes it.
+
+## Gotcha
+
+- Catalog rows live and die with their target asset. If you edit a
+  cited asset's trigger keywords or scope, update the matching row in
+  this skill in the same commit (enforced by
+  [`token-optimizer-maintenance`](../../rules/token-optimizer-maintenance.md)
+  rule + `scripts/check_token_optimizer_freshness.py` CI gate).
+- Tree must stay scannable (≤ 50 lines incl. labels). Catalog rows
+  carry the long form.
+- Authoritative-link assets (`rtk` upstream, `markitdown` upstream,
+  pricing constants) are never copied — always linked.
+
+## Do NOT
+
+- Do NOT inline content from a cited asset. If the leaf is "rtk does X",
+  the agent reads `rtk-output-filtering`. Duplication = drift = stale.
+- Do NOT replace any rule. The rules carry the Iron Laws; this skill
+  carries the lookup index.
+- Do NOT define new policies — every leaf must cite an existing rule,
+  skill, or upstream asset.
+- Do NOT consult this skill AFTER tokens were already burned — record
+  the lesson and move on.
+
+<!-- TELEMETRY: consulted=[uncomment + ISO timestamp on each consult] context=[CLI|doc|repeat|handoff|cost] -->

package/.agent-src/skills/unit-economics-modeling/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: unit-economics-modeling
+description: "Use when modeling CAC, LTV, gross-margin payback, or contribution margin per customer — for SaaS, marketplace, or transactional businesses."
+status: active
+tier: senior
+source: package
+---
+
+# unit-economics-modeling
+
+## When to use
+
+- A board ask: "is this business unit-economic?" — needs CAC / LTV / payback, not vibes.
+- A new channel is scaling and the question is whether the CAC payback period is sustainable.
+- A pricing or packaging change needs to be tested against contribution margin per cohort.
+
+Do NOT use for full-business intrinsic-value modeling, OKR setting, funnel-stage diagnosis, or backlog ranking (see Related Skills).
+
+## Procedure
+
+### Step 0: Inspect
+
+1. Confirm the business shape — SaaS / marketplace / transactional. The three canonical cases differ in **revenue recognition** and **churn definition**, not in arithmetic.
+2. Confirm a fully-loaded CAC is computable: paid spend + sales comp + content/SEO allocation + tooling. Marketing-spend-only CAC is a vanity metric.
+
+### Step 1: Compute CAC per channel
+
+1. CAC = `(fully-loaded acquisition spend in window) / (new paying customers acquired in same window)`. Match window to sales-cycle length, not calendar quarter.
+2. Compute by channel **and** blended. Blended-only hides the channel that is breaking the average.
+3. Anti-pattern: counting trial signups as customers. Customer = first paid charge cleared.
+
+### Step 2: Compute gross margin
+
+1. Gross margin = `(revenue − COGS) / revenue`. COGS includes hosting, payment fees, third-party APIs the customer's usage drives, and direct customer-success cost.
+2. Gross margin must be **per dollar of revenue**, not per customer. Per-customer gross margin is contribution margin (Step 3).
+3. SaaS healthy band: 70–85%. Marketplace: 15–40%. Transactional: 5–25%. Outside these — the business is mislabelled or the COGS allocation is wrong.
+
+### Step 3: Compute LTV
+
+1. Pick the canonical formula for the case:
+   - **SaaS:** `LTV = ARPA × gross_margin / monthly_churn_rate`. Use net-dollar churn for self-serve, gross logo churn for high-touch.
+   - **Marketplace:** `LTV = take_rate × GMV_per_user × retention_curve_AUC` over 24 months. Steady-state extrapolation is dishonest below 24 months of cohort data.
+   - **Transactional:** `LTV = avg_order_value × gross_margin × purchases_per_year × avg_lifetime_years`.
+2. Cap implied lifetime at 5 years for any business with < 3 years of cohort history. Anything longer is a fairy tale.
+3. State the formula used inline. Do not let the reader infer.
+
+### Step 4: Compute payback and ratio
+
+1. **CAC payback** (months) = `CAC / (ARPA × gross_margin)` for SaaS; analogue for marketplace and transactional. Healthy SaaS: ≤ 12 months.
+2. **LTV / CAC ratio**: target ≥ 3.0. Below 1.5 is acquisition-loss territory; above 5.0 means under-investment in growth (or bad LTV math).
+3. Both numbers, not one. Payback drives capital efficiency; ratio drives long-run economics.
+
+### Step 5: Cohort the answer
+
+1. Run Steps 1–4 by signup-quarter cohort. Trends matter more than the point estimate.
+2. If LTV/CAC is improving but payback is lengthening, you are buying retention with discounting — flag.
+3. If both deteriorate, the channel mix has shifted to a worse channel — segment by channel to find the leak.
+
+### Step 6: Validate
+
+1. Sanity-check LTV against revenue retention. If implied LTV > 8× annual revenue per customer with monthly churn > 2%, the math is wrong.
+2. Sanity-check CAC against fully-loaded P&L. If channel CACs sum to less than total acquisition spend, allocations are missing.
+
+## Gotcha
+
+- Marketing-spend-only CAC is the most common deception. Sales comp, BDR salaries, content production, and tooling all belong in fully-loaded CAC.
+- Net-dollar retention > 100% does not justify ignoring logo churn — they answer different questions.
+- ARPA averaged across plan tiers hides churn concentrated in one tier. Compute per tier when tiers differ in price by more than 2×.
+- Payback period using contribution margin (post variable-cost) is honest; payback using gross revenue is the kind of math VCs see in pitch decks and discount on sight.
+
+## Do NOT
+
+- Do NOT extrapolate LTV beyond observable cohort data without saying so explicitly.
+- Do NOT mix freemium activation rates with paid CAC; they live in different universes.
+- Do NOT report a single LTV/CAC for a business with multiple distinct customer segments — segment first.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The question is per-customer economics (CAC, LTV, payback, contribution margin).
+- The decision is whether to scale a channel or pricing tier.
+
+**WHEN NOT to use this**
+
+- Whole-business intrinsic value with terminal value — route to [`dcf-modeling`](../dcf-modeling/SKILL.md).
+- Diagnosing where conversion drops — route to [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Ranking competing initiatives — route to [`rice-prioritization`](../rice-prioritization/SKILL.md).
+- Setting team objectives that move these metrics — route to [`okr-tree-modeling`](../okr-tree-modeling/SKILL.md).
+
+## When the agent should load this
+
+- "What's our LTV / CAC?"
+- "Is this channel paying back fast enough?"
+- "Compute unit economics for this pricing tier."
+- "Are we unit-economic at this CAC?"
+- "Cohort our payback period."
+
+## Output
+
+1. **`unit-econ-table.md`** — table per channel and blended: CAC · ARPA · gross margin · payback months · LTV · LTV/CAC. With cohort columns (last 4 quarters).
+2. **`assumptions.md`** — formula chosen (SaaS / marketplace / transactional), churn definition, COGS allocation method, lifetime cap. One bullet per choice.
+3. **`cohort-trend.md`** — trend chart (ASCII or markdown table) of CAC, payback, LTV/CAC over the last 4–8 cohorts. Annotate channel-mix shifts.
+4. **`sanity-checks.md`** — explicit cross-checks (LTV vs annual revenue, channel CAC sum vs P&L). Flag any that fail with a one-line investigation pointer.

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

@@ -71,7 +71,7 @@ Goal: understand structure, identify major components, detect investigation path
 ### Investigation mode
 
 Use when there is a concrete issue inside a large or unclear system.
-Goal: isolate the affected area, route into root-cause analysis, verify likely causes with evidence.
+Goal: isolate the affected area, route into root-cause analysis, verify likely → with evidence.
 
 ### Optimization mode
 

package/.agent-src/skills/using-git-worktrees/SKILL.md

@@ -15,6 +15,7 @@ source: package
 * Experimenting with a refactor that may be thrown away — a throwaway
   worktree is cheaper than a throwaway commit
 * A long-running build or test suite is busy in the current worktree
+* `subagent-orchestration` mode 6 (`do-in-worktrees`) was selected for a cross-wing chain — this skill is the executor that creates the per-step isolated worktrees the chain expects
 
 Do NOT use when:
 

package/.agent-src/templates/AGENTS.md

@@ -113,7 +113,7 @@ Regenerate: `task generate-tools` · Clean: `task clean-tools`
 |---|---|
 | `.env` | Main environment |
 | `.env.local` | Local overrides |
-| `.env.testing` | Testing environment |
+| `.env.testing` | Testing env |
 
 ---