@tianhai/pi-workflow-kit 0.18.1 → 1.1.0

package/docs/plans/2026-06-03-karpathy-guidelines-ab-comparison.md

@@ -1,166 +0,0 @@
-# A/B Comparison: Writing Plans — Karpathy Behavioral Guidelines
-
-## Setup
-- **Same design doc** (bookmarks: CRUD + search)
-- **Same Go project scaffold**
-- **Same prompt** (no questions, full plan with concrete code)
-- **Variant A** (WITHOUT guidelines): 292-line SKILL.md — original writing-plans skill
-- **Variant B** (WITH guidelines): 354-line SKILL.md — with Behavioral Guidelines section appended
-
----
-
-## Structural Comparison
-
-| Dimension | A (Without) | B (With) |
-|---|---|---|
-| **Total tasks** | 4 | 6 |
-| **Lines in plan** | ~1,054 | ~1,019 |
-| **New files per plan** | 7 files in Task 1 alone | 1-2 files per task |
-| **External dependency** | None (stdlib only) | `github.com/google/uuid` |
-
----
-
-## Task Decomposition
-
-### A (Without) — 4 tasks
-| Task | Scope | Files touched |
-|---|---|---|
-| 1 | Bookmark + ALL infrastructure (model, store interface, mem store with full CRUD, service, handler, errors, route, tests) | 7 files |
-| 2 | Delete bookmark | 3 files |
-| 3 | List bookmarks (paginated, cursor) | 3 files |
-| 4 | Search bookmarks (keyword + pagination) | 3 files |
-
-### B (With) — 6 tasks
-| Task | Scope | Files touched |
-|---|---|---|
-| 1 | Scaffold (go.mod + model only) | 2 files |
-| 2 | Bookmark a message (store + handler + test + route) | 4 files |
-| 3 | List bookmarks (offset/limit pagination) | 4 files |
-| 4 | Remove a bookmark | 4 files |
-| 5 | Search bookmarks (keyword) | 4 files |
-| 6 | Final wiring + integration lifecycle test | 2 files |
-
----
-
-## Detailed Analysis by Guideline
-
-### Simplicity First
-
-**A (Without):** ⚠️ **Overbuilt in Task 1.** Task 1 creates a `BookmarkStore` interface with 4 methods (Create, Delete, ListByUser, SearchByUser) — methods that won't be used until Tasks 2-4. It also creates the full `MemoryStore` implementation with all 4 methods, an `errors.go` file, a `Service` struct, AND the handler — all in a single task. The store interface is the full contract upfront before any task exercises most of it.
-
-**B (With):** ✅ **Minimal per task.** Task 1 only creates `go.mod` + the `Bookmark` struct. Task 2 introduces `Store` with only `Create`, and `MemStore` with only `Create`. `List` is added to the interface in Task 3, `Delete` in Task 4, `Search` in Task 5 — each method appears when it's needed, not before.
-
-**Verdict:** Guidelines had a clear positive effect. Plan B builds only what each task needs.
-
-### Surgical Changes
-
-**A (Without):** ⚠️ Task 1 touches 7 files in one go (model, store interface, store mem, errors, service, handler, main.go). The Task 1 description says "create the full vertical slice" which bundles infrastructure that isn't tested yet.
-
-**B (With):** ✅ Each task touches 1-2 files for new code. Task 1 creates 2 files (go.mod, model.go). Task 2 adds 3 new files + modifies main.go. No task creates more than 4 files.
-
-**Verdict:** Guidelines had a clear positive effect. Plan B has tighter blast radius per task.
-
-### Think Before Coding (surface assumptions)
-
-**A (Without):** ❌ Silent assumptions throughout:
-- Used cursor-based pagination without noting the design just said "paginated" — didn't surface that offset-based vs cursor-based is a choice
-- Added `sync.RWMutex` and concurrent safety without the design mentioning concurrency
-- Created a `Service` layer between handler and store without justification
-
-**B (With):** ⚠️ Still has assumptions but more defensible:
-- Used offset/limit pagination (simpler, matches "paginated" literally)
-- No concurrency concerns added (store uses `sync.Mutex` only, no RWMutex overhead)
-- No `Service` layer — handler calls store directly
-- Did add `github.com/google/uuid` dependency without asking — minor assumption
-
-**Verdict:** Marginal positive effect. Plan B is less presumptuous but both plans made assumptions. Neither explicitly surfaced tradeoffs to the user.
-
-### Goal-Driven Execution
-
-**A (Without):** ✅ Good acceptance criteria with Given/When/Then. Has a `checkpoint: test` on 3/4 tasks and `checkpoint: done` on the last task.
-
-**B (With):** ✅ Good acceptance criteria. Has `checkpoint: test` on 3 tasks, `checkpoint: done` on 1, and no checkpoint on 2 simpler tasks. Added a full lifecycle integration test in Task 6 that wasn't in A.
-
-**Verdict:** Roughly equivalent. Both plans have strong acceptance criteria (required by the base skill). The lifecycle test in B is a nice bonus that catches integration issues.
-
----
-
-## Unrelated Observations (noise, not guidelines)
-
-| Observation | A (Without) | B (With) |
-|---|---|---|
-| Pagination style | Cursor-based (more complex) | Offset-based (simpler) |
-| External deps | None | `google/uuid` |
-| Handler method naming | `Create`, `Delete`, `List`, `Search` | `CreateBookmark`, `DeleteBookmark`, `ListBookmarks`, `SearchBookmarks` |
-| Test structure | Single `TestXxx` with `t.Run` subtests | Separate top-level test functions |
-| `make([]T, 0, len)` usage | Yes (mem store candidates) | Yes (list handler, search handler) |
-
----
-
-## Overall Assessment
-
-| Guideline | Effect | Evidence |
-|---|---|---|
-| **Simplicity First** | ✅ Strong positive | B builds incrementally; A front-loads the full store interface |
-| **Surgical Changes** | ✅ Positive | B touches fewer files per task (1-4 vs 7 in Task 1) |
-| **Think Before Coding** | ⚠️ Marginal | B made fewer silent assumptions but neither surfaced tradeoffs explicitly |
-| **Goal-Driven Execution** | ≈ Neutral | Both strong; base skill already enforces acceptance criteria |
-
-**Bottom line (iteration 1):** The guidelines measurably improved the plan. The biggest win is **Simplicity First** — Plan B's incremental interface growth (adding methods to `Store` as each task needs them) is clearly better than Plan A's upfront full-contract approach. This is exactly the kind of thing "no abstractions for single-use code" catches.
-
-**Weakness:** Neither plan explicitly called out assumptions or asked clarifying questions — the "Think Before Coding" guideline had the weakest signal. The guidelines alone may not be enough to overcome the model's tendency to fill gaps silently.
-
----
-
-## Iteration 2: Revised Guidelines
-
-### What changed
-
-The guidelines were reworked from 4 generic coding rules to 3 planning-specific principles:
-
-| v1 (Generic) | v2 (Planning-Specific) | Why |
-|---|---|---|
-| Think Before Coding | **Surface Assumptions** | v1 said "ask" — the agent ignores this when told not to ask. v2 says "annotate in the plan" with a concrete `> **Assumption:** ...` format and examples of what to annotate. |
-| Simplicity First | **Build Only What Each Task Needs** | Kept the same core principle but added the specific anti-pattern from the v1 A/B test: "don't define interface methods that no task exercises yet." |
-| Surgical Changes | **One Task, One Change** | Reframed from "don't touch adjacent code" to "each task should trace to exactly one user-facing behavior" with a concrete guardrail (max 4 new files). |
-| Goal-Driven Execution | *(removed)* | Redundant — the base skill already enforces Given/When/Then acceptance criteria. |
-
-### Iteration 2 Plan (v2 guidelines) vs Iteration 1 Plans
-
-| Dimension | A (No guidelines) | B1 (v1 guidelines) | B2 (v2 guidelines) |
-|---|---|---|---|
-| **Total tasks** | 4 | 6 | 4 |
-| **Max files/task** | 7 (Task 1) | 4 | 4 |
-| **Assumptions annotated** | 0 | 0 | **4** (header below) |
-| **External deps** | None | `google/uuid` | None |
-| **Store interface** | 4 methods upfront in Task 1 | 1 method per task | 1 method per task |
-| **Service layer** | Yes (unjustified) | No | No |
-
-### The big win: Surface Assumptions
-
-Plan B2 opens with four explicit assumption annotations:
-
-```
-> **Assumption:** User identification via X-User-ID request header since
-> no auth system exists in the project.
-
-> **Assumption:** Bookmarks include a Note field so users can annotate
-> bookmarks. The design says "search by keyword" but doesn't specify
-> the field.
-
-> **Assumption:** Offset/limit pagination (not cursor-based).
-
-> **Assumption:** In-memory store behind a Store interface.
-```
-
-None of the previous plans (A or B1) did this. The v1 "Think Before Coding" guideline was completely invisible in output. The v2 "Surface Assumptions" guideline produced visible, reviewable annotations on the first run.
-
-### Iteration 2 Assessment
-
-| Guideline | v1 Effect | v2 Effect | Improvement |
-|---|---|---|---|
-| **Surface Assumptions** (was Think Before Coding) | ⚠️ Invisible | ✅ 4 explicit annotations | Complete turnaround — concrete format + examples fixed the weakest signal |
-| **Build Only What's Needed** (was Simplicity First) | ✅ Strong | ✅ Strong | Maintained — interface still grows incrementally |
-| **One Task, One Change** (was Surgical Changes) | ✅ Positive | ✅ Positive | Maintained — max 4 files/task |
-
-**Bottom line (iteration 2):** The v2 guidelines fixed the weakest signal from v1. "Surface Assumptions" went from invisible to producing 4 explicit, reviewable annotations. The other two principles maintained their positive effect. The removal of "Goal-Driven Execution" (redundant) reduced noise without losing signal.

