orbitx 0.0.8 → 0.0.9

package/dist/index.d.ts

@@ -1,5 +1,5 @@
 export { AIProvider } from "./core/ai-provider.js";
-export type { ChatResponse, Message, StreamCallback } from "./core/ai-provider.js";
+export type { ChatResponse, Message, StreamCallback, ToolSchema, ToolCallRequest, MessageContentPart, ProviderCapabilities } from "./core/ai-provider.js";
 export { BaseAgent } from "./core/base-agent.js";
 export type { ExtractedSegment, ParsedToolCall } from "./core/base-agent.js";
 export { DeepSeekProvider } from "./core/deepseek-provider.js";
@@ -7,12 +7,40 @@ export { MCPClient } from "./core/mcp-client.js";
 export { MCPConnection } from "./core/mcp-connection.js";
 export { MCPIPCConnection } from "./core/mcp-ipc-connection.js";
 export { MCPServer } from "./core/mcp-server.js";
-export { MCPTool } from "./core/mcp.js";
+export { MCPTool, MCPCustomClass, generateRefId, normalizeToolOutput } from "./core/mcp.js";
+export type { MCP, MCPToolOutput } from "./core/mcp.js";
 export { OllamaProvider } from "./core/ollama-provider.js";
 export { Skill } from "./core/skill.js";
-export { ResearcherAgent } from "./templates/researcher.js";
+export { MCPComputer } from "./core/mcp-computer.js";
+export { ImageDescriber } from "./core/image-describer.js";
+export { toOpenAIFunctionTools } from "./core/tool-schema-translator.js";
+export { resolveAgentProviders } from "./core/agent-providers.js";
+export type { AgentProviderRole, AgentProviderEntry, AgentProvidersInput, ResolvedAgentProviders } from "./core/agent-providers.js";
 export { SimpleAgent } from "./templates/simple.js";
-export { ReadFileTool, WriteFileTool } from "./tools/fs/index.js";
-export { GetCurrentTimeTool } from "./tools/utils/index.js";
-export { FetchTool, ReadWebPageTool, WebSearchTool } from "./tools/www/index.js";
+export { GetCurrentTimeTool, DelayTool, UtilTools } from "./tools/utils/index.js";
+export { TodoCreateListTool, TodoRemoveListTool, TodoGetListsTool, TodoGetListTool, TodoCreateTaskTool, TodoRemoveTaskTool, TodoCheckTaskTool, TodoTools, TodoInteraction, } from "./tools/todo/index.js";
+export type { TodoTask, TodoList, TodoEvent } from "./tools/todo/index.js";
+export { BrowserCreateSessionTool, BrowserRemoveSessionTool, BrowserGetSessionsTool, BrowserNavigateTool, BrowserConsoleTool, BrowserInjectTool, BrowserReadTool, BrowserClickTool, BrowserFillTool, BrowserScrollInfoTool, BrowserScrollTool, BrowserNetworkStatusTool, BrowserNetworkTool, BrowserSubmitFormTool, BrowserScreenshotTool, BrowserTools, BrowserInteraction, } from "./tools/browser/index.js";
+export type { BrowserEvent } from "./tools/browser/index.js";
+export { FsReadFileTool, FsWriteFileTool, FsEditFileTool, FsListDirTool, FsCreateDirTool, FsDeleteTool, FsMoveTool, FsStatTool, FsTools, FsInteraction, } from "./tools/fs/index.js";
+export type { FsEvent } from "./tools/fs/index.js";
+export { BashRunTool, BashWaitTool, BashLogsTool, BashListTool, BashWriteInputTool, BashTerminateTool, BashTools, BashInteraction, } from "./tools/bash/index.js";
+export type { BashEvent } from "./tools/bash/index.js";
+export { PresentAddTool, PresentClearTool, PresentGetListTool, PresentTools, getPresentFolder, PresentInteraction } from "./tools/present/index.js";
+export type { PresentEvent } from "./tools/present/index.js";
+export { QuestionAnswerTool, QuestionAnswerTools, QuestionAnswerInteraction } from "./tools/question-answer/index.js";
+export type { QuestionAnswerEvent } from "./tools/question-answer/index.js";
+export { BackendSecuritySkill } from "./skills/backend-security.js";
+export { BigTaskSkill } from "./skills/big-task.js";
+export { CodeVerificationSkill } from "./skills/code-verification.js";
+export { LongTaskEfficiencySkill } from "./skills/long-task-efficiency.js";
+export { NodeBackendSkill } from "./skills/node-backend.js";
+export { PlannerSkill } from "./skills/planner.js";
+export { PresentSkill } from "./skills/present.js";
+export { QuestionAnswerSkill } from "./skills/question-answer.js";
+export { ReactFrontendSkill } from "./skills/react-frontend.js";
+export { ResearchSkill } from "./skills/research.js";
+export { ShoppingSkill } from "./skills/shopping.js";
+export { UiUxDesignSkill } from "./skills/ui-ux-design.js";
+export { WebEndToEndTestSkill } from "./skills/web-end-to-end-test.js";
 //# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AACnD,YAAY,EAAE,YAAY,EAAE,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AACnF,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,YAAY,EAAE,gBAAgB,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAC7E,OAAO,EAAE,gBAAgB,EAAE,MAAM,6BAA6B,CAAC;AAC/D,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,0BAA0B,CAAC;AACzD,OAAO,EAAE,gBAAgB,EAAE,MAAM,8BAA8B,CAAC;AAChE,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AACxC,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,KAAK,EAAE,MAAM,iBAAiB,CAAC;AAExC,OAAO,EAAE,eAAe,EAAE,MAAM,2BAA2B,CAAC;AAC5D,OAAO,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAEpD,OAAO,EAAE,YAAY,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAClE,OAAO,EAAE,kBAAkB,EAAE,MAAM,wBAAwB,CAAC;AAC5D,OAAO,EAAE,SAAS,EAAE,eAAe,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AACnD,YAAY,EAAE,YAAY,EAAE,OAAO,EAAE,cAAc,EAAE,UAAU,EAAE,eAAe,EAAE,kBAAkB,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAC1J,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,YAAY,EAAE,gBAAgB,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAC7E,OAAO,EAAE,gBAAgB,EAAE,MAAM,6BAA6B,CAAC;AAC/D,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,0BAA0B,CAAC;AACzD,OAAO,EAAE,gBAAgB,EAAE,MAAM,8BAA8B,CAAC;AAChE,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,OAAO,EAAE,cAAc,EAAE,aAAa,EAAE,mBAAmB,EAAE,MAAM,eAAe,CAAC;AAC5F,YAAY,EAAE,GAAG,EAAE,aAAa,EAAE,MAAM,eAAe,CAAC;AACxD,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,KAAK,EAAE,MAAM,iBAAiB,CAAC;AACxC,OAAO,EAAE,WAAW,EAAE,MAAM,wBAAwB,CAAC;AACrD,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,qBAAqB,EAAE,MAAM,kCAAkC,CAAC;AACzE,OAAO,EAAE,qBAAqB,EAAE,MAAM,2BAA2B,CAAC;AAClE,YAAY,EAAE,iBAAiB,EAAE,kBAAkB,EAAE,mBAAmB,EAAE,sBAAsB,EAAE,MAAM,2BAA2B,CAAC;AAEpI,OAAO,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAEpD,OAAO,EAAE,kBAAkB,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAElF,OAAO,EACH,kBAAkB,EAClB,kBAAkB,EAClB,gBAAgB,EAChB,eAAe,EACf,kBAAkB,EAClB,kBAAkB,EAClB,iBAAiB,EACjB,SAAS,EACT,eAAe,GAClB,MAAM,uBAAuB,CAAC;AAC/B,YAAY,EAAE,QAAQ,EAAE,QAAQ,EAAE,SAAS,EAAE,MAAM,uBAAuB,CAAC;AAE3E,OAAO,EACH,wBAAwB,EACxB,wBAAwB,EACxB,sBAAsB,EACtB,mBAAmB,EACnB,kBAAkB,EAClB,iBAAiB,EACjB,eAAe,EACf,gBAAgB,EAChB,eAAe,EACf,qBAAqB,EACrB,iBAAiB,EACjB,wBAAwB,EACxB,kBAAkB,EAClB,qBAAqB,EACrB,qBAAqB,EACrB,YAAY,EACZ,kBAAkB,GACrB,MAAM,0BAA0B,CAAC;AAClC,YAAY,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAE7D,OAAO,EACH,cAAc,EACd,eAAe,EACf,cAAc,EACd,aAAa,EACb,eAAe,EACf,YAAY,EACZ,UAAU,EACV,UAAU,EACV,OAAO,EACP,aAAa,GAChB,MAAM,qBAAqB,CAAC;AAC7B,YAAY,EAAE,OAAO,EAAE,MAAM,qBAAqB,CAAC;AAEnD,OAAO,EACH,WAAW,EACX,YAAY,EACZ,YAAY,EACZ,YAAY,EACZ,kBAAkB,EAClB,iBAAiB,EACjB,SAAS,EACT,eAAe,GAClB,MAAM,uBAAuB,CAAC;AAC/B,YAAY,EAAE,SAAS,EAAE,MAAM,uBAAuB,CAAC;AAEvD,OAAO,EACH,cAAc,EACd,gBAAgB,EAChB,kBAAkB,EAClB,YAAY,EACZ,gBAAgB,EAChB,kBAAkB,EACrB,MAAM,0BAA0B,CAAC;AAClC,YAAY,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAE7D,OAAO,EACH,kBAAkB,EAClB,mBAAmB,EACnB,yBAAyB,EAC5B,MAAM,kCAAkC,CAAC;AAC1C,YAAY,EAAE,mBAAmB,EAAE,MAAM,kCAAkC,CAAC;AAE5E,OAAO,EAAE,oBAAoB,EAAE,MAAM,8BAA8B,CAAC;AACpE,OAAO,EAAE,YAAY,EAAE,MAAM,sBAAsB,CAAC;AACpD,OAAO,EAAE,qBAAqB,EAAE,MAAM,+BAA+B,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,MAAM,kCAAkC,CAAC;AAC3E,OAAO,EAAE,gBAAgB,EAAE,MAAM,0BAA0B,CAAC;AAC5D,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,mBAAmB,EAAE,MAAM,6BAA6B,CAAC;AAClE,OAAO,EAAE,kBAAkB,EAAE,MAAM,4BAA4B,CAAC;AAChE,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,eAAe,EAAE,MAAM,0BAA0B,CAAC;AAC3D,OAAO,EAAE,oBAAoB,EAAE,MAAM,iCAAiC,CAAC"}

