@hopla/claude-setup 1.14.0 → 1.14.1

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "hopla",
       "description": "Agentic coding system: PIV loop, TDD, debugging, brainstorming, subagent execution, and team workflows",
-      "version": "1.14.0",
+      "version": "1.14.1",
       "source": "./",
       "author": {
         "name": "Hopla Tools",

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "hopla",
   "description": "Agentic coding system for Claude Code: PIV loop (Plan → Implement → Validate), TDD, debugging, brainstorming, subagent execution, and team workflows",
-  "version": "1.14.0",
+  "version": "1.14.1",
   "author": {
     "name": "Hopla Tools",
     "email": "julio@hopla.tools"

package/README.md

@@ -168,7 +168,7 @@ Plan → Implement → Validate → (repeat)
 
 ### System Evolution
 
-After each PIV loop, run `/hopla:execution-report` + `/hopla:system-review` to find process improvements. Don't just fix bugs — fix the system that allowed them.
+After each PIV loop, run the `execution-report` skill + `/hopla:system-review` to find process improvements. Don't just fix bugs — fix the system that allowed them.
 
 ---
 

package/cli.js

@@ -50,14 +50,31 @@ function safeRm(target, opts = {}) {
     fs.rmSync(target, opts);
 }
 
+// Atomic write: stage to a tmp file and rename over the target.
+// Protects ~/.claude/settings.json from corruption if the process crashes mid-write.
 function safeWrite(target, content) {
     if (DRY_RUN) return;
-    fs.writeFileSync(target, content);
+    const tmp = `${target}.tmp.${process.pid}.${Date.now()}`;
+    try {
+        fs.writeFileSync(tmp, content);
+        fs.renameSync(tmp, target);
+    } catch (err) {
+        try { fs.rmSync(tmp, { force: true }); } catch { /* ignore */ }
+        throw err;
+    }
 }
 
+// Atomic copy: copy to a tmp path and rename over the destination.
 function safeCopy(src, dest) {
     if (DRY_RUN) return;
-    fs.copyFileSync(src, dest);
+    const tmp = `${dest}.tmp.${process.pid}.${Date.now()}`;
+    try {
+        fs.copyFileSync(src, tmp);
+        fs.renameSync(tmp, dest);
+    } catch (err) {
+        try { fs.rmSync(tmp, { force: true }); } catch { /* ignore */ }
+        throw err;
+    }
 }
 
 function safeMkdir(dir, opts) {

package/commands/code-review-fix.md

@@ -58,4 +58,4 @@ Provide a summary of:
 ## Next Step
 
 After all fixes pass validation, suggest:
-> "All review issues fixed and validation passed. Run `/hopla-execution-report` to document the implementation, then `/hopla-git-commit` to commit."
+> "All review issues fixed and validation passed. Run the `execution-report` skill to document the implementation, then the `git` skill (say "commit") to commit."

package/commands/create-prd.md

@@ -222,4 +222,4 @@ Do not ask clarifying questions about changes — just apply them and confirm wh
 1. Rename `PRD.draft.md` → `PRD.md` (overwrite if it existed)
 2. Rename any `.draft` context documents to their final names
 3. Delete all `.draft` files
-4. Confirm: "✅ `PRD.md` saved. Run `/hopla-git-commit` to save it to the repository."
+4. Confirm: "✅ `PRD.md` saved. Run the `git` skill (say "commit") to save it to the repository."

package/commands/execute.md

@@ -166,7 +166,7 @@ Run integration tests or manual verification as specified in the plan (e.g. `npm
 Verify the feature works end-to-end.
 
 ### Level 5 — Code Review
-Run a code review on all changed files following the `/hopla-code-review` process. This catches bugs that linting, types, and tests miss (security issues, logic errors, pattern violations).
+Run a code review on all changed files following the the `code-review` skill process. This catches bugs that linting, types, and tests miss (security issues, logic errors, pattern violations).
 
 If the review finds critical or high severity issues, **fix them before proceeding**.
 
@@ -220,7 +220,7 @@ Provide a summary of what was done:
 ## Step 7: Suggest Next Steps
 
 After the summary, suggest:
-1. Run `/hopla-code-review` for a standalone review of the changes (recommended — a fresh review catches issues the executing agent may have missed)
-2. If issues are found, run `/hopla-code-review-fix` to fix them
-3. Run `/hopla-execution-report` to document the implementation
-4. Run `/hopla-git-commit` to commit the changes
+1. Run the `code-review` skill for a standalone review of the changes (recommended — a fresh review catches issues the executing agent may have missed)
+2. If issues are found, run `/hopla:code-review-fix` to fix them
+3. Run the `execution-report` skill to document the implementation
+4. Run the `git` skill (say "commit") to commit the changes

package/commands/guide.md

@@ -45,19 +45,19 @@ Three categories for every task:
 ## Your Available Commands
 
 ### For Planning & Product
-- `/hopla-create-prd` — Create a Product Requirements Document through guided conversation
-- `/hopla-plan-feature` — Create an implementation plan (AI researches, you approve)
-- `/hopla-review-plan` — Review a plan before execution
+- `/hopla:create-prd` — Create a Product Requirements Document through guided conversation
+- `/hopla:plan-feature` — Create an implementation plan (AI researches, you approve)
+- `/hopla:review-plan` — Review a plan before execution
 
 ### For Oversight
-- `/hopla-system-review` — Analyze how well the AI followed the plan
-- `/hopla-guide` — Show this guide again
+- `/hopla:system-review` — Analyze how well the AI followed the plan
+- `/hopla:guide` — Show this guide again
 
 ## Getting Started
 
-1. Start with `/hopla-create-prd` to define your project scope
-2. Use `/hopla-plan-feature "your feature idea"` to plan each feature
-3. Review the plan with `/hopla-review-plan`
+1. Start with `/hopla:create-prd` to define your project scope
+2. Use `/hopla:plan-feature "your feature idea"` to plan each feature
+3. Review the plan with `/hopla:review-plan`
 4. Hand off to a developer for execution, or ask the AI to execute
 
 ## Tips for Better Results

package/commands/guides/ai-optimized-codebase.md

@@ -1,7 +1,7 @@
 # AI-Optimized Codebase Guide
 
 ## When to Use This Guide
-Reference this guide when initializing a project with `/hopla-init-project` or when optimizing an existing codebase for better AI-assisted development.
+Reference this guide when initializing a project with `/hopla:init-project` or when optimizing an existing codebase for better AI-assisted development.
 
 ## Principles
 

package/commands/guides/mcp-integration.md

@@ -5,17 +5,17 @@ Reference this guide when planning features that involve external tools or servi
 
 ## MCP in the PIV Loop
 
-### During Planning (`/hopla-plan-feature`)
+### During Planning (`/hopla:plan-feature`)
 - Check what MCP servers are configured (listed in CLAUDE.md under "MCP Servers")
 - For each external integration point, specify which MCP tool to use
 - Example: "Step 3: Use Playwright MCP to verify the component renders correctly"
 
-### During Execution (`/hopla-execute`)
+### During Execution (`/hopla:execute`)
 - Before starting, verify MCP servers are available and responsive
 - When a task involves an MCP tool, use it explicitly (don't fall back to manual alternatives)
 - If an MCP server is unavailable, document it and skip that validation step
 
-### During Validation (`/hopla-validate`)
+### During Validation (`/hopla:validate`)
 - Use Playwright MCP for E2E browser validation if configured
 - Use database MCPs to verify data state after migrations
 - Document which validations were done via MCP vs. manual

package/commands/guides/remote-coding.md

@@ -50,9 +50,9 @@ jobs:
         run: |
           npx claude-code --print "
             Read issue #${{ github.event.issue.number }}.
-            /hopla-plan-feature based on the issue requirements.
-            /hopla-execute the plan.
-            /hopla-validate
+            /hopla:plan-feature based on the issue requirements.
+            /hopla:execute the plan.
+            /hopla:validate
             Create a PR with the results.
           "
 ```

package/commands/guides/review-checklist.md

@@ -1,6 +1,6 @@
 # Guide: Creating a Project-Specific Review Checklist
 
-Use this guide to create a `.agents/guides/review-checklist.md` file in your project with code review checks specific to your tech stack, domain, and known anti-patterns. The `/hopla-code-review` command loads this file automatically when it exists, applying your custom checks alongside the standard review categories.
+Use this guide to create a `.agents/guides/review-checklist.md` file in your project with code review checks specific to your tech stack, domain, and known anti-patterns. The the `code-review` skill command loads this file automatically when it exists, applying your custom checks alongside the standard review categories.
 
 ---
 
@@ -9,8 +9,8 @@ Use this guide to create a `.agents/guides/review-checklist.md` file in your pro
 Create a review checklist when:
 - The same bug pattern appears in **2+ code reviews** (e.g., stale closures in grid callbacks)
 - Your project uses a framework with non-obvious gotchas (AG Grid, Hono, Prisma, D3, etc.)
-- A `/hopla-system-review` flags a recurring issue that should be caught during code review
-- A `/hopla-execution-report` documents a new technical pattern in its "Technical Patterns Discovered" section
+- A `/hopla:system-review` flags a recurring issue that should be caught during code review
+- A the `execution-report` skill documents a new technical pattern in its "Technical Patterns Discovered" section
 
 ---
 
@@ -67,8 +67,8 @@ Patterns that have caused bugs in this project before:
 ## Maintenance
 
 Update this file when:
-- `/hopla-system-review` flags a recurring bug pattern (3+ occurrences across reviews)
-- `/hopla-execution-report` discovers a new technical pattern in "Technical Patterns Discovered"
+- `/hopla:system-review` flags a recurring bug pattern (3+ occurrences across reviews)
+- the `execution-report` skill discovers a new technical pattern in "Technical Patterns Discovered"
 - A code review finds a bug that should have been caught by a checklist item
 - A framework is upgraded and known gotchas change
 

package/commands/guides/scaling-beyond-engineering.md

@@ -10,21 +10,18 @@ According to Anthropic's 2026 Agentic Coding Trends Report:
 - The barrier between "people who code" and "people who don't" is becoming permeable
 - Domain experts implementing solutions directly removes bottlenecks
 
-## HOPLA's Planning Mode
+## HOPLA for Non-Technical Users
 
-HOPLA already supports non-technical users via `--planning` mode:
-- Restricted command set (planning and review only)
-- Limited git permissions (read-only)
-- Focus on product decisions, not implementation
+Non-technical users can adopt HOPLA today by installing the plugin and focusing on product-planning commands. The 4D Framework guide (`/hopla:guide`) walks them through Description → Discernment → Delegation → Diligence without requiring them to write or review code directly.
 
 ## Expanding the Model
 
 ### Phase 1: Product Planning (Current)
 Non-technical users can:
-- Create PRDs with `/hopla-create-prd`
-- Plan features with `/hopla-plan-feature`
-- Review plans with `/hopla-review-plan`
-- Guide workflow with `/hopla-guide` (4D Framework)
+- Create PRDs with `/hopla:create-prd`
+- Plan features with `/hopla:plan-feature`
+- Review plans with `/hopla:review-plan`
+- Guide workflow with `/hopla:guide` (4D Framework)
 
 ### Phase 2: Assisted Creation (Future)
 Non-technical users could:

package/commands/init-project.md

@@ -427,15 +427,15 @@ Create the following directories (with `.gitkeep` where needed):
 
 ```
 .agents/
-├── plans/               <- /hopla-plan-feature saves here (commit)
-│   ├── done/            <- /hopla-system-review archives completed plans here (commit)
-│   └── backlog/         <- /hopla-execute Scope Guard defers ideas here (commit)
+├── plans/               <- /hopla:plan-feature saves here (commit)
+│   ├── done/            <- /hopla:system-review archives completed plans here (commit)
+│   └── backlog/         <- /hopla:execute Scope Guard defers ideas here (commit)
 ├── specs/               <- brainstorm skill saves design docs here (commit)
 ├── guides/              <- on-demand reference guides (commit)
-├── rca/                 <- /hopla-rca saves root cause analysis docs here (commit)
-├── execution-reports/   <- /hopla-execution-report saves here (commit — needed for cross-session learning)
-├── system-reviews/      <- /hopla-system-review saves here (commit — needed for feedback loop)
-└── code-reviews/        <- /hopla-code-review saves here (do NOT commit — ephemeral, consumed by code-review-fix)
+├── rca/                 <- /hopla:rca saves root cause analysis docs here (commit)
+├── execution-reports/   <- the `execution-report` skill saves here (commit — needed for cross-session learning)
+├── system-reviews/      <- /hopla:system-review saves here (commit — needed for feedback loop)
+└── code-reviews/        <- the `code-review` skill saves here (do NOT commit — ephemeral, consumed by code-review-fix)
 ```
 
 Add to `.gitignore` (create if it doesn't exist):
@@ -476,6 +476,6 @@ Once confirmed:
 1. Save `CLAUDE.md` to the project root
 2. Create `.agents/` directory structure
 3. Update `.gitignore`
-4. If no PRD exists yet, tell the user: "Project initialized. Run `/hopla-create-prd` next to define the product scope, or `/hopla-plan-feature` to start planning a feature."
-   If a PRD already exists, tell the user: "Project initialized. Run `/hopla-plan-feature` to start planning the first feature."
-5. Suggest running `/hopla-git-commit` to save everything
+4. If no PRD exists yet, tell the user: "Project initialized. Run `/hopla:create-prd` next to define the product scope, or `/hopla:plan-feature` to start planning a feature."
+   If a PRD already exists, tell the user: "Project initialized. Run `/hopla:plan-feature` to start planning the first feature."
+5. Suggest running the `git` skill (say "commit") to save everything

package/commands/plan-feature.md

@@ -170,7 +170,7 @@ Run in this order — do not proceed if a level fails:
 
 - [ ] **Level 1 — Lint & Format:** `[project lint command]`
 - [ ] **Level 2 — Type Check:** `[project type check command]`
-- [ ] **Level 2.5 — Code Review:** Run `/hopla-code-review` on changed files
+- [ ] **Level 2.5 — Code Review:** Run the `code-review` skill on changed files
 - [ ] **Level 3 — Unit Tests:** `[project unit test command]`
 - [ ] **Level 4 — Integration Tests:** `[project integration test or manual curl/check]`
 - [ ] **Level 5 — Human Review:** Verify behavior matches requirements above
@@ -260,4 +260,4 @@ Before saving the draft, review the plan against these criteria:
 
 **Finalize:**
 1. Rename `.agents/plans/[feature-name].draft.md` → `.agents/plans/[feature-name].md` (overwrite if it already exists)
-2. Confirm: "✅ Plan saved to `.agents/plans/[feature-name].md`. Run `/hopla-review-plan .agents/plans/[feature-name].md` to review it, then `/hopla-execute .agents/plans/[feature-name].md` to implement it."
+2. Confirm: "✅ Plan saved to `.agents/plans/[feature-name].md`. Run `/hopla:review-plan .agents/plans/[feature-name].md` to review it, then `/hopla:execute .agents/plans/[feature-name].md` to implement it."

package/commands/rca.md

@@ -60,9 +60,9 @@ What needs to change to resolve this
 How to prevent similar issues in the future
 
 ## Next Steps
-- [ ] Implement fix (run `/hopla-execute` with a plan, or fix directly if simple)
+- [ ] Implement fix (run `/hopla:execute` with a plan, or fix directly if simple)
 - [ ] Add regression test
-- [ ] Validate with `/hopla-validate`
+- [ ] Validate with `/hopla:validate`
 ```
 
 ## Output

package/commands/review-plan.md

@@ -48,5 +48,5 @@ After the summary, ask (in the user's language):
 
 **Review loop:**
 - If the user has questions → answer them based on the plan content
-- If the user requests changes → note them and tell the user to ask Robert to update the plan, or apply minor clarifications directly if they are unambiguous
-- If the user approves → confirm: "✅ Plan approved. Run `/hopla-execute $1` to start."
+- If the user requests changes → note them and suggest re-running `/hopla:plan-feature` to update the plan, or apply minor clarifications directly if they are unambiguous
+- If the user approves → confirm: "✅ Plan approved. Run `/hopla:execute $1` to start."

package/commands/validate.md

@@ -66,10 +66,10 @@ If anything failed and could not be fixed, list the remaining issues and suggest
 
 ## After Validation Passes
 
-- Suggest running `/hopla-code-review` if not already done
+- Suggest running the `code-review` skill if not already done
 - Remind that completion claims must be backed by this fresh validation evidence (see hopla-verify skill)
 
 ## Next Step
 
 After validation passes, suggest:
-> "All validation levels passed. Consider running `/hopla-code-review` for a deeper analysis — code review catches bugs in 79% of implementations that pass automated validation (stale closures, missing input validation, route shadowing, unhandled promise rejections). Run `/hopla-code-review` to check, or `/hopla-git-commit` to commit directly."
+> "All validation levels passed. Consider running the `code-review` skill for a deeper analysis — code review catches bugs in 79% of implementations that pass automated validation (stale closures, missing input validation, route shadowing, unhandled promise rejections). Run the `code-review` skill to check, or the `git` skill (say "commit") to commit directly."

package/hooks/env-protect.js

@@ -1,19 +1,50 @@
 #!/usr/bin/env node
-// PreToolUse hook: blocks reads/greps targeting .env files
+// PreToolUse hook: blocks reads/greps/Bash commands that expose .env secrets.
+// Hooks.json matcher must include Bash so Bash calls reach this script.
+
+function isEnvPath(p) {
+    if (typeof p !== "string" || !p) return false;
+    // Matches: .env, ./.env, path/.env, .env.local, .env.production, path/.env.X
+    return /(^|\/)\.env(\.\w+)?$/.test(p);
+}
+
+function commandReadsEnv(cmd) {
+    if (typeof cmd !== "string" || !cmd) return false;
+    // Split on shell word separators so we inspect each argument/path token
+    const tokens = cmd.split(/[\s<>|&;"'`()]+/);
+    return tokens.some(isEnvPath);
+}
 
 async function main() {
     const chunks = [];
-    for await (const chunk of process.stdin) {
-        chunks.push(chunk);
+    for await (const chunk of process.stdin) chunks.push(chunk);
+
+    let toolCall;
+    try {
+        toolCall = JSON.parse(Buffer.concat(chunks).toString());
+    } catch {
+        // Malformed input — fail open so we never block legitimate tool use
+        process.exit(0);
     }
 
-    const toolCall = JSON.parse(Buffer.concat(chunks).toString());
-    const filePath = toolCall.tool_input?.file_path || toolCall.tool_input?.path || "";
+    const name = toolCall.tool_name || "";
+    const input = toolCall.tool_input || {};
+
+    // Read / Grep / Glob / Edit / Write — check file_path or path
+    const filePath = input.file_path || input.path || "";
+    if (isEnvPath(filePath)) {
+        process.stderr.write(
+            `Access denied: reading or editing .env files is blocked to prevent accidental secret exposure. ` +
+            `If you need env var names, check the README or ask the user.\n`
+        );
+        process.exit(2);
+    }
 
-    if (filePath.includes(".env")) {
+    // Bash — inspect the command string for tokens that read an .env file
+    if (name === "Bash" && commandReadsEnv(input.command)) {
         process.stderr.write(
-            `Access denied: Reading .env files is blocked to prevent accidental secret exposure. ` +
-            `If you need environment variable names, check the README or ask the user.\n`
+            `Access denied: this Bash command reads a .env file, which is blocked to prevent secret exposure. ` +
+            `If you need env var names, ask the user.\n`
         );
         process.exit(2);
     }

package/hooks/hooks.json

@@ -14,7 +14,7 @@
     ],
     "PreToolUse": [
       {
-        "matcher": "Read|Grep",
+        "matcher": "Read|Grep|Glob|Edit|Write|Bash",
         "hooks": [
           {
             "type": "command",

package/hooks/tsc-check.js

@@ -1,33 +1,44 @@
 #!/usr/bin/env node
-// PostToolUse hook: runs tsc --noEmit after file edits and feeds errors back to Claude
+// PostToolUse hook: runs tsc --noEmit after file edits and feeds errors back to Claude.
+// Prefers the project-local tsc (node_modules/.bin/tsc) over a global install so
+// the hook reports real results even when the user does not have tsc on PATH.
 
 import { execSync } from "child_process";
 import fs from "fs";
 import path from "path";
 
+function resolveTscCommand(cwd) {
+    const localBin = path.join(cwd, "node_modules", ".bin", "tsc");
+    if (fs.existsSync(localBin)) return `"${localBin}"`;
+    // Fall back to npx --no-install so we never trigger a network install;
+    // if tsc is not available anywhere, npx exits non-zero with a clear error.
+    return "npx --no-install tsc";
+}
+
 async function main() {
+    // Drain stdin (hook contract) but we don't need the payload for tsc --noEmit
     const chunks = [];
-    for await (const chunk of process.stdin) {
-        chunks.push(chunk);
-    }
+    for await (const chunk of process.stdin) chunks.push(chunk);
 
-    // If no tsconfig.json in cwd, exit silently (non-TS project)
-    const tsconfigPath = path.join(process.cwd(), "tsconfig.json");
+    const cwd = process.cwd();
+    const tsconfigPath = path.join(cwd, "tsconfig.json");
     if (!fs.existsSync(tsconfigPath)) {
+        // Not a TypeScript project — skip silently
         process.exit(0);
     }
 
-    let result;
+    const tsc = resolveTscCommand(cwd);
+
     try {
-        execSync("tsc --noEmit", { cwd: process.cwd(), stdio: "pipe" });
-        // No errors — exit silently
+        execSync(`${tsc} --noEmit`, { cwd, stdio: "pipe" });
+        // Compile clean — exit silently
         process.exit(0);
     } catch (err) {
         const output = (err.stdout || "").toString() + (err.stderr || "").toString();
         if (output.trim()) {
             process.stdout.write("TypeScript errors detected:\n" + output + "\n");
         }
-        // Exit 0: PostToolUse hooks cannot block, but stdout is fed back to Claude
+        // PostToolUse hooks cannot block; stdout is fed back to Claude
         process.exit(0);
     }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hopla/claude-setup",
-  "version": "1.14.0",
+  "version": "1.14.1",
   "description": "Hopla team agentic coding system for Claude Code",
   "type": "module",
   "bin": {

package/skills/brainstorm/SKILL.md

@@ -72,14 +72,14 @@ Conceptual design details
 - Anything still unclear
 
 ## Next Step
-Run `/hopla-plan-feature` to create the implementation plan from this design
+Run `/hopla:plan-feature` to create the implementation plan from this design
 ```
 
 ### Step 6: Review Loop
 Present the design document for user review.
 - Accept feedback using the `<? ... >` comment syntax
 - Iterate until the user approves
-- Only then suggest: "Design approved! Ready to create the plan with `/hopla-plan-feature`?"
+- Only then suggest: "Design approved! Ready to create the plan with `/hopla:plan-feature`?"
 
 ## Rules
 - Never skip to planning without design approval
@@ -90,5 +90,5 @@ Present the design document for user review.
 
 ## Integration
 
-- If the user hasn't defined requirements yet, suggest: "Before brainstorming, consider running `/hopla-create-prd` to define the product requirements. This gives us clearer constraints to design against."
+- If the user hasn't defined requirements yet, suggest: "Before brainstorming, consider running `/hopla:create-prd` to define the product requirements. This gives us clearer constraints to design against."
 - If the user is brainstorming a bug fix rather than a new feature, suggest: "This sounds like a bug rather than a new feature. Consider running the `debug` skill for systematic root cause analysis instead."

package/skills/code-review/SKILL.md

@@ -96,4 +96,4 @@ If no issues found: "Code review passed. No technical issues detected."
 ## Next Step
 
 After the review, suggest:
-> "Code review saved to `.agents/code-reviews/[name].md`. If issues were found, run `/hopla-code-review-fix .agents/code-reviews/[name].md` to fix them. If the review passed clean, proceed to `/hopla-execution-report`."
+> "Code review saved to `.agents/code-reviews/[name].md`. If issues were found, run `/hopla:code-review-fix .agents/code-reviews/[name].md` to fix them. If the review passed clean, proceed to the `execution-report` skill."

package/skills/debug/SKILL.md

@@ -75,7 +75,7 @@ When the bug is fixed, briefly report:
 ## Escalation
 
 If the 3-Strike Rule activates (3 fixes failed), suggest:
-> "This bug may need deeper investigation. Run `/hopla-rca` to produce a structured Root Cause Analysis document with evidence, proposed fix, and prevention steps."
+> "This bug may need deeper investigation. Run `/hopla:rca` to produce a structured Root Cause Analysis document with evidence, proposed fix, and prevention steps."
 
 If the bug is fixed, suggest:
-> "Bug fixed. Run `/hopla-validate` to verify no regressions, then `/hopla-git-commit` to save the fix."
+> "Bug fixed. Run `/hopla:validate` to verify no regressions, then the `git` skill (say "commit") to save the fix."

package/skills/execution-report/SKILL.md

@@ -115,4 +115,4 @@ Based on this implementation, what should change for next time?
 ## Next Step
 
 After the report is saved, suggest:
-> "Execution report saved to `.agents/execution-reports/[name].md`. Run `/hopla-git-commit` to commit your changes."
+> "Execution report saved to `.agents/execution-reports/[name].md`. Run the `git` skill (say "commit") to commit your changes."

package/skills/git/commit.md

@@ -73,4 +73,4 @@ After committing, remind the user:
 **Never push automatically** — wait for explicit confirmation.
 
 If the user confirms the push (or if the branch was already pushed), suggest:
-> "Ready to create a Pull Request? Run `/hopla-git-pr` to create one."
+> "Ready to create a Pull Request? Run the `git` skill (say "create PR") to create one."

package/skills/git/pr.md

@@ -90,7 +90,7 @@ After creating, show the PR URL to the user.
 **Never merge automatically** — the PR is for human review.
 
 After showing the PR URL, suggest:
-> "PR created. To complete the cycle, run `/hopla-execution-report` (if not done yet) and `/hopla-system-review` after the PR is merged."
+> "PR created. To complete the cycle, run the `execution-report` skill (if not done yet) and `/hopla:system-review` after the PR is merged."
 
 ## Step 7: Post-Merge Cleanup
 

package/skills/prime/SKILL.md

@@ -54,7 +54,7 @@ If there are pending plans, list them clearly after the prose summary:
 ```
 Pending plans:
 - inventory-page.draft.md ← draft, not finalized yet
-- add-user-authentication.md ← ready to execute with /hopla-execute
+- add-user-authentication.md ← ready to execute with /hopla:execute
 ```
 
 End with a sentence like: "All caught up — what are we working on today?"

package/skills/subagent-execution/SKILL.md

@@ -63,7 +63,7 @@ Report your status as DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or BLOCKED.
 - Commit at phase boundaries (every 3-5 tasks)
 - Always validate before committing
 
-## Integration with /hopla-execute
+## Integration with /hopla:execute
 This skill is an ALTERNATIVE to inline execution. Suggest it when:
 - The plan has 5+ tasks
 - The user expresses concern about quality in long sessions

package/skills/tdd/SKILL.md

@@ -44,7 +44,7 @@ description: "Test-driven development workflow using the RED-GREEN-REFACTOR cycl
 - Boilerplate with no logic
 - Legacy code without existing test infrastructure
 
-## Integration with /hopla-execute
+## Integration with /hopla:execute
 
 When executing a plan with TDD:
 1. For each implementation task that has associated tests:

package/skills/verify/SKILL.md

@@ -55,7 +55,7 @@ When completing a feature (not just a single file edit), run the full validation
 4. **Level 4**: Integration tests (if applicable)
 5. **Level 5**: Human review suggestion
 
-Reference `/hopla-validate` for project-specific validation commands.
+Reference `/hopla:validate` for project-specific validation commands.
 
 ## Scope
 

package/skills/worktree/SKILL.md

@@ -113,6 +113,6 @@ git branch -D <prefix>/<name>
 
 ## Integration
 
-- Combine with `/hopla-execute` — run execution from inside the worktree
+- Combine with `/hopla:execute` — run execution from inside the worktree
 - Combine with the `git` skill — commit and PR from inside the worktree; cleanup happens post-merge
 - Combine with parallel dispatch — multiple worktrees active simultaneously