Refresh work-system: safe deps, md tables, sharper status

.claude-plugin/marketplace.json

@@ -18,7 +18,7 @@
       "name": "work-system",
       "source": "./plugins/work-system",
       "description": "Generic task and worktree workflow system for Claude Code. Manage tasks as markdown files, work in isolated git worktrees, and track progress through the full lifecycle.",
-      "version": "1.2.5"
+      "version": "1.3.0"
     },
     {
       "name": "pr-flow",

plugins/work-system/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "work-system",
   "description": "Generic task and worktree workflow system for Claude Code. Manage tasks as markdown files, work in isolated git worktrees, and track progress through the full lifecycle: create, start, continue, check, close.",
-  "version": "1.2.5",
+  "version": "1.3.0",
   "author": {
     "name": "gering"
   },

plugins/work-system/README.md

@@ -103,10 +103,12 @@ Creates a worktree, copies the task file, and shows how to open a new Claude ses
 
 ### 3. Continue in the worktree
 
+Open a new Claude session in the worktree — `-n` names the session, and the
+`/continue` initial prompt loads the task context in one step:
+
 ```
 cd .claude/worktrees/add-dark-mode
-claude
-> /continue
+claude -n "add-dark-mode" "/continue"
 ```
 
 Loads the task context, checks dependencies, and shows current progress.

plugins/work-system/skills/adopt/SKILL.md

@@ -124,10 +124,12 @@ The Bash tool persists CWD between calls — a bare `cd .claude/worktrees/<task>
        session — this session stays in the main repo) and run:
 
          cd .claude/worktrees/<task-name>
-         claude -n "<task-name>"
-         # then inside the new session:
-         /continue
+         claude -n "<task-name>" "/continue"
     ```
+    `-n "<task-name>"` names the session (shown in `/resume` and the terminal title);
+    the `/continue` initial prompt runs the resume flow (load TASK.md, recent commits,
+    progress) deterministically — both in one launch. Do **not** execute the `cd` yourself
+    — it is for the user's new terminal.
 
 ## Remember
 

plugins/work-system/skills/close/SKILL.md

@@ -79,8 +79,11 @@ Rules:
 
 9. **Delete remote branch** (if exists):
    - Run: `git ls-remote --heads origin task/<task-name>`
-   - If exists, ask: "Delete remote branch too?"
-   - If yes: `git push origin --delete task/<task-name>`
+   - **If a merged PR was confirmed in step 2**: delete it directly, no prompt —
+     `git push origin --delete task/<task-name>`. The merge already integrated the work,
+     so the remote branch is safe to remove.
+   - **If NO merged PR was found** (manual close): ask "Delete remote branch too?" first;
+     only push the delete on confirmation.
 
 10. **Remove task file** (use the main-repo path from step 4 — do not `cd`):
     - Run: `rm <main-repo-path>/tasks/<task-name>.md`

plugins/work-system/skills/continue/SKILL.md

@@ -26,8 +26,8 @@ user_invocable: true
      - Run: `git worktree list` to get main repo path (first entry)
      - Try to read from main repo's `tasks/<task-name>.md`
 
-3. **Install dependencies automatically**:
-   Auto-detect project type and install if dependencies are missing:
+3. **Install dependencies** (detect, then install):
+   Auto-detect the project type when dependencies appear to be missing:
 
    | Indicator | Missing check | Command |
    |-----------|--------------|---------|
@@ -39,10 +39,18 @@ user_invocable: true
    | `Gemfile.lock` | `vendor/bundle` missing | `bundle install` |
    | `go.sum` | — | `go mod download` |
    | `Cargo.lock` | `target` missing | `cargo build` |
-   | `requirements.txt` | `.venv` missing | `pip install -r requirements.txt` |
-
-   Only run if the indicator file exists AND the missing check directory is absent.
-   Run the install command automatically — do NOT ask, just run it and show the result.
+   | `requirements.txt` | `.venv` missing | `python -m venv .venv && .venv/bin/pip install -r requirements.txt` |
+
+   Only consider a command if the indicator file exists AND the missing-check directory is absent.
+
+   **Show the command, then run it.** Every command above installs into a project-local
+   location (`node_modules`, `target`, `vendor/bundle`, `.venv`, …), so it's safe to run
+   without asking — don't add friction. One hard rule:
+   - **Never install into the global/system environment.** For Python, always use the local
+     `.venv` form in the table — a bare `pip install` would pollute the user's global
+     site-packages. If a detected install can't be redirected to a project-local location
+     and would mutate the global/system environment, **show it and ask first** instead of
+     running it.
 
 4. **Load project context** (optional):
    - If `.claude/knowledge/` exists, query the Knowledge Agent: "What are the project patterns and architecture?"

plugins/work-system/skills/kickoff/SKILL.md

@@ -92,11 +92,12 @@ The same rule applies to any project-specific setup the user's `CLAUDE.md` may a
        session — this session stays in the main repo) and run:
 
          cd .claude/worktrees/<task-name>
