@event4u/agent-config 14.17.0 → 14.19.0

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

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: fe-design
-description: "Frontend design heuristics — and, outside the ticket engine, the loop that applies them: audit, brief, inventory, build, review. Use when building or changing any UI, not only when planning one."
+description: "Frontend design heuristics and the loop applying them: existing-ui-audit, brief, inventory, build, review. Use when building or changing any UI, not only when planning one."
 personas:
   - frontend-engineer
 domain: engineering
@@ -46,10 +46,37 @@ else runs the loop.
 1. **Audit first** — run [`existing-ui-audit`](../existing-ui-audit/SKILL.md).
    What already exists (components, tokens, layout conventions) outranks every
    heuristic below. Reinventing an existing component is the #1 failure mode.
-2. **Brief** — cover the same five keys the engine requires before any code:
-   `layout`, `components`, `states`, `microcopy`, `a11y`. `states` means all
-   five of `empty`, `loading`, `error`, `success`, `disabled` — a brief missing
-   one is unfinished, not concise.
+2. **Brief** — seven keys before any code. Five are the ones the engine gates
+   (`REQUIRED_BRIEF_KEYS`): `layout`, `components`, `states`, `microcopy`,
+   `a11y`. `states` means all five of `empty`, `loading`, `error`, `success`,
+   `disabled` — a brief missing one is unfinished, not concise.
+
+   Two more are **declared, not gated**: `frequency` and `initiation`. The
+   engine does not halt on them, and that is stated rather than left to be
+   discovered — adding a required key would halt every brief already written
+   against the five.
+
+   | Key | Values | Why it is declared and never inferred |
+   |---|---|---|
+   | `frequency` | `one-time` · `low` · `medium` · `high` (100+ per day) | How often a surface is used decides whether motion on it reads as polish or as a toll. Nothing in a diff reveals it. |
+   | `initiation` | `keyboard` · `pointer` · `system` | A keyboard-initiated surface is reached by someone who already knows where they are going; an animation there is pure latency. |
+
+   Both are prefilled from the surface's role and overridden only on evidence.
+   There is no resolver and no inference from handlers: a `mousemove` listener
+   is not proof of pointer initiation, and a keyboard shortcut in the code is
+   not proof anyone uses it.
+
+   | Surface role | `frequency` | `initiation` |
+   |---|---|---|
+   | Command palette | `high` | `keyboard` |
+   | Tooltip | `high` | `pointer` |
+   | Modal / sheet | `medium` | `pointer` |
+   | Onboarding flow | `one-time` | `pointer` |
+   | Toast / notification | `medium` | `system` |
+   | Table row action | `high` | `pointer` |
+
+   The default for a role not listed is `medium` / `pointer`, stated in the
+   brief as a default rather than left blank.
 3. **Inventory — only when an artifact was provided, and before you build.**
    List the artifact's **interactions, keyframes, and script includes** from its
    source (`design-fidelity-mechanics` § Data-basis ladder — read it, do not

package/dist/agent-src/skills/fe-design/references/craft-floor.md

@@ -43,6 +43,13 @@ the moment the floor has to be present. Same content, later delivery.
     An undeclared pick is an undeclared choice (T7).
 12. **Zero silent drops.** A mechanic present in a supplied source and absent
     from the output, with no `flagged` entry, is a silent drop.
+13. **Shipped motion carries a `feel` line naming its method.** Duration and
+    easing being inside the bands in
+    [`design-patterns.md`](design-patterns.md) § Motion is a static check, and
+    motion that passes it can still be wrong to watch. The line names one of
+    `slow-motion` · `frame-step` · `device` · `next-day` and its outcome; an
+    outcome of `unbacked` is legal, an absent method is not
+    (`docs/contracts/evidence-artifact-types.md` § `feel`).
 
 ## What is NOT on this page
 

package/dist/agent-src/skills/fe-design/references/design-patterns.md

@@ -152,6 +152,16 @@ Step indicator (1 — 2 — 3)
 
 ## Motion — decision-tree and rationale
 
+This section is the **sole carrier** of motion duration bands, easing choice and
+the bounce prohibition; the five files that restate any of them are bound to the
+values below and are checked against them by
+`src/scripts/lint_motion_authority_drift.ts`:
+`src/skills/design-intelligence/references/design-rules-checklist.md`,
+`src/skills/design-intelligence/data/ux-guidelines.csv`,
+`src/skills/design-intelligence/data/app-interface.csv`,
+`src/skills/design-intelligence/data/styles.csv`,
+`src/skills/design-intelligence/data/motion.csv`.
+
 Before adding any animation to a UI element, run through this decision tree:
 
 **1. Should this animate at all?**
@@ -162,8 +172,8 @@ Before adding any animation to a UI element, run through this decision tree:
 
 **2. Which easing?**
 - Entering (element appearing)? **ease-out** (starts fast, slows to rest). Why: the element arriving quickly signals responsiveness; the deceleration feels natural as it settles.
-- Exiting (element disappearing)? **ease-in** (starts slow, accelerates out). Why: the reverse is true — fast exit signals completion.
-- **Never ease-in for entering elements.** Why: ease-in delays the initial movement — the exact moment the user is watching most closely — making it feel slow even at the same total duration.
+- Exiting (element disappearing)? **ease-out** as well. Why: one curve in both directions is the value a reader can hold and a gate can check; the field has no settled answer on exit easing, so a single shared curve removes the contradiction between carriers instead of propagating it. This line settles the **curve** only — how long an exit runs relative to its enter is a separate question it does not answer.
+- **Never ease-in, in either direction.** Why: ease-in delays the initial movement — the exact moment the user is watching most closely — making it feel slow even at the same total duration.
 - **Never bounce or elastic easing in UI.** Why: bounce draws attention to the animation itself, not the content; it feels dated.
 
 **3. How long?**
@@ -199,6 +209,41 @@ The six interaction states every interactive element must assert are
 [`design-review`](../../design-review/SKILL.md)'s; this entry is the motion half
 of the hover one.
 
+**6. Which mechanism carries it?**
+
+Steps 1-5 decide *whether* and *how much*. This step decides *with what*, and it
+is the step the tree used to skip: a CSS `transition` was the implicit answer to
+everything, which is why an entry animation on a `<dialog>` or a popover
+silently does nothing and a shared-element route change gets hand-rolled.
+
+- **A CSS `transition` on `transform` and `opacity`** is the default and covers
+  most of steps 1-5. Reach past it only for the cases below.
+- **An element entering or leaving the DOM, or the top layer** (`<dialog>`,
+  `popover`) has no "before" state to transition from and is gone before an exit
+  could run. That is what `@starting-style` is for — it supplies the entry's
+  starting values — together with `transition-behavior: allow-discrete` so
+  `display` and `overlay` participate instead of snapping. Without both, the
+  animation is not slow or wrong; it does not happen.
+- **The Web Animations API** (`Element.animate()`) is the mechanism when the
+  values are computed at runtime, when the animation must be interruptible
+  (`Animation.cancel()`, `.reverse()`, `.finished`), or when several elements
+  share one timeline. A keyframe set known at author time does not need it.
+- **A view transition** (`document.startViewTransition()`) is the mechanism for
+  a state or route change where an element persists across the change. It is the
+  first-party form of what a hand-built shared-element transition approximates,
+  and it is the case the 300-500ms page-transition band is for.
+- **`transform-origin`** decides where a `scale()` grows from. A menu or popover
+  scaling in should originate at its trigger, not at its own centre, or it reads
+  as arriving from nowhere. Scale in from ~0.96, never from `scale(0)`: growing
+  from nothing is an entrance, and steps 1-2 asked for feedback.
+- **`@media (hover: hover)`** gates any hover-carried motion. Without it a touch
+  device fires the hover treatment on tap and leaves it stuck, because there is
+  no pointer to leave.
+
+All six still obey step 3's bands, step 2's single `ease-out` curve, and the
+`@media (prefers-reduced-motion: reduce)` requirement above — a newer mechanism
+is not an exemption from the authority, it is another way of spending it.
+
 **4. What to animate?**
 Animate `transform` and `opacity` only. Why: these run on the GPU compositor thread, not the main thread; they never trigger layout or paint.
 `scale(0)` → `scale(1)` is wrong. Why: nothing in the real world appears from nothing. Use `scale(0.95)` + `opacity: 0` → `scale(1)` + `opacity: 1` instead.

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

@@ -176,6 +176,40 @@ complexity: lightweight  # default — skips bite-sized granularity
 
 Source: adapted from an external reference; complexity-gating is our addition (Council Round 1, Q4 — mitigates UX pushback for senior engineers on well-scoped work).
 
+## The four plan criteria — what a reviewer fails a plan on
+
+The 3-scan self-review below catches mechanical gaps. These four catch the plan
+itself. Each is written so a reviewer can **fail** on it: the criterion states
+what failing looks like, not what passing feels like. A plan that cannot be
+failed on any of the four has not been reviewed, it has been read.
+
+1. **Necessity** — every phase, step and artifact in the plan is traceable to a
+   stated problem or acceptance criterion. **Fails when** the plan contains work
+   no requirement asked for: a new abstraction with one caller, a migration for a
+   field nothing reads, a "while we're in there" refactor, a config surface
+   nobody requested. Name the orphan step and the requirement it does not map to.
+2. **Sufficiency** — every stated requirement and acceptance criterion is
+   discharged by at least one step. **Fails when** a requirement has no owning
+   step, or when the only step that claims it is a heading with no verifiable
+   outcome under it. This is the mirror of Necessity and is checked in the
+   opposite direction: walk the requirements, not the steps.
+3. **Ordering** — no step depends on the outcome of a step that comes after it,
+   and the load-bearing unknown is resolved before the work that assumes it (see
+   [`complexity-first-planning`](../complexity-first-planning/SKILL.md)).
+   **Fails when** step N consumes something step N+2 creates, or when the plan
+   builds three cheap phases on an integration nobody has proven yet.
+4. **Groundedness** — every command, skill, command-verb and tool the plan tells
+   someone to run **exists**. **Fails when** the plan names a verb, skill or
+   command that is not in the index. Check it against
+   [`CAPABILITIES.yaml`](../../../CAPABILITIES.yaml) at the repository root — the
+   generated capability index listing every shipped skill and command per
+   capability area — plus the project's own script/task entry points for anything
+   the index does not cover. This is the one of the four that is decidable
+   without judgement, so it is the one that should never be waved through.
+
+A failure on any of the four is a blocker, not a note: fix the plan and re-run
+the criterion, or move the item to *Open questions* with the reason.
+
 ## Self-review (3-scan checklist)
 
 Before presenting any plan, run these three scans in order. Each is a fast pass — not a deep review. Failures block presentation; fix and re-scan.

package/dist/agent-src/skills/git-workflow/SKILL.md

@@ -100,21 +100,46 @@ Work complete. What would you like to do?
 ### Option 1: Push and create PR
 
 1. Run quality pipeline + tests (only when `quality.local_auto_run: true`; default `false` → skip, remote CI is the gate).
-2. `git push -u origin <branch>`.
-3. `gh pr create` using PR template.
+2. **The push-ready sequence** — fetch → integrate the base SET → regenerate →
+   verify → re-check freshness (this repo wires it as a `push-ready` task target;
+   a consumer wires its own). Not optional housekeeping: see § A push closes its
+   own loop. A stale push is refused, so skipping this buys the refusal.
+3. `git push -u origin <branch>`.
+4. `gh pr create` using PR template.
+5. **Settle it** — the turn is not over at step 4:
+   `npx tsx node_modules/@event4u/agent-config/src/scripts/ci_settle.ts <pr>`
 
-### Option 2: Keep as-is
+## A push closes its own loop
 
-Report: "Branch `<name>` preserved locally." — do nothing.
-
-### Option 3: Discard
-
-**Confirm first** — list branch name and commit count.
-Wait for explicit confirmation. Then:
-```bash
-git checkout main
-git branch -D <feature-branch>
 ```
+A PUSH IS NOT A DELIVERY. THE EVIDENCE FOR A PUSH IS THE CI VERDICT,
+NEVER THE PUSH'S OWN EXIT CODE.
+BEHIND THE BASE → INTEGRATE BEFORE PUSHING, NEVER AFTER THE PR IS RED.
+RED AFTER PUSHING → FIX IT IN THE SAME TURN, OR SAY PLAINLY THAT YOU DID NOT.
+NEVER HAND THE USER A RED PR WITH ITS CAUSE NAMED AND UNFIXED.
+```
+
+Two halves, failing differently, over the 30 sessions and 50 PRs before
+2026-09-04. **Stale base**: 25 of 50 PRs carried a `Merge branch 'main' into …`
+commit (52 in total), and the three most-failing workflows are the base-relative
+ones — a branch pushed behind its base was verified against a base it no longer
+merges into. **Unsettled push**: 22 of 30 sessions ran `gh run view
+--log-failed`, and 20 of 50 PRs carried a follow-up `fix(ci|gates|budget)`
+commit. Only 19 of 50 landed with neither. Each half now has a deterministic
+carrier — the pre-push hook refuses a verified-behind branch and points at the
+push-ready sequence; the `push-settle` PostToolUse concern fires the moment git
+reports a ref advanced. Neither replaces the discipline: the hook is skippable
+with `AGENT_CONFIG_SKIP_PREPUSH_FRESHNESS=1` for a genuine WIP push, and the
+settle reminder is advisory, because leaving a push deliberately unsettled is
+legitimate — **ending the turn silently on one is not**.
+
+`ci_settle` non-zero → read only the failing part
+(`gh run view --job <id> --log-failed | grep -E '×|FAIL|Error'`), fix, push
+again; the author of the red is irrelevant (`fix-what-you-see`). Three failed
+attempts on one target → stop and surface them (`autonomous-execution` N=3).
+Exit `2` is **not** a verdict — the wait timed out or the API could not be read.
+Counts, carrier limits and the honest cost:
+[`references/push-closes-its-loop.md`](references/push-closes-its-loop.md).
 
 ## PR template
 

package/dist/agent-src/skills/git-workflow/references/push-closes-its-loop.md

@@ -0,0 +1,176 @@
+# A push closes its own loop — the measurement
+
+Reference for [`git-workflow`](../SKILL.md) § A push closes its own loop. The
+obligation lives in the skill; this file carries the evidence behind it and the
+two deterministic carriers that now exist, so neither has to be re-derived and
+neither inflates the skill body.
+
+## What was measured
+
+Corpus: the 30 most recent local session transcripts and the 50 most recent
+pull requests on this repository, read on 2026-09-04. Session events are counted
+from git's and `gh`'s own literal output in the transcripts, never from prose
+about them; PR workflow runs come from `actions/runs?event=pull_request`, which
+paginates out at 1,000 runs and therefore covers **36** of the 50 PRs — the
+older 14 are unmeasured, not clean, and are excluded from that row rather than
+counted as green.
+
+### Half one — the stale base
+
+| Signal | Count |
+|---|---|
+| PRs carrying ≥ 1 `Merge branch 'main' into <branch>` commit | **25 / 50** |
+| Such merge commits in total | **52** |
+| Sessions hitting a literal `CONFLICT (content)` / `Automatic merge failed` | **10 / 30** |
+| Sessions hitting a rejected push (`Updates were rejected` / non-fast-forward) | **20 / 30** |
+
+The worst single PRs needed four and five separate base merges. What that
+buys is not only conflict work: the three workflows that failed most —
+**Tests (18), Consistency (16), Rule Backstops (13)** — are the base-relative
+ones. Ratchets, budgets and generated counts are green against the base a branch
+forked from and red against the base it merges into, so a branch pushed behind
+its base was verified against a question nobody asked.
+
+### Half two — the unsettled push
+
+| Signal | Count |
+|---|---|
+| Sessions running `gh run view --log-failed` (a red job was investigated) | **22 / 30** |
+| PRs with ≥ 1 FAILED workflow run (of the 36 readable) | **17** |
+| Failed runs in total | **56** |
+| PRs carrying a follow-up `fix(ci\|gates\|budget\|deps\|tests)` commit | **20 / 50** |
+| Such repair commits in total | **41** |
+
+Every one of those pushes SUCCEEDED. What failed was the ending: the push
+returned 0, the turn closed, and the red arrived where the user found it.
+
+**Only 19 of 50 PRs landed with neither half.**
+
+## The two carriers
+
+| Half | Carrier | Behavior |
+|---|---|---|
+| Stale base | `check_branch_freshness` in the pre-push hook (`src/scripts/install-hooks.sh`) | Asks the REMOTE, one `ls-remote`, ~4.5 s. Refuses only on a VERIFIED behind state and names the push-ready sequence. Never merges. |
+| Unsettled push | the `push-settle` PostToolUse concern (`src/scripts/hooks/push_settle_hook.ts`) | Fires on git's own ref-advance report, resolves the PR number, and names the literal `ci_settle` command. Warn only. |
+
+### What each one does NOT do
+
+- **The hook never merges.** Resolution belongs to a step run with the result in
+  front of you; a hook that rewrites the tree at the moment the contributor
+  believes their work is finished turns one refused push into an unreviewed
+  commit. It refuses and names the push-ready sequence instead.
+- **The hook cannot see an unverifiable base.** Offline, in CI, on a detached
+  HEAD, or standing on the base itself, `check_branch_freshness` exits 0 and
+  says which — so an unreachable network never blocks a push, and a green there
+  means "did not refuse", not "current".
+- **The concern cannot block.** It is `severity: advisory`,
+  `fail_closed: false`. Leaving a push deliberately unsettled is legitimate;
+  ending the turn silently on one is what the reminder exists to stop. Whether
+  the reminder changes behavior is unmeasured — it ships as a carrier, not as a
+  claim.
+- **Neither reaches a host without the slot.** `agent-config hooks:status`
+  answers which slots are bound where you actually are; `post_tool_use` is
+  unbound on windsurf and copilot, and there the settle obligation is
+  model-carried by the skill alone.
+
+## Cost, stated rather than implied
+
+The pre-push gate set was already measured at 36.05 s against the 25 s
+`pre_push_budget_seconds` ceiling in `src/config/ci-local-parity.yml`, and the
+freshness gate adds ~4.5 s on the green path. That is a real cost on an already
+over-budget hook, and it is recorded here rather than hidden: the trade is 4.5 s
+per push against 52 base merges and 56 failed runs across 50 PRs. On the RED
+path the hook gets *cheaper*, not dearer — the refusal exits before the ~10 s
+regeneration and the preflight set, because everything after it would be
+answered against a base that is about to move.
+
+## The gap this change does NOT close
+
+**The pre-push hook is INSTALLED, not read from source.** `install-hooks.sh`
+writes `.git/hooks/pre-push`, and afterwards it is rewritten only by the
+package manager's post-install lifecycle step or by running the installer
+again. Measured in this repository on 2026-09-04, before this change: the
+installed hook was
+**113 lines** against a source body of ~146 — it was missing header revisions
+merged on 2026-08-30, so it had been stale for days with no signal anywhere.
+
+The freshness gate therefore does nothing on a checkout whose hook predates it,
+and the contributor is not told. That is a real hole in a change whose whole
+subject is "the agent should not leave work for the user to discover", and it is
+recorded rather than papered over:
+
+    task install-hooks     # rewrites .git/hooks/* from source
+
+### Closed 2026-09-05 — the contributor is now told
+
+`check_installed_hooks_fresh` renders what `install-hooks.sh` would write into a
+scratch directory and compares content AND the executable bit against
+`.git/hooks`. It runs in the pre-push body — advisory, and after the
+base-freshness gate — and again from the `post-merge` / `post-checkout`
+auto-sync block, at the moment a pull causes the drift.
+
+**It reports and never refuses, and the ordering is part of the answer.** The
+predicate is "installed == what THIS checkout renders", and `.git/hooks` is
+shared by every linked worktree, so with two worktrees whose installer bodies
+differ at most one satisfies it at a time — a refusal would fire on ordinary
+parallel work and the skip variable would become routine, which retires the
+check rather than enforcing it. And being behind a base that moved the installer
+is the commonest cause of a mismatch, whose repair is to MERGE: re-installing
+from a behind-base checkout writes the older hook set over the shared directory.
+Base freshness therefore answers first, and the notice never prescribes a
+re-install as universally correct. On the checkout that closed the gap it found `pre-push`, `post-merge` and
+`post-checkout` all stale — the same drift, five days on and one hook wider.
+
+It compares rendered output rather than slicing these heredocs, because
+`post-merge` and `post-checkout` are a heredoc PLUS an appended block: no slice
+of the installer equals what it installs, so a slice-based comparison would have
+been wrong for two of six hooks.
+
+**What was deliberately NOT built: the repair.** The roadmap asked for
+`post-merge` to re-run the installer so the hooks fixed themselves with no
+command. Two findings stopped it, and both are worth keeping.
+
+1. **Measured 2026-09-05:** a bash script that `cat >`-overwrites its own path
+   mid-run stops executing at that point and **exits 0**. Every statement after
+   it is skipped, silently. A repair placed in `post-merge` would truncate
+   `post-merge`'s own remaining body — the projection sync and the CLI rebuild —
+   and report success. Any future attempt needs the installer to stage and
+   `mv` into place first.
+2. **Linked worktrees share one `.git/hooks`** through the common dir. "The
+   installed hooks match the checked-out tree" has no unique referent when eight
+   worktrees hold eight versions of the installer: a repair would let whichever
+   worktree checked out last redefine the gates all the others run, and a
+   checkout of an older branch would reinstall older hooks over newer ones.
+
+An AI council (`claude-sonnet-4-5` + `codex-default`, 2026-09-05, two rounds,
+2 of 2 seats present in both) reached the same verdict independently in both
+seats: report, do not repair. *Reopen* on either per-worktree hook isolation
+(`core.hooksPath`) or a branch-independent dispatcher installed once in the
+common dir — both make "which version is authoritative" answerable, which is the
+question the repair cannot currently answer.
+
+### Answered 2026-09-05 — consumers get no git hooks, by decision
+
+A consumer install writes **no git hooks at all** (`src/install/` references
+`.git/hooks` nowhere, and the package manager's post-install lifecycle step does
+not run for a registry dependency), so the pre-push gate is a maintainer-only
+mechanism. The same council, unanimously, made that the decision rather than the
+status quo: the pre-push chain runs this repository's own consistency and
+preflight gate chains, which depend on its Taskfile, its `./scripts-run` shim
+and its generated trees — none of which exist in a consumer project — and a
+dependency install should not establish persistent repository execution. *Revisit-if* a
+consumer-native gate set is designed with its own opt-in command and consent
+step; that is a product feature, not an extension of this installer. Stated for
+consumers in `docs/development.md` § "Git hooks are maintainer-only". Named
+rather than linked: this file is projected byte-identically into
+`dist/agent-src/`, which sits one level deeper, so a repo-root-relative link
+resolves in one copy and not in the other.
+
+## Revisit-if
+
+- A later corpus shows base merges and post-push repair commits at a rate the
+  carriers cannot explain — then the carriers are firing and not landing, and
+  the next lever is delivery, not another reminder.
+- `pre_push_budget_seconds` is enforced by something. Today nothing measures the
+  hook, which is how the set grew past its own ceiling with no signal; once it
+  is measured, this gate is one of the entries that has to justify its slice.

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

@@ -167,6 +167,50 @@ Route::get('/mail-preview', function () {
 });
 ```
 
+## Surviving the mail client
+
+An email is not a web page. Mail clients strip, rewrite, and ignore CSS that
+every browser honors, so a template that renders correctly in
+`/mail-preview` tells you nothing about the inbox. Markdown templates (above)
+give you a tested baseline for free — this section is what to hold to when a
+design forces you off them.
+
+**Four requirements, in order of what breaks first:**
+
+1. **Table-based layout, not flexbox or grid.** Use nested `<table>` elements
+   with `role="presentation"`, a fixed outer width of 600px, and `cellpadding`
+   / `cellspacing` / `border` set to `0`. `display: flex` and
+   `display: grid` are unsupported or partially supported in the Windows
+   Outlook family and collapse to a single stacked column.
+2. **Inline styles, not a `<style>` block.** Write `style="…"` on the element.
+   A `<head><style>` block is stripped outright by some webmail clients, and
+   class selectors then match nothing. Use a CSS inliner at build time if the
+   template is authored with classes — never ship the classes unresolved. Keep
+   a `<style>` block only for what cannot be inlined (media queries), and treat
+   everything in it as optional.
+3. **No web fonts, no background images, no external JS.** Declare a font stack
+   ending in a system fallback; a remote font silently degrades. Background
+   images require the `v:fill` VML fallback in Outlook, so put the color on
+   `bgcolor` and treat the image as decoration.
+4. **Explicit width and alt text on every image, and no image-only content.**
+   Images are blocked by default in several clients, so an email whose call to
+   action is an image is an email with no call to action.
+
+**The client list worth testing, and what breaks in each:**
+
+| Client | What breaks |
+|---|---|
+| **Outlook 2016-2019 / Windows (Word engine)** | `flex`, `grid`, `float`, `max-width`, `border-radius`, background images, `padding` on `<div>`; the strictest target — if it renders, most others do |
+| **Outlook.com / Outlook 365 web** | strips `<style>` blocks in some views; rewrites `class` attributes; ignores `margin` on several elements |
+| **Gmail web** | clips the message past ~102 KB of HTML with a "view entire message" link — anything below the clip, including the unsubscribe link, is not seen; strips `<style>` when the message is clipped |
+| **Gmail app (iOS / Android)** | no support for embedded `<style>` on non-Gmail accounts; media queries ignored there, so the mobile layout must be the fluid default |
+| **Apple Mail / iOS Mail** | the most permissive; auto-scales small text and auto-links dates and addresses unless suppressed — a false green if it is the only client you check |
+| **Dark mode (Apple Mail, Outlook, Gmail)** | colors are force-inverted; a logo on a hardcoded white background becomes a white box on dark, and `#000` text on a transparent background becomes invisible |
+
+**Verify against a real client, not a preview route.** `/mail-preview` renders in
+a browser and proves none of the above. Send to real accounts, or use a
+rendering service, before the template ships.
+
 ## Core rules
 
 - **Always queue emails** — implement `ShouldQueue` to avoid blocking requests.

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

@@ -118,7 +118,9 @@ Schedule::command('queue:work')->everyMinute()->evenInMaintenanceMode();
 ## Running the scheduler
 
 ```bash
-# The scheduler itself runs every minute via system cron
+# The scheduler itself runs every minute via system cron.
+# cron has no working directory to inherit, and artisan takes no directory
+# flag, so the `cd` is the shape here rather than a habit worth replacing.
 * * * * * cd /path-to-project && php artisan schedule:run >> /dev/null 2>&1
 
 # Test locally

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

@@ -350,12 +350,6 @@ After detecting **any** match, record the stack in the analysis output and selec
 2. Tech stack inventory with versions and dependencies
 3. Architecture diagram or module map
 
-## Auto-trigger keywords
-
-- project analysis
-- codebase analysis
-- architecture analysis
-
 ## Gotcha
 
 - Full project analysis can take several minutes — warn the user about the time investment.

package/dist/agent-src/skills/react-native-setup/SKILL.md

@@ -113,8 +113,8 @@ Before installing or upgrading anything, inspect what's already there — modify
 - Stuck pods: `pod deintegrate && pod install`.
 
 **Build failures**
-- Clean iOS: `cd ios && rm -rf build Pods Podfile.lock && pod install && cd ..`.
-- Clean Android: `cd android && ./gradlew clean && cd ..`.
+- Clean iOS: `rm -rf ios/build ios/Pods ios/Podfile.lock` then `pod install --project-directory=ios`.
+- Clean Android: `./gradlew -p android clean`.
 - Clear Xcode derived data when stale build artefacts persist.
 
 **New Architecture issues**
@@ -142,7 +142,7 @@ echo $ANDROID_HOME      # non-empty
 ```bash
 npx @react-native-community/cli init MyProject
 cd MyProject
-cd ios && RCT_NEW_ARCH_ENABLED=1 pod install && cd ..
+RCT_NEW_ARCH_ENABLED=1 pod install --project-directory=ios
 npm start                # Metro
 npm run ios              # in a second terminal
 npm run android          # in a third terminal

package/dist/agent-src/skills/react-shadcn-ui/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: react-shadcn-ui
-description: "Use when building React UI on shadcn/ui primitives + Tailwind — the apply/review/polish skill dispatched by `directives/ui/*` for the `react-shadcn` stack."
+description: "Building React UI on shadcn/ui primitives + Tailwind — the apply/review/polish skill dispatched by `directives/ui/*` for the `react-shadcn` stack; idiom from tailwind-engineer."
 domain: engineering
 workspaces:
   - engineering

package/dist/agent-src/skills/sequential-thinking/SKILL.md

@@ -129,12 +129,22 @@ Explore alternatives when:
 1. Numbered reasoning steps with conclusions
 2. Final answer or recommendation with confidence level
 
-## Auto-trigger keywords
+## Tool availability — this is a procedure, not a tool call
 
-- problem solving
-- step-by-step
-- reasoning
-- decomposition
+Everything above runs **in-session**: it is a way of structuring reasoning, and
+it needs nothing installed.
+
+The wider MCP ecosystem carries a `sequentialthinking` server exposing a tool of
+that name. **This package registers no MCP server** — `mcp.json` ships
+`{"servers": {}}` — so on a default install that tool is not present, and
+nothing here tries to call it. Registering one is a consumer-side install
+decision this package deliberately does not make for you.
+
+So a reader on a default install can answer the question directly: the tool is
+not available to you, and none of this skill depends on it. If you have
+registered such a server yourself, the once-per-task limit below governs that
+call too — the limit is about looping, not about which mechanism does the
+thinking.
 
 ## Gotcha
 
@@ -145,9 +155,9 @@ Explore alternatives when:
 ## Do NOT
 
 - Do NOT use this for simple, well-understood tasks — it adds unnecessary overhead.
-- Do NOT call `sequentialthinking` more than **once per task**. If you're calling it repeatedly,
-  you're looping — stop and act directly instead.
-- Do NOT use `sequentialthinking` as a "thinking proxy" — if the task is "view a file" or
+- Do NOT run this procedure more than **once per task**. If you are reaching for it
+  repeatedly, you are looping — stop and act directly instead.
+- Do NOT use it as a "thinking proxy" — if the task is "view a file" or
   "run a command", just do it. No thinking step needed.
 - Do NOT skip the validation step — always check the solution against the original problem.
 - Do NOT ignore contradictions — they are signals, not noise.

package/dist/agent-src/skills/tailwind-engineer/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: tailwind-engineer
-description: "Use when writing or reviewing Tailwind CSS — utility-first, design-token discipline, no inline-style drift, responsive variants, dark mode — even on 'style this' or 'mach das hübsch'."
+description: "Writing or reviewing Tailwind CSS — utility-first, design tokens, no inline-style drift, responsive variants, dark mode — 'style this' or 'mach das hübsch'. Pairs with react-shadcn-ui."
 personas:
   - frontend-engineer
 domain: engineering

package/dist/agent-src/skills/testing-anti-patterns/SKILL.md

@@ -208,6 +208,46 @@ rg -n '\b(it|test|describe)\.skip\b|\.only\b|xit\(|xdescribe\(|@pytest\.mark\.(s
 
 This is the test-surface instance of the `autonomous-execution` N=3 / allowlist-growth antipattern (bulk `skip`/`xfail` to force green counts as the tool being wrong, not the content) and the `verify-before-complete` floor (green must be *earned*, not manufactured).
 
+### The named smells — canonical vocabulary, and what it does NOT cover
+
+The behaviors above are described; two of them also have field names a
+reviewer can cite, and this table is where the name meets the behavior. The
+grep column follows the shape [`ai-code-blindspots`](../ai-code-blindspots/SKILL.md)
+uses: an authoring-time backstop, zero results is the pass, a hit is a prompt
+to read that line — never an auto-fix.
+
+| Canonical name | The behavior, as already described above | Backstop grep |
+|---|---|---|
+| **Magic-number test** | Anti-Pattern 6 — "a hardcoded expected value the code will always emit". The expectation is a literal rather than something derived from the input, so the test cannot disagree with the code. | `rg -n '\b(toBe\|toEqual\|assertEquals\|assertSame)\(\s*-?[0-9]{2,}' tests/` |
+| **Assertion roulette** | The multi-case stack Anti-Pattern 6 *requires* (boundary, error, abuse in one test), written without per-assertion messages — so a failure names a line number and not a reason. The stack is right; the silence is the smell. | `rg -c '\b(expect\|assert\w*\|self\.assert\w*\|\$this->assert\w*)\(' tests/ \| awk -F: '$2 >= 8'` |
+
+Both greps are scoped to **the test file you just wrote**, not to a tree —
+`tests/` above is a placeholder for that path. Run over a whole repository
+they are useless as verdicts: measured on this repository on 2026-09-04 the
+first returns 585 lines and the second 1189 files, because an exact assertion
+against a two-digit literal and a file with eight assertions are both ordinary.
+They are authoring-time prompts to reread one file, exactly as
+`ai-code-blindspots` states, and neither is a gate.
+
+The second grep counts per **file**, not per test — no regex sees a test
+boundary.
+
+**Three further names are deliberately NOT in the table**, recorded here so a
+later round meets a record rather than a fresh argument. Measured 2026-09-04
+over both files of this skill: `roulette`, `eager`, `lazy` and `duplicate` each
+return **0** occurrences, and `hardcoded` returns **6**.
+
+- **Eager test** (one test exercising several behaviors) would carry the same
+  behavior and the same grep as assertion roulette above, and Anti-Pattern 6
+  *prescribes* the shape on purpose. A row for it would be one entry under two
+  names, which is the drift this table exists to prevent.
+- **Lazy test** (several tests over one fixture, differing only in name) is
+  described nowhere above. A row would be new guidance wearing a naming step's
+  clothes.
+- **Duplicate assert** (the same condition asserted twice in one test) is
+  likewise undescribed, and is not greppable without parsing test boundaries —
+  so it could not carry the backstop column even if it were.
+
 ## Output format
 
 1. The mocking decision recorded as a one-line comment in the test file (`// mock at <seam>: <reason>`).

package/dist/agent-src/skills/ui-apply-generic/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: ui-apply-generic
-description: "Use when implementing a UI brief on a stack with no framework executor — Svelte, Astro, Angular, plain HTML. Carries the stack-independent contract; idiom comes from the stack corpus."
+description: "Use when implementing a UI brief on a stack with no framework executor — Svelte, Astro, Angular, plain HTML. Stack-independent sibling of react-shadcn-ui; idiom from the stack corpus."
 personas:
   - frontend-engineer
 domain: engineering

package/dist/agent-src/skills/ui-component-architect/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: high
 name: ui-component-architect
-description: "Use when shaping a UI component tree — composition vs inheritance, slot patterns, prop API design, controlled vs uncontrolled, polymorphic — even on 'split this component'."
+description: "Shaping a UI component tree — composition vs inheritance, slot patterns, prop API design, controlled vs uncontrolled, polymorphic — on 'split this component'. Feeds react-shadcn-ui."
 personas:
   - frontend-engineer
 domain: engineering