@mrciphersmith/keryx 0.2.164 → 0.3.1

package/src/gdskills/bundled/stacks/ts-js-node/governance/scout.json

@@ -0,0 +1,40 @@
+[
+  {
+    "query": "Use when resolving `tsc` type errors, module resolution failures (ESM/CJS, moduleResolution nodenext/bundler, `type: module`, exports maps), or lint/test failures blocking a Node.js TypeScript/JavaScript build. Applies the smallest root-cause fix and never silences the checker with @ts-ignore, any, or eslint-disable. Not for Go/Rust/Python build failures, and not for implementing new features (use nodejs-implementation).",
+    "decision": "create",
+    "topMatch": "ts-js-node/nodejs-implementation",
+    "recordedAt": "2026-09-24T15:57:58.995Z",
+    "skillName": "nodejs-build-fix"
+  },
+  {
+    "query": "Use when migrating a Node.js package or app from CommonJS to ES modules -- package.json type/exports map changes, adding file extensions to relative imports, replacing __dirname/__filename with import.meta.dirname/filename, fixing require() of an ESM-only dependency, dual-package hazards, and the resulting Jest/tsconfig adjustments. Not for a greenfield ESM project (use nodejs-implementation) or a general dependency upgrade (use dependency-update).",
+    "decision": "create",
+    "topMatch": "ts-js-node/nodejs-build-fix",
+    "recordedAt": "2026-09-24T15:58:09.568Z",
+    "skillName": "nodejs-esm-migration"
+  },
+  {
+    "query": "Use when implementing or extending a feature in a Node.js service, library, or CLI written in TypeScript or JavaScript -- covers tsconfig strictness, ESM/node: protocol imports, async/await with AbortSignal, error handling with cause, and input validation at process boundaries. Not for UI markup/rendering code (use the matching UI framework pack) or writing/fixing tests (use nodejs-testing).",
+    "decision": "fork",
+    "topMatch": "ts-js-node/nodejs-testing",
+    "recordedAt": "2026-09-24T15:58:09.708Z",
+    "skillName": "nodejs-implementation",
+    "justification": "Nearest matches: ts-js-node/nodejs-testing (0.40) writes/fixes the test suite for Node code, a different lifecycle stage than implementing the feature itself. ts-js-node/nodejs-build-fix (0.28) fixes tsc/module-resolution errors on an existing build, not new feature implementation. ts-js-node/nodejs-code-review (0.24) is read-only review that never edits code. None perform implementation work (writing feature code with tsconfig/ESM/AbortSignal/cause-chain/input-validation concerns), so this is a genuine fork by lifecycle stage, not a substitute."
+  },
+  {
+    "query": "Use when a Node.js project's test suite (node:test, Vitest, Jest, or bun test) needs writing, extending, or fixing for TypeScript or JavaScript server/library/CLI code -- covers discovering the project's actual runner, mocking at process boundaries, fake timers, and deterministic async assertions. Not for pytest/Python tests, and not for auditing test conventions without changing test files (that is review-testing-practices).",
+    "decision": "fork",
+    "topMatch": "react/react-testing",
+    "recordedAt": "2026-09-24T15:58:09.847Z",
+    "skillName": "nodejs-testing",
+    "justification": "Nearest matches: react/react-testing (0.36) covers React Testing Library/JSX component tests, a different framework and rendering surface than Node server/library/CLI tests. ts-js-node/nodejs-implementation (0.35) implements feature code, not writing/fixing tests -- a different lifecycle stage. python/python-testing (0.32) is pytest-specific for Python, wrong language and runner ecosystem (node:test/Vitest/Jest/bun test). None substitute for discovering and using the Node project's actual test runner, so this is a genuine fork, not a substitute."
+  },
+  {
+    "query": "Use when reviewing a TypeScript or JavaScript Node.js change (a diff on a server, library, or CLI) for floating promises, unhandled rejections, `any` leaks, event-loop-blocking sync calls, resource cleanup gaps, and dependency risk. Read-only -- judges the diff and reports findings, never edits or authors source. Not for React component review, general architecture review, or security-only audits (use review-security-code for a broader OWASP pass).",
+    "decision": "fork",
+    "topMatch": "python/python-code-review",
+    "recordedAt": "2026-09-24T15:58:16.450Z",
+    "skillName": "nodejs-code-review",
+    "justification": "Nearest matches: python/python-code-review (0.32) reviews Python-specific mutation/safety issues, wrong language -- no coverage of Node's event loop, floating promises, or dependency risk vocabulary. go/go-code-review (0.21) reviews Go concurrency/idiom risks (goroutines, context misuse), unrelated to Node's promise/event-loop concerns. ts-js-node/nodejs-testing (0.20) writes/fixes test files, not a read-only review of a diff. None cover Node/TS-specific floating-promise, unhandled-rejection, event-loop-blocking, or resource-cleanup review, so this is a genuine fork by language/runtime, not a substitute."
+  }
+]