package/dist/index.js

@@ -5,12 +5,32 @@ export { MCPClient } from "./core/mcp-client.js";
 export { MCPConnection } from "./core/mcp-connection.js";
 export { MCPIPCConnection } from "./core/mcp-ipc-connection.js";
 export { MCPServer } from "./core/mcp-server.js";
-export { MCPTool } from "./core/mcp.js";
+export { MCPTool, MCPCustomClass, generateRefId, normalizeToolOutput } from "./core/mcp.js";
 export { OllamaProvider } from "./core/ollama-provider.js";
 export { Skill } from "./core/skill.js";
-export { ResearcherAgent } from "./templates/researcher.js";
+export { MCPComputer } from "./core/mcp-computer.js";
+export { ImageDescriber } from "./core/image-describer.js";
+export { toOpenAIFunctionTools } from "./core/tool-schema-translator.js";
+export { resolveAgentProviders } from "./core/agent-providers.js";
 export { SimpleAgent } from "./templates/simple.js";
-export { ReadFileTool, WriteFileTool } from "./tools/fs/index.js";
-export { GetCurrentTimeTool } from "./tools/utils/index.js";
-export { FetchTool, ReadWebPageTool, WebSearchTool } from "./tools/www/index.js";
+export { GetCurrentTimeTool, DelayTool, UtilTools } from "./tools/utils/index.js";
+export { TodoCreateListTool, TodoRemoveListTool, TodoGetListsTool, TodoGetListTool, TodoCreateTaskTool, TodoRemoveTaskTool, TodoCheckTaskTool, TodoTools, TodoInteraction, } from "./tools/todo/index.js";
+export { BrowserCreateSessionTool, BrowserRemoveSessionTool, BrowserGetSessionsTool, BrowserNavigateTool, BrowserConsoleTool, BrowserInjectTool, BrowserReadTool, BrowserClickTool, BrowserFillTool, BrowserScrollInfoTool, BrowserScrollTool, BrowserNetworkStatusTool, BrowserNetworkTool, BrowserSubmitFormTool, BrowserScreenshotTool, BrowserTools, BrowserInteraction, } from "./tools/browser/index.js";
+export { FsReadFileTool, FsWriteFileTool, FsEditFileTool, FsListDirTool, FsCreateDirTool, FsDeleteTool, FsMoveTool, FsStatTool, FsTools, FsInteraction, } from "./tools/fs/index.js";
+export { BashRunTool, BashWaitTool, BashLogsTool, BashListTool, BashWriteInputTool, BashTerminateTool, BashTools, BashInteraction, } from "./tools/bash/index.js";
+export { PresentAddTool, PresentClearTool, PresentGetListTool, PresentTools, getPresentFolder, PresentInteraction } from "./tools/present/index.js";
+export { QuestionAnswerTool, QuestionAnswerTools, QuestionAnswerInteraction } from "./tools/question-answer/index.js";
+export { BackendSecuritySkill } from "./skills/backend-security.js";
+export { BigTaskSkill } from "./skills/big-task.js";
+export { CodeVerificationSkill } from "./skills/code-verification.js";
+export { LongTaskEfficiencySkill } from "./skills/long-task-efficiency.js";
+export { NodeBackendSkill } from "./skills/node-backend.js";
+export { PlannerSkill } from "./skills/planner.js";
+export { PresentSkill } from "./skills/present.js";
+export { QuestionAnswerSkill } from "./skills/question-answer.js";
+export { ReactFrontendSkill } from "./skills/react-frontend.js";
+export { ResearchSkill } from "./skills/research.js";
+export { ShoppingSkill } from "./skills/shopping.js";
+export { UiUxDesignSkill } from "./skills/ui-ux-design.js";
+export { WebEndToEndTestSkill } from "./skills/web-end-to-end-test.js";
 //# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAEnD,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AAEjD,OAAO,EAAE,gBAAgB,EAAE,MAAM,6BAA6B,CAAC;AAC/D,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,0BAA0B,CAAC;AACzD,OAAO,EAAE,gBAAgB,EAAE,MAAM,8BAA8B,CAAC;AAChE,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AACxC,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,KAAK,EAAE,MAAM,iBAAiB,CAAC;AAExC,OAAO,EAAE,eAAe,EAAE,MAAM,2BAA2B,CAAC;AAC5D,OAAO,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAEpD,OAAO,EAAE,YAAY,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAClE,OAAO,EAAE,kBAAkB,EAAE,MAAM,wBAAwB,CAAC;AAC5D,OAAO,EAAE,SAAS,EAAE,eAAe,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAEnD,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AAEjD,OAAO,EAAE,gBAAgB,EAAE,MAAM,6BAA6B,CAAC;AAC/D,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,0BAA0B,CAAC;AACzD,OAAO,EAAE,gBAAgB,EAAE,MAAM,8BAA8B,CAAC;AAChE,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,OAAO,EAAE,cAAc,EAAE,aAAa,EAAE,mBAAmB,EAAE,MAAM,eAAe,CAAC;AAE5F,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,KAAK,EAAE,MAAM,iBAAiB,CAAC;AACxC,OAAO,EAAE,WAAW,EAAE,MAAM,wBAAwB,CAAC;AACrD,OAAO,EAAE,cAAc,EAAE,MAAM,2BAA2B,CAAC;AAC3D,OAAO,EAAE,qBAAqB,EAAE,MAAM,kCAAkC,CAAC;AACzE,OAAO,EAAE,qBAAqB,EAAE,MAAM,2BAA2B,CAAC;AAGlE,OAAO,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAEpD,OAAO,EAAE,kBAAkB,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAElF,OAAO,EACH,kBAAkB,EAClB,kBAAkB,EAClB,gBAAgB,EAChB,eAAe,EACf,kBAAkB,EAClB,kBAAkB,EAClB,iBAAiB,EACjB,SAAS,EACT,eAAe,GAClB,MAAM,uBAAuB,CAAC;AAG/B,OAAO,EACH,wBAAwB,EACxB,wBAAwB,EACxB,sBAAsB,EACtB,mBAAmB,EACnB,kBAAkB,EAClB,iBAAiB,EACjB,eAAe,EACf,gBAAgB,EAChB,eAAe,EACf,qBAAqB,EACrB,iBAAiB,EACjB,wBAAwB,EACxB,kBAAkB,EAClB,qBAAqB,EACrB,qBAAqB,EACrB,YAAY,EACZ,kBAAkB,GACrB,MAAM,0BAA0B,CAAC;AAGlC,OAAO,EACH,cAAc,EACd,eAAe,EACf,cAAc,EACd,aAAa,EACb,eAAe,EACf,YAAY,EACZ,UAAU,EACV,UAAU,EACV,OAAO,EACP,aAAa,GAChB,MAAM,qBAAqB,CAAC;AAG7B,OAAO,EACH,WAAW,EACX,YAAY,EACZ,YAAY,EACZ,YAAY,EACZ,kBAAkB,EAClB,iBAAiB,EACjB,SAAS,EACT,eAAe,GAClB,MAAM,uBAAuB,CAAC;AAG/B,OAAO,EACH,cAAc,EACd,gBAAgB,EAChB,kBAAkB,EAClB,YAAY,EACZ,gBAAgB,EAChB,kBAAkB,EACrB,MAAM,0BAA0B,CAAC;AAGlC,OAAO,EACH,kBAAkB,EAClB,mBAAmB,EACnB,yBAAyB,EAC5B,MAAM,kCAAkC,CAAC;AAG1C,OAAO,EAAE,oBAAoB,EAAE,MAAM,8BAA8B,CAAC;AACpE,OAAO,EAAE,YAAY,EAAE,MAAM,sBAAsB,CAAC;AACpD,OAAO,EAAE,qBAAqB,EAAE,MAAM,+BAA+B,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,MAAM,kCAAkC,CAAC;AAC3E,OAAO,EAAE,gBAAgB,EAAE,MAAM,0BAA0B,CAAC;AAC5D,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,mBAAmB,EAAE,MAAM,6BAA6B,CAAC;AAClE,OAAO,EAAE,kBAAkB,EAAE,MAAM,4BAA4B,CAAC;AAChE,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,eAAe,EAAE,MAAM,0BAA0B,CAAC;AAC3D,OAAO,EAAE,oBAAoB,EAAE,MAAM,iCAAiC,CAAC"}