package/docs/plans/completed/2026-04-11-checkpoint-review-gates-design.md

@@ -1,50 +0,0 @@
-# Checkpoint Review Gates for Task Execution
-
-## Problem
-
-Executing-tasks runs through tasks without pausing. There's no way for the human to review tests before implementation, or review implementation before committing. The TDD labels in plans are advisory, not enforceable. There's no configuration for review gates.
-
-## Design
-
-Add optional `checkpoint` labels to individual tasks in the implementation plan. Executing-tasks pauses at checkpoint boundaries for human review.
-
-## Checkpoint labels
-
-Each task can optionally include a `checkpoint` label:
-
-- **`checkpoint: test`** — pause after writing the failing test, before implementing
-- **`checkpoint: done`** — pause after implementation + tests pass, before committing
-- **No label** — auto-advance, no pause
-
-The label is orthogonal to the TDD scenario. A "new feature" task with `checkpoint: test` means: write failing test → pause → implement → run tests → commit. Without a checkpoint, the same task flows straight through.
-
-## Who sets checkpoints
-
-The agent decides which tasks get checkpoints during plan writing, based on complexity and risk. The user reviews the plan before execution and can add, remove, or change checkpoints.
-
-## Changes
-
-### writing-plans/SKILL.md
-
-Add `checkpoint` as an optional field in the task format section, with the two values and the "no label means auto-advance" rule. Update the TDD table to show how checkpoints interact with each scenario. Add guidance for the agent on when to use each checkpoint value.
-
-### executing-tasks/SKILL.md
-
-Update the per-task lifecycle to handle checkpoints:
-
-- **No checkpoint** — existing flow unchanged
-- **`checkpoint: test`** — write failing test → show diff → pause for review → proceed based on human input → implement → run tests → fix if needed → commit
-- **`checkpoint: done`** — implement → run tests → fix if needed → show diff → pause for review → proceed based on human input → commit
-
-The pause is a simple conversation stop — the agent shows what was done and the diff, then waits. The human can say anything: change the test, tweak the implementation, approve, revert, adjust the plan. No rigid menu.
-
-Pause message format:
-
-```
-⏸ Paused at checkpoint: [test|done] for task [N]
-
-**What was done:** [brief summary]
-**Diff:** [show relevant diff]
-
-Review and let me know how to proceed.
-```

