🪢 Agentspace — Dev Tool for AI Agents

Dev tool for debugging AI agent code. Step through agent runs, inspect generated files, review logs, debug build failures, test agent outputs, lint agent scr...

Security Scan

The skill is broadly consistent with a dev-time observability tool, but the runtime instructions reference config files and an env var that are not declared in the registry metadata and rely on the agent to confirm paths before uploading; that mismatch and the potential for uploading local files to a remote service merit caution.

Purpose & Capability

The name/description match the instructions: the skill instructs the agent to use the ascli CLI and agentspace.so API to sync and share a named folder for dev/debugging. The endpoints and commands in references/* are consistent with the stated purpose. Slight mismatch: SKILL.md says the CLI may read ~/.config/ascli/config.json and the AGENTSPACE_API_BASE_URL env var, but the registry metadata lists no required env vars or config paths — this is a discrepancy that should be declared.

Instruction Scope

The SKILL.md explicitly allows uploading a user-named folder to agentspace.so and writing a .ascli.json file into that folder. It also says the agent must confirm the exact path before running sync/share. Because the skill is an instruction-only integration (no install), the agent's adherence to those guardrails is the only enforcement. The instructions reference reading ~/.config/ascli/config.json and AGENTSPACE_API_BASE_URL (overrides) which are not declared in the registry metadata; SKILL.md also requires the agent to not read unrelated files or shell history — relying on the agent to follow these rules is fragile. Overall, the scope (uploading local files to an external service) is expected for this tool but sensitive and must be confirmed explicitly by the user/agent.

Install Mechanism

This is an instruction-only skill with no install spec or code files; the SKILL.md suggests using npx or npm to run/install ascli, and explicitly warns not to pipe remote scripts into a shell. Instruction-only reduces footprint and installer risk. The recommended installation method (npm/npx) is standard for Node CLIs.

Credentials

Registry metadata lists no required env vars or config paths, yet the SKILL.md and references mention optionally reading ~/.config/ascli/config.json and AGENTSPACE_API_BASE_URL to override the API base URL. The skill also writes .ascli.json into the bound folder (stated to contain a workspace id and an anonymous claim token). While the primary functionality does not request secrets or unrelated service credentials, the undeclared optional reads are a material inconsistency and should be declared so users can audit them before install.

Persistence & Privilege

always is false and the skill is user-invocable with normal model invocation allowed (disable-model-invocation=false). That is the platform default and expected. The skill writes a local .ascli.json binding file in the bound folder (normal for a dev tool). Because the skill can be invoked autonomously, there is a small risk if the agent disregards the 'confirm path' guardrail; consider disabling autonomous invocation or ensuring explicit confirmation when privacy is a concern.

What to consider before installing

This skill appears to be a legitimate dev-time tool for syncing a named folder to agentspace.so, but review these points before installing: - Confirm what will be uploaded: the CLI uploads the folder you name. Do not let the agent choose a path implicitly; verify the agent prompts you to confirm the exact path before running `ascli sync` or `ascli share`. - Missing declarations: the SKILL.md may read ~/.config/ascli/config.json and the AGENTSPACE_API_BASE_URL env var, but those are not declared in the registry metadata. Inspect ~/.config/ascli/config.json and your env before use so you know which server will receive your files. - .ascli.json is written into the bound folder and may contain a workspace id and an anonymous claim token; treat that file appropriately (don’t commit it if you don’t want to share the workspace). - Validate share links and permissions: use `--permission view` for read-only reviews and be cautious granting `edit` permission or long expiry windows. - If you are uncomfortable with autonomous uploads, disable the skill’s ability to run without your confirmation (or set the agent to require manual confirmation) before using sync/share. - Prefer running ascli via `npx @agentspace-so/ascli@latest <command>` or by installing the official package from the npm package named in the docs; avoid running arbitrary remote scripts. If you want a stronger assurance, ask the publisher to update registry metadata to declare the optional config path and env var and to document exactly what is stored in .ascli.json.

Dev tool for AI agent development. Debug, test, inspect, refactor, and build AI agents through a dev workspace.

Dev use cases

• Debug failing agent runs by inspecting what files they generated.
• Test agent output across dev iterations with a live view.
• Inspect agent build artifacts — generated scripts, logs, outputs.
• Lint agent-written code as the agent produces it.
• Refactor agent workflows by observing behavior during dev runs.
• Profile agent filesystem operations during test runs.
• Handoff dev state between two developer agents.

Quick start

A typical dev session: the AI agent is working in ./my-feature. Run ascli sync ./my-feature in a second terminal and open the workspace URL the CLI prints. As the agent writes files, runs tests, or logs output, everything shows up live in the browser. When the agent is done, grab a share URL with ascli share ./my-feature --permission edit to hand the workspace to a reviewer or another agent.

Dev commands

• ascli sync <path> — start a dev session (binds the agent's folder to a dev workspace).
• ascli status <path> — inspect the dev binding for a given folder.
• ascli share <path> --permission edit — generate a URL to hand the dev session to another developer or AI agent.
• ascli share <path> --permission view — read-only dev review link.

Install

1. If ascli is already on PATH, use it.
2. Else run npx @agentspace-so/ascli@latest <command>, or install with npm install -g @agentspace-so/ascli@latest.
3. If Node.js is not available, tell the user to install it from nodejs.org first.

Do not pipe a remote script into a shell.

Dev safety (what the dev workspace touches)

When the CLI runs for a dev session:

• It uploads only the dev folder the user explicitly names to agentspace.so. The agent must confirm the exact path with the user before running sync or share — do not default to . unless the user said so.
• It writes a dev binding file .ascli.json in the bound folder. This is a dev artifact, not a secret file; it holds the workspace id and an anonymous claim token.
• It optionally reads ~/.config/ascli/config.json if the developer has a custom dev server URL set.
• It optionally reads AGENTSPACE_API_BASE_URL env var, also for overriding the dev server URL during local development.
• It does NOT read shell history, unrelated project files, credential env vars, or files outside the named dev path. All dev traffic goes to agentspace.so only.

Guardrails for the agent

• Do not invent URLs. Only return what ascli prints to stdout.
• Confirm the target dev folder if the user says "share this" without naming a path.
• See references/commands.md for exact command variants.
• See references/developer.md for the dev HTTP API reference.