Sdd Dev Workflow

What to consider before installing/using this skill: - Metadata mismatch: The skill's SKILL.md says ZHIPU_API_KEY is required (and mentions ANTHROPIC_API_KEY, GITHUB_TOKEN) but the registry metadata did not declare required credentials. Treat any request for LLM API keys as sensitive — confirm why each key is needed before providing it. - Review scripts before running: The package includes multiple bash scripts (init, driver, monitor, auto-installer) that will create projects, start tmux sessions, run Claude Code, auto-install packages (pip/apt/npm), and read/modify local OpenClaw and Claude configuration files. Inspect sdd-driver.sh, claude-code-helper.sh, init-project.sh, and monitor-task.sh line-by-line to ensure behavior is acceptable. - Gateway/agent config edits are sensitive: The docs instruct editing ~/.openclaw/openclaw.json or calling gateway config.patch to allow subagents. That changes system agent permissions and should only be done in a controlled environment after understanding the consequences. - Automatic installs and 'bypass' modes: The workflow recommends automated pip/apt/npm installs without prompting and suggests permission modes like bypassPermissions. Do NOT run these on production hosts. Use an isolated VM/container sandbox for initial testing. - Least privilege: Provide only the credentials absolutely required and prefer read-only or limited-scope tokens (e.g., a repository-limited GitHub token) when possible. Consider creating dedicated, revocable API keys for testing. - If you plan to use autonomous sessions: expect persistent session artifacts under ~/.openclaw and possibly saved session logs; the skill encourages keeping sessions (cleanup: keep). Decide retention and access policies first. - What would change this assessment: If the registry metadata were corrected to explicitly declare required env vars and the SKILL.md removed or constrained instructions that modify gateway config or use bypassPermissions, the skill would be more coherent. Also providing transparency about exactly what sdd-driver.sh does (a complete script audit) would reduce risk. Practical next steps: audit the included scripts locally (don't run them yet), test in an isolated VM/container, and only then run check-environment and init scripts after confirming they won't change gateway config or auto-install unreviewed code.