@tianhai/pi-workflow-kit 0.8.0 → 0.8.1

package/extensions/workflow-guard.ts

@@ -101,10 +101,27 @@ const SAFE_PATTERNS = [
 	/^\s*eza\b/,
 ];
 
+/** Split a compound command into individual sub-commands.
+ * Handles &&, ||, ;, and | (pipe) operators, ignoring leading whitespace.
+ */
+function splitCompoundCommand(command: string): string[] {
+	// Match sub-commands separated by &&, ||, ; (with optional whitespace)
+	// We don't split on | to allow piping (e.g. `git log | head`)
+	return command
+		.split(/&&|\|\||;/)
+		.map((s) => s.trim())
+		.filter((s) => s.length > 0);
+}
+
 export function isSafeCommand(command: string): boolean {
-	const isDestructive = DESTRUCTIVE_PATTERNS.some((p) => p.test(command));
-	const isSafe = SAFE_PATTERNS.some((p) => p.test(command));
-	return !isDestructive && isSafe;
+	const parts = splitCompoundCommand(command);
+	return parts.every(
+		(part) => {
+			const isDestructive = DESTRUCTIVE_PATTERNS.some((p) => p.test(part));
+			const isSafe = SAFE_PATTERNS.some((p) => p.test(part));
+			return !isDestructive && isSafe;
+		},
+	);
 }
 
 const SKILL_TO_PHASE: Record<string, Phase> = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tianhai/pi-workflow-kit",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "Workflow skills and enforcement extensions for pi",
   "keywords": [
     "pi-package"

package/skills/brainstorming/SKILL.md

@@ -13,11 +13,7 @@ Read-only exploration. You may **not** edit or create any files except under `do
 2. **Understand the idea** — read existing code, docs, and recent commits. Ask questions one at a time to refine the idea. Prefer multiple choice when possible.
 3. **Explore approaches** — propose 2-3 approaches with trade-offs. Lead with your recommendation.
 4. **Present the design** — break it into sections of 200-300 words. Check after each section whether it looks right. Cover: architecture, components, data flow, error handling, testing.
-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.
+5. **Write the design doc** — save it to `docs/plans/YYYY-MM-DD-<topic>-design.md`. Ask the user to commit it. Branch creation and worktree setup should be deferred to the execution phase (`/skill:executing-tasks`).
 
 ## Principles
 

package/skills/executing-tasks/SKILL.md

@@ -7,6 +7,27 @@ description: "Use this to implement an approved plan task-by-task. Run after wri
 
 Implement the plan from `docs/plans/*-implementation.md` task by task.
 
+## Before you start
+
+1. **Check git state** — run `git status` and `git log --oneline -5`. Note any uncommitted changes.
+2. **Suggest workspace isolation** — if the user isn't already on a feature branch or worktree, present the options:
+
+   - **Branch** (smaller changes):
+     ```
+     git checkout -b <feature-name>
+     ```
+   - **Worktree** (larger features, keeps main clean):
+     ```
+     git worktree add ../<repo>-<feature-name> -b <feature-name>
+     ```
+
+   Derive `<feature-name>` from the plan doc (e.g. `docs/plans/2026-04-16-auth-design.md` → `auth`). Ask the user which they prefer, then wait for confirmation before proceeding.
+
+3. **Commit the plan docs** — if `docs/plans/` has uncommitted files, commit them on the new branch:
+   ```
+   git add docs/plans/ && git commit -m "docs: add design and implementation plan"
+   ```
+
 ## Per-task lifecycle
 
 Check each task for a `checkpoint` label and follow the appropriate flow:

package/skills/writing-plans/SKILL.md

@@ -9,7 +9,7 @@ Read-only exploration. You may **not** edit or create any files except under `do
 
 ## Process
 
-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.
+1. **Check for a design doc** — look for `docs/plans/*-design.md`. If one exists, use it as the basis for the plan. If no design doc exists, ask the user to describe what they want to build and read relevant code.
 2. **Write the implementation plan** — break the design into tasks. Save to `docs/plans/YYYY-MM-DD-<topic>-implementation.md`.
 
 ## Task format