@lebronj/pi-suite 0.1.9 → 0.1.10

package/README.md

@@ -21,7 +21,7 @@ curl -fsSL https://registry.npmjs.org/@lebronj/pi-suite/-/pi-suite-0.1.8.tgz | t
 ## What Is Included
 
 - Local extensions: goal mode, pet, prompt URL widget, TUI redraw stats, snake, TPS notifications.
-- Prompts: changelog audit, issue analysis, PR review, wrap workflow.
+- Prompts: changelog audit, issue analysis, PR review, review workflow, commit workflow, wrap workflow.
 - Skills: provider checklist, weather, LeetCode array practice, Pi capability reference, image-to-editable-PPT workflow.
 - Vendored package: `@jhp/pi-memory`, including qmd search, external curator service, and memory/skill-draft versioning.
 
@@ -81,6 +81,14 @@ Useful commands:
 
 Memory evolution is local-only by default and does not configure a shared remote. If a user wants backup sync, set `PI_EVOLUTION_REMOTE` to their own private repo before bootstrap/setup, or add a personal remote later with `git -C ~/.pi/agent/evolution remote add origin <url>`. Set `PI_EVOLUTION_AUTO_PUSH=1` only if automatic remote sync is desired.
 
+## Review And Commit Workflows
+
+Use `/review [target] [--fix] [--comment] [--summary]` to inspect current diffs, branch ranges, or PRs with findings first and a verdict last. It is local-only by default: GitHub comments are drafted first and posted only after explicit confirmation.
+
+Use `/commit [message|split|pr|apply]` to inspect current changes, warn about mixed concerns, draft commit messages, suggest split points, or draft PR text. It does not stage, commit, or push unless you explicitly confirm the exact action.
+
+These workflows are prompt-template workflows only. They do not merge read behavior, add tool discovery, rewrite memory/skills, or run as hidden background processes.
+
 ## Goal Mode
 
 Use `/goal <objective>` to keep Pi working on one task until it is verified complete. Goal mode injects hidden task context, enables a `goal` tool for completion/drop/resume, and auto-continues between turns instead of stopping at a minimal implementation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lebronj/pi-suite",