package/docs/plans/completed/2026-04-11-checkpoint-review-gates-implementation.md

@@ -1,98 +0,0 @@
-# Checkpoint Review Gates: Implementation Plan
-
-## Tasks
-
-### Task 1: Update writing-plans/SKILL.md — add checkpoint field and agent guidance
-
-**Scenario:** Trivial (docs)
-
-**File:** `skills/writing-plans/SKILL.md`
-
-Add a "Checkpoint labels" section after "TDD in the plan" with the optional `checkpoint` field, values, and agent guidance. Also update the TDD table to show how checkpoints interact with each scenario.
-
-After the "TDD in the plan" section, add:
-
-```
-## Checkpoint labels
-
-Optionally label each task with a `checkpoint` to require human review before proceeding:
-
-| Checkpoint | When to use | What happens during execution |
-|---|---|---|
-| *(none)* | Trivial tasks, well-understood changes | Auto-advance, no pause |
-| **`checkpoint: test`** | Test design matters (API contracts, edge cases, complex behavior) | Pause after writing the failing test, before implementing |
-| **`checkpoint: done`** | Implementation review matters (complex logic, security, performance) | Pause after implementation + tests pass, before committing |
-
-Use judgment when assigning checkpoints. Prefer `checkpoint: test` for new features with non-obvious test design. Prefer `checkpoint: done` for tasks where the implementation approach is debatable. Most tasks should not need a checkpoint. The user can adjust checkpoints when reviewing the plan.
-```
-
-Also update the "Task format" section — after the `git commit` bullet, add:
-
-```
-- Optional `checkpoint: test` or `checkpoint: done` label
-```
-
-**Commit:** `feat(writing-plans): add checkpoint labels for review gates`
-
-### Task 2: Update executing-tasks/SKILL.md — handle checkpoints in per-task lifecycle
-
-**Scenario:** Trivial (docs)
-
-**File:** `skills/executing-tasks/SKILL.md`
-
-Replace the "Per-task lifecycle" section with checkpoint-aware flows. Add a "Checkpoint review" section.
-
-Replace the existing "Per-task lifecycle" section with:
-
-```
-## Per-task lifecycle
-
-Check each task for a `checkpoint` label and follow the appropriate flow:
-
-### No checkpoint (auto-advance)
-
-1. **Implement** — write the code as described in the plan
-2. **Run tests** — verify the changes work
-3. **Fix if needed** — if tests fail, debug and fix before moving on
-4. **Commit** — `git add` the relevant files and commit with a clear message
-
-### checkpoint: test
-
-1. **Write the test** — follow the TDD scenario for the task
-2. **Pause for review** — show what was done and the diff, then wait for human input
-3. **Continue** — implement, run tests, fix if needed
-4. **Commit** — `git add` the relevant files and commit with a clear message
-
-### checkpoint: done
-
-1. **Implement** — write the code as described in the plan
-2. **Run tests** — verify the changes work
-3. **Fix if needed** — if tests fail, debug and fix before moving on
-4. **Pause for review** — show what was done and the diff, then wait for human input
-5. **Commit** — `git add` the relevant files and commit with a clear message
-```
-
-After the "TDD discipline" section, add:
-
-```
-## Checkpoint review
-
-When pausing at a checkpoint, present:
-
-```
-⏸ Paused at checkpoint: [test|done] for task [N]
-
-**What was done:** [brief summary]
-**Diff:** [show relevant diff]
-
-Review and let me know how to proceed.
-```
-
-Wait for the human to respond. They may:
-- Approve and continue
-- Request changes to the test or implementation
-- Ask to revert the task
-- Adjust the remaining plan
-```
-
-**Commit:** `feat(executing-tasks): add checkpoint review gates`