package/src/gdskills/bundled/stacks/ts-js-node/pack.json

@@ -0,0 +1,41 @@
+{
+  "id": "ts-js-node",
+  "family": "language",
+  "modules": ["ts-js-node-rules", "ts-js-node-skills"],
+  "detectionMarkers": ["typescript", "javascript", "node"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 314, Wave 4 batch 1"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": ["nodejs-implementation"],
+    "test": ["nodejs-testing"],
+    "review": ["nodejs-code-review"],
+    "build-fix": ["nodejs-build-fix"],
+    "migrate": ["nodejs-esm-migration"]
+  },
+  "agentProfile": {
+    "displayName": "TypeScript/JavaScript (Node.js)",
+    "auditFocus": [
+      "Every Promise is awaited, returned, or explicitly voided -- no floating promises",
+      "Async work has a rejection handler somewhere in its chain -- no unhandled rejections",
+      "No new `any` on a changed signature or a cast that erases a narrower type the code already had",
+      "No synchronous fs/crypto/zlib call on a request-handling or otherwise hot path",
+      "Opened resources (file handles, DB connections, timers, listeners, child processes) are closed or cleared on every exit path, including errors",
+      "A new runtime dependency is justified -- no unvetted package added for one small utility"
+    ],
+    "buildCommands": [
+      "npm run build",
+      "npx tsc --noEmit",
+      "npx eslint .",
+      "npm test"
+    ],
+    "fixGuardrails": [
+      "Never silence a `tsc` error with `@ts-ignore`, `@ts-expect-error` without a linked issue, or a cast to `any`",
+      "Never add an eslint-disable comment to make a lint failure go away instead of fixing the underlying code",
+      "Never flip `strict`/`noImplicitAny`/`skipLibCheck` or widen `moduleResolution` in tsconfig.json to make an error disappear",
+      "Never delete or skip a failing test to turn the suite green"
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/ts-js-node/rules/coding-style.mdc

@@ -0,0 +1,73 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.js", "**/*.mjs", "**/*.cjs"]
+metadata:
+  origin: authored
+---
+
+# TypeScript/JavaScript (Node.js) coding style
+
+Narrows `core-common-rules`' stack-agnostic style rules to Node.js server,
+library and CLI code written in TypeScript or JavaScript. Applies to
+`*.ts`/`*.js`/`*.mjs`/`*.cjs` files; JSX/TSX component code belongs to the
+`react` pack, which extends this one. Everything not Node/TS-specific still
+comes from the common rules this file `extends`.
+
+## Typing and module shape
+
+- Keep `tsconfig.json`'s `strict: true` on; do not narrow it or add
+  per-file `// @ts-nocheck` to make new code compile.
+- Prefer `unknown` over `any` for a value whose shape is not yet known;
+  narrow it with a type guard before use. An untyped external payload
+  (parsed JSON, a fetch body) is `unknown`, not `any`.
+- Match `moduleResolution` to what the project already declares
+  (`nodenext` or `bundler`) -- do not mix `require()` and `import` in code
+  the project already runs as ESM (`"type": "module"` in `package.json`).
+- Import Node built-ins with the `node:` prefix (`node:fs`, `node:path`,
+  `node:crypto`) -- some built-ins (`node:sea`, `node:sqlite`, `node:test`)
+  require it outright, and it disambiguates a built-in from a same-named
+  npm package everywhere else.
+- Use `import type { X } from "..."` (or `verbatimModuleSyntax`, when the
+  project enables it) for type-only imports so they are erased from the
+  emitted JS.
+
+## Naming and structure
+
+- `camelCase` for functions/variables, `PascalCase` for classes/types/
+  interfaces/enums, `UPPER_SNAKE_CASE` for module-level constants that are
+  effectively compile-time -- the ecosystem baseline, not a house variant.
+- One cohesive export group per module; a file mixing unrelated public
+  exports should split along the seam its imports already show.
+- Prefer named exports over a single default export in a module with more
+  than one thing to export -- named exports survive a rename/refactor with
+  a traceable diff; a default export does not.
+
+## Async and errors
+
+- `async`/`await` over raw `.then()` chains for new code; a `.then()` chain
+  longer than one link should become `await` with a `try`/`catch`.
+- Every `Promise` is awaited, returned to a caller that awaits it, or
+  explicitly discarded with `void somePromise()` when firing-and-forgetting
+  is genuinely intended -- never a bare unreferenced promise statement.
+- Pass `AbortSignal` (`AbortSignal.timeout(ms)` or a caller-supplied
+  `signal`) into `fetch` and other cancelable APIs instead of hand-rolled
+  timeout races with `setTimeout` + `Promise.race`.
+- Throw `Error` (or a subclass) with a message that names what failed and
+  the relevant value; chain the original cause with `new Error("...", {
+  cause })` rather than swallowing it or string-concatenating it into the
+  new message.
+- Never catch an error only to `console.log` and continue as if it
+  succeeded -- rethrow, return a typed failure, or handle it for real.
+
+## Imports and formatting
+
+- Format and lint with the project's own configured tool (`eslint`,
+  `prettier`, `biome`) -- do not hand-format around a tool that is already
+  configured, and do not introduce a second formatter.
+- Group imports: Node built-ins, then third-party packages, then local
+  (relative) imports, one blank line between groups -- the shape
+  `eslint-plugin-import`/`simple-import-sort` enforce when configured; run
+  it instead of hand-ordering when the project has it.
+- Explicit `.js` extensions on relative ESM imports when
+  `moduleResolution: nodenext` requires them (Node's own ESM resolver does
+  not add extensions); match whatever the surrounding files already do.

package/src/gdskills/bundled/stacks/ts-js-node/rules/patterns.mdc

@@ -0,0 +1,61 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.js", "**/*.mjs", "**/*.cjs"]
+metadata:
+  origin: authored
+---
+
+# TypeScript/JavaScript (Node.js) patterns
+
+Idiomatic design patterns and anti-patterns for Node.js services, libraries
+and CLIs written in TypeScript or JavaScript. Scoped to server/library/CLI
+code; component composition patterns belong to the `react` pack.
+
+## Idiomatic patterns
+
+- Validate external input (HTTP body, CLI args, env vars, file content) at
+  the boundary where it enters the process, with a schema library (`zod`,
+  `valibot`, `ajv`) if the project already has one, or explicit checks if
+  not -- do not let unvalidated `unknown` data flow deep into business
+  logic and get treated as trusted.
+- Use dependency injection (constructor/factory parameters) for anything
+  that talks to the outside world (DB client, HTTP client, clock, RNG) so
+  it can be swapped for a test double -- do not reach for a global
+  singleton in code that needs to be testable.
+- Prefer small, composable functions over a class hierarchy when there is
+  no shared mutable state to encapsulate; reach for a class specifically
+  when you need to hold state across calls (a connection pool, a cache).
+- Use `Array.prototype` methods (`map`/`filter`/`reduce`/`flatMap`) for
+  data transforms instead of manual index loops with push, unless a hot
+  loop's profiling shows the allocation cost matters.
+- Return a discriminated union (`{ ok: true, value } | { ok: false, error
+  }`) or throw a typed error class for an operation with an expected
+  failure mode -- do not overload a return value's meaning with `null`/
+  `undefined`/`-1` for both "not found" and "failed".
+- Use `EventEmitter`/`AsyncIterator` for a genuine stream of events over
+  time; do not reach for either to model a single async result -- that is
+  what a `Promise` is for.
+
+## Anti-patterns to flag
+
+- **God module / barrel re-export cycle**: an `index.ts` that re-exports
+  everything from a package and gets imported back into one of the modules
+  it re-exports -- creates a circular dependency the bundler/`tsc` may
+  tolerate but that breaks initialization order at runtime.
+- **Synchronous work in an async-looking function**: an `async function`
+  whose body is entirely synchronous CPU work with no `await` -- it still
+  blocks the event loop exactly like a non-async function; the `async`
+  keyword adds a microtask, not a thread.
+- **Manual promise construction around an already-async API**: wrapping a
+  callback-based Node API in `new Promise(...)` when `node:util`'s
+  `promisify` or the API's own `.promises`/`fs/promises` variant already
+  exists -- duplicates logic the platform maintains for you.
+- **Mutating a shared config/options object**: a function that receives an
+  options object and mutates it in place instead of returning a new one --
+  surprises every other caller holding a reference to the same object.
+- **Deep relative import chains** (`../../../../lib/x`) reaching across
+  module boundaries instead of a package-level export -- signals the
+  module boundary itself is wrong, not that the import needs a path alias.
+- **try/catch that only rethrows the same error unchanged**: adds a stack
+  frame and nothing else; either add context (`cause`, a wrapped error
+  type) or remove the try/catch.

package/src/gdskills/bundled/stacks/ts-js-node/rules/security.mdc

@@ -0,0 +1,71 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.js", "**/*.mjs", "**/*.cjs"]
+metadata:
+  origin: authored
+---
+
+# TypeScript/JavaScript (Node.js) security
+
+Node.js-specific risks beyond the OWASP baseline in the common rules --
+process/OS-level surface (child processes, the filesystem, the module
+loader) that a Node runtime exposes and a generic web-security checklist
+does not name directly.
+
+## Command and process execution
+
+- Never build a shell command string from untrusted input and pass it to
+  `child_process.exec`/`execSync` -- the shell reinterprets `;`, `|`, `` ` ``,
+  `$()` in the input. Use `execFile`/`execFileSync`/`spawn` with the
+  command and an **argument array** (`spawn("git", ["log", userBranch])`),
+  never string-concatenated into one command line.
+- If `shell: true` is passed to `spawn`/`exec` at all, treat every argument
+  as attacker-controlled and reject/escape it -- prefer removing `shell:
+  true` over trying to escape correctly.
+
+## Filesystem
+
+- Resolve a user-supplied path with `path.resolve`/`path.join` against a
+  fixed root, then verify the result still starts with that root
+  (`resolved.startsWith(root + path.sep)`) before any `fs` call --
+  otherwise `../../etc/passwd`-style traversal escapes the intended
+  directory.
+- Never pass an unvalidated path straight from a request/CLI arg to
+  `fs.readFile`/`fs.writeFile`/`fs.unlink` without that containment check.
+
+## Data handling
+
+- Guard against prototype pollution when merging/assigning JSON into an
+  existing object (`Object.assign`, a hand-rolled deep merge, or an older
+  `lodash.merge`): reject or strip `__proto__`, `constructor`, and
+  `prototype` keys, or use `Object.create(null)`/`structuredClone` for the
+  target instead of a plain object literal.
+- Never pass untrusted input to `eval`, `new Function(...)`, or a `vm`
+  module context expecting it to sandbox safely -- Node's `vm` module is
+  not a security boundary against a determined attacker; use a real
+  out-of-process sandbox if untrusted code must run at all.
+- Treat any `RegExp` built from user input, or a hand-written pattern with
+  nested quantifiers (`(a+)+`, `(a|a)*`), as a ReDoS risk on
+  attacker-controlled input length -- prefer a linear-time match, an
+  input length cap before the regex runs, or a known-safe regex engine.
+
+## Network and secrets
+
+- Validate and allowlist the target of any outbound `fetch`/`http(s)`
+  request built from user input (a URL, hostname, or webhook target) --
+  an unchecked outbound request lets an attacker probe internal services
+  (SSRF), including cloud metadata endpoints (`169.254.169.254`).
+- Never `console.log`/log a request body, header, or env var wholesale in
+  a path that might carry a token, password, or API key -- log an
+  identifier (user id, request id), not the credential-bearing payload.
+- Run `npm audit` (or the project's package manager's equivalent) and keep
+  the lockfile committed and in sync with `package.json`; do not add a
+  dependency with a known-critical advisory without a documented reason.
+
+## Runtime posture
+
+- Where the deployment target supports it, know that Node's permission
+  model (`--permission` plus `--allow-fs-read`/`--allow-fs-write`/
+  `--allow-child-process`) exists to restrict what a process may touch --
+  flag when a service handling untrusted input runs with no such
+  restriction and no containerization either.

package/src/gdskills/bundled/stacks/ts-js-node/rules/testing.mdc

@@ -0,0 +1,63 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.js", "**/*.mjs", "**/*.cjs"]
+metadata:
+  origin: authored
+---
+
+# TypeScript/JavaScript (Node.js) testing
+
+Test layout, runner and determinism conventions for Node.js server/library/
+CLI code. Discover the project's actual runner before writing anything --
+`node:test`, Vitest, Jest and `bun test` all exist in active use and are
+not interchangeable in syntax or config.
+
+## Layout and runner
+
+- Discover the runner from `package.json`'s `scripts.test`, `devDependencies`,
+  and any `vitest.config.*`/`jest.config.*` before writing a test --
+  `describe`/`it`/`test` globals differ in import source (`node:test`,
+  `vitest`, or Jest's ambient globals) even though the call shape looks
+  similar.
+- Match the project's existing test location convention: co-located
+  `*.test.ts`/`*.spec.ts` next to the source file, or a parallel `test/`/
+  `__tests__/` tree -- do not introduce the other layout alongside it.
+- For `node:test`, run with `node --test` (or the project's npm script
+  wrapping it); it needs no extra dependency and ships in Node itself.
+
+## Fixtures and mocking
+
+- Mock at the process boundary (network calls, the filesystem, a DB
+  client, `Date.now`/timers) -- not an internal function one module over,
+  which only checks that two mocks agree with each other.
+- Use the runner's own timer mocking (`node:test`'s `mock.timers`,
+  Vitest's `vi.useFakeTimers()`, Jest's `jest.useFakeTimers()`) for any
+  test that depends on `setTimeout`/`setInterval`/`Date.now` -- a test
+  that waits on a real timer is slow and, under load, flaky.
+- Use `node:test`'s `mock.fn()`/`mock.method()` (or the runner's
+  equivalent) instead of hand-rolled spy objects when the runner ships
+  one already.
+
+## Determinism
+
+- Async tests must `await` every assertion-relevant promise; a test
+  function that returns before its assertions run reports green
+  regardless of what the assertions found.
+- Pass the test's own `AbortSignal` (`t.signal` in `node:test`, or the
+  runner's equivalent) into any `fetch`/cancelable call a test makes, so a
+  test that times out does not leave the request running past it.
+- Never depend on test execution order or on state a previous test left
+  behind (a shared in-memory array, a module-level counter) -- each test
+  sets up and tears down its own state.
+- A flaky test (timing-, network-, or order-dependent) gets fixed at the
+  dependency it is racing, not wrapped in a retry or a longer timeout.
+
+## Coverage expectations
+
+- Every new/changed exported function, class method, and CLI command gets
+  at least: one happy-path case, one edge case (empty/`null`/`undefined`/
+  boundary value), and one error case that asserts the thrown error type
+  or message, not just that something threw.
+- A bug fix ships with a regression test that fails on the pre-fix code
+  and passes after -- without one, the fix has no evidence it addressed
+  the reported behavior.

package/src/gdskills/bundled/stacks/ts-js-node/skills/nodejs-build-fix/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: nodejs-build-fix
+description: "Use when resolving `tsc` type errors, module resolution failures (ESM/CJS, moduleResolution nodenext/bundler, `type: module`, exports maps), or lint/test failures blocking a Node.js TypeScript/JavaScript build. Applies the smallest root-cause fix and never silences the checker with @ts-ignore, any, or eslint-disable. Not for Go/Rust/Python build failures, and not for implementing new features (use nodejs-implementation)."
+triggers:
+  - "fix this tsc type error"
+  - "resolve this module not found error in Node"
+  - "fix ESM/CJS import error"
+  - "the build fails with moduleResolution error"
+  - "fix this eslint failure blocking CI"
+  - "package.json exports map is breaking the build"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Node.js build-fix (tsc / module resolution / lint)
+
+Resolve a `tsc` type error, module resolution failure, or lint/test
+failure blocking a Node.js TypeScript/JavaScript build. Applies the
+smallest change that fixes the actual root cause -- never a change that
+merely makes the checker stop complaining. See `rules/coding-style.mdc`
+for the typing/module conventions a correct fix should restore.
+
+## Workflow
+
+### Step 1: Reproduce the failure
+
+```bash
+npx tsc --noEmit
+npx eslint .
+npm test
+```
+
+Run the project's own `package.json` scripts (`build`, `lint`, `test`) if
+they differ from the above -- they may wrap these with project-specific
+flags (path mapping, project references). Capture the exact error message
+and file:line; do not guess at the cause from the symptom alone.
+
+### Step 2: Classify the failure
+
+- **Type error** (`tsc`): a genuine type mismatch, a missing property, an
+  incompatible generic instantiation, or a `noImplicitAny` violation.
+- **Module resolution error**: `Cannot find module`, `has no exported
+  member`, an ESM/CJS interop error (`require() of ES Module`, `Unknown
+  file extension`), or an `exports` map mismatch.
+- **Lint error**: an `eslint` rule violation -- read the rule name in the
+  output, not just the message.
+- **Test failure**: an assertion failure or a runner-level error (setup
+  crash, timeout).
+
+### Step 3: Find the root cause
+
+**Type errors**: read the actual inferred type at the error site (hover
+equivalent: trace the value back to its declaration or the function that
+returned it) before changing anything. A type error is usually telling
+the truth about a real mismatch, not a checker false positive.
+
+**Module resolution**: check `package.json`'s `"type"` field,
+`tsconfig.json`'s `moduleResolution`, and whether the failing import
+crosses an ESM/CJS boundary (a CJS package with no ESM build, imported
+from ESM code, or vice versa). Check the target package's own `exports`
+map in its `package.json` for what subpaths it actually publishes.
+
+**Lint**: read what the specific rule enforces (not just its name) before
+changing code to satisfy it -- some rules require a structural change
+(e.g. `no-floating-promises` wants an `await`, not a suppression).
+
+**Test failures**: determine whether the test is wrong (asserts stale
+behavior) or the source is wrong (behavior regressed) before touching
+either -- read the test's intent from its name and assertions first.
+
+### Step 4: Apply the smallest correct fix
+
+- A type error: fix the actual type mismatch (correct the signature, add
+  the missing property, narrow the union) -- not a suppression.
+- A module resolution error: fix the import path/extension, the
+  `tsconfig.json` setting that genuinely matches the project's runtime
+  target, or the `package.json` `exports`/`type` field -- not a blanket
+  `moduleResolution: "node"` downgrade that papers over the real
+  ESM/CJS boundary issue.
+- A lint error: change the code to satisfy the rule's actual intent.
+- A test failure: fix the source if behavior regressed, or fix the test if
+  its expectation was stale -- state which, and why, in the report.
+
+### Step 5: Verify and report
+
+Re-run the exact command from Step 1; confirm it now exits 0. Report the
+root cause and the fix, not just "error resolved".
+
+```
+Fixed: src/lib/orderQueue.ts:18
+  Root cause: `OrderQueue.push` typed its callback parameter as `any`,
+  masking a real mismatch where callers passed `OrderEvent` but the queue
+  expected `QueueItem`.
+  Fix: added the `QueueItem` mapping in `toQueueItem()`, removed the `any`.
+  Verified: tsc --noEmit exits 0.
+```
+
+## Rules
+
+- Follow `rules/coding-style.mdc` for the typing/module conventions a fix
+  must restore, not just silence.
+- ALWAYS fix the root cause with the smallest change; never widen the fix
+  beyond the file(s) the failure actually touches.
+- NEVER use `@ts-ignore`, an undocumented `@ts-expect-error`, a cast to
+  `any`, or an `eslint-disable` comment to make an error/warning
+  disappear.
+- NEVER flip `strict`, `noImplicitAny`, `skipLibCheck`, or widen
+  `moduleResolution` in `tsconfig.json` just to make a specific error go
+  away -- a tsconfig change is only correct when it fixes a genuine
+  project-wide misconfiguration, and it needs to be called out explicitly
+  as such in the report.
+- NEVER delete or skip a failing test to turn the suite green.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just add `@ts-ignore` above this line, it's probably a false positive" | `tsc` is almost never wrong about a real mismatch; verify the type before assuming the checker is broken |
+| "I'll cast to `any` here to unblock the build, someone can type it properly later" | The build-fix skill's whole purpose is the properly-typed fix; `any` defers the real work indefinitely |
+| "eslint-disable this line, the rule doesn't apply here" | If the rule genuinely does not apply, that is a project-level rule config change to propose, not a per-line suppression buried in an unrelated fix |
+| "This test is flaky, I'll just skip it to unblock CI" | Skipping a failing test does not fix the build, it hides a real signal; find the root cause or report it unresolved |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- The exact command that reproduced the failure in Step 1 now exits 0.
+- No `@ts-ignore`, `@ts-expect-error` (without a linked issue already
+  present before this fix), `any` cast, or `eslint-disable` was added.
+- No unrelated `tsconfig.json`/`eslint` config was loosened.
+- The report states the actual root cause, not just "fixed the error".
+- `git status` shows changes confined to the files the root cause
+  required.

package/src/gdskills/bundled/stacks/ts-js-node/skills/nodejs-build-fix/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "Fix this tsc error: Type 'string | undefined' is not assignable to type 'string'",
+      "Resolve this Node.js 'Cannot find module' error after adding a new import",
+      "Fix this require() of ES Module error in our Node service",
+      "The build fails with a moduleResolution nodenext error on this import",
+      "Fix this eslint no-floating-promises failure blocking CI",
+      "package.json exports map is breaking the build with ERR_PACKAGE_PATH_NOT_EXPORTED"
+    ],
+    "negative": [
+      "go vet ./... is failing on this package, help resolve the compile error",
+      "Write a CLI command in this Node.js project that lists pending jobs from the queue",
+      "Upgrade this codebase from React 18 to React 19 and fix the deprecated lifecycle warnings",
+      "Review this diff for floating promises and unhandled rejections",
+      "Write vitest tests to cover this new order calculation function",
+      "Fix this mypy type error in the Python data pipeline"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-ts-ignore-suppression",
+      "prompt": "tsc reports: Property 'total' does not exist on type 'OrderDraft'. What's the right way to fix this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer treats the tsc error as a genuine mismatch between the OrderDraft type and code that reads a total property from it, and fixes the type contract (or the code reading the wrong property) rather than silencing the checker.",
+          "pass_criteria": [
+            "Names the exact fix: adds a `total: number` (or the correctly-typed) property to the OrderDraft type/interface -- a plain field, or a `get total(): number` accessor that computes/derives it, both count, since either way the type now genuinely declares a typed, non-`any`, non-suppressed `total` -- or names the exact property the code should read instead of total",
+            "Shows the corrected type declaration or corrected property-access code, not just a statement of intent that the type will be fixed"
+          ],
+          "fail_criteria": [
+            "Recommends @ts-ignore or an undocumented @ts-expect-error above the line as the fix",
+            "Recommends casting the value to `any` (e.g. `(order as any).total`) instead of fixing the type declaration -- naming @ts-ignore or `any` only to warn against them as part of a correct fix does not count as this failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The error means the OrderDraft type genuinely doesn't have a total property, but the code reads it. Don't reach for @ts-ignore or cast to any -- that just hides a real mismatch instead of fixing it. First check where total actually comes from. If every OrderDraft should carry a running total, add it to the type so the type reflects what the object actually holds:\n\ninterface OrderDraft {\n  items: LineItem[];\n  total: number;\n}\n\nIf total is meant to be derived instead (e.g. summed from line items), don't add it to the type at all -- read the correct property and compute it instead of reading a nonexistent one:\n\nconst total = order.items.reduce((sum, item) => sum + item.price, 0);\n\nA third, equally valid shape: a `get total(): number` accessor declared on the interface/class itself, computing the value in place, rather than a plain stored field or an external free function -- structurally it still adds a typed, non-`any`, non-suppressed `total` that satisfies the checker.\n\nEither way, trace the value back to where OrderDraft objects are constructed, confirm which case applies, then apply that fix. After the change, re-run tsc --noEmit and confirm it exits clean with no new suppressions added anywhere in the diff.",
+        "known_wrong": "Easiest fix: put // @ts-ignore on the line above order.total so tsc stops complaining, or just type it as `any` for now and cast it with (order as any).total if you want it inline. This unblocks the build immediately without having to touch the OrderDraft type definition. You can always come back and add the real property later once someone has time to figure out where total should come from -- for now this keeps CI green and doesn't risk breaking anything else in the type.",
+        "vague": "Fix the OrderDraft type so it matches what the code expects, instead of hiding the error with a suppression. That keeps the checker honest and avoids papering over a real mismatch.",
+        "subtle_wrong": "The type checker is right that total doesn't exist on OrderDraft, so I widened the local usage with a cast: const draft = order as OrderDraft & { total: number }; and used draft.total at the call site. This avoids any and keeps most of the type safety while unblocking the build; I didn't touch the shared OrderDraft interface since I wasn't sure if other call sites expect total to be absent."
+      },
+      "anti_patterns": ["@ts-ignore", "`any`"]
+    },
+    {
+      "id": "reproduce-before-fix",
+      "prompt": "The Node.js build is failing but I haven't run anything yet. What's the first step to fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer's first step is to reproduce the failure by actually running the project's build/lint/test commands and reading the exact error message, rather than guessing at a fix from the symptom alone.",
+          "pass_criteria": [
+            "Names the specific command to run first (e.g. npx tsc --noEmit, npx eslint ., npm test, or the project's own package.json build/lint/test script) before proposing any fix -- not just 'run the build' in the abstract",
+            "States the goal of capturing the exact error message and file:line before changing any code"
+          ],
+          "fail_criteria": [
+            "Proposes a fix (dependency bump, config change, lockfile deletion) before running the failing command to see the actual error",
+            "Recommends loosening tsconfig settings like moduleResolution or strict as a first move instead of reproducing and diagnosing the failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Before touching any code, reproduce the failure yourself: run npx tsc --noEmit, npx eslint ., and npm test (or whatever the project's own package.json build/lint/test scripts wrap these with, since they may add path mapping or project references). Capture the exact error message and the file:line it points at -- don't guess at the cause from a vague description of 'the build is failing'. Once you have the real output, classify what kind of failure it is: a genuine tsc type error, a module resolution error (ESM/CJS interop, Cannot find module), an eslint rule violation, or a test failure. Only after you've seen the actual error and traced the value or import back to its source should you start forming a fix -- a type error is usually telling the truth about a real mismatch, not a checker false positive, so understanding it precisely first prevents a wrong fix or an unnecessary suppression.",
+        "known_wrong": "Since it's a Node build and these usually break from an outdated dependency, I'd just bump all the devDependencies to their latest versions and delete the lockfile, then reinstall -- that usually clears up whatever's stale. If it's still red after that, loosening tsconfig.json's moduleResolution to \"node\" or turning off strict mode is a quick way to get a clean build while you figure out the real problem later. No need to run anything first; these are the usual suspects for a broken Node build.",
+        "vague": "Before changing anything, I'd make sure to actually see what's failing and understand the error before jumping to a fix.",
+        "subtle_wrong": "First run the test suite to see what's currently broken. If the failure isn't immediately obvious from that output, it's usually faster to go ahead and bump the flagged dependency to its latest version, since an outdated package is the most common cause of a broken Node build -- you can always dig into the exact error afterward if the bump doesn't clear it up."
+      }
+    }
+  ]
+}