spec驱动开发vibe coding skill

在克隆的 Git 仓库中驱动完整的规格驱动开发生命周期（init→requirements→architecture→process_design→project_plan→coding→test→bugfix→code_review→release）。阶段门控、产物强制输出、多语言支持，内置 commit me...

This skill largely does what it says — orchestrates a spec-driven lifecycle inside a cloned Git repo — and requiring git plus a Git token is expected. However, there are three things to watch before installing or running it: 1) Token handling: The skill requires SPEC_DEV_GIT_TOKEN and claims it will not be written to artifacts/logs, yet its described flow constructs authenticated HTTPS URLs and uses the git credential helper (mentions ~/.git-credentials) and may push tags upstream. These steps commonly write tokens to disk or leave them in git metadata. Only supply a token with the minimum rights needed (preferably a token limited to the target repo and only to the required scopes). Consider using a short-lived token and be prepared to revoke it after use. 2) Undeclared environment variables & session capture: The SKILL.md reads OPENCODE_SESSION_ID, CLAUDE_SESSION_ID, and AGENT_SESSION_ID (not declared in requires.env). If your environment populates these, they may be written into checkpoint metadata. Verify whether you want these session IDs captured and stored in repo files. 3) Dynamic instruction loading & prompt-injection artifacts: The orchestrator will read auxiliary/skills/available_skills.xml and load SKILL.md files from the repository on-demand. That means repo contents can change the skill's behavior at runtime. Also, the pre-scan found unicode control characters — review the SKILL.md and any auxiliary SKILL.md files in the repo for obfuscated or malicious instructions before running. Practical mitigations: - Run the skill in a sandboxed environment or throwaway runner with access only to the intended repo. Do not run it with broad filesystem or network privileges. - Provide a least-privilege PAT scoped to only the target repo and the minimal push/tag scopes; prefer short-lived tokens and rotate/revoke after use. - Inspect and (if possible) lock the auxiliary/skills/* files in the repo so their contents are reviewed and trusted before allowing the orchestration to load them. - Check ~/.git-credentials and git remote URLs after first run; prefer credential helpers that avoid persistent plaintext storage (credential cache or OS native helpers) or adjust the workflow to avoid writing token into files. - If you require stronger assurance, request a code-based implementation (not instruction-only) so you can review exact commands executed, or run the skill step-by-step with manual confirmation for commits/pushes. If you want, I can: (a) list the exact places the SKILL.md writes or could write secrets, (b) suggest a minimal PAT scope to use safely, or (c) point out exact lines in the SKILL.md that should be changed to avoid writing tokens to disk.

Type: OpenClaw Skill Name: spec-driven-dev Version: 1.0.1 The skill bundle implements a complex Git-driven development workflow that requires a sensitive 'SPEC_DEV_GIT_TOKEN'. While its behavior is aligned with the stated purpose, it performs high-risk actions such as persisting credentials to '~/.git-credentials' and executing shell commands (clone, push, reset) constructed from user-provided variables like 'git_remote' and 'us_id' (found in SKILL.md and spec-driven-checkpoint/SKILL.md). Although the instructions include 'Forbidden Behaviors' to prevent token leakage in logs, the reliance on string manipulation for shell execution and the handling of authentication tokens create a significant security risk if inputs are not perfectly sanitized by the agent.