Javascript engineering
AI coding agent runtime that makes LLMs understand your codebase with repository-aware context, memory, and continuous learning
npx -y skills add ldilov/harness-forge --skill javascript-engineeringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
javascript engineering guidance for node.js, browser apps, clis, and packages. use when .js, .jsx, .mjs, .cjs, bundler config, or package contract behavior dominate the task and a typescript-first pack would be too type-system-centric.
SKILL.md
3.2 KB, as published. Nobody here has run it
JavaScript Engineering
Use this skill when the repository is JavaScript-first or the task depends more on runtime behavior, packaging, module format, or toolchain quirks than on a TypeScript type system.
Activation
- JavaScript files, Node runtime behavior, browser bundling, or package publishing dominate the task
- the repo uses
.js,.jsx,.mjs,.cjs, or mixed module formats - package
exports,imports, CLI behavior, or browser and server boundaries are central to the change
Load Order
rules/common/README.mdrules/common/coding-style.mdrules/common/patterns.mdrules/common/testing.mdrules/common/security.mdskills/javascript-engineering/references/knowledge-bases/seeded/typescript/docs/frameworks.mdwhen the repository shares the wider Node, React, or Vite ecosystem
Execution Contract
- map entrypoints, scripts, package manager, module system, and bundler behavior before editing code
- identify whether the edited code runs in Node, the browser, SSR, workers, or multiple runtimes
- preserve public package contracts unless the task explicitly authorizes a breaking change
- prefer plain, explicit JavaScript and JSDoc-backed contracts over hidden conventions
- validate the actual runtime path and packaging behavior, not just lint output
Outputs
- touched-file plan grouped by package or runtime boundary
- implementation or debugging summary with the exact module or packaging seam that changed
- validation path with lint, test, smoke, and package-contract checks
- compatibility note when
exports, entrypoints, or environment assumptions changed
Validation
- run the repo's preferred test, lint, and smoke commands first
- confirm Node version, package manager, and lockfile assumptions before touching dependencies or module format
- inspect
package.jsontype,main,module,exports, andimportswhen resolution is part of the bug - verify browser, SSR, and Node boundaries explicitly when code is shared across environments
Escalation
- escalate when the repo mixes incompatible ESM, CommonJS, bundler, or runtime assumptions
- escalate when changing
exportswould break undocumented consumer entrypoints - escalate when package publishing, CLI behavior, or deployment constraints are unclear
Supplemental Engineering References
skills/javascript-engineering/references/repo-exploration.mdskills/javascript-engineering/references/output-templates.mdskills/javascript-engineering/references/agent-patterns.mdskills/javascript-engineering/references/debugging-playbook.mdskills/javascript-engineering/references/ecosystem-guide.mdskills/javascript-engineering/references/node-service-patterns.mdskills/javascript-engineering/references/browser-and-bundler-patterns.mdskills/javascript-engineering/references/package-contracts.mdskills/javascript-engineering/references/testing-and-debugging.mdskills/javascript-engineering/references/examples.md