package/docs/plans/completed/2026-04-11-finalizing-merge-options-design.md

@@ -1,33 +0,0 @@
-# Finalizing: Merge Strategy Options
-
-## Problem
-
-The finalizing skill hard-codes "Create PR" as the only shipping option. In practice, small features often don't need a PR — they can be merged directly back to the parent branch.
-
-## Design
-
-Add a merge strategy step after updating documentation. The human chooses one of four options:
-
-1. **Create PR** — push and open a PR for external review via `gh pr create`
-2. **Rebase & merge** (recommended) — rebase onto parent, fast-forward merge, push parent, delete feature branch. Preserves per-task commit history linearly.
-3. **Squash & merge** — squash all commits into one on parent, push parent, delete feature branch. Clean single-commit history.
-4. **Merge commit** — merge with `--no-ff`, push parent, delete feature branch. Preserves all commits and branch topology.
-
-### Flow for options 2–4 (local merge)
-
-1. Detect parent branch (compare `main` vs `master`, fall back to `git show-branch`)
-2. Switch to parent branch and pull latest
-3. Execute the chosen merge strategy:
-   - Rebase: `git rebase <parent>` on feature branch, then `git merge --ff-only <feature>` on parent
-   - Squash: `git merge --squash <feature>` on parent, then `git commit`
-   - Merge commit: `git merge --no-ff <feature>` on parent
-4. Push parent to origin
-5. Delete feature branch locally and remotely
-
-### Prompting
-
-The skill should ask the human which option they prefer, presenting rebase & merge as the default recommendation.
-
-## Changes
-
-- Update `skills/finalizing/SKILL.md` to replace the hard-coded PR step with the 4-option choice.

package/docs/plans/completed/2026-04-11-finalizing-merge-options-implementation.md