-  "version": "0.1.9",
+  "version": "0.1.10",
   "description": "JHP's Pi extension suite for team coding workflows",
   "type": "module",
   "keywords": [

package/prompts/commit.md

@@ -0,0 +1,83 @@
+---
+description: Draft commit messages, split advice, and PR text without side effects
+argument-hint: "[message|split|pr|apply] [scope]"
+---
+Run the `/commit` workflow for: $ARGUMENTS
+
+Scope and guardrails:
+- This workflow is only for commit planning, commit message drafting, split advice, PR description drafting, and explicitly confirmed commit execution.
+- Do not change core read behavior, do not introduce unified resource reads, and do not use or build tool discovery.
+- Default to local-only analysis. Do not create commits, push, or update remote PR text unless I explicitly confirm the exact action after seeing the draft or plan.
+- Do not rewrite memory or skills as part of this workflow.
+- Never stage unrelated files. Never use `git add .` or `git add -A`.
+
+Default behavior:
+1. Inspect `git status --short --branch`.
+2. Inspect staged and unstaged diffs for the requested scope.
+3. Detect mixed concerns before drafting any final commit plan.
+4. Draft commit messages and PR text in plain language.
+5. Keep execution separate from suggestions.
+
+Mode handling:
+- No mode or `message`: summarize the current changes and draft one commit message. If changes are mixed, warn and suggest split boundaries first.
+- `split`: explain whether the diff should be split, group files by intent, and recommend commit order.
+- `pr`: draft a PR title and body that answer what changed, why it changed, and how it was validated.
+- `apply`: only create a commit after I confirm the exact file scope and commit message. If confirmation is missing or ambiguous, show the proposed plan and stop.
+
+Commit message rules:
+- Prefer conventional commit shape when appropriate.
+- Keep the title short and specific.
+- Use the body only when it adds useful why/context.
+- Avoid jargon and AI-flavored prose.
+- Avoid embedding large diff summaries.
+
+Commit draft format:
+```text
+Change Summary
+- ...
+
+Split Advice
+- ...
+
+Draft Commit Message
+fix(scope): concise title
+
+Optional body explaining why the change matters.
+
+Next Step
+Reply with the exact files or commit message to apply if you want me to commit.
+```
+
+PR draft format:
+```md
+## What changed
+
+...
+
+## Why
+
+...
+
+## Validation
+
+- ...
+```
+
+Split advice rules:
+- Call out mixed concerns before any commit action.
+- Recommend commit order.
+- Group files by intent, not by convenience.
+- Do not auto-split unless I explicitly ask.
+
+Confirmed execution rules:
+1. Re-read `git status --short` immediately before staging.
+2. Stage only the confirmed files or hunks.
+3. Commit only the confirmed scope.
+4. Return the commit hash and message.
+5. Leave unrelated dirty files untouched.
+6. Never push unless I explicitly confirm a separate push action.
+
+No-op rules:
+- If there are no changes, do not invent a message. Say the worktree has no changes to commit.
+- If the requested scope has no diff, say so and stop.
+- If mixed dirty files are present outside the confirmed scope, mention that they were left untouched.

package/prompts/review.md

@@ -0,0 +1,67 @@
+---
+description: Review local changes, branch ranges, or PRs with prioritized findings
+argument-hint: "[target] [--fix] [--comment] [--summary]"
+---
+Run the `/review` workflow for: $ARGUMENTS
+
+Scope and guardrails:
+- This workflow is only for code review and the optional bounded fix/comment/summary modes described here.
+- Do not change core read behavior, do not introduce unified resource reads, and do not use or build tool discovery.
+- Default to local-only analysis. Do not post GitHub comments unless I explicitly confirm after seeing the draft.
+- Do not commit, push, rewrite memory, or rewrite skills as part of this workflow.
+- Do not switch branches or check out PR branches unless I explicitly ask.
+
+Target resolution:
+- If no target is provided, review the current worktree diff, including staged and unstaged changes.
+- If a git range is provided, review that range with `git diff <range>` and related files as needed.
+- If a PR number or URL is provided, inspect PR metadata and diff with `gh pr view`, `gh pr diff`, `gh api`, or fetched refs without changing branches.
+- If the target is ambiguous, ask one concise clarifying question before reviewing.
+
+Review process:
+1. Inspect `git status` before local review so unrelated dirty files are visible.
+2. Read the relevant diff first, then read full related files when needed to validate behavior.
+3. Focus on concrete bugs, user-visible regressions, security/data-loss risks, missing validation, and meaningful test gaps.
+4. Prioritize findings by severity and actionability. Do not pad with style nits.
+5. If no findings are found, state that explicitly and mention residual risks or unrun checks.
+
+Severity meanings:
+- P0: data loss, security issue, or complete breakage.
+- P1: clear bug or user-visible regression.
+- P2: edge case, missing coverage, or maintenance risk.
+- P3: style, wording, or low-risk improvement.
+
+Output format:
+```text
+Findings
+
+P1 path/to/file.ts:88
+Problem statement in one sentence.
+Impact: why this matters.
+Suggestion: the smallest useful fix.
+
+P2 path/to/test.ts:45
+Problem statement in one sentence.
+Impact: why this matters.
+Suggestion: the smallest useful fix.
+
+Verdict
+Fix P1 before merging. P2 should be addressed if this area is changing.
+```
+
+Formatting rules:
+- Findings come first. Keep summary prose after findings, not before.
+- Include file paths and line numbers for concrete issues when available.
+- Use plain language a non-author can understand.
+- Keep the verdict short and specific.
+
+Mode handling:
+- `--summary`: add a concise review summary after the verdict.
+- `--comment`: draft one general GitHub PR comment after the verdict, show it locally, and wait for my confirmation before posting.
+- `--fix`: review first. If I did not already name the exact findings or severities to fix, stop after the review and ask which findings to repair. If I did name them, apply only those confirmed fixes, run targeted validation, then report what changed and what risk remains.
+
+Fix loop constraints:
+- Keep fixes minimal and bounded to the selected findings.
+- Do not rewrite unrelated files.
+- Do not chase speculative issues.
+- Run targeted validation after edits when a relevant local check exists.
+- If a fix is broad or risky, ask for confirmation before editing even when `--fix` is present.