eng-skills 0.1.0 → 0.3.0

package/README.md

@@ -46,10 +46,16 @@ docs/
     guard.mjs              # PreToolUse(Bash): denies rm -rf, force push, .env exfil, …
   commands/
     onboard.md             # /onboard — Claude researches YOUR codebase, fills CLAUDE.md
-    feature.md             # /feature — research → plan → implement → verify → document
+    kickoff.md             # /kickoff — new project: interview → landscape research → spec
+    feature.md             # /feature — clarify → research → plan → implement → verify → document
     fix.md                 # /fix — reproduce → root-cause → fix → prove → document
     decide.md              # /decide — record an ADR
     phase.md               # /phase — honest progress review, phase-gate closeout
+  skills/
+    brainstorming/         # asks clarifying questions + researches what others do BEFORE building
+    root-cause/            # systematic RCA discipline — no symptom-patching
+    frontend-verify/       # screenshot/console/network verification via chrome-devtools MCP
+.mcp.json                  # chrome-devtools MCP server (offered for frontend projects — asks first)
 ```
 
 Everything is dependency-free Node (~150 lines of hooks total). No runtime, no daemon,
@@ -89,20 +95,51 @@ architecture as ADRs — so the knowledge base starts warm, not empty.
 
 ## The daily workflow
 
+You don't have to remember the slash commands. CLAUDE.md contains an
+**intent-routing table**: a plain "add a dark mode toggle" triggers the same
+clarify → research → plan → implement → verify → document workflow as typing
+`/feature` — casual phrasing doesn't skip steps. The commands are just explicit
+shortcuts:
+
 | Command | What it does |
 |---|---|
-| `/feature <desc>` | Researches the codebase (and web when useful) *before* writing code, writes a checkbox plan to `docs/plans/`, implements with TDD, verifies end-to-end, documents in `docs/features/`. |
+| `/kickoff <idea>` | From-scratch projects: interviews you (mandatory questions), researches the competitive landscape ("what are others doing"), locks stack decisions as ADRs, writes the spec and phase roadmap — *then* scaffolds. |
+| `/feature <desc>` | Asks clarifying questions first, researches the codebase (and web when useful) *before* writing code, writes a checkbox plan to `docs/plans/`, implements with TDD, verifies end-to-end, documents in `docs/features/`. |
 | `/fix <bug>` | Reproduce first, root-cause (not symptom-patch), failing test → fix, document Symptom/Root cause/Fix/Verification/Prevention in `docs/fixes/`. |
 | `/decide <choice>` | Numbered ADR with context, options, decision, consequences. Supersede — never delete — old decisions. |
 | `/phase status` | Cross-checks the current phase checklist against reality (do claimed tests actually pass?). |
 | `/phase next <name>` | Phase-gate closeout: verify acceptance criteria, get operator sign-off, open the next phase. |
 
+## Skills
+
+Three skills install to `.claude/skills/` and trigger automatically:
+
+- **brainstorming** — before any non-trivial build: interviews the user
+  (batched clarifying questions are *mandatory*, not optional), researches the
+  codebase *and* the landscape (what libraries/products already solve this),
+  presents real options with trade-offs, and locks the user's choices into a
+  design spec in `docs/specs/`.
+- **root-cause** — debugging discipline: reproduce before touching code, trace
+  real data instead of theorizing, five-whys to the actual root cause, prove the
+  fix with evidence, add prevention. Explicit anti-pattern list (no retry-loops,
+  no sleep-fixes, no speculative change-stacking).
+- **frontend-verify** — after any UI change: run the app, navigate with the
+  chrome-devtools MCP, screenshot and *look*, check console messages and network
+  requests, exercise the interaction, iterate 2–3×. "The code looks right" is
+  not verification.
+
+For frontend projects (React/Vue/Svelte/Next/… detected in package.json), `init`
+offers to add the [chrome-devtools MCP](https://www.npmjs.com/package/chrome-devtools-mcp)
+to `.mcp.json` — it asks first, merges with existing servers, and never overrides.
+
 ## CLI reference
 
 ```bash
 npx eng-skills init [dir]   # scaffold (default: current directory)
   --force                   # overwrite existing files
   --dry-run                 # print what would happen, write nothing