@@ -1,75 +0,0 @@
-# Finalizing: Merge Strategy Options — Implementation Plan
-
-## Context
-
-Replace the hard-coded "Create PR" step in the finalizing skill with a 4-option merge strategy prompt (Create PR, Rebase & merge, Squash & merge, Merge commit).
-
-Design doc: `docs/plans/2026-04-11-finalizing-merge-options-design.md`
-
----
-
-## Task 1 — Replace the PR step with a merge strategy prompt
-
-**TDD scenario:** Trivial (skill docs, no code to test)
-
-**File:** `skills/finalizing/SKILL.md`
-
-Replace step 3 ("Create PR") and step 4 ("Clean up") with the new merge strategy section. Keep steps 1 and 2 unchanged.
-
-**New content for step 3 onwards:**
-
-```markdown
-3. **Choose a merge strategy** — ask the human which option they prefer:
-
-   1. **Create PR** — push and open a PR for external review:
-      ```
-      git push origin <branch>
-      gh pr create --title "feat: <summary>" --body "<task summary>"
-      ```
-
-   2. **Rebase & merge** *(recommended)* — rebase onto parent, fast-forward merge, push parent, delete branch:
-      ```
-      parent=$(git show-branch -a 2>/dev/null | grep '\*' | grep -v "$(git branch --show-current)" | head -1 | sed 's/.*\[\(.*\)\].*/\1/' | sed 's/[\^~].*//')
-      git checkout "$parent" && git pull
-      git checkout - && git rebase "$parent"
-      git checkout "$parent" && git merge --ff-only -
-      git push origin "$parent"
-      git branch -d - && git push origin --delete -
-      ```
-
-   3. **Squash & merge** — squash all commits into one on parent, push parent, delete branch:
-      ```
-      parent=$(git show-branch -a 2>/dev/null | grep '\*' | grep -v "$(git branch --show-current)" | head -1 | sed 's/.*\[\(.*\)\].*/\1/' | sed 's/[\^~].*//')
-      git checkout "$parent" && git pull
-      git merge --squash -
-      git commit -m "feat: <summary>"
-      git push origin "$parent"
-      git branch -d - && git push origin --delete -
-      ```
-
-   4. **Merge commit** — merge with `--no-ff`, push parent, delete branch:
-      ```
-      parent=$(git show-branch -a 2>/dev/null | grep '\*' | grep -v "$(git branch --show-current)" | head -1 | sed 's/.*\[\(.*\)\].*/\1/' | sed 's/[\^~].*//')
-      git checkout "$parent" && git pull
-      git merge --no-ff -m "Merge branch '<branch>'" -
-      git push origin "$parent"
-      git branch -d - && git push origin --delete -
-      ```
-
-   For options 2–4, confirm the detected parent branch with the human before proceeding.
-
-4. **Clean up** — if a worktree was used, remove it:
-   ```
-   git worktree remove ../<repo>-<feature-name>
-   ```
-```
-
-**Commit:** `feat: add merge strategy options to finalizing skill`
-
----
-
-## Done
-
-The finalizing skill now offers four merge strategies instead of only "Create PR". No code files changed — this is a skill-documentation update only.
-
-To verify: read `skills/finalizing/SKILL.md` and confirm it contains all four options with correct commands.

package/docs/plans/completed/2026-04-11-workspace-setup-design.md

@@ -1,28 +0,0 @@
-# Workspace Setup: Move Branch Creation to Brainstorming
-
-## Problem
-
-Brainstorming commits the design doc to whatever branch you're on (usually `main`), polluting it. If the idea is scrapped, you have to revert the commit. The implementation branch created later by writing-plans starts from a point after the design commit, which is messy.
-
-## Design
-
-Move branch/worktree creation from writing-plans into brainstorming. The design doc lands on the feature branch from the start, keeping `main` clean.
-
-## Changes
-
-### brainstorming/SKILL.md
-
-Step 5 changes from writing + committing the design doc on the current branch to:
-
-1. Create a feature branch (`git checkout -b <feature-name>`) or worktree (`git worktree add ../<repo>-<feature-name> -b <feature-name>`) for larger features
-2. Write the design doc to `docs/plans/YYYY-MM-DD-<topic>-design.md`
-3. Single commit on the new branch with the design doc
-
-Feature name is derived from the topic slug in the design doc filename.
-
-### writing-plans/SKILL.md
-
-- Remove step 2 ("Set up workspace") entirely
-- Step 1 expands to verify the feature branch/worktree context created by brainstorming
-- Steps renumber: 1→2→3 becomes 1→2
-- Fallback path (no design doc, brainstorming was skipped) still creates a branch itself so writing-plans works standalone

