pi-workflow-engine 0.5.0 → 0.6.1

package/README.md

@@ -65,7 +65,11 @@ In a pi session, from inside a git repo with changes:
 /workflow refactor-scout src/    # find safe refactor opportunities
 /workflow diagnose "typecheck fails after the schema change"
 /workflow perf-review "workflow startup latency"
-/workflow code-review --inspect  # open the live workflow inspector
+/workflow code-review --inspect  # open the live workflow inspector while the run is active
+/workflow:inspector              # reopen the last completed workflow inspector
+/workflow code-review --result-viewer     # explicitly open the post-review results viewer
+/workflow code-review --review-viewer     # alias for --result-viewer
+/workflow code-review --no-result-viewer  # explicitly keep the post-review viewer closed
 ```
 
 The host agent can also invoke the `workflow` tool mid-conversation. It accepts either a registered workflow `name` or a one-off inline workflow `script`:
@@ -78,15 +82,17 @@ Opt into dynamic multi-agent orchestration with the literal `dynamax` token, or
 
 ```text
 dynamax inspect this bug with multiple focused agents
-/dynamax on
-/dynamax status
-/dynamax off
+/workflow:dynamax on
+/workflow:dynamax status
+/workflow:dynamax off
 ```
 
 `dynamax` is a permission signal for the host agent: once opted in, it may run an existing named workflow or author an inline workflow script through the `workflow` tool. In interactive mode, `/workflow` with no arguments also offers `✍ Author temporary one-shot workflow…`; choose it, type a brief, and pi will ask the host agent to author/run a temporary inline workflow.
 
 The advisory workflows inspect and report only; they do not edit files. They return the same shape: summary, ranked findings, evidence, impact, recommendations, and next steps.
 
+The package also ships the `workflow-code-review-actions` skill. When you select review findings in the results viewer, the parent agent can use that skill to either make minimal local fixes or raise GitHub PR inline comments through GitHub MCP/tools or `gh`.
+
 ## Built-in workflows
 
 - `code-review`: Reviews the current branch, open PR, ref range, or target. It looks for correctness bugs and cleanup issues, then independently verifies candidates before ranking them.
@@ -104,6 +110,22 @@ The bundled review workflow is deliberately shaped like a serious review process
 4. **Verify**: send each survivor to an independent verifier that must confirm, mark plausible, or refute with evidence.
 5. **Synthesize**: produce one ranked report with stats, verdicts, and concrete locations.
 
+After a direct TUI `/workflow code-review` run produces findings, pi records a readable table-formatted result message without asking whether to open another surface. Use `--result-viewer`/`--review-viewer` when you want the interactive findings viewer to open immediately, or `--no-result-viewer`/`--no-review-viewer` when a script or alias should explicitly keep it closed. Use `/workflow:inspector` after a run to reopen the last completed workflow inspector.
+
+Viewer controls:
+
+- `↑`/`↓`: move between findings.
+- `1`-`9`: jump directly to a visible finding.
+- `space`: tag/untag the current finding.
+- `a`: tag or untag all visible findings.
+- `enter`: expand/collapse the detail pane.
+- `←`/`→` or `pageup`/`pagedown`: scroll detail text.
+- `f`: hand selected findings to the parent agent for minimal local fixes.
+- `c`: comment on selected findings upstream.
+- `q`/`escape`: close the viewer.
+
+GitHub inline comments require a GitHub PR checkout, an authenticated `gh`, and findings with changed-file line numbers. If direct PR context resolution or posting is unavailable, the viewer queues a parent-agent fallback prompt that can use installed GitHub MCP/tools, project skills, or `gh`. Workflow tool invocations remain non-interactive: they do not prompt or open the viewer, and they return table-formatted results only.
+
 The review lenses live in `.pi/extensions/pi-workflow-engine/workflows/code-review.ts`. That is where your repo's real failure modes belong.
 
 ## Authoring workflows
@@ -172,7 +194,7 @@ Under the hood:
 - **Each `agent()` is an in-process pi `AgentSession`** using `createAgentSession` and `SessionManager.inMemory()`.
 - **Structured output is a terminating tool**. The engine registers one tool whose `parameters` is your schema; pi validates the call and the engine captures the args. There is no JSON scraping.
 - **A single global semaphore caps concurrent agents**, so `parallel` and `pipeline` can nest freely while every `agent()` call still respects the run cap.
-- **Three surfaces are registered**: `/workflow <name> [args]` for direct use, `/dynamax on|off|status` for sticky orchestration opt-in, and a `workflow` tool for host-agent delegation by `name` or inline `script`.
+- **Three surfaces are registered**: `/workflow <name> [args]` for direct use, grouped workflow commands such as `/workflow:dynamax on|off|status` and `/workflow:inspector`, and a `workflow` tool for host-agent delegation by `name` or inline `script`.
 
 ## Local development
 

package/USAGE.md

@@ -3,7 +3,8 @@
 `pi-workflow-engine` adds multi-agent workflows to pi. Most users only need two surfaces:
 
 - `/workflow <name> [args]` to run a saved workflow directly.
-- `dynamax` when you want the host agent to author a one-off inline workflow for investigation/review.
+- `/workflow:*` commands for related actions such as inspector reopening and dynamax sticky mode.
+- `dynamax` as a literal one-shot opt-in token when you want the host agent to author a one-off inline workflow for investigation/review.
 
 ## Run a workflow
 
@@ -22,7 +23,10 @@ The built-in workflows are advisory. They inspect, verify, and report; they do *
 Useful flags:
 
 ```text
