orbitx 0.0.8 → 0.1.0

package/dist/skills/node-backend.js

@@ -0,0 +1,110 @@
+import Skill from "../core/skill.js";
+import { FsTools, } from "../tools/fs/index.js";
+import { BashTools, } from "../tools/bash/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const NodeBackendSkill = () => new Skill({
+    name: "node-backend",
+    description: "Use this skill whenever the task involves building, modifying, running, or debugging a Node.js backend — REST/GraphQL APIs, servers, CLIs, background workers, schedulers, database access layers, or any server-side/non-browser Node code. Covers scaffolding a brand-new Node project from scratch as well as extending or fixing an existing one. Trigger this for any backend Node.js coding task, whether the project already exists on disk or needs to be created.",
+    tools: [
+        ...FsTools(),
+        ...BashTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Node.js Backend Skill
+
+## Purpose
+Use this skill when building, modifying, or running a modern Node.js backend project: APIs, servers, CLIs, background workers, and anything else that runs on Node rather than in a browser.
+
+## Project structure (mandatory for new projects)
+
+Never dump routes, DB calls, and business logic into one or two files "for now." Pick a structure up front based on project size, and stick to it as the project grows — retrofitting structure onto a pile of flat files later is expensive and error-prone. Two acceptable conventions:
+
+**Small/medium projects (single cohesive domain, roughly under ~15 endpoints, one team):** layer-first (MVC-style):
+\`\`\`
+src/
+  controllers/   # request/response handling only — parse input, call a service, shape the response
+  services/      # business logic — the actual "what does this operation do"
+  models/        # data shape + persistence (ORM models/schemas, or raw query functions)
+  routes/        # route definitions, mapping HTTP verb+path -> controller
+  middleware/    # auth, validation, error handling, logging, rate limiting
+  config/        # env loading, DB connection, constants
+  utils/         # pure helper functions with no framework/business dependency
+  app.js         # wires middleware + routes together, exports the app
+  server.js      # starts the HTTP server (imports app.js) — keep this separate from app.js so tests can import app.js without binding a port
+\`\`\`
+
+**Larger projects (multiple distinct domains/features, e.g. "orders", "users", "billing" that don't share much logic):** feature-first (domain-based), where each feature owns its own slice:
+\`\`\`
+src/
+  features/
+    orders/
+      order.controller.js
+      order.service.js
+      order.model.js
+      order.routes.js
+    users/
+      user.controller.js
+      user.service.js
+      user.model.js
+      user.routes.js
+  middleware/    # shared/cross-cutting only
+  config/
+  utils/
+  app.js
+  server.js
+\`\`\`
+
+**Choosing between them:** default to layer-first for anything that's clearly one small-to-medium app. Switch to feature-first once you notice the layer-first folders (\`controllers/\`, \`models/\`, etc.) are accumulating multiple unrelated domains and cross-referencing between them is getting confusing — at that point, feature-first keeps each domain's controller/service/model/routes together and easier to reason about in isolation. If genuinely unsure, ask which the user's team already prefers rather than guessing; if there's no existing convention to match, layer-first is the safer default for anything not already known to be large.
+
+**Regardless of which convention:**
+- Controllers must never contain raw SQL/query-builder calls or business rules directly — that belongs in services/models. A controller's job is: validate/parse request → call service → send response → handle/forward errors.
+- Services must never touch \`req\`/\`res\` directly — that keeps business logic testable without spinning up an HTTP server.
+- Route files should be thin: they map paths to controller functions and attach route-specific middleware (e.g. an auth guard, a validator), nothing else.
+- If you inherit an existing project that doesn't follow either convention, match its existing structure rather than silently imposing a new one mid-project — flag the mismatch to the user instead if it's bad enough to be worth raising.
+
+For production APIs, apply the backend-security skill alongside this one — a functionally-correct endpoint that skips input validation, authorization checks, or secret handling is not production-ready.
+
+Before handoff, also apply code-verification — for a TypeScript backend, typecheck clean (\`tsc --noEmit\` or the project's own script); for any backend, this pairs with the "verifying your work actually runs" section below rather than replacing it: typecheck/build first, then actually start the server and hit real endpoints as described there.
+
+## Starting a new project
+1. Create the project folder: \`fs-create-dir\`.
+2. Initialize it: \`bash-run\` with command \`npm init -y\` and \`cwd\` set to the new folder. This creates \`package.json\`.
+3. Decide and install your stack (see "Choosing dependencies" below), then \`npm install\` them with \`cwd\` set to the project folder.
+4. Write source files with \`fs-write-file\` (creates parent directories automatically unless \`createDirs: false\`), following the project structure above.
+5. Add npm scripts (\`start\`, \`dev\`, \`test\`, \`build\` as relevant) to \`package.json\` via \`fs-edit-file\` or \`fs-write-file\`, so the project is runnable the standard way rather than requiring you to remember a raw command.
+
+## Working with an existing project
+- Always \`fs-list-dir\` (with \`recursive: true\` when you need the whole tree — page through it with \`offsetResult\`/\`limitResult\` if it's large) before assuming a project's structure. Don't guess file layout.
+- Read \`package.json\` first with \`fs-read-file\` to learn the existing scripts, dependencies, and module type (\`"type": "module"\` vs CommonJS) before writing new code — new code must match the project's existing conventions (ESM \`import\`/\`export\` vs CommonJS \`require\`), not your own default assumption.
+- Prefer targeted edits (replacing a specific line range) over reading a whole file and rewriting it wholesale, which risks losing unrelated content if the rewrite is incomplete. Read the file first to get accurate current line numbers — another edit may have shifted them since you last looked. A full-file overwrite has no undo — only safe for genuinely new files, or when you've already reviewed everything being replaced.
+
+## Running processes
+- Use \`bash-run\` for anything that runs to completion (installs, one-off scripts, migrations, tests). It waits up to \`waitMs\` (default 15s) and returns the tail of output; increase \`waitMs\` for slow installs instead of polling immediately.
+- Use \`bash-run\` for long-running/endless processes too (e.g. \`npm run dev\`, \`node server.js\` with no exit) — it returns early with status \`"running"\` once \`waitMs\` elapses, and the process keeps going in the background. Save the returned \`processId\`.
+- Poll a long-running process with \`bash-wait\` (blocks up to \`waitMs\` again) or \`bash-logs\` (pages through everything the process has printed so far via \`offsetLine\`/\`limitLine\`) to check whether it started successfully — e.g. confirm a server actually printed "listening on port 3000" rather than assuming it did.
+- If a command prompts interactively (a CLI asking "overwrite? (y/n)" or "project name:"), use \`bash-write-input\` to answer it rather than letting it hang.
+- Always \`bash-terminate\` a long-running dev/watch process once you're done testing it, so it doesn't keep occupying its port for the next run.
+- Check \`bash-list\` if you're not sure what's still running — don't start a second server on the same port blind.
+
+## Verifying your work actually runs
+Writing the code is not the job — confirming it runs is. After writing or changing backend code:
+1. Install any new dependencies you referenced (\`npm install <pkg>\`), don't just import them and assume they exist.
+2. Start the server/script with \`bash-run\` and check the output (or \`bash-logs\`) for a successful startup message and the absence of stack traces.
+3. For an HTTP server, actually hit an endpoint (e.g. \`curl http://localhost:PORT/...\` via \`bash-run\`) and check the response, rather than trusting that "it started" means "it works".
+4. If there's a test suite, run it (\`npm test\` or equivalent) and read the actual output — don't report success from the exit code alone if the tail of output shows failures.
+5. Terminate any long-running process you started for verification once you've confirmed it works, unless the user wants it left running.
+
+## Choosing dependencies
+- Prefer well-established, actively maintained packages appropriate to what's already in \`package.json\` (don't introduce a second framework/ORM/etc. alongside one already in use without a clear reason).
+- Check the installed version actually landed as expected by reading \`package.json\`/\`package-lock.json\` after install if it matters for compatibility.
+- Keep the dependency footprint proportionate to the task — don't pull in a large framework for something a few lines of native Node can do, unless the project already uses that framework.
+
+## Code quality expectations
+- Match the project's existing style, module system, and error-handling conventions.
+- Handle errors explicitly (don't let unhandled promise rejections or missing try/catch around I/O silently crash the process) — a backend that crashes on the first bad request is not "done".
+- Don't hardcode secrets/credentials into source files; use environment variables and mention this to the user if a \`.env\` file is expected but missing.
+`
+});
+export default NodeBackendSkill;
+//# sourceMappingURL=node-backend.js.map