package/dist/sandbox.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=sandbox.d.ts.map

package/dist/sandbox.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sandbox.d.ts","sourceRoot":"","sources":["../src/sandbox.ts"],"names":[],"mappings":""}

package/dist/sandbox.js

@@ -0,0 +1,27 @@
+import MCPFSStorage from "./core/mcp-fs-storage.js";
+import MCPIPCConnection from "./core/mcp-ipc-connection.js";
+import MCPRNG from "./core/mcp-rng.js";
+import MCPServer from "./core/mcp-server.js";
+import { BashTools } from "./tools/bash/index.js";
+import { BrowserTools } from "./tools/browser/index.js";
+import { FsTools } from "./tools/fs/index.js";
+import { PresentTools } from "./tools/present/index.js";
+import { TodoTools } from "./tools/todo/index.js";
+import { UtilTools } from "./tools/utils/index.js";
+console.log("Starting Sandbox MCP Server ...");
+const _MCPConnectionPath = process.env.MCPConnectionPath || "/tmp/mcp-server/socket.sock";
+const _MCPConnection = new MCPIPCConnection(_MCPConnectionPath);
+const _MCPStorage = new MCPFSStorage("/home/ubuntu/mcp-data");
+const _MCPRNG = new MCPRNG(_MCPStorage);
+const _MCPServer = new MCPServer(_MCPConnection, _MCPStorage, _MCPRNG);
+const tools = [
+    ...BashTools(),
+    ...BrowserTools(),
+    ...FsTools(),
+    ...PresentTools(),
+    ...TodoTools(),
+    ...UtilTools()
+];
+tools.forEach(tool => _MCPServer.registerTool(tool));
+console.log(`MCP Server Stared at "${_MCPConnectionPath}" with ${tools.map(t => t.getOptions().name)}`);
+//# sourceMappingURL=sandbox.js.map

