菜单
Understand the pre-initialized Daytona volume filesystem. Use when operating inside a sandbox to know what directories exist, where to store state, how the memory DB works, and what guarantees hold across sessions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | volume-bootstrap |
| description | Understand the pre-initialized Daytona volume filesystem. Use when operating inside a sandbox to know what directories exist, where to store state, how the memory DB works, and what guarantees hold across sessions. |
When you land inside a Daytona sandbox with a volume attached, the filesystem is already initialized. This skill explains what's there and how to use it.
When volume_name is set on the interpreter, the runtime automatically runs:
ensure_daytona_volume_layout() — creates all canonical directoriesinit_memory_db() — bootstraps SQLite schema at memories/core.dbseed_system_skills() — populates skills/system/ with bundled fleet-rlm skillsYou do NOT need to mkdir any standard directories. They exist.
MEMORY_ROOT/ ← /home/daytona/memory/
├── memories/
│ └── core.db ← SQLite persistent memory (auto-created)
├── knowledge/
│ ├── ingested/ ← Raw ingested files
│ └── summaries/ ← Generated summaries
├── skills/
│ ├── system/ ← Auto-seeded from fleet-rlm package
│ └── user/ ← User-added custom skills
├── sessions/<session_id>/
│ └── conversation.json ← Durable session manifest
├── logs/ ← Runtime logs
├── uploads/ ← Pre-ingestion file staging
├── memory/ ← (durable) key-value items
├── artifacts/ ← (durable) produced outputs
├── buffers/ ← (durable) named buffer lists
└── meta/ ← (durable) workspace metadata
MEMORY_ROOT is injected as a global in sandbox code. Use it instead of hardcoding paths.
# Write a fact (root agent only — depth-gated)
remember("project_language", "Python 3.12")
# Search memory (any agent depth can read)
results = recall("language")
# Returns up to 50 matches from core.db
# Accumulate items across execute() calls
add_buffer("findings", "First observation")
add_buffer("findings", "Second observation")
# Retrieve later in same session
items = get_buffer("findings") # ["First observation", "Second observation"]
# Load ingested document
content = load_document("knowledge/ingested/report.pdf")
# Search knowledge base
results = search_knowledge("deployment architecture")
# Load a bundled skill
skill_text = load_skill("rlm")
import json
from pathlib import Path
out = Path(MEMORY_ROOT) / "artifacts" / "analysis.json"
out.write_text(json.dumps({"status": "complete", "findings": [...]}))
| What | Persists across sessions? |
|---|---|
Everything under MEMORY_ROOT/ | Yes (same volume_name) |
memories/core.db entries | Yes |
Files in knowledge/, artifacts/, logs/ | Yes |
Session manifests in sessions/ | Yes |
| Workspace files (cloned repos, temp code) | No — transient |
Buffer contents (add_buffer) | No — session-scoped |
| Python variables and interpreter state | No — per-execute |
| Data type | Write to | Read back via |
|---|---|---|
| Factual memory | remember(key, value) | recall(query) |
| Generated artifacts | MEMORY_ROOT/artifacts/<name> | direct file read |
| Ingested documents | MEMORY_ROOT/knowledge/ingested/<name> | load_document(path) |
| Temporary staging | MEMORY_ROOT/uploads/ | process then move to knowledge/ |
| Structured logs | MEMORY_ROOT/logs/<name>.jsonl | direct file read |
| Session scratchpad | MEMORY_ROOT/sessions/<id>/scratch.json | direct file read |
VFS_CANONICAL_ROOTS.., %2e%2e, %2f, %5c) is rejected| Operation | Root agent (depth=0) | Child agent (depth>0) |
|---|---|---|
remember(key, value) | Allowed | Blocked (read-only) |
recall(query) | Allowed | Allowed |
| Direct file write to volume | Allowed | Allowed (if context isolation mode shares volume) |
add_buffer / get_buffer | Allowed | Allowed (own session scope) |
Delegate recursive work to child RLM sandboxes with budget management. Use when decomposing tasks into sub-queries, fanning out batched work, managing LLM call budgets, or building parent-child RLM hierarchies.
Diagnose fleet-rlm runtime failures, API contract drift, sandbox errors, and observability issues. Use when something is broken — Daytona connection failures, websocket mismatches, escalation not triggering, budget exhaustion, or missing traces.
Optimize fleet-rlm DSPy programs and RLM skill bundles using GEPA with MLflow tracking. Use when running optimization loops, designing feedback metrics, building training datasets, or comparing runs.
Hub skill for fleet-rlm: when to use dspy.RLM vs ReAct/CodeAct and which workflow skill to load next.
Design DSPy signatures and compose runtime modules for fleet-rlm tasks. Use when creating input/output field definitions, choosing between built-in signatures, selecting execution modes, or wiring custom modules.
Fetch and inspect JavaScript-heavy pages with Playwright in a Daytona browser-capable snapshot.