@hopla/claude-setup 1.12.1 → 1.14.1

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.12.1",
+  "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
@@ -87,3 +87,8 @@ Present the design document for user review.
 - Always ground proposals in the existing codebase (not abstract theory)
 - If the feature is trivial (< 30 minutes of work), skip the full process — just confirm approach and proceed
 - In planning mode (non-technical users): focus on product decisions, not technical details
+
+## 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 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

@@ -37,6 +37,7 @@ For each changed file, look for:
 - Stale closures — callbacks passed to imperative APIs (grids, charts, maps) that capture stale state instead of using refs or stable references
 - Unhandled promise rejections — `.then()` without `.catch()`, async calls without `try/catch` in non-void contexts
 - Side effects inside JSX render — mutations of arrays/objects inside `.map()` in JSX (breaks React strict mode, causes double-execution bugs)
+- Stale dependency arrays — for every new `useState`/`useRef` variable introduced in the diff, verify it appears in the dependency arrays of `useEffect`, `useCallback`, or `useMemo` that reference it. Missing deps cause stale closures — this was the #1 React bug category across 28 implementations
 
 **2. Security Issues**
 - Exposed secrets or API keys
@@ -44,10 +45,11 @@ For each changed file, look for:
 - Missing input validation on API endpoints — required fields, format constraints (regex, length), payload size limits
 - Insecure data handling — raw user input in queries, responses exposing internal data or stack traces
 - XSS vulnerabilities (frontend)
+- Multi-user authorization context — for multi-tenant apps, verify each endpoint filters by the correct context (e.g., active org vs personal org, admin vs viewer). Check that middleware/auth guards match the intended audience for each route
 
 **3. Performance Problems**
 - Unnecessary re-renders (React)
-- N+1 queries or redundant API calls
+- N+1 queries — database queries or API calls inside loops (`for`, `.map`, `.forEach`), duplicate existence checks before mutations, sequential operations that could use `Promise.all()` or batch SQL. This was found in 5 of 13 recent implementations
 - Memory leaks
 
 **4. Code Quality**
@@ -94,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

@@ -71,3 +71,11 @@ When the bug is fixed, briefly report:
 - **Fix**: What was changed and why
 - **Test**: What test verifies the fix
 - **Prevention**: How to prevent similar bugs (if applicable)
+
+## 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."
+
+If the bug is fixed, suggest:
+> "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

@@ -101,7 +101,7 @@ New gotchas, patterns, or conventions learned during this implementation that sh
 
 - **Pattern/Gotcha:** [description]
 - **Where it applies:** [what type of feature or context triggers this]