package/docs/plans/completed/2026-04-11-workspace-setup-implementation.md

@@ -1,57 +0,0 @@
-# Workspace Setup: Implementation Plan
-
-## Tasks
-
-### Task 1: Update brainstorming/SKILL.md — add workspace setup to step 5
-
-**Scenario:** Trivial (docs)
-
-Replace step 5 with workspace creation + design doc commit.
-
-**File:** `skills/brainstorming/SKILL.md`
-
-Replace:
-
-```
-5. **Write the design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit.
-```
-
-With:
-
-```
-5. **Set up workspace & write the design doc** — create a branch for this work. For larger features, use a git worktree for isolation:
-   ```
-   git worktree add ../<repo>-<feature-name> -b <feature-name>
-   ```
-   Save the design doc to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit on the new branch.
-```
-
-**Commit:** `refactor(brainstorming): move workspace setup into step 5`
-
-### Task 2: Update writing-plans/SKILL.md — remove step 2, expand step 1
-
-**Scenario:** Trivial (docs)
-
-Remove step 2 ("Set up workspace") entirely. Expand step 1 to verify the feature branch context. Renumber step 3 → 2.
-
-**File:** `skills/writing-plans/SKILL.md`
-
-Replace:
-
-```
-1. **Check for a design doc** — look for `docs/plans/*-design.md`. If one exists, use it as the basis for the plan. If none exists, ask the user to describe what they want to build, read relevant code, and create the plan directly.
-2. **Set up workspace** — create a branch for this work. For larger features, use a git worktree for isolation:
-   ```
-   git worktree add ../<repo>-<feature-name> -b <feature-name>
-   ```
-3. **Write the implementation plan** — break the design into tasks. Save to `docs/plans/YYYY-MM-DD-<topic>-implementation.md`.
-```
-
-With:
-
-```
-1. **Check for a design doc & workspace** — look for `docs/plans/*-design.md`. If one exists, use it as the basis for the plan. Verify you're on the feature branch (or in its worktree) created during brainstorming. If no design doc exists, ask the user to describe what they want to build, read relevant code, create a branch, and create the plan directly.
-2. **Write the implementation plan** — break the design into tasks. Save to `docs/plans/YYYY-MM-DD-<topic>-implementation.md`.
-```
-
-**Commit:** `refactor(writing-plans): remove workspace setup, verify branch context`

package/docs/plans/completed/2026-04-15-bash-guard-design.md

@@ -1,39 +0,0 @@
-# Bash Guard for Workflow Guard Extension
-
-## Problem
-
-`workflow-guard.ts` blocks `write`/`edit` outside `docs/plans/` during brainstorm and plan phases, but ignores `bash` entirely. The LLM can mutate files via bash (e.g. `echo "..." > file.ts`, `sed -i`, `tee`, heredocs).
-
-## Design
-
-Adopt the `isSafeCommand()` approach from [pi-mono plan-mode example](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/examples/extensions/plan-mode/utils.ts).
-
-### Approach
-
-**No changes to `pi.setActiveTools()`** — `write`/`edit` remain active so the existing path-based `tool_call` guard continues to allow writes to `docs/plans/`.
-
-**Add a bash guard** in the existing `tool_call` handler using `isSafeCommand()`:
-- Copy SAFE_PATTERNS and DESTRUCTIVE_PATTERNS from the example's `utils.ts` as-is
-- Copy `isSafeCommand()` logic as-is
-- In the `tool_call` handler, when phase is set and tool is `bash`, check `isSafeCommand(event.input.command)`
-- Block with reason if not safe
-- Notify via `ctx.ui.notify()` when blocking
-
-### Changes
-
-1. **`extensions/workflow-guard.ts`**
-   - Add `isSafeCommand()` function (copied from example, with DESTRUCTIVE_PATTERNS and SAFE_PATTERNS)
-   - Extend `tool_call` handler to also intercept `bash` when phase is set
-   - Check `event.input.command` against `isSafeCommand()`
-   - Block and notify if unsafe
-
-2. **`tests/workflow-guard.test.ts`**
-   - Add tests for bash guard: safe commands pass, destructive commands blocked, redirects blocked
-   - Import and test `isSafeCommand` directly (it's a pure function, easy to unit test)
-
-### What stays the same
-
-- Phase detection via `/skill:` commands (no change)
-- `write`/`edit` path-based blocking for `docs/plans/` (no change)
-- `docs/plans/` write exception (no change)
-- No `pi.setActiveTools()` usage