메뉴
Phase 0 of Leopold. One-shot setup that makes a project extract the most from Claude Code: generates CLAUDE.md (/init), teaches Claude how to build/run the app (/run-skill-generator), verifies MCP + permissions, then hands off to /leopold-brief. Run this once per project.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Phase 1 of Leopold. A structured debate that captures the mission and your decision-making, then writes the brief (MISSION, CHARTER, GUARDRAILS, PLAN) that the autonomous run executes.
Launch a local live web dashboard to watch the current project's Leopold run — status, cost meters (context/subagents/forks), event feed, decisions, and a Stop button. Local-only (127.0.0.1), zero dependencies.
Compile a Leopold brief into a dynamic workflow and run it. The plan lives in code instead of one growing context window, every item gets an independent adversarial review, and git stays locked — nothing is committed. The workflow is resumable and shows up in /workflows.
Control plane for the global prompt enhancer: status, on/off, preview a prompt against the gate, and the learn loop that mines your enhancement ledger into proposed prompt-profile rules. Never edits PROMPT-PROFILE.md itself — you review and apply.
The self-improving charter. Mines past Leopold decisions, session corrections, and git history for recurring judgment calls, skeptic-verifies each candidate, and proposes charter amendments. Never edits CHARTER.md itself — you review and apply.
Phase 2 of Leopold. Enters autonomous mode and conducts Claude Code through the plan, deciding from the charter instead of asking, with git locked. The Stop hook keeps it going until the plan is done or a stop condition fires.
| name | leopold-up |
| version | 0.1.0 |
| description | Phase 0 of Leopold. One-shot setup that makes a project extract the most from Claude Code: generates CLAUDE.md (/init), teaches Claude how to build/run the app (/run-skill-generator), verifies MCP + permissions, then hands off to /leopold-brief. Run this once per project. |
| allowed-tools | ["Read","Write","Edit","Bash","Glob","Grep","Skill","AskUserQuestion"] |
| triggers | ["leopold up","set up leopold","leopold setup","bootstrap leopold"] |
You are running Phase 0 of Leopold: the one-command onboarding. Most people use a fraction of what Claude Code offers — no project memory, no run-skill, a permission flood, MCP unconfigured. Your job is to fix all of that in one pass so the autonomous run (and the human's normal sessions) start from the strongest possible footing.
Work top to bottom. Skip a step only if it is already done; say so and move on. Do not ask the user to do anything you can do yourself.
If there is no CLAUDE.md (or .claude/CLAUDE.md) at the project root, run the native
/init skill to generate one (it documents the build, test, and architecture so every
future session starts informed). If one already exists, read it and offer to enrich any
obvious gaps (test command, conventions, key directories) — don't rewrite what's there.
Run /run-skill-generator so Claude learns how to build, start, and drive this
project's app from a clean environment (build command, env vars, ports). This is what makes
the run-time review gate real: with a run-skill present, the autonomous run can /verify a
change by actually exercising the app, not just passing tests. If the project is a pure
library/CLI with nothing to "run", note that and skip.
If leopold up was run from the CLI it already seeded a per-project allowlist. Confirm
.claude/settings.json has a sensible permissions.allow for routine dev (read/grep, the
build/test/lint commands, read-only git, git add). If it's missing or thin, add it with the
update-config skill (or edit .claude/settings.json directly). The Leopold guard still
locks git commit/push during a run regardless, so a generous allowlist is safe.
Check which power tools are connected and offer the ones that aren't:
List what /mcp shows and what leopold-driver doctor reports; install missing ones via
leopold-driver serena|ovmem|gstack install (ask first — these touch the home dir / network).
Suggest setting a sensible default reasoning effort for the project via /effort (e.g.
medium for app work, high for a security/billing-heavy codebase). Per-item effort is set
automatically during a run, but the human's own sessions benefit from a good default.
Finish with a short summary of what you set up and what was already in place, then point the user at the next step:
Setup done. Run /leopold-brief to debate the mission and write the brief, then /leopold-run to hand Leopold the seat (autonomous, reviewed, git-locked). Use
leopold-driver run --parallel 3for independent plan items, andleopold-driver insightsto see where a run spent its effort.
Do not start a brief or a run yourself — Phase 0 ends at the hand-off.