package/dist/sandbox.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"sandbox.js","sourceRoot":"","sources":["../src/sandbox.ts"],"names":[],"mappings":"AAAA,OAAO,YAAY,MAAM,0BAA0B,CAAC;AACpD,OAAO,gBAAgB,MAAM,8BAA8B,CAAC;AAC5D,OAAO,MAAM,MAAM,mBAAmB,CAAC;AACvC,OAAO,SAAS,MAAM,sBAAsB,CAAC;AAC7C,OAAO,EAAE,SAAS,EAAE,MAAM,uBAAuB,CAAC;AAClD,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,OAAO,EAAE,MAAM,qBAAqB,CAAC;AAC9C,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,SAAS,EAAE,MAAM,uBAAuB,CAAC;AAClD,OAAO,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAEnD,OAAO,CAAC,GAAG,CAAC,iCAAiC,CAAC,CAAC;AAC/C,MAAM,kBAAkB,GAAG,OAAO,CAAC,GAAG,CAAC,iBAAiB,IAAI,6BAA6B,CAAC;AAC1F,MAAM,cAAc,GAAG,IAAI,gBAAgB,CAAC,kBAAkB,CAAC,CAAC;AAChE,MAAM,WAAW,GAAG,IAAI,YAAY,CAAC,uBAAuB,CAAC,CAAC;AAC9D,MAAM,OAAO,GAAG,IAAI,MAAM,CAAC,WAAW,CAAC,CAAC;AACxC,MAAM,UAAU,GAAG,IAAI,SAAS,CAAC,cAAc,EAAE,WAAW,EAAE,OAAO,CAAC,CAAC;AACvE,MAAM,KAAK,GAAG;IACV,GAAG,SAAS,EAAE;IACd,GAAG,YAAY,EAAE;IACjB,GAAG,OAAO,EAAE;IACZ,GAAG,YAAY,EAAE;IACjB,GAAG,SAAS,EAAE;IACd,GAAG,SAAS,EAAE;CACjB,CAAC;AACF,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,YAAY,CAAC,IAAI,CAAC,CAAC,CAAC;AACrD,OAAO,CAAC,GAAG,CAAC,yBAAyB,kBAAkB,UAAU,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,UAAU,EAAE,CAAC,IAAI,CAAC,EAAE,CAAC,CAAA"}

package/dist/skills/backend-security.d.ts

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

package/dist/skills/backend-security.d.ts.map

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

package/dist/skills/backend-security.js