package/dist/skills/node-backend.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"node-backend.js","sourceRoot":"","sources":["../../src/skills/node-backend.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EACH,OAAO,GACV,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACH,SAAS,GACZ,MAAM,wBAAwB,CAAC;AAChC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,gBAAgB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAC5C,IAAI,EAAE,cAAc;IACpB,WAAW,EAAE,4cAA4c;IACzd,KAAK,EAAE;QACH,GAAG,OAAO,EAAE;QACZ,GAAG,SAAS,EAAE;QACd,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8FjB;CACA,CAAC,CAAC;AAEH,eAAe,gBAAgB,CAAC"}

package/dist/skills/planner.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const PlannerSkill: () => Skill;
+export default PlannerSkill;
+//# sourceMappingURL=planner.d.ts.map

package/dist/skills/planner.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"planner.d.ts","sourceRoot":"","sources":["../../src/skills/planner.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAMrC,eAAO,MAAM,YAAY,aA2CvB,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/skills/planner.js

@@ -0,0 +1,49 @@
+import Skill from "../core/skill.js";
+import { TodoTools, } from "../tools/todo/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const PlannerSkill = () => new Skill({
+    name: "planner",
+    description: "Use this skill whenever a job is large, multi-step, vague, or spans multiple tools/domains/skills — anything with 3+ distinct steps or deliverables, work expected to take many tool calls, a job that touches several other skills at once (e.g. backend + frontend + security + verification), or an explicit request for a plan. Maintains a persistent, checkable todo list so progress survives long conversations, context resets, and detours without losing track of what's done and what's left. This is the tracking mechanism the big-task and long-task-efficiency skills both rely on for large jobs — stand this up first, before doing any work, whenever those skills are also active. Skip for single-step or trivial requests and pure question-answering with no side effects.",
+    tools: [
+        ...TodoTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Planner Skill
+
+## Purpose
+Use this skill any time a job is too big, too vague, or too multi-step to execute in one shot. A todo list is your working memory across a long task: it lets you break a large goal into concrete, checkable steps, survive long conversations without losing track of what's done, and give the user visibility into your progress.
+
+This skill is the tracking backbone that big-task and long-task-efficiency both depend on. big-task's core rule — never stop early, never quietly narrow scope — is only checkable if there's an actual list to check against; long-task-efficiency's checkpointing guidance assumes this list exists and stays current. On any job where those two skills are active, stand up the todo list here first, before doing any actual work, so "is this genuinely done" has a real answer instead of a guess.
+
+## Core workflow
+1. **Create the list first, before doing any work.** Call \`todo-create-list\` with a short, descriptive \`name\` (e.g. "Add auth to API"). Save the returned \`todoListId\` — every other call in this skill needs it.
+2. **Break the goal into tasks up front.** Call \`todo-create-task\` once with the FULL array of tasks you can already foresee, rather than adding them one at a time as you go. Each task needs a \`name\` (short, action-oriented, e.g. "Install express and jsonwebtoken") and can have an optional \`description\` with extra detail (acceptance criteria, file paths, commands to run). Order the array the way you intend to execute them — the list has no separate "order" field, so array order in your own head/notes is what matters.
+3. **Work the list one task at a time.** Before starting a task, you can call \`todo-get-list\` to refresh your view of what's done and what's pending — especially useful after a long detour, an error, or a context-compaction event, so you never have to ask the user "what was I doing?".
+4. **Check off a task the moment it's genuinely complete** — call \`todo-check-task\` with \`check: true\` and the task's id. "Complete" means verified, not just attempted: if a task was "run the test suite" and tests failed, don't check it off — fix the failure first, or split it into a new task describing the fix.
+5. **Adjust the plan as you learn more.** There's no in-place edit for a task's name or description — to revise one, remove the old task and create its replacement, rather than leaving stale wording in place. If a step turns out to need sub-steps you didn't foresee, call \`todo-create-task\` again to append them to the same list. If a task turns out to be unnecessary or wrong, call \`todo-remove-task\` rather than leaving it unchecked and stale — a stale task list is worse than no task list, because it misleads whoever reads it next (including future-you).
+6. **Clean up when the job is done.** Once every task is checked and the user's goal is met, you generally don't need to remove the list — it stands as a record of what was done. Only call \`todo-remove-list\` if the user asks you to discard it, if the plan was abandoned/superseded, or if you're starting the same kind of job fresh and don't want stale lists cluttering \`todo-get-lists\`.
+
+## Writing good tasks
+- One task = one concrete, independently checkable action. Bad: "Build the app". Good: "Scaffold Vite project", "Install dependencies", "Implement login form", "Wire login form to /api/login", "Manually verify login flow end-to-end".
+- Prefer verbs: "Create X", "Install Y", "Run Z", "Verify W".
+- Put anything a future reader (or you, after a context reset) would need to resume the task — exact file paths, exact commands, exact endpoints — in the task's \`description\`, not just its \`name\`. The name is a label; the description is the instructions.
+- If a task depends on another task's output (e.g. "Write tests" depends on "Implement feature"), keep them as separate tasks in dependency order rather than merging them — this keeps your checked/unchecked state an honest signal of real progress.
+- Because revising a task means removing and recreating it rather than editing it in place, put real thought into a task's \`name\`/\`description\` before creating it — it's cheap to get right up front and mildly wasteful to redo.
+- **A "build" task and its "verify" task are always separate tasks, never one.** "Implement the API endpoint" and "typecheck/build the API endpoint" and "verify the endpoint actually responds correctly" are three different checkable items, even though they're all part of finishing the same endpoint. Collapsing them into one task is exactly how a job gets marked done after only the first part happened.
+
+## Multi-domain jobs — group tasks by which skill they belong to
+When a job spans several other skills at once (e.g. node-backend + backend-security + react-frontend + ui-ux-design + code-verification + web-end-to-end-test, per big-task's "multi-domain big tasks" guidance), a flat unordered list of 20 tasks is hard to audit against "did every domain actually get finished." Instead:
+- Cluster tasks by domain in the array you pass to \`todo-create-task\` — all the backend build/verify/secure tasks together, then all the frontend build/verify/design tasks together, then the end-to-end test tasks — even though there's no formal grouping field, keeping them contiguous in order makes the list scannable as "here's backend's full slice, here's frontend's full slice."
+- For each domain touched, make sure its task cluster includes not just the build step but the domain-appropriate verification step(s) — e.g. a backend cluster should include both "implement endpoint" and "typecheck/build clean" and, if security-sensitive, "apply backend-security checklist," not just the first.
+- When calling \`todo-get-list\` to check overall status on a multi-domain job, explicitly scan for any domain whose cluster has zero checked tasks — that's the concrete signal of an untouched domain that big-task warns about, and it's much easier to catch by scanning a domain-grouped list than an interleaved one.
+
+## Multiple lists
+Use \`todo-get-lists\` to see every list currently tracked. Keep one list per distinct user goal running concurrently — don't mix two unrelated jobs into a single list, since it makes "is this job done?" ambiguous. If the user starts a new, unrelated request while an old list still has unchecked tasks, ask yourself whether the old job is actually finished before assuming it's safe to ignore.
+
+## Reporting progress to the user
+When asked "what's the status?" or after finishing a meaningful chunk of work, call \`todo-get-list\` and summarize it in plain language (what's done, what's next) rather than dumping raw ids. On a multi-domain job, summarize per domain cluster (e.g. "backend: built and verified; frontend: built, not yet tested; security pass: not started") rather than one aggregate "mostly done" — an aggregate can hide an entire untouched domain, which is exactly the honest-reporting standard big-task asks for. The todo list is bookkeeping for you — the user wants a narrative, not a database dump.
+`
+});
+export default PlannerSkill;
+//# sourceMappingURL=planner.js.map