+  --yes                     # accept recommendations without prompting (CI/scripts)
+  --no-mcp                  # never offer the chrome-devtools MCP config
 ```
 
 ## Design principles (and their sources)

package/bin/cli.mjs

@@ -13,6 +13,8 @@ const positional = argv.filter((a) => !a.startsWith('--'));
 const command = positional[0] || 'init';
 const FORCE = flags.has('--force');
 const DRY = flags.has('--dry-run');
+const YES = flags.has('--yes');
+const NO_MCP = flags.has('--no-mcp');
 
 if (flags.has('--help') || command === 'help') {
   console.log(`
@@ -24,14 +26,18 @@ Usage:
 Options:
   --force      overwrite files that already exist (default: skip them)
   --dry-run    show what would be written without writing anything
+  --yes        accept all recommendations without prompting (for CI/scripts)
+  --no-mcp     never offer the chrome-devtools MCP config
   --help       this message
 
 What it sets up:
   CLAUDE.md                 protocol + TODO(onboard) markers Claude fills in
   docs/                     features/ fixes/ decisions/ phases/ plans/ specs/ + templates
   .claude/hooks/            pre-edit reminder, post-edit changelog, stop-gate, bash guard
-  .claude/commands/         /onboard /feature /fix /decide /phase
+  .claude/commands/         /onboard /kickoff /feature /fix /decide /phase
+  .claude/skills/           brainstorming, root-cause, frontend-verify
   .claude/settings.json     hook wiring (merged into an existing file safely)
+  .mcp.json                 chrome-devtools MCP for frontend projects (asks first)
 
 After installing, open Claude Code in the repo and run /onboard.
 `);
@@ -143,6 +149,71 @@ function installClaudeMd() {
   if (!DRY) fs.writeFileSync(dest, existing.trimEnd() + '\n\n' + section + '\n');
 }
 
+const FRONTEND_DEPS = [
+  'react', 'react-dom', 'next', 'vue', 'nuxt', 'svelte', '@sveltejs/kit',
+  '@angular/core', 'solid-js', 'astro', 'vite', 'preact', 'remix', '@remix-run/react',
+];
+
+function detectFrontend() {
+  try {
+    const pkg = JSON.parse(fs.readFileSync(path.join(target, 'package.json'), 'utf8'));
+    const deps = { ...pkg.dependencies, ...pkg.devDependencies };
+    return FRONTEND_DEPS.filter((d) => deps[d]);
+  } catch {
+    return [];
+  }
+}
+
+async function confirm(question) {
+  if (YES) return true;
+  if (!process.stdin.isTTY) return false; // non-interactive: never assume yes
+  const { createInterface } = await import('node:readline/promises');
+  const rl = createInterface({ input: process.stdin, output: process.stdout });
+  const answer = (await rl.question(`${question} [Y/n] `)).trim().toLowerCase();
+  rl.close();
+  return answer === '' || answer === 'y' || answer === 'yes';
+}
+
+/** Offer to add the chrome-devtools MCP server for frontend projects. */
+async function offerMcp() {
+  if (NO_MCP) return;
+  const found = detectFrontend();
+  if (!found.length) return;
+
+  const rel = '.mcp.json';
+  const dest = path.join(target, rel);
+  const ours = JSON.parse(fs.readFileSync(path.join(TEMPLATES, 'mcp.json'), 'utf8'));
+
+  let existing = null;
+  if (fs.existsSync(dest)) {
+    try {
+      existing = JSON.parse(fs.readFileSync(dest, 'utf8'));
+    } catch {
+      console.log(`  !  ${rel} exists but is not valid JSON — skipping MCP setup.`);
+      return;
+    }
+    if (existing.mcpServers?.['chrome-devtools']) {
+      skipped.push(rel + ' (chrome-devtools already configured)');
+      return;
+    }
+  }
+
+  console.log(`\nFrontend project detected (${found.slice(0, 3).join(', ')}).`);
+  console.log('The chrome-devtools MCP lets Claude open your app in a browser,');
+  console.log('take screenshots, and check console/network — the frontend-verify');
+  console.log('skill uses it to visually verify every UI change.');
+  const ok = await confirm(existing ? `Add chrome-devtools server to your existing ${rel}?` : `Create ${rel} with the chrome-devtools server?`);
+  if (!ok) {
+    console.log(`  =  ${rel} skipped by choice (re-run with --yes, or add it later)`);
+    return;
+  }
+  const next = existing ?? { mcpServers: {} };
+  next.mcpServers ||= {};
+  next.mcpServers['chrome-devtools'] = ours.mcpServers['chrome-devtools'];
+  (existing ? merged : written).push(rel + (existing ? ' (+ chrome-devtools server)' : ''));
+  if (!DRY) fs.writeFileSync(dest, JSON.stringify(next, null, 2) + '\n');
+}
+
 function ensureGitignore() {
   const dest = path.join(target, '.gitignore');
   const line = '.claude/.docs-state/';
@@ -158,9 +229,12 @@ console.log(`\neng-skills init → ${target}${DRY ? '  (dry run)' : ''}\n`);
 for (const f of ['lib.mjs', 'pre-edit.mjs', 'post-edit.mjs', 'stop-gate.mjs', 'guard.mjs']) {
   copyTemplate(path.join('claude', 'hooks', f), path.join('.claude', 'hooks', f));
 }
-for (const f of ['onboard.md', 'feature.md', 'fix.md', 'decide.md', 'phase.md']) {
+for (const f of ['onboard.md', 'kickoff.md', 'feature.md', 'fix.md', 'decide.md', 'phase.md']) {
   copyTemplate(path.join('claude', 'commands', f), path.join('.claude', 'commands', f));
 }
+for (const s of ['brainstorming', 'root-cause', 'frontend-verify']) {
+  copyTemplate(path.join('claude', 'skills', s, 'SKILL.md'), path.join('.claude', 'skills', s, 'SKILL.md'));
+}
 mergeSettings();
 
 // Knowledge base
@@ -177,6 +251,7 @@ for (const d of ['features', 'fixes', 'plans', 'specs']) {
 
 installClaudeMd();
 ensureGitignore();
+await offerMcp();
 
 for (const f of written) console.log(`  +  ${f}`);
 for (const f of merged) console.log(`  ~  ${f}`);
@@ -185,8 +260,11 @@ for (const f of skipped) console.log(`  =  ${f} (exists, skipped)`);
 console.log(`
 Done. Next steps:
   1. cd ${path.relative(process.cwd(), target) || '.'} && claude