-- **Suggested documentation:** [which file should capture this: CLAUDE.md, `.agents/guides/review-checklist.md`, or a new guide]
+- **Ready-to-paste CLAUDE.md entry:** [Write the EXACT text that should be added to the project's CLAUDE.md to prevent this gotcha in future features. Format it as a bullet point under the appropriate section. If it belongs in a guide instead, write the exact text for the guide. Do not write vague suggestions like "document this" — write the actual content so the system reviewer can apply it directly.]
 
 If nothing new was discovered, write "No new patterns discovered."
 
@@ -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

@@ -20,7 +20,10 @@ git log --oneline -5
 - Identify what was added, modified, or deleted
 - Determine the appropriate commit type: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`
 - Identify the scope if relevant (e.g., `auth`, `api`, `ui`)
-- Check current branch — confirm it follows Git Flow naming (`feature/`, `fix/`, `hotfix/`, `develop`, `dev`)
+- Resolve branch context using `flow-detection.md` (same directory):
+  - Confirm the current branch is NOT a base branch (`main`/`master`/`develop`/`dev`) — if it is, warn the user before committing
+  - Confirm the branch prefix matches `feature/`, `fix/`, `hotfix/`, or `release/` — otherwise ask the user
+  - Detect whether you are inside a worktree (via `git rev-parse --git-dir` vs `--git-common-dir`) and report the location to the user for context
 
 ## Step 3: Stage Files
 
@@ -42,7 +45,18 @@ Present the proposed commit message to the user **before executing**:
 
 Wait for explicit approval before running `git commit`.
 
-## Step 5: Execute Commit
+## Step 5: Version Bump (if configured)
+
+Before committing, check the project's `CLAUDE.md` for a `## Versioning` section. If it exists:
+
+1. Read the versioning configuration (command, trigger, files)
+2. Check if the **trigger condition** matches (e.g., specific branches, always, etc.)
+3. If it matches, run the version bump command
+4. Stage the version files alongside the other changes
+
+If no `## Versioning` section exists in the project's `CLAUDE.md`, skip this step entirely.
+
+## Step 6: Execute Commit
 
 Once approved, create the commit:
 
@@ -50,10 +64,13 @@ Once approved, create the commit:
 git commit -m "<type>(<scope>): <description>"
 ```
 
-## Step 6: Push Reminder
+## Step 7: Push Reminder
 
 After committing, remind the user:
 
 > "Commit created locally. Do you want to push to `origin/<branch>`?"
 
 **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 the `git` skill (say "create PR") to create one."

package/skills/git/flow-detection.md

@@ -0,0 +1,68 @@
+# Git Flow Detection — Shared Reference
+
+> Shared by the `git` skill (`commit.md`, `pr.md`), the `worktree` skill, and the `execute` command. Keep the logic here and reference it from callers — do not duplicate.
+
+## Step 1: Detect the branching model
+
+```bash
+git branch -r
+```
+
+Resolve `$DEFAULT_BASE`:
+
+- `origin/develop` exists → **Git Flow**, `$DEFAULT_BASE = develop`
+- Else `origin/dev` exists → **Git Flow**, `$DEFAULT_BASE = dev`
+- Else only `origin/main` / `origin/master` → **GitHub Flow**, `$DEFAULT_BASE = main` (or `master`)
+
+## Step 2: Map branch prefix → base branch
+
+| Branch prefix | Base (Git Flow) | Base (GitHub Flow) |
+|---|---|---|
+| `feature/*` | `$DEFAULT_BASE` | `main` |
+| `fix/*` | `$DEFAULT_BASE` | `main` |
+| `hotfix/*` | `main` | `main` |
+| `release/*` | `main` | N/A — ask the user |
+
+**Edge cases:**
+
+- Branch does not match a known prefix → ask the user which base to use
+- Current branch is `main`/`master`/`develop`/`dev` → stop and warn; commits and PRs must come from a feature/fix/hotfix/release branch
+- `hotfix/*` on a Git Flow project but base resolved to `develop` → **refuse** and correct to `main`
+
+## Step 3: Detect worktree context
+
+```bash
+GIT_DIR=$(git rev-parse --git-dir)
+GIT_COMMON_DIR=$(git rev-parse --git-common-dir)
+```
+
+- `GIT_DIR` ≠ `GIT_COMMON_DIR` → you are **inside a worktree**
+- Else you are in the **main repo**
+
+List all active worktrees when useful for the user:
+
+```bash
+git worktree list
+```
+
+The main repo path is:
+
+```bash
+MAIN_REPO=$(dirname "$(git rev-parse --git-common-dir)")
+```
+
+## Step 4: Verify the resolved base exists remotely
+
+```bash
+git show-ref --verify --quiet refs/remotes/origin/$BASE || echo "missing"
+```
+
+If missing, ask the user before proceeding.
+
+## Step 5: Standard warnings
+
+Emit these to the user when applicable:
+
+- On `main`/`develop`/`dev`: "You're on `$BRANCH` — this is a base branch. Commits and PRs should come from feature branches."
+- Unknown prefix: "Branch `$BRANCH` does not match `feature/`, `fix/`, `hotfix/`, or `release/`. Which base branch should it target?"
+- Hotfix from wrong base: "`hotfix/*` must branch from `main`, not `$DETECTED_BASE`. Refusing to proceed — recreate the branch from `main`."

package/skills/git/pr.md

@@ -21,21 +21,16 @@ Read the following if they exist:
 
 **If the user specified a base branch**, use it.
 
-**Otherwise, infer from Git Flow branch naming:**
+**Otherwise**, resolve it using `flow-detection.md` (same directory):
 
-| Current branch prefix | Base branch |
-|---|---|
-| `feature/*` | `develop` or `dev` |
-| `fix/*` | `develop` or `dev` |
-| `hotfix/*` | `main` |
-| `release/*` | `main` |
+1. Detect the branching model and `$DEFAULT_BASE` (Step 1 of flow-detection.md)
+2. Map the current branch prefix → base branch (Step 2 of flow-detection.md)
+3. Verify the resolved base exists remotely (Step 4 of flow-detection.md)
+4. Apply the standard warnings (Step 5 of flow-detection.md)
 
-To resolve `develop` vs `dev`: run `git branch -r` and look for `origin/develop` or `origin/dev`. Use whichever exists.
+**Always show the resolved base branch in Step 5** so the user can catch mistakes before the PR is created.
 
-**Guard rails:**
-- If the current branch is `main`, `master`, `develop`, or `dev` → stop and warn: "You're on `[branch]` — PRs should come from feature branches."
-- If the branch name doesn't match any Git Flow prefix → ask the user: "I can't determine the base branch from `[branch]`. Should this PR target `develop` or `main`?"
-- **Always show the resolved base branch in Step 5** so the user can catch mistakes before the PR is created.
+Also detect if you are inside a worktree (Step 3 of flow-detection.md) — this is needed for post-merge cleanup in Step 7.
 
 ## Step 3: Check Push Status
 
@@ -94,11 +89,44 @@ 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 the `execution-report` skill (if not done yet) and `/hopla:system-review` after the PR is merged."
+
 ## Step 7: Post-Merge Cleanup
 
-After the user confirms the PR was approved and merged on GitHub, run the cleanup workflow based on the branch type:
+After the user confirms the PR was approved and merged on GitHub, detect whether the branch lives in a worktree and run the appropriate cleanup.
+
+### Detect worktree
+
+Apply Step 3 of `flow-detection.md`:
+
+```bash
+GIT_DIR=$(git rev-parse --git-dir)
+GIT_COMMON_DIR=$(git rev-parse --git-common-dir)
+MAIN_REPO=$(dirname "$GIT_COMMON_DIR")
+```
+
+If `GIT_DIR` ≠ `GIT_COMMON_DIR`, the branch is in a worktree — use **Path A**. Otherwise use **Path B**.
+
+### Path A — Cleanup from a worktree
+
+Capture the worktree path before moving out:
+
+```bash
+WORKTREE_PATH=$(git rev-parse --show-toplevel)
+cd "$MAIN_REPO"
+
+git checkout [base-branch]
+git pull origin [base-branch]
+
+git worktree remove "$WORKTREE_PATH"
+git branch -d [merged-branch]
+git push origin --delete [merged-branch] 2>/dev/null  # skip if GitHub already deleted it
+```
 
-### For all branch types:
+If `git worktree remove` fails because the tree has uncommitted work, stop and ask the user — do **not** pass `--force` without explicit confirmation.
+
+### Path B — Cleanup from the main repo
 
 ```bash
 git checkout [base-branch]
@@ -107,7 +135,9 @@ git branch -d [merged-branch]
 git push origin --delete [merged-branch] 2>/dev/null  # skip if GitHub already deleted it
 ```
 
-### Additional steps for `hotfix/*` and `release/*`:
+**Important:** When `dev` is merged to `main` via PR, do NOT pull `main` back into `dev` — `dev` already has all the commits. Only sync `main` → `dev` for hotfix/release branches (see below).
+
+### Additional steps for `hotfix/*` and `release/*`
 
 These branches were merged to `main` but `develop` also needs the changes:
 
@@ -127,4 +157,4 @@ git push origin v[version]
 
 Ask the user for the version number before tagging.
 
-**Always confirm each destructive action** (branch deletion, tag creation) before executing.
+**Always confirm each destructive action** (branch deletion, worktree removal, tag creation) before executing.

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,10 +55,20 @@ 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
 
 - **Applies to**: Any declaration of completion, whether mid-conversation or at end of task
 - **Does NOT apply to**: Intermediate progress updates ("I've finished editing file X, moving to file Y")
 - **Partial completion**: You may say "file X is updated" without full validation, but "the feature is complete" requires the full gate
+
+## Plan Execution Check
+
+When verifying completion of a plan execution (not just a standalone task):
+
+1. **Divergences documented?** — Ask: "Were there any tasks added, skipped, or changed from the original plan?" If yes, verify they are documented in the completion report.
+2. **Unplanned files?** — Run `git diff --name-only` and compare against the plan's task list. Flag any files changed that aren't in any task.
+3. **All acceptance criteria met?** — Read the plan's acceptance criteria and verify each one has fresh evidence.
+
+These checks prevent the common pattern where implementation is "done" but divergences are silently omitted from the report.

package/skills/worktree/SKILL.md

@@ -1,14 +1,18 @@
 ---
 name: worktree
-description: "Git worktree management for isolated feature development. Use when starting a new feature that benefits from isolation, when the user says 'worktree', 'isolated branch', 'parallel development', or when implementing multiple features simultaneously. Do NOT use for quick fixes or single-file changes."
+description: "Git worktree management for isolated feature development with Git Flow awareness. Use when starting a new feature that benefits from isolation, when the user says 'worktree', 'isolated branch', 'parallel development', or when implementing multiple features simultaneously. Do NOT use for quick fixes or single-file changes."
 ---
 
-# Git Worktrees for Isolated Development
+# Git Worktrees — Isolated Development with Git Flow
 
-## What Are Worktrees?
-Git worktrees create separate working directories for different branches, sharing the same git history. Each worktree is an independent workspace.
+> 🌐 **Language:** All user-facing output must match the user's language. Code, paths, and commands stay in English.
+
+## What are worktrees?
+
+Git worktrees create separate working directories for different branches while sharing the same git history. Each worktree is an independent workspace.
+
+## When to use
 
-## When to Use
 - Starting a feature that should be isolated from other work
 - Developing multiple features in parallel
 - Needing a clean baseline to test against
@@ -16,58 +20,99 @@ Git worktrees create separate working directories for different branches, sharin
 
 ## Setup Process
 
-### Step 1: Choose Worktree Directory
+### Step 1: Identify branch type and resolve base branch
+
+Ask the user (or infer from context) which type of branch to create:
+
+| Prefix | Purpose | Base (Git Flow) | Base (GitHub Flow) |
+|---|---|---|---|
+| `feature/*` | New functionality | `develop` / `dev` | `main` |
+| `fix/*` | Non-urgent bug fix | `develop` / `dev` | `main` |
+| `hotfix/*` | Urgent production fix | `main` | `main` |
+| `release/*` | Release candidate | `main` | N/A — ask user |
+
+Use `../git/flow-detection.md` (Steps 1–2) to resolve the base branch from the prefix. Confirm it exists remotely (Step 4).
+
+**Guard rails:**
+
+- **Refuse** to create a `hotfix/*` worktree from `develop`/`dev`. Hotfixes must come from `main` — correct the base before proceeding.
+- If the prefix is unknown, ask the user which base to use.
+- Always show the resolved base to the user before executing `git worktree add`.
+
+### Step 2: Choose worktree directory
+
 Check in order:
+
 1. Existing `.worktrees/` or `worktrees/` directory
-2. CLAUDE.md preference (if configured)
-3. Ask the user
+2. `CLAUDE.md` preference (if configured)
+3. Ask the user (default: `worktrees/<kebab-name>`)
+
+### Step 3: Ensure the worktree directory is gitignored
 
-### Step 2: Ensure Directory is Gitignored
 ```bash
-# Verify the worktree directory is in .gitignore
-grep -q "worktrees" .gitignore || echo "worktrees/" >> .gitignore
+grep -q "^worktrees/" .gitignore 2>/dev/null || echo "worktrees/" >> .gitignore
 ```
 
-### Step 3: Create Worktree
+### Step 4: Create the worktree from the correct base
+
+Fetch first so the local base tracks the remote:
+
 ```bash
-# Create worktree with a new feature branch
-git worktree add worktrees/feature-name -b feature/feature-name
+git fetch origin <base-branch>
+git worktree add worktrees/<name> -b <prefix>/<name> origin/<base-branch>
 ```
 
-### Step 4: Setup Project in Worktree
-Auto-detect and run setup:
-- **Node.js**: `npm install` or `yarn install`
-- **Python**: `pip install -r requirements.txt` or `poetry install`
-- **Rust**: `cargo build`
-- **Go**: `go mod download`
+Examples:
 
-### Step 5: Verify Clean Baseline
 ```bash
-cd worktrees/feature-name
-# Run tests to ensure baseline is green
-npm test  # or equivalent
+# Feature off develop
+git worktree add worktrees/auth -b feature/auth origin/develop
+
+# Hotfix off main
+git worktree add worktrees/crash-fix -b hotfix/crash-fix origin/main
+
+# Fix on GitHub Flow project
+git worktree add worktrees/typo -b fix/typo origin/main
 ```
 
-If tests fail before any changes, STOP and report — the baseline is broken.
+### Step 5: Install project dependencies (if applicable)
+
+Auto-detect from the project root — run only what matches:
+
+- `package-lock.json` → `npm install`
+- `yarn.lock` → `yarn install`
+- `pnpm-lock.yaml` → `pnpm install`
+- `requirements.txt` → `pip install -r requirements.txt`
+- `pyproject.toml` with `poetry.lock` → `poetry install`
+- `Cargo.toml` → `cargo build`
+- `go.mod` → `go mod download`
+
+If none match, skip.
+
+### Step 6: Verify clean baseline (optional)
+
+If `CLAUDE.md` or `package.json` defines a test command, run it once inside the worktree to confirm the baseline is green. If no test command is defined, skip.
 
-### Step 6: Work in the Worktree
-All work for this feature happens in `worktrees/feature-name/`.
+If tests fail **before any changes**, STOP and report — the baseline is broken.
+
+### Step 7: Work in the worktree
+
+All work for this branch happens in `worktrees/<name>/`. Use the `git` skill from inside the worktree directory for commits and PRs — it detects the worktree context automatically.
 
 ## Cleanup
 
-### After Merge
-```bash
-git worktree remove worktrees/feature-name
-git branch -d feature/feature-name
-```
+Post-merge cleanup is handled by the `git` skill — see `../git/pr.md` Step 7. It detects the worktree and runs `git worktree remove` automatically.
+
+If the branch is **abandoned** before merge, confirm with the user and then:
 
-### If Abandoned
 ```bash
-git worktree remove --force worktrees/feature-name
-git branch -D feature/feature-name
+cd "$(dirname "$(git rev-parse --git-common-dir)")"  # back to main repo
+git worktree remove --force worktrees/<name>
+git branch -D <prefix>/<name>
 ```
 
 ## Integration
-- Use with `/hopla-execute` for isolated feature implementation
-- Use with `/hopla-git-pr` for creating PRs from the worktree branch
-- Combine with parallel dispatch for multiple features simultaneously
+
+- 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

package/commands/end-to-end.md

@@ -1,67 +0,0 @@
-# End-to-End Feature Implementation
-
-> Execute the complete PIV loop for a feature in one go: prime → brainstorm → plan → review → execute → validate → commit.
-
-> ⚠️ **Advanced**: Only use this command after you've proven each individual command works reliably. Build trust gradually.
-
-## Input
-- `$ARGUMENTS`: Feature description or requirement
-
-## Autonomy Levels
-
-This command represents **Level 3 autonomy**. Make sure you've mastered:
-- Level 1: Manual prompts (writing everything each time)
-- Level 2: Individual commands (/hopla-plan-feature, /hopla-execute, etc.)
-- Level 3: Command chaining (this command)
-
-## Process
-
-### Phase 1: Context Loading
-Load project context:
-- Read CLAUDE.md, README, package.json
-- Check git state (branch, status, pending plans)
-- Identify current development phase
-
-### Phase 2: Brainstorm (if needed)
-If the feature is non-trivial (estimated > 1 hour):
-- Explore 2-3 approaches with trade-offs
-- Get user approval on approach
-- Save design doc to `.agents/specs/`
-
-If trivial: skip to Phase 3.
-
-### Phase 3: Plan
-- Research codebase for related patterns
-- Generate structured implementation plan
-- Save to `.agents/plans/[feature-name].md`
-
-### 🔒 GATE: Plan Review
-**STOP and present the plan to the user.**
-- Show executive summary
-- Wait for explicit approval before proceeding
-- If changes requested: iterate on the plan
-
-### Phase 4: Execute
-- Create feature branch (`feature/[name]` from develop)
-- Execute all plan tasks sequentially
-- Validate after each phase boundary
-
-### Phase 5: Validate
-- Run full validation pyramid (lint → types → tests → integration)
-- Run code review
-- Fix any critical/important issues found
-
-### 🔒 GATE: Human Review
-**STOP and present results to the user.**
-- Show what was built, what was validated
-- Wait for approval before committing
-
-### Phase 6: Commit & PR
-- Create conventional commit(s)
-- Suggest creating a PR if on a feature branch
-
-## Rules
-- Never skip the human gates (plan review, final review)
-- If any phase fails, stop and report — don't push through
-- Each phase should feel like a natural conversation, not a script
-- Adapt: skip brainstorming for small features, skip PR for hotfixes