package/dist/skills/planner.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"planner.js","sourceRoot":"","sources":["../../src/skills/planner.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EACH,SAAS,GACZ,MAAM,wBAAwB,CAAC;AAChC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACxC,IAAI,EAAE,SAAS;IACf,WAAW,EAAE,mwBAAmwB;IAChxB,KAAK,EAAE;QACH,GAAG,SAAS,EAAE;QACd,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmCjB;CACA,CAAC,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/skills/present.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const PresentSkill: () => Skill;
+export default PresentSkill;
+//# sourceMappingURL=present.d.ts.map

package/dist/skills/present.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"present.d.ts","sourceRoot":"","sources":["../../src/skills/present.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAKrC,eAAO,MAAM,YAAY,aAiDvB,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/skills/present.js

@@ -0,0 +1,56 @@
+import Skill from "../core/skill.js";
+import { PresentTools } from "../tools/present/index.js";
+import { BashTools } from "../tools/bash/index.js";
+import { FsListDirTool, FsDeleteTool, FsStatTool } from "../tools/fs/index.js";
+export const PresentSkill = () => new Skill({
+    name: "present",
+    description: "Use this skill whenever a job produces output the user should receive as files — code, documents, generated assets, a small script, or an entire project. Covers deciding whether to present files individually or as a single zip, and cleaning up build/dependency artifacts (node_modules, build/dist output, caches, lockfiles' junk, etc.) before zipping so the archive only contains what the user actually needs. Trigger this at the point a task is otherwise complete and its output is ready to hand back.",
+    tools: [
+        ...PresentTools(),
+        ...BashTools(),
+        FsListDirTool(),
+        FsDeleteTool(),
+        FsStatTool(),
+    ],
+    instructions: `
+# Present Skill
+
+## Purpose
+Once a job is actually done, the output still has to reach the user in a form they can use. This skill governs that last step: deciding whether to present files one by one or as a single archive, and — for anything project-sized — making sure the archive doesn't ship junk (dependencies, build output, caches) that the user never asked for and shouldn't have to download.
+
+## Decide: few files vs. a project
+- **A handful of files** (a script, a couple of generated documents, a small number of clearly-related outputs): present them individually with present-add, one call per file. Don't zip small, simple results — that just adds friction for the user (an extra unzip step) for no benefit.
+- **A project or anything with many files / a directory tree** (a scaffolded app, a multi-file codebase, a folder of generated assets): zip the whole thing into a single archive and present that one zip instead of dozens of present-add calls. Many small files are hard to review individually and easy to lose track of; one archive is not.
+- When unsure whether something counts as "a few files" or "a project," lean on file count and structure: a flat handful of standalone files → present individually. Anything with subdirectories, or more than ~6-8 files, or an identifiable "project root" (has a package.json, requirements.txt, .git, src/ folder, etc.) → treat it as a project and zip it.
+
+## Before zipping a project: clean it up first
+Never zip a project as-is without checking for artifacts that don't belong in the archive. Before creating the zip:
+1. **Inspect the project root** with fs-list-dir (recursive) to see what's actually in there.
+2. **Identify and remove anything that is regenerable or environment-specific rather than actual project output**, for example:
+   - Dependency folders: \`node_modules\`, \`vendor\`, Python \`venv\`/\`.venv\`, \`__pycache__\`
+   - Build/compile output that the user didn't specifically ask to receive: \`dist\`, \`build\`, \`.next\`, \`target\`, \`out\`, compiled \`.class\`/\`.o\`/\`.pyc\` files
+   - Caches and local tooling state: \`.cache\`, \`.turbo\`, \`.parcel-cache\`, \`.DS_Store\`, editor folders like \`.vscode\`/\`.idea\` unless the user asked for editor config specifically
+   - VCS internals the user has no use for in a delivered zip: \`.git\` (unless the user explicitly wants git history)
+   - Log files and temp files generated during the work itself (\`*.log\`, \`tmp/\`, \`.tmp\`)
+3. **Use fs-delete (recursive where needed) or bash-run** to remove these before archiving. Removing node_modules in particular is usually the single biggest size reduction — dependencies are meant to be reinstalled (\`npm install\`, \`pip install -r requirements.txt\`, etc.), not shipped.
+4. **Keep anything that's actual project output or source**: source code, configuration the project needs to run (package.json, requirements.txt, tsconfig.json, Dockerfiles, etc.), README/docs, and any files the user specifically asked to see the build/output of.
+5. If genuinely unsure whether something is safe to remove (e.g. a folder whose purpose isn't obvious from its name), check what it is (fs-stat, fs-list-dir into it) before deleting rather than deleting blindly.
+
+## Zipping
+- Use bash-run to invoke the system zip utility (e.g. \`zip -r project.zip .\` from inside the project root, or \`tar -czf project.tar.gz .\` if zip isn't relevant to the context) after cleanup is done, not before.
+- Zip from a location where the archive's internal paths make sense when extracted (typically zip the project folder's *contents* so extracting doesn't require the user to dig through a redundant wrapper folder, unless a single top-level folder is expected/desired).
+- After zipping, present-add only the resulting archive file — never present-add every individual file of a project once it's been zipped; that defeats the purpose.
+
+## Presenting
+- present-add requires a single file path — it will reject a directory. This is exactly why projects get zipped first: it's not optional plumbing, it's the mechanism for handing back a whole folder as one deliverable.
+- If present-add is called multiple times across a session and some of those earlier presents are now stale/superseded (e.g. you're re-zipping after a fix), use present-clear first so the user doesn't end up with old and new versions both listed.
+- Use present-get-list if you need to confirm what's currently presented before deciding whether to clear or add more.
+
+## What this does NOT mean
+- Don't zip trivial output just to have "one file" — a single script or a couple of standalone documents should still be presented individually; zipping one file adds an unzip step for no reason.
+- Don't delete anything you're not confident is regenerable/unnecessary. When a folder's purpose is ambiguous, inspect it rather than guessing — an overzealous cleanup that removes something the user actually wanted is worse than a slightly larger zip.
+- Cleanup is about removing artifacts that don't belong in a delivered archive, not about editing or "improving" the user's actual project files — don't modify source/content as part of this skill's cleanup step.
+`
+});
+export default PresentSkill;
+//# sourceMappingURL=present.js.map

package/dist/skills/present.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"present.js","sourceRoot":"","sources":["../../src/skills/present.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,YAAY,EAAE,MAAM,2BAA2B,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AACnD,OAAO,EAAE,aAAa,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAC;AAE/E,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACxC,IAAI,EAAE,SAAS;IACf,WAAW,EAAE,wfAAwf;IACrgB,KAAK,EAAE;QACH,GAAG,YAAY,EAAE;QACjB,GAAG,SAAS,EAAE;QACd,aAAa,EAAE;QACf,YAAY,EAAE;QACd,UAAU,EAAE;KACf;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsCjB;CACA,CAAC,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/skills/question-answer.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const QuestionAnswerSkill: () => Skill;
+export default QuestionAnswerSkill;
+//# sourceMappingURL=question-answer.d.ts.map

package/dist/skills/question-answer.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"question-answer.d.ts","sourceRoot":"","sources":["../../src/skills/question-answer.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAGrC,eAAO,MAAM,mBAAmB,aAkD9B,CAAC;AAEH,eAAe,mBAAmB,CAAC"}

package/dist/skills/question-answer.js

@@ -0,0 +1,55 @@
+import Skill from "../core/skill.js";
+import { QuestionAnswerTools } from "../tools/question-answer/index.js";
+export const QuestionAnswerSkill = () => new Skill({
+    name: "question-answer",
+    description: "Use this skill whenever the agent needs information, clarification, confirmation, or a decision from the user before it can safely or correctly continue a task. Trigger this any time the next step depends on something only the user can provide — missing requirements, ambiguous instructions, a choice between multiple valid approaches, confirmation before a destructive or irreversible action, or any other point where guessing would risk doing the wrong thing. Do not use this to ask questions the agent could instead answer by reading files, running commands, or searching — only use it when the user themselves is the source of the needed information.",
+    tools: [
+        ...QuestionAnswerTools()
+    ],
+    instructions: `
+# Question Answer Skill
+
+## Purpose
+Use this skill when the agent has reached a point where it cannot safely or correctly proceed without input from the user — missing information, genuine ambiguity, a choice between multiple reasonable paths, or confirmation before something risky or irreversible.
+
+## The tool
+There is a single tool, \`question-answer\`, which takes one input:
+- \`questions\`: an array of \`{ question: string, predefinedAnswer?: string[] }\` objects.
+
+Because it takes an array, always batch every question the agent currently needs into **one** \`question-answer\` call rather than calling the tool multiple times in a row. If the agent has three things to clarify, that's one call with three entries in \`questions\`, not three separate calls.
+
+Use \`predefinedAnswer\` to offer suggested/likely answers as a list of short strings when reasonable options exist (e.g. \`["yes", "no"]\` or \`["PostgreSQL", "MySQL", "SQLite"]\`). Leave it out for genuinely open-ended questions.
+
+## Core rule: ask, then stop
+When questions need to be asked, call \`question-answer\` with all of them and then **do nothing else**. Do not:
+- Continue reasoning about the task
+- Make assumptions and proceed anyway "just in case"
+- Call other tools
+- Produce a final answer or summary
+- Call \`question-answer\` again in the same turn
+
+This tool has \`stopIterationAfterUsingThisTool\` set — the agent's turn ends automatically by system logic the moment it's called. The tool call itself is the entire action for that turn. The user's answers will arrive as a new turn, at which point the agent resumes normally using them.
+
+## When to ask vs. when not to ask
+Ask the user when:
+- Required information is missing and cannot be discovered by reading files, running commands, or searching
+- The task is ambiguous enough that different reasonable interpretations would lead to meaningfully different outcomes
+- Multiple valid approaches exist and the choice depends on user preference, not technical correctness
+- An action is destructive, irreversible, or high-cost (e.g. deleting data, spending money, sending something externally) and confirmation is warranted
+
+Do not ask when:
+- The answer can be found by inspecting the project, files, or environment directly — investigate first, ask second
+- The ambiguity is minor and a sensible default exists — pick the default, note the assumption, and proceed
+- The agent already asked this same question earlier in the conversation and got an answer
+
+## How to ask
+- Batch all currently-needed questions into the single \`questions\` array for one tool call — don't split related questions across multiple calls.
+- Phrase each question so it's understandable on its own, with enough context that the user doesn't need to re-read the whole conversation.
+- Supply \`predefinedAnswer\` options where a small set of likely answers exists, to make answering faster for the user.
+
+## After the tool call
+Nothing. The agent does not add commentary, does not summarize what it's about to do next, and does not speculate about likely answers. The turn is over as soon as \`question-answer\` is called — the system handles pausing and waiting for the user's response.
+`
+});
+export default QuestionAnswerSkill;
+//# sourceMappingURL=question-answer.js.map

package/dist/skills/question-answer.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"question-answer.js","sourceRoot":"","sources":["../../src/skills/question-answer.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,mBAAmB,EAAE,MAAM,mCAAmC,CAAC;AAExE,MAAM,CAAC,MAAM,mBAAmB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAC/C,IAAI,EAAE,iBAAiB;IACvB,WAAW,EAAE,gpBAAgpB;IAC7pB,KAAK,EAAE;QACH,GAAG,mBAAmB,EAAE;KAC3B;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2CjB;CACA,CAAC,CAAC;AAEH,eAAe,mBAAmB,CAAC"}

package/dist/skills/react-frontend.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const ReactFrontendSkill: () => Skill;
+export default ReactFrontendSkill;
+//# sourceMappingURL=react-frontend.d.ts.map

package/dist/skills/react-frontend.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"react-frontend.d.ts","sourceRoot":"","sources":["../../src/skills/react-frontend.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AASrC,eAAO,MAAM,kBAAkB,aAwG7B,CAAC;AAEH,eAAe,kBAAkB,CAAC"}

package/dist/skills/react-frontend.js

@@ -0,0 +1,111 @@
+import Skill from "../core/skill.js";
+import { FsTools, } from "../tools/fs/index.js";
+import { BashTools, } from "../tools/bash/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const ReactFrontendSkill = () => new Skill({
+    name: "react-frontend",
+    description: "Use this skill whenever the task involves building, modifying, running, or debugging a modern React project (.tsx or .jsx), typically Vite-scaffolded — creating new components or pages, adding features to an existing React app, fixing a rendering or state bug, wiring up routing/forms/data-fetching, starting or restarting a dev server, or running a production build. Also covers scaffolding a brand-new React project from scratch. Trigger this for any React/frontend coding task, whether the project already exists on disk or needs to be created.",
+    tools: [
+        ...FsTools(),
+        ...BashTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# React Frontend Skill
+
+## Purpose
+Use this skill when building, modifying, or running a modern React project (TSX or JSX), typically scaffolded with Vite.
+
+## Project structure (mandatory for new projects)
+
+Don't let every component pile up flat in \`src/\`. Pick a structure up front based on project size and stick to it:
+
+**Small/medium projects (a handful of pages, one cohesive app):** type-first:
+\`\`\`
+src/
+  components/     # reusable, presentational building blocks (Button, Modal, Card)
+  pages/          # route-level components, one per route/screen
+  hooks/          # custom hooks (useAuth, useFetch, etc.)
+  services/       # API calls / data-fetching layer — no component ever calls fetch()/axios directly, it goes through here
+  context/        # React context providers, or store/ if using a state library (Zustand, Redux)
+  utils/          # pure helper functions
+  types/          # shared TS types/interfaces (TSX projects only)
+  assets/         # images, fonts, static files
+  App.tsx
+  main.tsx
+\`\`\`
+
+**Larger projects (many distinct features/domains, e.g. "checkout", "profile", "admin" that don't share much UI):** feature-first, where each feature owns its own slice:
+\`\`\`
+src/
+  features/
+    checkout/
+      components/
+      hooks/
+      checkout.service.ts
+      CheckoutPage.tsx
+    profile/
+      components/
+      hooks/
+      profile.service.ts
+      ProfilePage.tsx
+  components/     # truly shared/cross-feature components only (Button, Modal)
+  hooks/          # truly shared hooks only
+  services/       # shared API client setup (base fetch wrapper, auth interceptor)
+  context/ or store/
+  utils/
+  types/
+  App.tsx
+  main.tsx
+\`\`\`
+
+**Choosing between them:** default to type-first for anything that's clearly one small-to-medium app. Switch to feature-first once distinct product areas stop sharing much and cross-navigating \`components/\`/\`hooks/\` to find "everything related to checkout" becomes tedious. If the project already has an established convention, match it rather than imposing a different one mid-project.
+
+**Regardless of which convention:**
+- Presentational components (in \`components/\`) should not fetch data directly — data fetching lives in \`services/\`, wired up via hooks, and passed down as props or accessed via a hook the component calls.
+- Pages/route-level components can orchestrate hooks and services but should delegate actual rendering detail to smaller components rather than being 500-line files.
+- Don't hardcode API base URLs inline in a component or service file — centralize them via \`import.meta.env.VITE_*\` and a single API client module, so there's one place to change the base URL.
+- Co-locate a component's styles/tests with the component itself (e.g. \`Button.tsx\`, \`Button.module.css\`, \`Button.test.tsx\` in the same folder) rather than separating by file type across the whole project.
+
+For any real user-facing UI, apply the ui-ux-design skill alongside this one — a component that renders and handles clicks but has no loading/empty/error states, no keyboard accessibility, or generic unexamined styling is not a finished deliverable.
+
+Before handoff, pair this skill with code-verification (typecheck/build clean — for TSX projects, \`tsc --noEmit\` or the project's own typecheck script) and web-end-to-end-test (actually drive the running app in a browser and confirm real behavior) — a component that "looks right" in source but hasn't been typechecked and hasn't actually been clicked through in a live session is not verified.
+
+## Starting a new project
+Scaffold with Vite via \`bash-run\` (use \`cwd\` for where it should be created, and a real project name instead of "my-app" unless the user hasn't specified one):
+- React + TypeScript: \`npm create vite@latest my-app -- --template react-ts --no-interactive --eslint\`
+- React + JavaScript: \`npm create vite@latest my-app -- --template react --no-interactive --eslint\`
+
+Then:
+1. \`npm install\` (or \`npm i\`) with \`cwd\` set to the new project folder — required before anything will run.
+2. \`npm run dev\` via \`bash-run\` to start the dev server. This is a long-running process: it will return with status \`"running"\` once \`waitMs\` elapses rather than exiting. Save the \`processId\`.
+3. Confirm it actually started by checking the output/\`bash-logs\` for the local dev URL (e.g. "Local: http://localhost:5173/") rather than assuming success just because the command didn't error immediately.
+
+## Working with an existing project
+- \`fs-list-dir\` (recursive when needed, paged via \`offsetResult\`/\`limitResult\` for large trees) before assuming the project's structure — check whether it uses \`src/\` conventions, a router, a state library, TSX vs JSX, before writing new code.
+- Read \`package.json\` first to see what's already installed (React version, router, UI library, styling approach — Tailwind vs CSS modules vs styled-components etc.) and match it. Don't introduce a second styling system or router into a project that already has one.
+- Prefer targeted edits (replacing a specific line range) over rewriting a whole existing file, so unrelated code isn't accidentally dropped. Read the file first to get current line numbers, since prior edits may have shifted them — a full-file overwrite has no undo, so treat it as safe only for brand-new files or after reviewing the complete current content.
+
+## Component and code conventions
+- Match the existing file's extension and import style: if the project is \`.tsx\`, write typed props; if \`.jsx\`, don't introduce TypeScript syntax.
+- Keep components focused — one component per concern; extract a sub-component rather than letting one file grow unmanageable, matching whatever granularity the existing codebase already uses.
+- Follow the existing project's conventions for state management, data fetching, and styling rather than introducing your own preferred pattern from scratch.
+- Don't leave unused imports, dead code, or commented-out blocks behind after an edit.
+
+## Running and verifying your work
+Writing a component is not the job — confirming it renders and behaves correctly is:
+1. Make sure the dev server is running, starting it if not.
+2. After a change, check the dev server's logs for compile errors — Vite/React will report these there before you ever open a browser.
+3. If a build is required for the task (not just dev iteration), actually run the production build and check the output for errors/warnings rather than assuming a clean dev server means the production build also succeeds.
+4. When the change is behavior-sensitive (a form, a click handler, navigation, data fetching) and browser tools are available in this environment, actually drive the running dev server with the browser tools (open a session at the dev URL, read the page, interact, re-read) to confirm the real rendered behavior matches intent — don't rely on "the code looks right" alone.
+5. Stop the dev server when done verifying, unless the user wants it left running for their own use.
+
+## Common pitfalls to avoid
+- Forgetting to actually install a dependency after adding it to \`package.json\` by hand — reference in code is not enough.
+- Starting a second dev server on the same port when one is already running — check running processes first.
+- Editing a file without reading it first — targeted line-based edits require accurate current line numbers, and guessing them corrupts the file.
+- Hardcoding API URLs/secrets into frontend source — these ship to the browser in plain text; use environment variables (Vite: \`import.meta.env.VITE_*\`) and flag to the user if a required \`.env\` value is missing.
+`
+});
+export default ReactFrontendSkill;
+//# sourceMappingURL=react-frontend.js.map

package/dist/skills/react-frontend.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"react-frontend.js","sourceRoot":"","sources":["../../src/skills/react-frontend.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EACH,OAAO,GACV,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACH,SAAS,GACZ,MAAM,wBAAwB,CAAC;AAChC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,kBAAkB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAC9C,IAAI,EAAE,gBAAgB;IACtB,WAAW,EAAE,qiBAAqiB;IACljB,KAAK,EAAE;QACH,GAAG,OAAO,EAAE;QACZ,GAAG,SAAS,EAAE;QACd,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+FjB;CACA,CAAC,CAAC;AAEH,eAAe,kBAAkB,CAAC"}

package/dist/skills/research.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const ResearchSkill: () => Skill;
+export default ResearchSkill;
+//# sourceMappingURL=research.d.ts.map

package/dist/skills/research.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"research.d.ts","sourceRoot":"","sources":["../../src/skills/research.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAIrC,eAAO,MAAM,aAAa,aA2ExB,CAAC;AAEH,eAAe,aAAa,CAAC"}

package/dist/skills/research.js

@@ -0,0 +1,81 @@
+import Skill from "../core/skill.js";
+import { BrowserTools } from "../tools/browser/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const ResearchSkill = () => new Skill({
+    name: "research",
+    description: "Use this skill whenever a question needs real, current information from the live web rather than training data — current events, prices, recent releases, live documentation, specific facts that could have changed, comparisons, or anything the agent isn't fully certain about. Drives a real headless browser: opens search engines and pages, reads them, clicks through, fills and submits forms, waits for slow/JS-heavy pages to finish loading, and cross-checks multiple independent sources before answering — never treats a single opened page as a finished answer. Trigger this any time an answer would otherwise be a guess, could be outdated, needs verification from an actual live source instead of memory, or spans enough distinct sub-questions/sources that it should be planned rather than done ad hoc. For large research jobs (many sub-questions, a full report, a comparison across many items), this skill works together with the planner skill (to track sub-questions as checkable tasks) and the long-task-efficiency skill (to avoid wasteful re-opening/re-reading across a long session) — treat all three as one workflow on big jobs, not separate silos.",
+    tools: [
+        ...BrowserTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Research Skill
+
+## Mindset: one source is a data point, not an answer
+A search engine's results page is a list of guesses, not an answer, and a single opened page is one person's/one outlet's account, not the truth. The single most common way research goes wrong is stopping the moment *something* was found — opening one page, reading a plausible-sounding paragraph, and reporting it as fact. Never do this. Treat "I found a page that says X" and "I have confirmed X" as two different states, and don't report the second when you've only reached the first.
+
+The bar for "done": you have opened and actually read **multiple independent sources** that agree (or you've explicitly noted where and why they disagree), not just multiple search results skimmed from a results page. Independent means different publishers/authors/original data — three news aggregators repeating the same wire story are one source, not three.
+
+**How many sources is enough** scales with stakes:
+- A single stable, easily-verified fact (a date, a definition, a spec value from an official doc) — one authoritative primary source can be enough, but prefer the primary source itself (official docs, the company's own page, a primary filing) over a summary of it.
+- Anything numeric, time-sensitive, or where sources could disagree (prices, statistics, "current" status, recent events) — corroborate across at least 2–3 independent sources before reporting a number or status as settled.
+- Anything contested, high-stakes, or where you notice initial sources disagree — keep going until the disagreement is either resolved or explicitly characterized as an open disagreement in your answer. Don't average conflicting numbers or silently pick one; open more sources specifically to adjudicate, or report the split.
+- A broad/open-ended question (a comparison, "what are the best X," a full research report) — this isn't a few-source job, it's a many-source job; see "Scaling to bigger jobs" below.
+
+## Search engine strategy
+- **Never use Google** as your search entry point — it blocks automated/headless browsers and will waste a turn on a block page or CAPTCHA before you even get results. Default to **DuckDuckGo first**; fall back to **Bing** if DuckDuckGo's results are thin, stale, or don't surface what you need for a particular query. If the user already named an exact site/URL to use, go straight there instead of a general search engine.
+- Vary your query phrasing meaningfully between attempts — a query that comes back thin is a signal to reformulate (different terms, add a year/date, name a more specific source, change the angle), not to re-run the same phrase on a second engine and call it a new attempt.
+- Prefer going straight to a known authoritative domain when you already know where the answer lives (official docs, a company's own blog/press page, a government or standards site) rather than routing everything through a general search engine first.
+
+## Handling bot checks and CAPTCHAs — skip, don't fight
+- If a page shows a CAPTCHA, "verify you're human," a hard login wall, or any other bot-check, **do not attempt to solve it and do not retry the same page more than once.** Abandon that source immediately and pick a different result. There are almost always other sources with equivalent information; burning turns fighting a bot check is close to always the wrong tradeoff versus just moving to the next link.
+- The same applies to paywalled or clearly spam/low-quality/SEO-farm pages — recognize them quickly (thin content, no author/publisher, content that doesn't match the title) and move on rather than trying to extract signal from a bad source.
+- Google specifically is likely to bot-check headless traffic on the results page itself — this is the main reason to avoid it as an entry point, not just a stylistic preference.
+
+## Core loop
+1. **Open a session** on a search engine (DuckDuckGo, falling back to Bing) or a known site if you already know exactly where to look. Keep track of its session id — every other browser action needs it.
+2. **Read the page** to get a structured outline of headings, text, links, buttons, and form fields, each tagged with a reference id you use to act on it. You cannot see pixels — only this outline — so never guess a selector or a URL; only act on refs you actually read.
+3. **Check the page is actually ready before you trust it.** JS-heavy pages can still be loading when you first read them. If a page looks sparse, blank, or mid-load, check whether network requests are still pending. If they are, wait briefly and re-check rather than reading immediately — don't just barrel ahead and read a half-loaded page as if it were final. If a page seems broken, unexpectedly empty, or a submitted form seems to have done nothing, check the page's logged console output for errors before deciding it failed.
+4. **Act** — click a link/button ref, or fill a text field ref with a value. For a plain search box with no visible submit button, fill it and submit on enter, or submit the form directly by its ref.
+5. **Re-read after every action that changes the page.** Refs from before an action are stale the instant the DOM changes — a click, a navigation, a form submit, a scroll that lazy-loads new content. Always take a fresh read after any of these before your next action.
+6. **When reading a long page**, if the output is truncated, continue reading the *same* snapshot using the continuation reference provided rather than re-reading from scratch — re-reading from scratch mid-page hands you an entirely new set of refs and silently invalidates the ones you already noted. Only take a fresh (non-continuation) read when the page itself has actually changed.
+7. **Go deep, not just wide on the results page.** Read the search results outline, pick several promising links by their ref, and open each in turn — don't stop after skimming just the results page text. Aim to actually visit enough distinct sources that you could defend your answer if challenged, not just the first hit.
+8. **If a page is slow or looks incomplete**, use the delay utility to give it time to finish loading, then re-check network activity and re-read, instead of immediately giving up on the source or reporting incomplete content as if it were complete.
+9. **Close every session** you opened once you're done with it. Don't leave sessions open, and don't open a new session per page — reuse one session across an entire line of research; multiple navigations within the same session are normal and expected.
+
+## Content that only appears after scrolling or clicking a tab — a common false negative
+A page reading as "sparse" or "missing the section I need" is not always the whole story. Many sites lazy-load content only once it's scrolled into view, or hide it behind a tab/accordion that isn't expanded by default: comment sections, review sections, extended specs, citation/reference lists, "read more" truncated article bodies, and related-content sections are all commonly gated this way. If you expected a page to contain something (a count/summary near the top implies more detail exists further down — e.g. a visible review count or comment count with no actual review/comment text shown yet) and don't see it in your first read, don't conclude it's absent:
+- Check whether there's a tab, "Show more," or anchor link to click that reveals the section, and click it, then re-read.
+- If the page is long, scroll toward where the missing content should logically be (near a count/summary that hints at it) and re-read — content genuinely can be present in the DOM only after that scroll position is reached.
+- Only conclude a section is genuinely absent after you've tried the applicable one of these, not on the strength of a single top-of-page read.
+- After any scroll or tab-click, treat prior refs as stale and take a fresh read, same as after any other page-changing action.
+
+## Corroboration discipline (the step people skip)
+Before you write a single fact into your answer, ask: *have I actually opened a second independent source for this, or am I about to report from memory of one page?* Concretely:
+- After opening your first promising source, deliberately open at least one more before drafting any claim that's numeric, time-sensitive, or contested — don't draft the answer and "check it later"; check first.
+- If your second source agrees, you're likely done for that specific claim (unless stakes call for a third — see thresholds above). If it disagrees, that disagreement is itself a signal to open a third source to adjudicate, not to just pick whichever you saw first or whichever sounds more confident.
+- Keep a running mental (or, on a big job, written — see below) list of "claim → which sources actually support it" so you don't lose track of what's been corroborated versus what's still resting on one page.
+- Note in your final answer when sources genuinely disagree and couldn't be resolved — this is a better outcome than silently picking one, and it's honest about the state of the evidence.
+
+## Scaling to bigger jobs — fuse with planner and long-task-efficiency
+A "research the competitive landscape," "write a report on X," or "compare these five options across these six dimensions" job is not a few-source job — it's a many-source job that needs the same discipline as any other large task:
+- **Use the planner skill's todo list** to break the research into concrete, checkable sub-questions (one sub-question or comparison-cell = one task) before opening a single browser tab. This is what keeps a long research session honest — you can always answer "what's actually been corroborated so far and what's still open" by checking the list, rather than trying to hold it all in your head across dozens of page opens.
+- **Apply big-task's core rule**: don't respond to "this needs a lot of sources" by doing three sources and writing "you could look into the rest yourself." If the job calls for checking ten items, check ten items, not three plus a note that the pattern generalizes.
+- **Apply long-task-efficiency's discipline** on a long research session specifically: reuse one browser session across a whole line of inquiry rather than opening a new one per page; don't re-open a source you've already read and corroborated unless something suggests it may have changed; batch independent lookups (e.g. researching five unrelated companies for a comparison) rather than fully context-switching prose between every single one; checkpoint sub-question-by-sub-question in the todo list so an interrupted session resumes cheaply instead of re-researching from scratch.
+- **Report progress honestly on long jobs**: if asked for status mid-research, say what's actually been corroborated, what's been opened but not yet cross-checked, and what hasn't been touched yet — not an optimistic gloss.
+
+## Handling obstacles (quick reference)
+- **Bot checks / CAPTCHA / login walls**: don't try to solve them. Abandon that source immediately and pick a different result.
+- **Slow-loading or JS-heavy pages**: wait, check network status again, then read — don't mistake a loading spinner for "no results."
+- **Empty or broken-looking pages**: check console output for errors before concluding the page has nothing useful; a broken script isn't the same as an empty page.
+- **Ambiguous or conflicting information across sources**: don't average or guess — open one or two more sources specifically to resolve the conflict, and note the disagreement in your answer if it can't be resolved.
+
+## Standards for a finished answer
+- Never fabricate a URL, a search result, a page's contents, or a quote. Everything reported must come from a page you actually opened and read.
+- Never present an answer built from a single opened source as if it were fully corroborated — if you genuinely could only find one source after real effort, say so plainly ("I could only find this stated in one place") rather than implying broader confirmation than you actually have.
+- Prefer answers backed by multiple independently-opened sources over a single page, especially for anything numeric, time-sensitive, or contested.
+- If, after a reasonable number of attempts, good sources can't be found or loaded, say so plainly rather than presenting a thin or single-source answer with unwarranted confidence.
+`
+});
+export default ResearchSkill;
+//# sourceMappingURL=research.js.map

package/dist/skills/research.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"research.js","sourceRoot":"","sources":["../../src/skills/research.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,YAAY,EAAE,MAAM,2BAA2B,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,aAAa,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACzC,IAAI,EAAE,UAAU;IAChB,WAAW,EAAE,soCAAsoC;IACnpC,KAAK,EAAE;QACH,GAAG,YAAY,EAAE;QACjB,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmEjB;CACA,CAAC,CAAC;AAEH,eAAe,aAAa,CAAC"}

package/dist/skills/shopping.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const ShoppingSkill: () => Skill;
+export default ShoppingSkill;
+//# sourceMappingURL=shopping.d.ts.map

package/dist/skills/shopping.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shopping.d.ts","sourceRoot":"","sources":["../../src/skills/shopping.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAIrC,eAAO,MAAM,aAAa,aAiExB,CAAC;AAEH,eAAe,aAAa,CAAC"}