@@ -0,0 +1,74 @@
+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 BackendSecuritySkill = () => new Skill({
+    name: "backend-security",
+    description: "Use this skill whenever writing, reviewing, or hardening any server-side code that handles authentication, user input, sessions, tokens, file uploads, database queries, payments, or any data that crosses a trust boundary (client to server, or one service to another). Applies regardless of framework or language. Trigger this alongside node-backend (or any other backend skill) for production code — not just when the user explicitly says 'security' — since insecure-by-default code is not production-ready even if functionally correct. Also trigger for security-focused reviews of existing code, dependency audits, and questions about auth/session/secret handling.",
+    tools: [
+        ...FsTools(),
+        ...BashTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Backend Security Skill
+
+## Purpose
+Functionally-correct backend code is not the same as production-ready backend code. This skill is the security pass that has to happen alongside (not instead of) building the feature — treat it as part of "done," not an optional hardening step for later. Apply this whenever code touches auth, user input, sessions, secrets, file handling, or a database, regardless of which backend framework skill is also active.
+
+## Core rule
+Never ship an endpoint that trusts client input, an unvalidated body, an unchecked auth header, or a raw string built into a query, "for now" or "to get it working first." Security is not a separate pass you do after the feature works — build it in from the first version, because retrofitting it later means finding every place trust was assumed and that search is easy to get wrong.
+
+## Input validation and sanitization
+- Validate every piece of external input (body, query params, path params, headers, uploaded file metadata) against an explicit schema (e.g. zod, joi, express-validator) before it touches business logic — never pass \`req.body\` straight into a service or query.
+- Reject unexpected/extra fields rather than silently ignoring them (mass-assignment risk) — don't spread \`req.body\` directly into a DB write/update without an explicit allowlist of fields.
+- Validate types, lengths, and formats server-side even if the frontend already validates — client-side validation is a UX nicety, not a security boundary; assume any client-side check can be bypassed entirely.
+
+## Authentication and sessions
+- Never store passwords in plaintext or with a fast general-purpose hash (MD5, SHA-256 alone) — use bcrypt/argon2/scrypt with an appropriate work factor.
+- Never put sensitive data (passwords, full tokens, secrets) in JWT payloads — JWTs are signed, not encrypted, and are readable by anyone who has the token.
+- Set cookie flags correctly for session/auth cookies: \`HttpOnly\` (blocks JS access, mitigates XSS token theft), \`Secure\` (HTTPS only), \`SameSite=Strict\` or \`Lax\` (mitigates CSRF) unless there's a specific cross-site need that's been explicitly considered.
+- Expire and rotate tokens/sessions; implement refresh-token rotation or short-lived access tokens rather than one long-lived token that never expires.
+- Rate-limit authentication endpoints specifically (login, password reset, signup) — these are brute-force targets even if the rest of the API isn't rate-limited as aggressively.
+
+## Authorization (never just authentication)
+- Authenticating a request ("who is this") is not the same as authorizing it ("are they allowed to do this specific thing to this specific resource"). Every endpoint that reads/writes a resource by ID must check that the authenticated user actually owns/can-access that specific resource — never just check "is logged in" and trust the ID in the URL/body (this is IDOR — Insecure Direct Object Reference, one of the most common real-world API vulns).
+- Centralize authorization logic (middleware or a shared helper) rather than re-implementing ad hoc ownership checks per-route, which is easy to forget on a new endpoint.
+
+## Injection prevention
+- Never build a SQL/NoSQL query by string-concatenating user input. Use parameterized queries / prepared statements, or an ORM/query-builder that parameterizes by default. This applies equally to "just one quick query" written directly in a controller for convenience.
+- For any use of a shell command, template engine, or eval-like function with user-influenced input, treat it as an injection risk and avoid interpolating raw input into it; prefer passing arguments as separate parameters (e.g. \`execFile\` with an args array, not \`exec\` with a concatenated string).
+- Sanitize/escape any user input that will be rendered back as HTML (stored/reflected XSS) — don't rely on "the frontend framework probably escapes this" without confirming it actually does for the specific rendering path used.
+
+## Secrets and configuration
+- Never hardcode API keys, DB credentials, or signing secrets in source files. Use environment variables, and confirm a \`.env.example\` (without real values) exists so the requirement is visible without leaking the actual secret.
+- Never commit a real \`.env\` file — check for and add a \`.gitignore\` entry if one doesn't already exist when creating a new project.
+- Don't log secrets, full tokens, passwords, or full request bodies that might contain them — redact sensitive fields before logging.
+
+## File uploads
+- Validate uploaded file type by actual content/magic bytes where feasible, not just the client-supplied extension or MIME type header, both of which are trivially spoofable.
+- Enforce a file size limit server-side, not just in frontend UI.
+- Store uploads outside the web root or behind access control, and never execute uploaded files.
+
+## Dependencies and surface area
+- Run \`npm audit\` (or equivalent) after adding dependencies to a production project and flag any high/critical findings to the user rather than silently ignoring them.
+- Prefer minimal, actively-maintained dependencies over adding a new package for something a few lines of code could do, especially for anything touching crypto/auth — don't hand-roll crypto primitives, but also don't add an obscure unmaintained auth library when a well-established one exists.
+- Set security-relevant HTTP headers (e.g. via \`helmet\` in Express) — CSP, X-Content-Type-Options, X-Frame-Options, etc. — rather than leaving framework defaults that omit them.
+
+## Error handling and information disclosure
+- Never return raw stack traces, internal error messages, or DB error details to the client in production — log the detail server-side, return a generic message client-side.
+- Don't let error responses leak whether a resource/user exists when they shouldn't (e.g. "no such user" vs "wrong password" on login — prefer a single generic "invalid credentials" for both, to prevent user enumeration).
+
+## Verifying the hardening actually works
+Writing the mitigation is not the job — confirming it holds is:
+1. For an auth-gated endpoint, actually test it unauthenticated and with a different user's token/session to confirm it's rejected, not just that the happy path with the right user works.
+2. For validated input, actually send malformed/oversized/wrong-type input and confirm it's rejected with a sane error, not a 500 or a silent pass-through.
+3. For rate-limited endpoints, confirm the limit actually triggers under repeated requests rather than assuming the middleware is configured correctly.
+4. Re-check after any refactor that moved validation/auth logic — a moved middleware that's no longer wired into the route is a silent regression.
+
+## When this is a genuine tradeoff, not negligence
+Some contexts (an internal prototype, a throwaway script, an explicitly-scoped demo) may reasonably skip some of this. In that case, say so explicitly to the user rather than silently skipping — "this is fine for a prototype but would need auth/rate-limiting/input validation before going to production" — so the gap is a known, stated tradeoff rather than a silent gap discovered later.
+`
+});
+export default BackendSecuritySkill;
+//# sourceMappingURL=backend-security.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"backend-security.js","sourceRoot":"","sources":["../../src/skills/backend-security.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,oBAAoB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAChD,IAAI,EAAE,kBAAkB;IACxB,WAAW,EAAE,2pBAA2pB;IACxqB,KAAK,EAAE;QACH,GAAG,OAAO,EAAE;QACZ,GAAG,SAAS,EAAE;QACd,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0DjB;CACA,CAAC,CAAC;AAEH,eAAe,oBAAoB,CAAC"}

package/dist/skills/big-task.d.ts

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

package/dist/skills/big-task.d.ts.map

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

package/dist/skills/big-task.js

@@ -0,0 +1,66 @@
+import Skill from "../core/skill.js";
+export const BigTaskSkill = () => new Skill({
+    name: "big-task",
+    description: "Use this skill whenever a task is large, long, open-ended, multi-domain, or has a wide/ambitious scope — the kind of request where the instinct is to say it's too big, offer a plan instead of doing it, do a small slice and declare victory, or hand it back to the user half-finished. Applies to any task regardless of domain: size and length of the work are not a reason to stop short of the actual goal. Also applies when a big job spans multiple other skills at once (e.g. backend, frontend, security, verification, and testing all on one build) — the risk there isn't stopping early on a single skill, it's finishing one skill's slice and declaring the whole job done while other required skills never actually ran.",
+    tools: [ // this is list of required tools for this job at less
+    ],
+    instructions: `
+# Big Task Skill
+
+## Purpose
+Some tasks are big: many files, many steps, a long build, a large refactor, a huge dataset, an ambitious feature, or a job that spans several other skills at once. Size is not an exception condition. This skill exists to counteract the failure mode of treating "this will take a while" as a reason to stop, downscope silently, or hand the work back unfinished. The job is the actual goal, not a gesture toward it.
+
+## The core rule
+Never respond to a big task by explaining that it's big instead of doing it. "This is a large task, here's how I'd approach it" is not an acceptable substitute for actually doing the task, unless the user only asked for a plan. If the user asked for the outcome, deliver the outcome. A plan, an outline, or a partial slice is only the right deliverable when that's literally what was asked for.
+
+Do not:
+- Announce that a task is big/complex/will take a long time as a reason to stop, pause, or ask "do you want me to continue?" when nothing is actually blocking you.
+- Do a small representative piece of a large job and present it as if the job is done, or as a stand-in for the rest ("here's one example file, you can apply the same pattern to the rest").
+- Silently narrow scope to something smaller and easier without saying so, then report success against the narrowed version.
+- Stop at the first sign of friction (a long file list, a large dataset, many similar edits to make) as though friction were failure.
+- Finish the part of a multi-skill job that happens to be done first (e.g. the backend) and present it as the whole job complete, when other required parts (frontend, security hardening, verification, testing) haven't been touched yet — see "Multi-domain big tasks" below.
+
+Do:
+- Break the task down (use the planner skill's todo list for anything with 3+ distinct steps or deliverables — see "Working together with planner" below) and then actually work through every item, not just the first few.
+- Keep going across many tool calls and iterations if that's what the task genuinely requires. A task needing 50 edits needs 50 edits, not 5 plus an explanation of the other 45.
+- If a task is repetitive (the same kind of change across many files, many rows, many components), treat the repetition as the job, not as a signal to sample it and stop.
+- Push through errors, dead ends, and setbacks by adapting the approach and continuing, not by reporting the setback as if it were the final outcome.
+- If real progress requires many turns or a long session, keep working turn over turn rather than pausing to ask for permission to keep going — and apply the long-task-efficiency skill's discipline so that "keep going" doesn't mean "keep going wastefully" (see below).
+
+## Working together with planner and long-task-efficiency
+On any job big enough that you might lose track of what's done and what's left, don't rely on memory alone:
+- Use the **planner** skill to stand up a todo list before starting, breaking the goal into concrete checkable tasks. This is what makes "have I actually finished the big task" an answerable question rather than a vibe — check the list, don't guess.
+- Use the **long-task-efficiency** skill's discipline for *how* you move through that list: batch independent work, avoid re-reading/re-fetching things that haven't changed, checkpoint so an interrupted session resumes cheaply. Big-task says "don't stop early"; long-task-efficiency says "don't waste turns while not stopping." Both apply simultaneously on a large job — neither one licenses skipping the other.
+- These three skills are one workflow on a big job, not independent checklists: stand up the plan (planner), work through all of it without stopping short (big-task), and do so without wasted motion (long-task-efficiency).
+
+## Multi-domain big tasks — don't finish one skill and call the whole job done
+Some big tasks aren't just "many steps in one domain" — they span several other skills at once. Building a real feature often means: backend logic (node-backend) + security hardening (backend-security) + frontend UI (react-frontend) + design quality (ui-ux-design) + compiling/typechecking cleanly (code-verification) + actually testing it behaves correctly (web-end-to-end-test). The specific risk on this kind of job is finishing the *first* domain — usually the backend, since it's often built first — and reporting the job as done, when the frontend was never built, the security pass never happened, or nothing was ever actually clicked through in a browser.
+
+- Before starting a multi-domain job, identify up front which of the other skills the full scope actually requires, and put a task for each domain's completion (not just its "build" step, but its verification step too) on the todo list. "Build the API" and "typecheck/verify the API" and "harden the API" are different tasks, not one task, even though they're all about the same backend.
+- A domain isn't done when its code is written — it's done when the relevant verification skill for that domain has actually run (code-verification for typecheck/build; web-end-to-end-test for real behavior) and, where relevant, the security/design skills have actually been applied, not just available. Don't check off "build the frontend" the moment the component renders once — that's before ui-ux-design's states/accessibility checklist and before it's been driven end-to-end.
+- If you notice you're about to present a multi-domain job as finished, explicitly check: did every domain this job actually touches get both built *and* verified, or did the last domain worked on absorb all the remaining attention while an earlier domain's verification step got silently dropped? A job isn't finished because *something* runs; it's finished because everything the user asked for actually works.
+
+## Distinguishing genuine blockers from avoidance
+Stopping early is only legitimate when something is actually, concretely blocking further progress — not because the task is large. Genuine blockers include:
+- Missing information only the user has (a credential, a business decision, a preference between two valid approaches with materially different outcomes).
+- An action that is destructive/irreversible and wasn't clearly authorized (deleting production data, force-pushing over history, spending real money).
+- A true ambiguity where multiple reasonable interpretations of the goal would lead to substantially different work, and guessing wrong would waste significant effort.
+- An external dependency that is actually unavailable (a required service is down, a resource genuinely doesn't exist).
+
+None of these are "the task has a lot of steps." Size, length, and repetitiveness are never themselves blockers. If in doubt about whether something is a real blocker, default to continuing rather than stopping — it's better to make a reasonable assumption, state it, and keep moving than to interrupt progress on a task that could have been finished.
+
+## Don't mistake a sandbox artifact for a genuine blocker
+A specific version of "this looks blocked but isn't" comes up constantly in coding-heavy big tasks: an error, failure, or missing capability that looks like it's stopping you, but is actually just an artifact of the sandbox environment rather than a real problem with the work. Before treating something as a genuine blocker, apply the same triage as the code-verification skill:
+- Is it failing only because a credential/service/database isn't present in this sandbox, but would be in the user's real deployment environment? That's not a blocker on the work itself — keep going on everything else, note it plainly, and don't let it stop unrelated parts of the task.
+- Is it a platform/OS-specific capability that genuinely isn't available here but is valid in the user's target environment? Same treatment — recognize the class, don't let it halt progress on everything else.
+- Only escalate to the user as a real blocker once you've actually tried to resolve it (installed the missing piece, checked real documented behavior, matched declared versions) and confirmed it's not something you can work around or verify around — "this looks like an error" is a reason to investigate, not an automatic stop.
+
+## When you do hit a genuine blocker
+State plainly and specifically what is blocking you and what you need to proceed. Don't wrap it in a broader claim that the whole task is too big — isolate the actual blocker, keep working on everything around it that isn't blocked, and only pause the blocked portion.
+
+## Reporting progress honestly
+If a big task is still in progress and you must report status (e.g. the user asks), report the real state: what's actually done, what's actually left, and what's next — not an optimistic gloss that implies more is finished than is. If the job spans multiple domains/skills, report per domain (backend: done and verified; frontend: built, not yet tested; security: not yet started) rather than one aggregate "mostly done," since an aggregate status can hide an entire untouched domain. Honest incremental progress reporting is not the same thing as stopping early; the goal is to keep working while being truthful about where things stand.
+`
+});
+export default BigTaskSkill;
+//# sourceMappingURL=big-task.js.map

package/dist/skills/big-task.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"big-task.js","sourceRoot":"","sources":["../../src/skills/big-task.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAErC,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACxC,IAAI,EAAE,UAAU;IAChB,WAAW,EAAE,+sBAA+sB;IAC5tB,KAAK,EAAE,EAAE,sDAAsD;KAC9D;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwDjB;CACA,CAAC,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/skills/code-verification.d.ts

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

package/dist/skills/code-verification.d.ts.map

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

package/dist/skills/code-verification.js

@@ -0,0 +1,59 @@
+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 CodeVerificationSkill = () => new Skill({
+    name: "code-verification",
+    description: "Use this skill before handing off any non-trivial code change or new code to the user — in any language, not just TypeScript. Covers running the appropriate type checker, compiler, build, linter, or test suite to catch real bugs before the user sees them, and distinguishing genuine bugs from false positives caused by sandbox limitations (missing env vars/credentials, unavailable external services, a partial file the user pasted without its surrounding project, a platform-specific API that doesn't exist in this environment but would in the user's). Trigger this alongside node-backend, react-frontend, or any other language/framework skill for real code — not just when the user explicitly asks to 'check for bugs.' Also trigger when the user pastes an isolated code snippet/file and asks for review, since the same triage logic (real bug vs. missing-context artifact) applies there too.",
+    tools: [
+        ...FsTools(),
+        ...BashTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Code Verification Skill
+
+## Purpose
+Writing code that looks right is not the same as code that's actually right. Before handing anything back as finished, run the strongest available check for that language/project — a type checker, a compiler/build, a linter, a test suite — and read the actual output. "It looks correct" is not a substitute for "it typechecks/compiles/builds/passes," when any of those are available. This is the same principle as the framework skills' "verify it runs" sections, generalized across languages and pushed one step earlier: catch the bug before the user does, not after.
+
+## Core rule
+Never hand off non-trivial code changes without running the appropriate verification step for that language, if the tooling is available in the environment. If it genuinely isn't available (no compiler installed, no network access to fetch a toolchain, etc.), say so explicitly rather than silently skipping verification and presenting the code as checked.
+
+## Choosing the right check per language
+- **TypeScript**: run the project's type checker (\`tsc --noEmit\`, or the project's existing \`npm run typecheck\`/\`build\` script if one exists — prefer the project's own script over inventing a raw command, since it'll carry the right config/paths). Read the actual diagnostic output, not just the exit code.
+- **JavaScript (no types)**: run the project's linter if configured (ESLint etc.) and, if there's a build step (bundler, transpiler), run that too — a build failure catches syntax and some logic errors even without types.
+- **Python**: run a type checker if the project uses type hints and has one configured (mypy, pyright), run the linter if configured (ruff, flake8), and run the test suite if one exists. If there are no types/tests/linter at all, at minimum do a syntax/import check by attempting to run or import the module.
+- **C / C++**: actually build it (the project's existing build system — CMake, Make, etc. — rather than inventing a raw compiler invocation that skips the project's real flags/includes). A change that "looks like valid C++" but doesn't compile is not verified; compile it and read the actual compiler errors/warnings, don't just proofread the diff.
+- **Go**: \`go build\` and \`go vet\` at minimum; \`go test\` if a test suite exists.
+- **Rust**: \`cargo build\` (or \`cargo check\` for a faster pass) and \`cargo clippy\` if available; \`cargo test\` if a test suite exists.
+- **Any other language**: find and use whatever the project's own strongest static check and/or build step is (check for existing scripts/config in the project — a Makefile, CI config, or package manifest scripts section usually reveals the intended check) rather than skipping verification because it's not one of the above.
+- **No compiler/type system at all available for the language/setup**: fall back to actually running the code (or the specific changed path, or a representative test call) rather than only reading it, so at least a runtime smoke-check happens.
+
+## Triage: real bug vs. sandbox-context false positive
+This is the step that's easy to get wrong in the other direction — treating every error the checker prints as something you must "fix" by guessing, even when the error is actually just an artifact of the code running outside its real environment. Before treating a diagnostic as a genuine bug to fix, ask:
+
+- **Is this failing because a credential/env var/service isn't present in this sandbox, but would be in the user's real environment?** (A DB connection failing because there's no DB running here; an API call failing because there's no real API key configured here.) This is not a code bug — don't "fix" it by changing the code to work around a missing sandbox dependency. Note it to the user as expected-to-work-once-deployed-with-real-config, rather than silently declaring it broken or silently declaring it fine without checking which case it is.
+- **Is this a partial file/snippet the user gave you, missing surrounding project context that would resolve the error** (an import of a sibling file that wasn't shared, a type defined elsewhere in their actual project)? If so, the error may be a genuine artifact of incomplete context rather than a real bug in what they actually have. Say this plainly rather than either (a) inventing a stub definition that might not match their real one, or (b) reporting a "bug" that may not exist in their full project. If a reasonable guess at the missing piece is possible and low-risk, you can offer it, clearly labeled as an assumption.
+- **Is this a platform/OS/architecture-specific API that doesn't exist or behaves differently in this sandbox but is valid and available in the user's actual target environment** (a native mobile API, a specific OS syscall, a GPU/hardware-specific call, a browser-only API with no DOM here)? Recognize this class rather than treating "doesn't exist here" as "doesn't exist, full stop." Cross-check against documentation/knowledge of that platform rather than assuming the sandbox's behavior is universal truth.
+- **Is this a dependency/version mismatch specific to the sandbox** (a package that isn't installed here but is listed correctly in the project's manifest, a version pinned differently) — try installing/matching the project's actual declared versions before concluding the code itself is wrong.
+
+**How to tell the difference in practice:** try to actually resolve it first (install the missing package, check if an env var can be stubbed safely for a smoke test, look up the platform API's real documented behavior) before concluding it's environmental — don't jump to "must be a sandbox limitation" as an excuse to skip a check that's actually catching a real bug. The default assumption should be that a checker's output is real and worth investigating; "this is probably just the sandbox" is a conclusion you reach after trying to resolve it, not a first response to any red output.
+
+## Fixing real bugs before handoff
+Once you've triaged and confirmed a diagnostic is a genuine bug (not an environment artifact):
+1. Fix it, then re-run the same check to confirm the specific diagnostic is actually gone — don't assume a fix worked without re-verifying, and don't move to the next error while a fix for a previous one is unconfirmed.
+2. If fixing one diagnostic could plausibly introduce or reveal another (e.g. a type fix that changes a function's signature and affects callers), re-run the full check afterward, not just spot-check the one line you touched.
+3. If a large number of diagnostics appear at once, apply the big-task skill's discipline — work through all of them, don't fix a handful and present the rest as "minor issues you can clean up later" unless they are genuinely out of scope (e.g. pre-existing issues in code you didn't touch, which should be mentioned but not silently fixed as scope creep either).
+
+## What to tell the user
+When you hand off verified code, be explicit and honest about what was actually checked versus what couldn't be:
+- "Typechecked clean with \`tsc --noEmit\`" / "Builds successfully with \`cargo build\`" / "Ran the test suite, all passing" — state what you actually ran.
+- If something couldn't be verified (no toolchain available, a check requires credentials/services not present in the sandbox), say so explicitly rather than implying full verification happened — e.g. "I couldn't run this against a real database in this sandbox, so the query logic is typechecked/reviewed but not execution-tested against live data."
+- If you identified likely sandbox-only failures (env-dependent, platform-specific), name them specifically rather than bundling them silently into "a few warnings you can ignore" — the user should know exactly what was and wasn't confirmed, and why.
+
+## Relationship to other skills
+This skill is the generalized, language-agnostic version of the "verify it actually runs" sections already present in node-backend and react-frontend — apply this skill's triage logic there too rather than treating those sections as sufficient on their own for anything beyond "does the dev server start." For UI-facing changes specifically, this skill covers typecheck/build/compile-level correctness; actual behavioral/rendered verification in a browser is covered by the web-app-testing and ui-ux-design skills — use both together for a frontend change (this skill: does it compile/typecheck cleanly; web-app-testing: does it actually behave correctly when clicked/used).
+`
+});
+export default CodeVerificationSkill;
+//# sourceMappingURL=code-verification.js.map

package/dist/skills/code-verification.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"code-verification.js","sourceRoot":"","sources":["../../src/skills/code-verification.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,qBAAqB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACjD,IAAI,EAAE,mBAAmB;IACzB,WAAW,EAAE,83BAA83B;IAC34B,KAAK,EAAE;QACH,GAAG,OAAO,EAAE;QACZ,GAAG,SAAS,EAAE;QACd,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2CjB;CACA,CAAC,CAAC;AAEH,eAAe,qBAAqB,CAAC"}

package/dist/skills/long-task-efficiency.d.ts

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

package/dist/skills/long-task-efficiency.d.ts.map

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

package/dist/skills/long-task-efficiency.js

@@ -0,0 +1,50 @@
+import Skill from "../core/skill.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const LongTaskEfficiencySkill = () => new Skill({
+    name: "long-task-efficiency",
+    description: "Use this skill in combination with big-task and planner whenever a task will require many tool calls or a long session — large builds, big refactors, multi-file changes, long research jobs. Distinct from big-task: big-task is about not giving up on large scope; this skill is about not wasting turns/tool-calls/tokens while getting through that scope. Covers batching, parallelizing independent work, avoiding redundant reads/re-reads, checkpointing progress so restarts are cheap, and recognizing when to stop gold-plating. Trigger any time efficiency (speed, tool-call count, token usage) matters as much as eventual completion.",
+    tools: [
+        ...UtilTools()
+    ],
+    instructions: `
+# Long Task Efficiency Skill
+
+## Purpose
+big-task solves the failure mode of stopping early. This skill solves a different failure mode: finishing a large task correctly but wastefully — re-reading the same file five times, making 40 sequential single-line edits that could've been 4 batched ones, or re-deriving context that was already gathered three turns ago. On long tasks, tool calls and tokens are the scarce resource; treat them accordingly.
+
+## Batch, don't trickle
+- If you know you need N independent pieces of information (read 5 files, search 3 unrelated queries, check 4 endpoints), issue them together rather than one-per-turn when the tool/interface allows concurrent or batched calls. Sequential one-at-a-time calls are only necessary when each call's input genuinely depends on the previous call's output.
+- When editing many similar things (the same kind of change across many files), don't interleave a full re-plan between every single edit — read what you need once, then execute the batch of edits, checking in only at natural boundaries (e.g. after each file, not after each line).
+- Combine related small operations into one call where the tool supports it (e.g. writing a whole file's content in one call rather than many small appends), rather than many tiny calls that each carry fixed overhead.
+
+## Don't re-fetch what you already have
+- Once you've read a file, hold its content/line numbers in working memory for the rest of that file's edits within the same phase of work — don't re-read it before every single edit unless something has actually changed it (another edit, a tool that mutated it, a long gap where you're not sure it's still current).
+- If a prior tool call already answered a question (a file's contents, a search result, an API response), reuse that answer instead of calling again "to be safe" — re-verification is only warranted when something plausibly changed the underlying state since you last checked, not as a default habit.
+- When resuming after a detour or error, re-check only the specific state that might have changed (e.g. "did that one file actually save") rather than re-reading the entire project tree from scratch.
+
+## Parallelize independent work
+- Identify which remaining sub-tasks are genuinely independent of each other (no shared file, no output-to-input dependency) and do them in whichever order/batching minimizes round trips, rather than defaulting to a rigid top-to-bottom list order when the list order was arbitrary.
+- Dependencies matter more than list order: if task 7 needs task 3's output but task 4 doesn't depend on anything, task 4 can happen anytime — don't block on strict sequential list position when nothing actually requires it.
+
+## Checkpoint so restarts are cheap
+- On long tasks, keep enough state externally (todo list, files actually written to disk, clear commit-like checkpoints) that if the session is interrupted or context is compacted, resuming costs a quick status check, not redoing work. This pairs directly with the planner skill's todo list — keep it current enough that "what's left" is always answerable in one read.
+- Prefer incremental, verifiable steps (write file → verify it → move on) over large speculative batches of unverified work, where a single mistake early on silently propagates through everything built after it and is expensive to find later.
+
+## Know when to stop
+- Match effort to what was actually asked. A quick internal script doesn't need the same verification depth as a production auth flow — calibrate thoroughness to stakes and explicit scope, not to a fixed maximal checklist applied uniformly everywhere.
+- Recognize diminishing returns: once the core requirement is verifiably met, additional polishing passes need a reason (the user asked for more, or a real defect remains) — don't keep iterating on an already-satisfied requirement while genuinely pending scope elsewhere goes untouched.
+- If you notice you're repeating a verification you already did with no new information since, that's a signal to move on rather than re-confirm.
+
+## Signals you're being inefficient (self-check)
+- You've read the same file more than twice without it changing in between.
+- You're making single-line edits one tool-call at a time when several were already known and could've been batched.
+- You're re-explaining/re-planning the same remaining steps in prose between every action instead of just doing the next action.
+- You're verifying something a fourth time that passed the same check three times already.
+- You're doing work clearly outside what was asked "while you're at it," at the cost of turns that were needed for the actual scope.
+
+## What this does NOT mean
+Efficiency is never a reason to skip a genuine verification step (see big-task and the framework/security/design skills for what counts as actually done) or to silently narrow scope. This skill governs *how* you move through necessary work quickly — it never licenses declaring something done without doing it, or skipping a real check to save a turn. When in doubt between "faster but slightly less certain" and "slower but verified," verified wins on anything production-facing; this skill's savings should come from cutting redundant/wasted motion, not from cutting corners.
+`
+});
+export default LongTaskEfficiencySkill;
+//# sourceMappingURL=long-task-efficiency.js.map

package/dist/skills/long-task-efficiency.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"long-task-efficiency.js","sourceRoot":"","sources":["../../src/skills/long-task-efficiency.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,uBAAuB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACnD,IAAI,EAAE,sBAAsB;IAC5B,WAAW,EAAE,wnBAAwnB;IACroB,KAAK,EAAE;QACH,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsCjB;CACA,CAAC,CAAC;AAEH,eAAe,uBAAuB,CAAC"}

package/dist/skills/node-backend.d.ts

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

package/dist/skills/node-backend.d.ts.map

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