-/workflow code-review --inspect          # show live inspector
+/workflow code-review --inspect          # show the live inspector while the run is active
+/workflow:inspector                      # reopen the last completed workflow inspector
+/workflow code-review --result-viewer    # explicitly open the findings viewer
+/workflow code-review --review-viewer    # alias for --result-viewer
 /workflow code-review --concurrency=4    # cap concurrent subagents
 /workflow code-review --refresh          # rediscover newly added workflow files
 ```
@@ -57,9 +61,9 @@ dynamax use parallel agents to review this design and report the risks
 Sticky for the session:
 
 ```text
-/dynamax on
-/dynamax off
-/dynamax status
+/workflow:dynamax on
+/workflow:dynamax off
+/workflow:dynamax status
 ```
 
 With dynamax enabled, the host agent usually calls the `workflow` tool with `script`: a one-off inline workflow. It can still call a saved workflow by `name` when one already fits.
@@ -75,7 +79,9 @@ Workflow results are rendered in pi with:
 - next steps;
 - run stats when available.
 
-During a run, pi shows live phases and subagent status. Use `--inspect` if you want a larger live view.
+During a run, pi shows live phases and subagent status. Use `--inspect` if you want a larger live view while the workflow is active, then `/workflow:inspector` if you want to bring the last completed inspector back up afterward.
+
+Code-review findings are rendered as a formatted result message by default. pi no longer asks whether to open the findings viewer. Use `--result-viewer` or `--review-viewer` when you want to inspect findings interactively, press `enter` to expand/collapse the nicely formatted finding text, and use `1`-`9` to jump directly to a visible finding.
 
 ## Author a saved workflow
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-workflow-engine",
-  "version": "0.5.0",
+  "version": "0.6.1",
   "type": "module",
   "description": "A customisable multi-agent workflow-orchestration engine for the pi coding agent.",
   "keywords": [
@@ -24,12 +24,14 @@
     ".pi/extensions/pi-workflow-engine",
     ".pi/settings.json",
     "assets",
+    "skills",
     "README.md",
     "USAGE.md",
     "LICENSE"
   ],
   "pi": {
     "extensions": [".pi/extensions/pi-workflow-engine/index.ts"],
+    "skills": ["skills"],
     "image": "https://raw.githubusercontent.com/timbrinded/pi-workflow-engine/master/assets/preview.png"
   },
   "scripts": {

package/skills/workflow-code-review-actions/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: workflow-code-review-actions
+description: "Act on selected code-review findings from pi-workflow-engine: make minimal fixes or post GitHub PR inline comments using gh, GitHub MCP/tools, or project-specific tools."
+---
+
+Use this skill when the parent agent receives selected code-review finding JSON from `pi-workflow-engine`.
+
+## Inputs
+
+The prompt will include compact JSON with:
+
+- `context`: workflow name, target, diff command, changed files, and optional summary.
+- `issues`: selected findings with `id`, `summary`, `category`, `severity`, `confidence`, `location`, `impact`, `evidence`, and `recommendation`.
+
+## Fix mode
+
+When mode is `fix selected code-review findings`:
+
+1. Inspect the selected issue JSON before editing.
+2. Make minimal edits that address only the selected findings.
+3. Preserve unrelated user changes and avoid broad refactors.
+4. Run focused validation if available for the touched files or behavior.
+5. Summarize changed files and validation results.
+6. Do not post GitHub PR comments in fix mode.
+
+## Comment mode
+
+When mode is `post inline GitHub PR comments`:
+
+1. Do not edit files or make code changes.
+2. Prefer installed GitHub MCP/tools if visible in the active tool list.
+3. If no GitHub MCP/tools are available, use `gh`:
+   - Resolve the PR with `gh pr view --json number,headRefOid,url,headRepositoryOwner,headRepository`.
+   - Resolve the repository with `gh repo view --json nameWithOwner` when owner/name is missing.
+   - Post each inline comment with `gh api repos/{owner}/{repo}/pulls/{number}/comments` and include `commit_id`, `path`, `line`, and `side=RIGHT`.
+4. Keep each comment concise: summary, severity/confidence/category, impact, evidence, and recommendation.
+5. Report posted, skipped, and failed counts.
+
+## Safety rules
+
+- Do not post duplicate comments.
+- Do not comment line-less findings inline.
+- Ask the user if the upstream PR cannot be identified.
+- Keep actions scoped to the selected issue IDs only.