-  2. Run /onboard — Claude researches this codebase and fills in CLAUDE.md.
-  3. Build things with /feature, fix things with /fix, record choices with /decide.
+  2. Existing codebase: run /onboard — Claude researches it and fills in CLAUDE.md.
+     Brand-new project: run /kickoff <what you want to build>.
+  3. Build with /feature, fix with /fix, record choices with /decide.
+     Skills installed: brainstorming (asks before building), root-cause
+     (debugging discipline), frontend-verify (browser screenshots via MCP).
 
 The stop-gate hook now blocks any turn that changes code without updating docs/.
 Verify hooks are active with /hooks inside Claude Code.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eng-skills",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "Scaffold battle-tested Claude Code engineering conventions into any repo: enforced docs protocol (features/fixes/decisions/phases), pre/post/stop hooks, research-first slash commands, and a CLAUDE.md that Claude fills in by reading your codebase.",
   "keywords": [
     "claude",

package/templates/CLAUDE.md

@@ -44,6 +44,25 @@ Notes:
 - If the Stop hook blocks you, it's working as designed: write the missing doc, then finish.
 - If hooks don't fire at all, the workspace may be untrusted — verify with `/hooks`.
 
+## 🧭 Intent routing (applies WITHOUT slash commands)
+
+The workflows below are how work is done in this repo — **whether or not the user
+types the slash command**. When a plain-language request matches an intent, read
+the corresponding command file and follow its workflow:
+
+| The user asks to… | Follow the workflow in |
+|---|---|
+| build/add/implement anything non-trivial | `.claude/commands/feature.md` (clarify → research → plan → implement → verify → document) |
+| fix a bug, investigate an error or wrong behavior | `.claude/commands/fix.md` + the `root-cause` skill |
+| choose between approaches / anything with a real trade-off | `.claude/commands/decide.md` (record the ADR) |
+| start a new project or major subsystem | `.claude/commands/kickoff.md` |
+| "where are we" / review progress | `.claude/commands/phase.md` |
+
+Do not skip steps because the user phrased the request casually. "Can you quickly
+add X" still gets clarifying questions if the design is ambiguous, still gets
+verified, and still gets documented. Only genuinely trivial changes (typo, rename,
+one-line tweak) may skip the plan — never the verification or the docs.
+
 ## Phase roadmap
 
 <!-- TODO(onboard): bullet list of phases, one marked `← CURRENT`, each pointing

package/templates/claude/commands/feature.md

@@ -5,6 +5,14 @@ argument-hint: <feature description>
 
 Build the following feature using the research-first workflow: **$ARGUMENTS**
 
+## 0. Clarify (MANDATORY for non-trivial features)
+
+If any requirement is ambiguous in a way that changes the design — scope, edge
+cases, UX, performance expectations — ask the user now (AskUserQuestion when
+available, batched, max 4). For genuinely trivial changes, state your
+assumptions in one line and proceed. For anything larger, use the
+**brainstorming** skill first: interview → landscape research → spec.
+
 ## 1. Research (before any code)
 
 - Search the codebase for everything the feature touches: existing modules to reuse, conventions to follow, contracts (API schemas, types, DB models) to extend.
@@ -22,7 +30,7 @@ Work through the plan's checkboxes, ticking them as you go. TDD for logic. Follo
 
 ## 4. Verify
 
-Run the project's tests and build/typecheck. For user-facing behavior, exercise the feature end-to-end (run the app, hit the endpoint, drive the UI) — not just tests. Paste real output as evidence.
+Run the project's tests and build/typecheck. For user-facing behavior, exercise the feature end-to-end (run the app, hit the endpoint, drive the UI) — not just tests. For UI changes, use the **frontend-verify** skill: screenshot the running app via the chrome-devtools MCP, check console and network, iterate until it actually looks right. Paste real output as evidence.
 
 ## 5. Document (required — the Stop hook enforces this)
 

package/templates/claude/commands/fix.md

@@ -7,7 +7,7 @@ Fix the following bug: **$ARGUMENTS**
 
 ## 1. Reproduce & root-cause
 
-Reproduce the bug first (failing test, curl, script). Then find the *root cause* — trace the actual failure, don't patch the symptom. Check `docs/fixes/` for related past fixes before starting; the same class of bug may have history.
+Use the **root-cause** skill: reproduce the bug first (failing test, curl, script — for frontend bugs, the chrome-devtools MCP: console, network, screenshots), then trace the actual failure to its root cause. Don't patch the symptom. Check `docs/fixes/` for related past fixes before starting; the same class of bug may have history.
 
 ## 2. Fix
 

package/templates/claude/commands/kickoff.md

@@ -0,0 +1,48 @@
+---
+description: Start a brand-new project — interview the user, research the landscape, lock the stack, write the spec and phase roadmap
+argument-hint: <what you want to build>
+---
+
+Kick off a new project: **$ARGUMENTS**
+
+This is the from-scratch counterpart to `/onboard`. Use the **brainstorming**
+skill's discipline throughout: questions first, research second, code last.
+
+## 1. Interview (MANDATORY)
+
+Ask the user, in 1–2 batched rounds (AskUserQuestion when available):
+- Who is this for, and what single problem must v1 solve?
+- What is explicitly out of scope for v1?
+- Constraints: platform, budget, deadline, must-use / must-avoid tech?
+- Any stack preference, or should you recommend one?
+- How will they demo success ("the demo sentence")?
+
+## 2. Landscape research
+
+Web-search what already exists: competing products, closest open-source
+projects, the standard stack choices for this kind of app in the current year.
+Deliver a short landscape summary: what exists, what's table-stakes, where this
+project differentiates. If something off-the-shelf already solves the problem,
+say so honestly before building anything.
+
+## 3. Lock decisions
+
+Present 2–3 stack/architecture options with trade-offs, recommend one, let the
+user choose. Record the chosen stack and each major trade-off as ADRs in
+`docs/decisions/` (`/decide`).
+
+## 4. Spec + roadmap
+
+- Write `docs/specs/YYYY-MM-DD-<name>-design.md`: goal, out-of-scope, locked
+  decisions table, architecture sketch, landscape notes.
+- Break the build into 3–6 phases with review gates; create
+  `docs/phases/phase-1-<name>.md` from the template and update the Phase roadmap
+  in `CLAUDE.md` (Phase 0 = this kickoff; mark phase 1 `← CURRENT`).
+- Fill in CLAUDE.md's mission, stack, and commands sections for the chosen stack.
+
+## 5. Scaffold
+
+Only after the user approves the spec: generate the project skeleton, verify it
+boots/builds, and document it as the first feature doc. If it's a frontend
+project, confirm `.mcp.json` has the chrome-devtools server and use the
+**frontend-verify** skill for every UI milestone from day one.

package/templates/claude/commands/onboard.md

@@ -30,6 +30,16 @@ with researched, accurate content — not guesses.
 
 4. **Verify.** Run the test/build command you documented in Commands to confirm it actually works. If it fails, document the real state honestly rather than an aspirational one.
 
-5. **Report.** Summarize what you filled in and anything you were unsure about so the human can correct it.
+5. **Ask, don't assume.** Where the codebase is ambiguous about things only the
+   human knows — current priorities, what's deprecated vs. active, invariants that
+   aren't visible in code — ask the user (AskUserQuestion when available) instead
+   of guessing. Their answers go into CLAUDE.md and the phase roadmap.
+
+6. **Recommend the toolkit.** Based on what you found, tell the user which of the
+   installed skills matter most here (e.g. frontend project → **frontend-verify**
+   + the chrome-devtools MCP in `.mcp.json`; complex domain → **brainstorming**
+   before every feature), and flag any recommended setup that's missing.
+
+7. **Report.** Summarize what you filled in and anything you were unsure about so the human can correct it.
 
 Do NOT modify source code during onboarding — this is a documentation-only pass.

package/templates/claude/skills/brainstorming/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: brainstorming
+description: Use BEFORE building any non-trivial feature or starting a new project — interviews the user with clarifying questions, researches the codebase and what others have built, presents options with trade-offs, and locks decisions into a design spec. Trigger on "build", "create", "add a feature", "new app", or any request where requirements are not fully specified.
+---
+
+# Brainstorming — question first, research second, code last
+
+Never jump from a one-line request to implementation. The cost of a wrong
+assumption compounds through every file you touch.
+
+## 1. Interview the user (MANDATORY — do not skip)
+
+Ask clarifying questions before proposing anything. Use the AskUserQuestion tool
+when available (give 2–4 concrete options per question), otherwise ask in plain
+text. Cover at least:
+
+- **Who/why**: who uses this and what problem does it solve for them?
+- **Scope**: what is explicitly OUT of scope for this iteration?
+- **Constraints**: performance, compatibility, budget, deadline, stack preferences?
+- **Success**: how will we know it works — what would the user demo?
+
+Skip only questions whose answers are already unambiguous from the request or the
+repo. One round of good questions is mandatory; a second round is fine if answers
+open new forks. Don't interrogate — batch questions, max 4 per round.
+
+## 2. Research (both directions)
+
+- **Inward**: search the codebase for what already exists — modules to reuse,
+  conventions to follow, prior art in `docs/features/`, constraints in
+  `docs/decisions/`. Never design something the repo already has.
+- **Outward**: search the web for how others solve this — established libraries,
+  competing products' approaches, known pitfalls. For anything involving an
+  external API, verify current docs; do not trust memory. Summarize the landscape
+  in 3–5 bullets: what exists, what's standard, where we differ and why.
+
+## 3. Present options, drive a decision
+
+Present 2–3 genuinely different approaches with honest trade-offs (not one real
+option padded with strawmen). Recommend one and say why. Let the user choose —
+their choice becomes a **locked decision**.
+
+## 4. Write the spec
+
+Write `docs/specs/YYYY-MM-DD-<name>-design.md`:
+
+- Goal (one paragraph), out-of-scope list
+- **Locked decisions table** (D1, D2, … — decision + why + who decided)
+- Architecture sketch, file/module layout
+- Landscape notes (what others do, sources)
+- Open questions that can wait
+
+Significant trade-offs also get an ADR in `docs/decisions/` so they survive
+beyond this feature. Then hand off to planning/implementation (`/feature`).

package/templates/claude/skills/frontend-verify/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: frontend-verify
+description: Visually verify frontend/UI changes in a real browser using the Chrome DevTools MCP — screenshot, console, and network checks against the locally running app. Use after ANY change that affects rendered UI, and when debugging frontend issues.
+---
+
+# Frontend verification — see it before you ship it
+
+"The code looks right" is not verification for UI work. Render it, look at it,
+check the console. Claude's UI output improves dramatically over 2–3
+screenshot-and-fix iterations.
+
+## Setup (once)
+
+This skill uses the Chrome DevTools MCP server. If its tools (take_screenshot,
+navigate_page, list_console_messages, …) are not available in this session, it
+isn't connected — check that `.mcp.json` in the repo root contains:
+
+```json
+{
+  "mcpServers": {
+    "chrome-devtools": {
+      "command": "npx",
+      "args": ["-y", "chrome-devtools-mcp@latest"]
+    }
+  }
+}
+```
+
+(`npx eng-skills init` offers to add this for frontend projects.) The user must
+restart Claude Code after adding it and approve the server on first use.
+
+## The verification loop
+
+1. **Run the app locally** (dev server from CLAUDE.md's Commands section). Wait
+   until it's actually serving — curl the URL or watch the output.
+2. **Navigate** to the affected page/state with the chrome-devtools MCP.
+3. **Screenshot** and actually look at it: layout, spacing, overflow, dark/light
+   mode if the app supports it, mobile viewport if relevant (resize_page).
+4. **Check the console** (list_console_messages) — a rendering change that logs
+   errors/warnings is not done.
+5. **Check network** (list_network_requests) for failed or duplicate requests
+   the change may have introduced.
+6. **Exercise the interaction**, not just the render: click, fill forms, submit
+   (click/fill/fill_form tools). Verify the resulting state.
+7. **Compare and iterate.** If a design mock was provided, compare screenshot to
+   mock, list every difference, fix, and re-screenshot. 2–3 iterations is
+   normal — don't stop at the first "close enough".
+
+## Evidence
+
+Attach/describe the final screenshot in your report and paste console/network
+findings. The feature/fix doc's Verification section should say what was
+visually confirmed, in which viewport(s).

package/templates/claude/skills/root-cause/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: root-cause
+description: Systematic root-cause analysis for bugs and unexpected behavior. Use whenever debugging anything — an error, a failing test, wrong output, a flaky behavior — BEFORE proposing a fix. Prevents symptom-patching.
+---
+
+# Root-cause debugging — evidence over hypothesis
+
+A fix that doesn't address the root cause is a second bug with better PR.
+
+## The loop
+
+1. **Reproduce first.** Turn the report into a deterministic reproduction: a
+   failing test, a curl command, a script, or a browser flow. If you cannot
+   reproduce it, you are not debugging — you are guessing. Say so and gather
+   more evidence instead.
+
+2. **Trace, don't theorize.** Follow the actual data through the actual code:
+   log/inspect at the boundaries (input → transform → output) until you find the
+   first place where reality diverges from expectation. For frontend issues, use
+   the chrome-devtools MCP (console messages, network requests, DOM state) — see
+   the `frontend-verify` skill. For backend, read real logs and add targeted
+   temporary instrumentation; remove it after.
+
+3. **Ask "why" until it stops being interesting.** The failing line is rarely
+   the cause. Five-whys until you reach a decision, assumption, or missing
+   guarantee (e.g. "the API can return null here and we assumed it couldn't").
+   Check `docs/fixes/` — if the same class of bug happened before, the previous
+   Prevention section failed and that itself is a finding.
+
+4. **Fix at the root, prove it.** Write the failing test that captures the root
+   cause (not just the symptom), make it pass with the smallest correct change,
+   then re-run the original reproduction AND the surrounding test suite. Paste
+   real output as evidence — "should work now" is not verification.
+
+5. **Prevent + document.** What guard, test, or type makes this class of bug
+   impossible? Write `docs/fixes/YYYY-MM-DD-<slug>.md` (template in
+   `docs/_templates/fix.md`) with Symptom / Root cause / Fix / Verification /
+   Prevention.
+
+## Anti-patterns (stop yourself)
+
+- Changing code before reproducing.
+- "Fixed" by retrying / adding a sleep / widening a try-catch.
+- Fixing the test instead of the code without proving the test was wrong.
+- Stacking multiple speculative changes at once — change one variable per experiment.

package/templates/mcp.json

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "chrome-devtools": {
+      "command": "npx",
+      "args": ["-y", "chrome-devtools-mcp@latest"]
+    }
+  }
+}