ワンクリックで
verify-project-setup
Check the host's runtime versions, required files, and recommended configs against what the project expects.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Check the host's runtime versions, required files, and recommended configs against what the project expects.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
How to build a NEW tool of your own by writing its code in your sandbox, testing it, and forging it into a live, callable tool with `env(action="forge_tool")`. Use when no existing tool does what you need and you can implement it as a small script. Multiple tools + skills can be saved together as one reusable Sandbox Tool Pack.
How to inspect and edit your OWN operating environment at runtime — system prompt, active tools, and skills — using the `env` tool. Use when you need to change your own capabilities (turn a tool on/off, rewrite your instructions, author a new skill) or save them for this session.
Run the same task on a recurring cron schedule. Parses interval syntax (5m, 2h, 1d, "*/15 * * * *"), records the schedule, and acknowledges back to the user.
Review code in the current working tree across three independent dimensions (reuse, quality, efficiency) and synthesise a small punch-list of high-value cleanups.
Interview the user about a workflow they keep repeating, then generate a reusable SKILL.md and write it to disk so the next session starts with the skill already loaded.
Apply the same prompt or operation to a list of items in turn, collecting results. Useful for "do X to each of these files / PRs / records" tasks.
| name | Verify Project Setup |
| description | Check the host's runtime versions, required files, and recommended configs against what the project expects. |
| category | diagnostic |
| effort | medium |
| when_to_use | When the user is debugging an environment problem ("why doesn't this work on my machine?"), onboarding to a project, or validating CI parity. Run this *before* any nontrivial install / setup advice — it captures ground truth. |
| allowed_tools | ["Read","Glob"] |
| shell | bash |
| shell_timeout_s | 15 |
| version | 1.0.0 |
The output below is captured at skill execution time. Read it, note any mismatches, then explain to the user what's healthy, what's suspicious, and what to fix next. Do not re-run these commands yourself — the data is already here.
uname -suname -runame -mecho "$SHELL"pwdfor cmd in node npm pnpm bun yarn python python3 pip uv ruff git gh docker make; do
if command -v "$cmd" >/dev/null 2>&1; then
ver="$("$cmd" --version 2>&1 | head -n 1)"
printf " %-8s %s\n" "$cmd" "$ver"
fi
done
[ -f package.json ] && echo present || echo absent[ -f pyproject.toml ] && echo present || echo absent[ -f requirements.txt ] && echo present || echo absent[ -f Dockerfile ] && echo present || echo absent[ -f .env.example ] && echo present || echo absent[ -f README.md ] && echo present || echo absent[ -f LICENSE ] && echo present || echo absentgit rev-parse --show-toplevel 2>/dev/null || echo "(not a git repo)"git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "(not a git repo)"git rev-parse --short HEAD 2>/dev/null || echo "(not a git repo)"git diff --quiet 2>/dev/null && git diff --cached --quiet 2>/dev/null && echo clean || echo dirtycommand -v fnm >/dev/null && echo "fnm" || (command -v nvm >/dev/null && echo "nvm" || echo "(none detected)")command -v python || command -v python3 || echo "(none)"echo "${VIRTUAL_ENV:-(none)}"Scan the captured output above. Report findings as:
Keep the report scannable. Use bullets, not paragraphs.