lazycodex-ai 5.1.61 → 5.1.63

package/packages/shared-skills/skills/frontend/references/design/README.md

@@ -12,7 +12,7 @@ Restraint with a visible hierarchy. The brief's primary action is the one promin
 - **Layer A, taste skills (12 files, named `-skill.md` or `imagegen-`):** how to execute. Discipline, spacing, motion physics, anti-slop guardrails, output completeness.
 - **Layer B, design systems (70 brand files):** what it looks like. Concrete colour, type, and component tokens for one brand.
 
-`_INDEX.md` lists all 83 with mood-to-brand mappings and stacking rules; read it when routing is not obvious. Most non-trivial tasks load one from each layer. For a brand or style outside the curated set, or when the user says "Open Design", load the `open-design` skill (the local nexu-io/open-design library, 150+ design systems) as the expanded library; this file keeps routing discipline, the `DESIGN.md` gate, and execution quality.
+`_INDEX.md` lists all 83 with mood-to-brand mappings and stacking rules; read it when routing is not obvious. Most non-trivial tasks load one from each layer. For a brand or style outside the curated set, or when the user says "Open Design", use the nexu-io/open-design library (https://github.com/nexu-io/open-design), 150+ design systems, as the expanded library; this file keeps routing discipline, the `DESIGN.md` gate, and execution quality.
 
 ## Phase 0: Design System Gate (before routing, before any UI code)
 
@@ -23,7 +23,7 @@ Look for `DESIGN.md`, `design-system.md`, or `design-tokens.md` at the project r
 **It does not exist: read `design-system-architecture.md` for the structure, then take the branch:**
 
 1. **Greenfield, no concrete reference.** Research is a build step with named deliverables, not exploration to budget: run the lanes in parallel and open `DESIGN.md` with `## 0. Research Log`, one line per lane. A lane with no line did not run; skip a lane only when its tool or network is unavailable, and name the skip there.
-   - *Embedded references:* shortlist 2-3 plausible Layer B candidates from `_INDEX.md`, then read ONE Layer A style skill and ONE Layer B reference in full, every line (they are 200-500 lines; a sliced read produces the flattened token set this gate exists to prevent). Log the shortlist, the pick, and why. `open-design` only when the curated set has no fit; `ui-ux-db` lookups for palette, type, and domain questions that come up here.
+   - *Embedded references:* shortlist 2-3 plausible Layer B candidates from `_INDEX.md`, then read ONE Layer A style skill and ONE Layer B reference in full, every line (they are 200-500 lines; a sliced read produces the flattened token set this gate exists to prevent). Log the shortlist, the pick, and why. The open-design library only when the curated set has no fit; `ui-ux-db` lookups for palette, type, and domain questions that come up here.
    - *Lazyweb real-product screens:* read `lazyweb.md` FIRST and run its recipe verbatim; it mints its own anonymous token, so never improvise curl calls against the host. Log the queries, how many screens you actually viewed, and the layout grammar taken, never pixel copies. When the harness has the user's own Mobbin MCP connected, run its `search_screens`, `search_flows`, or `search_sections` in this lane too; never reach Mobbin any other way (`component-catalogs.md` section 2). For every reference keep the product name and URL, write what you saw apart from what you recommend, and treat a recurring pattern as a convention, not proof. If the findings lean on one product, widen the set before you build.
    - *StyleGallery:* read `stylegallery.md`, fetch the pattern whose primary spatial problem matches the screen, and write the `Layout:` line.
    - *Imagen concept drafts:* generate 2-3 drafts, each seeded with the loaded Layer A + Layer B tokens (palette, type, material); pick the strongest and treat it as the reference-fidelity contract. Log the paths and the pick.

package/packages/shared-skills/skills/frontend/references/design/component-catalogs.md

@@ -15,7 +15,7 @@
 | Tailwind-only, no React, server-rendered HTML | daisyUI class components | - | Motion is CSS transitions on `DESIGN.md` section 6 tokens. |
 | Charts and data viz | `ui-ux-db` `--domain chart` for the chart type | bklit for animated chart source; MUI X Charts on Material projects | Section 4. |
 | Landing sections: header, pricing, FAQ, logo cloud, stats, testimonials, footer | smoothui blocks, cult-ui blocks | the section galleries in section 2 (navbar, pricing, CTA, hero, footer) | Take structure only; copy and imagery stay the project's. |
-| A brand outside the 70 Layer B files | `open-design` skill | designmd.ai: community `DESIGN.md` files, MCP; read each file's licence first (its uploader picks MIT, CC0, CC-BY, CC-BY-SA, or a custom one) | Never refero styles (section 2). |
+| A brand outside the 70 Layer B files | The nexu-io/open-design library | designmd.ai: community `DESIGN.md` files, MCP; read each file's licence first (its uploader picks MIT, CC0, CC-BY, CC-BY-SA, or a custom one) | Never refero styles (section 2). |
 
 ## 2. Catalogs (measured 2026-10-06; microkit, motion-primitives, uiverse, and 21st.dev on 2026-10-25)
 

package/packages/shared-skills/skills/frontend/references/design/design-system-architecture.md

@@ -60,7 +60,7 @@ rather than borders, creating layers you feel more than see."
 | Status/info | --status-info | #2563EB | #3B82F6 | Informational |
 
 ### Rules
-- Accent marks the one or two most likely actions on a screen, on the control's background rather than its glyph or label. Peer choices differ by style, never by size. Nothing decorative carries accent.
+- Accent marks the screen's one primary action, on the control's background rather than its glyph or label; a second likely action takes a quieter style. Peer choices differ by style, never by size. Nothing decorative carries accent.
 - Never introduce a color not in this table. Extend the table first.
 
 ## 3. Typography
@@ -229,7 +229,7 @@ Both paths start with `grounding.md`: the guideline source read in full, the ide
 
 ### For New Projects
 
-1. **Select references before taste** — no visual reference means `_INDEX.md` shortlist of 2-3 Layer B candidates, then exactly one Layer A style skill and one Layer B brand/design-system reference. Use `open-design` only when the curated set has no fit.
+1. **Select references before taste** — no visual reference means `_INDEX.md` shortlist of 2-3 Layer B candidates, then exactly one Layer A style skill and one Layer B brand/design-system reference. Use the open-design library only when the curated set has no fit.
 2. **Assemble from references** — extract tokens, layout grammar, component anatomy, states, motion, and taste decisions, then recombine them into project-specific primitives. Customize for the user's product; never copy logos, trademarked assets, or brand-specific copy.
 3. **Define the system** — colour roles first (both themes), then atmosphere, typography, spacing, and one depth strategy, grounded in the selected references and product semantics. Sanity-check the palette and type pairing with one `ui-ux-db` domain search (CLI in `references/ui-ux-db/README.md`).
 4. **Document initial primitives** — only components you are about to build, including variants and states, starting from shadcn/ui anatomy (or the project's own kit) restyled with the tokens.

package/packages/shared-skills/skills/frontend/references/design/print-paged-media.md

@@ -73,4 +73,4 @@ pdftoppm -png -r 150 report.pdf out/page   # one PNG per page
 
 Read every page image for: blank or near-empty pages, a block stranded alone after a keep-together push, a table or figure split mid-exhibit, a heading orphaned at a page foot, clipped or overflowing text, and a running header or footer that drifted or vanished.
 
-Extracting the text proves the words are present. It cannot see any defect in this list - layout is exactly the information that extraction discards. Fix, re-render, and look again until the pages are clean; the same standard governs the `ulw-research` delivery gate and the `mass-ulw` verification wave.
+Extracting the text proves the words are present. It cannot see any defect in this list - layout is exactly the information that extraction discards. Fix, re-render, and look again until the pages are clean. The `ulw-research` delivery gate and the `mass-ulw` verification wave hold the same page-by-page inspection standard; `ulw-research` bounds its repair loop (its `repair decide` stop rules) and ships any residual defect listed in its manifest.

package/packages/shared-skills/skills/frontend/references/design/react-dev-tooling-skill.md

@@ -222,7 +222,7 @@ If any of those leak into production, the dev gate is broken. Fix the gate befor
 ## Cross-skill references
 
 - For **render performance / Lighthouse 100** work, see `../perfection/react-perf-tooling.md` — Playwright + `react-scan/lite` integration used during automated audits.
-- For **debugging an in-flight React bug**, see `../../debugging/references/tools/react-devtools.md` — runtime/static use during a bug hunt rather than initial setup.
+- For **browser runtime inspection during an in-flight React bug** (rendered state, console, network), load the `debugging` skill and follow its `references/tools/browser-qa.md`; React-specific inspection uses the React dev tooling this file sets up.
 - The Phase 0 Design System Gate (in `README.md`) and this React Dev Tooling Gate are both pre-implementation gates. Run Phase 0 first (design system must exist), then this gate (dev tooling must be installed).
 
 ## Mantra

package/packages/shared-skills/skills/frontend/references/designpowers/lane-a-direction.md

@@ -1,17 +1,17 @@
 # Lane A: Direction & Discovery
 
-Lane A feeds `ulw-plan`. It does not replace Prometheus, write a parallel plan, or start implementation. Its job is to translate designpowers discovery, research, persona, taste, debate, and state capabilities into prompt context that lets `ulw-plan` produce a decision-complete work plan with design-specific acceptance criteria.
+Lane A feeds `ulw-plan`. It does not replace the `ulw-plan` planner, write a parallel plan, or start implementation. Its job is to translate designpowers discovery, research, persona, taste, debate, and state capabilities into prompt context that lets `ulw-plan` produce a decision-complete work plan with design-specific acceptance criteria.
 
 ## Phase Owner
 
 | Capability | Source boundary | owner | Mapping |
 |---|---|---|---|
-| Discover the human problem, constraints, audience, success criteria, and early taste signals | Authored concept preserved from excluded raw `design-discovery` | `ulw-plan` | Inject a compact design brief request before Prometheus drafts tasks. Prometheus still decides the plan structure and asks only unresolved owner decisions. |
+| Discover the human problem, constraints, audience, success criteria, and early taste signals | Authored concept preserved from excluded raw `design-discovery` | `ulw-plan` | Inject a compact design brief request before the planner drafts tasks. The planner still decides the plan structure and asks only unresolved owner decisions. |
 | Identify research gaps and inclusion-aware research methods | `research-planning` | `ulw-plan` | Convert research questions into plan discovery tasks or explicit assumptions with evidence requirements. |
 | Define principles, experience map, positioning, and success metrics | Authored concept preserved from excluded raw `design-strategy` | `ulw-plan` | Add strategy constraints and design principles to the plan's acceptance criteria. |
 | Represent the full ability spectrum | `inclusive-personas` | `ulw-plan` | Require personas and stress cases in plan inputs, including permanent, temporary, and situational contexts. |
 | Calibrate current-project taste and quality bar | Authored concept preserved from excluded raw `design-taste` | `ulw-plan` | Add live taste constraints for this project only; do not import cross-project memory as a design rule. |
-| Surface competing directions and trade-offs | `design-debate` | `ulw-plan` | When direction is ambiguous, ask Prometheus to present 2-3 options with accessibility and usability trade-offs before choosing defaults. |
+| Surface competing directions and trade-offs | `design-debate` | `ulw-plan` | When direction is ambiguous, ask the planner to present 2-3 options with accessibility and usability trade-offs before choosing defaults. |
 | Curate references and inspiration without copying | `inspiration-scouting` | `ulw-plan` | Add evidence-backed inspiration notes as optional plan context, with "what to take" and "what to leave." |
 | Maintain shared design state | Authored concept preserved from excluded raw `design-state` | `ulw-plan` | Read and update `.omo/frontend-design/state.md` as the OpenAgent-native state ledger. |
 
@@ -33,7 +33,7 @@ Before planning, extract or infer:
 - competing directions and trade-offs when direction is not settled
 - existing `.omo/frontend-design/state.md` decisions, debt, and open questions
 
-Add design-specific acceptance criteria to the Prometheus plan:
+Add design-specific acceptance criteria to the `ulw-plan` plan:
 - each UI task names the persona or journey it serves
 - each task has accessibility and cognitive-accessibility checks where relevant
 - each visual decision traces to a design principle, taste signal, or design-system token
@@ -52,7 +52,7 @@ Lane A passes only when the plan has inspectable design context, not vague inten
 ## Guardrails
 
 - `ulw-plan` owns the final plan. Lane A may enrich prompts, but it must not create a second planning lane or standalone design plan.
-- `writing-design-plans` content is used only as task-quality guidance; Prometheus remains the source of executable TODOs.
+- `writing-design-plans` content is used only as task-quality guidance; the `ulw-plan` plan remains the source of executable TODOs.
 - Cross-project memory is descriptive only and must not steer this project's direction unless the user states the preference now.
 - Direction debates pause for user decision when the trade-off is product-shaping, accessibility-critical, or hard to reverse.
 - No new scheduler, background automation, or project root design-state convention is introduced; state stays at `.omo/frontend-design/state.md`.

package/packages/shared-skills/skills/frontend/references/designpowers/routing.md

@@ -14,7 +14,7 @@
 
 ## Planning Through `/ulw-plan`
 
-When planning is needed, `designpowers` supplies design-specific context and lets `/ulw-plan` own the plan artifact. Do not write a separate design plan. The Prometheus plan should receive:
+When planning is needed, `designpowers` supplies design-specific context and lets `/ulw-plan` own the plan artifact. Do not write a separate design plan. The `ulw-plan` plan should receive:
 
 - product or page goal;
 - primary tasks and user journeys;
@@ -35,7 +35,7 @@ When a plan is approved or selected, `/ulw-execute` remains the orchestrator. `d
 - required `/visual-qa` loading for rendered visual proof;
 - the design debt rule: unresolved accessibility debt cannot disappear into a summary.
 
-Direct implementation outside `/ulw-execute` is not part of this routing contract when a Prometheus plan is active.
+Direct implementation outside `/ulw-execute` is not part of this routing contract when a `ulw-plan` plan is active.
 
 ## UI Build Through Frontend `design` And `perfection`
 

package/packages/shared-skills/skills/frontend/references/perfection/README.md

@@ -16,7 +16,7 @@ The correct path:
 3. Run Lighthouse against the Playwright-controlled page via `playwright-lighthouse` OR via `chrome-launcher` + the `lighthouse` Node API, attaching to the Playwright CDP endpoint so cookies, auth state, and warmed caches mirror what a real returning user sees.
 4. Use the **mobile** preset (4x CPU throttle, Fast 3G) for the primary number, AND the **desktop** preset for the secondary number. Report both.
 
-If the `playwright` skill is not loaded in this session, load it now via the `skill` tool.
+If no browser-automation skill is loaded in this session, load the `browser` skill now (read its `SKILL.md`).
 
 ### 2. 100 IN EVERY CATEGORY IS THE FLOOR.
 
@@ -90,7 +90,6 @@ Quick audit via the cross-platform Python CLI (macOS, Linux, Windows):
 
 ```bash
 uv run $SKILL_DIR/scripts/perfection/lighthouse-audit.py https://localhost:3000
-uv run $SKILL_DIR/scripts/perfection/lighthouse-audit.py https://localhost:3000 --threshold 95
 uv run $SKILL_DIR/scripts/perfection/lighthouse-audit.py https://localhost:3000 --desktop-only
 bun $SKILL_DIR/scripts/perfection/check-draft-guard.ts src/   # exit 1 = accent stripe or outline, promo copy, emoji icon, hype badge, or vanity stat
 ```

package/packages/shared-skills/skills/frontend/references/perfection/react-perf-tooling.md

@@ -20,17 +20,38 @@ If the project does not yet have react-scan and react-doctor wired into its dev
 import { chromium } from "playwright";
 import { playAudit } from "playwright-lighthouse";
 
+declare global {
+  interface Window {
+    __renderEvents: unknown[];
+  }
+}
+
+// Narrow only the fields this gate reads from a react-scan commit event.
+function hasUnnecessaryRender(event: unknown): boolean {
+  if (typeof event !== "object" || event === null || !("tree" in event) || !Array.isArray(event.tree)) return false;
+  return event.tree.some(
+    (node: unknown) =>
+      typeof node === "object" &&
+      node !== null &&
+      "changeDescription" in node &&
+      typeof node.changeDescription === "object" &&
+      node.changeDescription !== null &&
+      "kind" in node.changeDescription &&
+      node.changeDescription.kind === "unnecessary",
+  );
+}
+
 const browser = await chromium.launch({ channel: "chrome" });
 const context = await browser.newContext();
 
 // Inject react-scan/lite BEFORE the app boots
 await context.addInitScript(() => {
-  // @ts-ignore — pulled from the project's node_modules or a self-hosted bundle
+  // react-scan is a dev dependency of the project (see ../design/react-dev-tooling-skill.md), so its types resolve
   import("react-scan/lite").then(({ instrument }) => {
-    (window as any).__renderEvents = [];
+    window.__renderEvents = [];
     instrument({
-      onEvent: (event: any) => {
-        if (event.kind === "commit") (window as any).__renderEvents.push(event);
+      onEvent: (event) => {
+        if (event.kind === "commit") window.__renderEvents.push(event);
       },
       recordChangeDescriptions: true,
       includeFiberSource: true,
@@ -51,10 +72,8 @@ await playAudit({
 });
 
 // Pull render events and assert on render quality
-const events = await page.evaluate(() => (window as any).__renderEvents);
-const unnecessary = events.filter((e: any) =>
-  e.tree?.some((node: any) => node.changeDescription?.kind === "unnecessary"),
-);
+const events = await page.evaluate(() => window.__renderEvents);
+const unnecessary = events.filter(hasUnnecessaryRender);
 
 if (unnecessary.length > 0) {
   console.error(`FAIL: ${unnecessary.length} unnecessary renders detected during audit`);

package/packages/shared-skills/skills/frontend/scripts/perfection/lighthouse-audit.py

@@ -16,7 +16,6 @@
 # 3. Run:
 #      uv run lighthouse-audit.py https://example.com
 #      uv run lighthouse-audit.py https://example.com --desktop-only
-#      uv run lighthouse-audit.py https://example.com --threshold 95
 # ──────────────────
 
 """Lighthouse audit via real Playwright Chrome.

package/packages/shared-skills/skills/git-master/SKILL.md

@@ -16,7 +16,7 @@ Classify the request first:
 - `HISTORY`: answer when, where, who, why, or which commit changed something.
 - `STATUS`: inspect branch, diff, or working-tree state without changing it.
 
-Do not commit, rebase, push, force-push, reset, stash-pop, or delete anything unless the user explicitly asked for that operation. If the request is only investigative, report findings and stop.
+Do not commit, rebase, push, force-push, reset, stash-pop, or delete anything unless the user explicitly asked for that operation. When a workflow the user started mandates one of them (ulw-loop commits each verified unit, ulw-execute lands its branches), that workflow's instruction is the ask. If the request is only investigative, report findings and stop.
 
 ## Ground Truth
 
@@ -38,7 +38,17 @@ Missing upstream or missing `main`/`master` is normal. Fall back to the best ava
 
 ## PR Body Evidence Attachments
 
-When a PR body needs screenshots or terminal PNGs, use the repo reference at `docs/reference/github-attachment-upload.md`. The allowed hosting path is GitHub user attachments from the authenticated web attachment flow; never commit temporary images, never use GitHub Releases for PR evidence, and never use external image hosts. Do not log browser cookies, CSRF tokens, S3 form fields, or upload headers.
+When a PR body needs screenshots or terminal PNGs, the allowed hosting path is GitHub user attachments from the authenticated web attachment flow; never commit temporary images, never use GitHub Releases for PR evidence, and never use external image hosts. Do not log browser cookies, CSRF tokens, S3 form fields, or upload headers.
+
+The flow needs an authenticated GitHub web session (a `gh` API token alone is not enough):
+
+1. Open the target PR or issue page in that session and read its file-attachment CSRF token and repository id.
+2. `POST https://github.com/upload/policies/assets` with `repository_id`, `name`, `size`, `content_type`, and that token as `authenticity_token`.
+3. Upload the bytes to the returned S3 URL with the returned form fields exactly as given.
+4. `PUT https://github.com/upload/assets/:id` with the returned `asset_upload_authenticity_token`.
+5. Put only the final `https://github.com/user-attachments/assets/<uuid>` URL in the PR body (write the body to a temp file and pass it with `gh pr edit --body-file`).
+
+If no authenticated browser session is available, leave the local evidence paths in the PR body and state the blocker.
 
 ## Commit Mode
 

package/packages/shared-skills/skills/init-deep/SKILL.md

@@ -171,7 +171,7 @@ for each background task ID (`bg_...`): background_output(task_id="bg_...")
 ```
 AGENTS_LOCATIONS = [
   { path: ".", type: "root" },
-  { path: "src/hooks", score: 18, reason: "high complexity" },
+  { path: "src/hooks", score: 16, reason: "high complexity" },
   { path: "src/api", score: 12, reason: "distinct domain" }
 ]
 ```

package/packages/shared-skills/skills/lsp-setup/SKILL.md

@@ -27,11 +27,11 @@ reference before installing or configuring anything**.
 | `.py .pyi` | `references/python/README.md` |
 | `.go` | `references/go/README.md` |
 | `.rs` | `references/rust/README.md` |
-| `.c .cpp .cc .cxx .h .hpp .hh .hxx` | `references/c-cpp/README.md` |
+| `.c .cpp .cc .cxx .c++ .h .hpp .hh .hxx .h++` | `references/c-cpp/README.md` |
 | `.java` | `references/java/README.md` |
 | `.kt .kts` | `references/kotlin/README.md` |
 | `.cs .razor .cshtml` | `references/csharp/README.md` |
-| `.swift` | `references/swift/README.md` |
+| `.swift .m .mm` | `references/swift/README.md` |
 | `.rb .rake .gemspec .ru` | `references/ruby/README.md` |
 | `.php` | `references/php/README.md` |
 | `.dart` | `references/dart/README.md` |
@@ -75,13 +75,20 @@ command -v <server-executable>   # e.g. typescript-language-server, gopls, rust-
 
 Most builtin servers need **no config** — they are resolved automatically by
 file extension. Write config only to: pick between competing servers, set a
-`priority`, pass `initialization` options, override `extensions`, set `env`, or
-`disable` a server.
+`priority`, pass `initialization` options, override `extensions`, set `env`
+(user config only), or `disable` a server.
 
-Two project-scoped config files, **identical JSON shape**:
+Config files per harness, **identical JSON shape**. Each harness reads the
+first project file that exists, plus one user file:
 
-- Codex harness → `.codex/lsp-client.json` (user: `~/.codex/lsp-client.json`)
-- OpenCode/omo harness → `.opencode/lsp.json` (also `.omo/lsp.json`)
+| Harness | Project config | User config |
+|---|---|---|
+| Codex | `.codex/lsp-client.json` | `$CODEX_HOME/lsp-client.json` (default `~/.codex/lsp-client.json`) |
+| OpenCode | `.opencode/lsp.json`, then `.omo/lsp.json`, then `.omo/lsp-client.json` | `lsp.json` in the OpenCode config dir (default `~/.config/opencode/lsp.json`) |
+| OmO native | `.omo/lsp-client.json`, then `.pi/lsp-client.json` | `~/.omo/lsp-client.json` (`~/.pi/lsp-client.json` when only that one exists) |
+
+A standalone `lsp-tools-mcp` launch reads the paths in
+`LSP_TOOLS_MCP_PROJECT_CONFIG` / `LSP_TOOLS_MCP_USER_CONFIG` instead.
 
 ```jsonc
 {
@@ -100,14 +107,16 @@ Two project-scoped config files, **identical JSON shape**:
 
 Rules enforced by `config-loader.ts`:
 
-- In a **project** config (`.codex/lsp-client.json`, `.opencode/lsp.json`) an
-  entry whose id is a **builtin** server inherits `command` automatically — you
-  only override `extensions` / `priority` / `initialization`. A non-builtin id
-  in a project config is **ignored**.
-- To define a **fully custom** (non-builtin) server with its own `command`, put
-  it in the **user** config (`~/.codex/lsp-client.json`, or the path set by
-  `LSP_TOOLS_MCP_USER_CONFIG`), where `command` + `extensions` are honored.
-- Project entries win over user entries; both win over builtin defaults.
+- In a **project** config an entry whose id is a **builtin** server inherits
+  `command` automatically — you only override `extensions` / `priority` /
+  `initialization` / `disabled`. Its `env` is dropped, and a non-builtin id in
+  a project config is **ignored**.
+- To set `env`, or to define a **fully custom** (non-builtin) server with its
+  own `command`, put it in the **user** config from the table above, where
+  `command` + `extensions` + `env` are honored.
+- Project entries win over user entries; both win over builtin defaults. A user
+  entry is skipped when an enabled project entry has the same id, so keep an id
+  that needs `env` out of the project config.
 
 Each language reference gives a ready-to-paste snippet.
 

package/packages/shared-skills/skills/lsp-setup/references/bash/README.md

@@ -27,17 +27,17 @@ command -v shellcheck
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "bash": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 
-None commonly required. `bash-language-server` discovers `shellcheck` on PATH automatically. To point at a non-PATH binary, export `SHELLCHECK_PATH` via `env`:
+None commonly required. `bash-language-server` discovers `shellcheck` on PATH automatically. To point at a non-PATH binary, export `SHELLCHECK_PATH` via `env` (USER config only; a project entry drops `env`):
 
 ```json
 { "lsp": { "bash": { "env": { "SHELLCHECK_PATH": "/opt/bin/shellcheck" } } } }

package/packages/shared-skills/skills/lsp-setup/references/c-cpp/README.md

@@ -20,13 +20,13 @@ command -v clangd
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "clangd": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/csharp/README.md

@@ -22,13 +22,13 @@ command -v csharp-ls
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "csharp": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/dart/README.md

@@ -20,13 +20,13 @@ command -v dart
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "dart": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/elixir/README.md

@@ -21,13 +21,13 @@ command -v elixir-ls
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "elixir-ls": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/go/README.md

@@ -25,13 +25,13 @@ command -v gopls
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "gopls": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/haskell/README.md

@@ -27,13 +27,13 @@ command -v haskell-language-server-wrapper
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "haskell-language-server": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/java/README.md

@@ -20,17 +20,17 @@ command -v jdtls
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "jdtls": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 
-jdtls maintains a per-project **workspace data directory** and the **first index is slow** (it resolves the full classpath and builds). Point `JAVA_HOME` at a JDK 17+ if `jdtls` cannot find one:
+jdtls maintains a per-project **workspace data directory** and the **first index is slow** (it resolves the full classpath and builds). Point `JAVA_HOME` at a JDK 17+ if `jdtls` cannot find one (USER config only; a project entry drops `env`):
 
 ```json
 { "lsp": { "jdtls": { "env": { "JAVA_HOME": "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" } } } }

package/packages/shared-skills/skills/lsp-setup/references/julia/README.md

@@ -28,17 +28,17 @@ command -v julia
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "julials": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 
-None commonly required. To pin which environment hosts LanguageServer.jl, set `JULIA_PROJECT` (or `JULIA_DEPOT_PATH`) via `env`:
+None commonly required. To pin which environment hosts LanguageServer.jl, set `JULIA_PROJECT` (or `JULIA_DEPOT_PATH`) via `env` (USER config only; a project entry drops `env`):
 
 ```json
 { "lsp": { "julials": { "env": { "JULIA_PROJECT": "@lsp" } } } }

package/packages/shared-skills/skills/lsp-setup/references/kotlin/README.md

@@ -1,6 +1,6 @@
 # Kotlin — LSP setup
 
-- **Builtin server:** `kotlin-ls` — `kotlin-lsp`
+- **Builtin server:** `kotlin-ls` — `kotlin-lsp --stdio`
 - **Extensions:** `.kt .kts`
 - **Install hint:** `https://github.com/Kotlin/kotlin-lsp`
 
@@ -22,17 +22,17 @@ command -v kotlin-lsp
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "kotlin-ls": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 
-None commonly required. If `kotlin-lsp` cannot find a Java runtime, set `JAVA_HOME`:
+None commonly required. If `kotlin-lsp` cannot find a Java runtime, set `JAVA_HOME` (USER config only; a project entry drops `env`):
 
 ```json
 { "lsp": { "kotlin-ls": { "env": { "JAVA_HOME": "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" } } } }

package/packages/shared-skills/skills/lsp-setup/references/lua/README.md

@@ -20,13 +20,13 @@ command -v lua-language-server
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "lua-ls": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 

package/packages/shared-skills/skills/lsp-setup/references/php/README.md

@@ -20,13 +20,13 @@ command -v intelephense
 
 ## Configure
 
-Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in `.codex/lsp-client.json` (Codex) AND `.opencode/lsp.json` (OpenCode/omo):
+Builtin — usually NO config needed (auto-resolved by extension). Configure only to set priority, init options, override extensions, or disable. Same JSON shape in every harness's project config (per-harness paths: the Configure step in `SKILL.md`):
 
 ```json
 { "lsp": { "php": { "priority": 100 } } }
 ```
 
-For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled`/`env`. A fully custom (non-builtin) server with its own `command` must go in the USER config (`~/.codex/lsp-client.json`).
+For builtin ids in a PROJECT config, `command` is supplied automatically — only set `priority`/`initialization`/`extensions`/`disabled` (a project entry drops `env`). `env`, and a fully custom (non-builtin) server with its own `command`, must go in your harness's USER config (see the Configure step in `SKILL.md`).
 
 ### Initialization options (only if commonly needed)
 
@@ -51,7 +51,7 @@ Without a key the server runs fine in free mode.
 - **phpactor** (not builtin): `phpactor language-server`. Pure-PHP, no Node dependency.
 
 ## Troubleshooting
-- **PATH:** `intelephense` must be on PATH; reopen the shell after a global npm install. If missing, check `npm bin -g` is on PATH.
+- **PATH:** `intelephense` must be on PATH; reopen the shell after a global npm install. If missing, check that `$(npm prefix -g)/bin` (Windows: `npm prefix -g`) is on PATH.
 - **No Node:** Intelephense fails to start without Node.js. Install Node, then reinstall.
 - **Wrong PHP version inference:** set `intelephense.environment.phpVersion` via `initialization` to match your project.