-         claude
-         # then inside the new session:
-         /continue
+         claude -n "<task-name>" "/continue"
     ```
-    Do **not** execute the `cd` command yourself — it is for the user's new terminal.
+    `-n "<task-name>"` names the session (shown in `/resume` and the terminal title);
+    the `/continue` initial prompt runs the resume flow (load TASK.md, recent commits,
+    progress) deterministically — both in one launch. Do **not** execute the `cd` command
+    yourself — it is for the user's new terminal.
 
 ## Remember
 

plugins/work-system/skills/list/SKILL.md

@@ -14,36 +14,24 @@ user_invocable: true
 
 1. **Show active worktrees**:
    - Run: `git worktree list`
-   - Parse output and format nicely:
-   ```
-   📂 Active Worktrees:
-   ┌─────────────────────────────────────────────────────────┐
-   │ Main repo: /path/to/project (main)                     │
-   │ Worktree:  /path/to/project/.claude/worktrees/dark-mode  │
-   │            └─ Branch: task/dark-mode                    │
-   └─────────────────────────────────────────────────────────┘
-   ```
+   - Render as a markdown table under a `## 📂 Active Worktrees` heading:
+
+   | Type | Path | Branch |
+   |------|------|--------|
+   | Main | `/path/to/project` | `main` |
+   | Worktree | `…/.claude/worktrees/dark-mode` | `task/dark-mode` |
 
 2. **List pending tasks**:
    - Run: `ls -1 tasks/*.md 2>/dev/null`
    - For each task file, read first line (title)
    - Check if worktree/branch exists for it
-   ```
-   📋 Pending Tasks:
-   ┌──────────────────────────────────────────────────────────┐
-   │ 1. fix-calendar-bug.md                                  │
-   │    "Fix DST-related date shift in calendar view"        │
-   │    Status: 🔄 In Progress (worktree exists)             │
-   │                                                         │
-   │ 2. add-dark-mode.md                                     │
-   │    "Add dark mode toggle to settings"                   │
-   │    Status: 📋 Not Started                               │
-   │                                                         │
-   │ 3. refactor-notifications.md                            │
-   │    "Refactor notification scheduling"                   │
-   │    Status: 🔍 In Review (PR #45 open)                   │
-   └──────────────────────────────────────────────────────────┘
-   ```
+   - Render as a markdown table under a `## 📋 Tasks` heading:
+
+   | # | Task | Title | Status |
+   |---|------|-------|--------|
+   | 1 | `fix-calendar-bug` | Fix DST-related date shift in calendar view | 🔄 In Progress |
+   | 2 | `add-dark-mode` | Add dark mode toggle to settings | 📋 Not Started |
+   | 3 | `refactor-notifications` | Refactor notification scheduling | 🔍 In Review (PR #45) |
 
 3. **Check for open PRs** (if `gh` is available):
    - Run: `gh pr list --state open --json number,title,headRefName --limit 10`

plugins/work-system/skills/status/SKILL.md

@@ -30,34 +30,47 @@ user_invocable: true
      - Files mentioned
      - Key terms for searching
 
-3. **Search for evidence of completion**:
-
-   a) **Check for PRs** (if `gh` is available):
-   - Run: `gh pr list --state all --search "<task-name>" --limit 5 --json number,title,state,mergedAt,url`
-   - Show any matching PRs with status
-
-   b) **Check for branches**:
-   - Run: `git branch --all | grep -i "<task-name>"`
-   - Show existing branches
-
-   c) **Search commit history**:
+3. **Search for evidence of completion** — weight the signals: a) and b) are
+   authoritative, c) and d) are only weak corroboration (see step 4):
+
+   a) **Check for the task's PR** (if `gh` is available) — strongest signal:
+   - Primary, exact-branch match: `gh pr list --state all --head "task/<task-name>" --limit 5 --json number,title,state,mergedAt,url`
+   - Only if that returns nothing, fall back to a fuzzy search (may surface unrelated PRs):
+     `gh pr list --state all --search "<task-name>" --limit 5 --json number,title,state,mergedAt,url`
+   - Show matching PRs with status; a **merged** PR for `task/<task-name>` means completed.
+
+   b) **Check the task branch** — second-strongest signal:
+   - Run: `git branch --all --list "*task/<task-name>*"`
+   - If the branch is gone but a merged PR exists → completed and cleaned up.
+   - If the branch exists, check whether it merged into main:
+     `git branch --all --merged <main-branch> --list "*task/<task-name>*"`
+     (detect `<main-branch>` via `git symbolic-ref refs/remotes/origin/HEAD` → fallback `main`/`master`).
+
+   c) **Commit history** (weak signal — corroboration only, do not conclude from this alone):
    - Run: `git log --all --oneline --grep="<task-name>" | head -10`
-   - Also search for key terms from task file
+   - A task *name* appearing in a commit message is easy to produce by accident (a WIP
+     commit, an unrelated mention). Treat matches as supporting evidence behind a) and b),
+     never as proof of completion.
 
-   d) **Check mentioned files** (if task mentions specific files):
+   d) **Check mentioned files** (weak signal — if task mentions specific files):
    - Run: `git log --oneline -- <file-path> | head -5`
-   - Show recent changes to those files
+   - Recent changes show *activity*, not completion. Corroboration only.
 
 4. **Analyze and report**:
 
-   **Strong evidence (completed)**:
+   Decision rule: only conclude **COMPLETED** when an authoritative signal (3a or 3b)
+   confirms it — a merged PR for `task/<task-name>`, or the task branch merged into the
+   main branch. Commit-message or file-activity matches (3c/3d) on their own are *not*
+   enough; if they're the only signal, report IN PROGRESS / inconclusive instead.
+
+   **Strong evidence (completed)** — driven by 3a/3b:
    ```
    ✅ Task appears COMPLETED
 
    Evidence:
-   • PR #123 "Fix calendar bug" — MERGED (2024-01-15)
-   • Branch task/fix-calendar was merged and deleted
-   • 3 commits mention "calendar bug"
+   • PR #123 "Fix calendar bug" — MERGED (2026-01-15)   ← authoritative
+   • Branch task/fix-calendar merged into main, then deleted   ← authoritative
+   • (3 commits mention "calendar bug" — corroborating only)
 
    Recommendation: Delete task file with /close
    ```