@lebronj/pi-suite 0.1.9 → 0.1.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lebronj/pi-suite",
-  "version": "0.1.9",
+  "version": "0.1.11",
   "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.

package/scripts/bootstrap.sh

@@ -218,4 +218,8 @@ Provider: openai
 Base URL: $TEAM_BASE_URL
 Model: $TEAM_MODEL
 Run: pi
+
+Optional Figma tools are not installed by default.
+Enable later with: pi install npm:pi-mono-figma
+Disable later with: pi remove npm:pi-mono-figma
 MSG

package/skills/pi-skill/SKILL.md

@@ -18,6 +18,7 @@ When adding, removing, renaming, or materially changing any pi capability in thi
 - `edit`: precise exact-text replacements in one file.
 - `write`: create or overwrite files.
 - `goal`: inspect, resume/drop, or complete an active goal-mode objective when goal mode is running.
+- `autogoal`: inspect, checkpoint, pause/resume/drop, block, or complete an active bounded autogoal run when `/autogoal` is running.
 - `lsp_diagnostics` / `lsp_navigation`: code-intelligence path for diagnostics, definitions, references, hover, symbols, call hierarchy, rename, and workspace diagnostics when pi-lens/LSP tools are installed.
 - `ast_grep_search` / `ast_grep_replace` / `ast_dump`: AST-aware code search and replacement when pi-lens tools are installed; prefer over raw text search for structural code patterns.
 - `lens_diagnostics`: inspect pi-lens warnings/errors for files touched this session when available.
@@ -170,6 +171,19 @@ mcp({ tool: "tool_name", args: "{}" })
 
 Do not route built-in pi tools through MCP; call them directly.
 
+## Autogoal
+
+Autogoal is provided by `autogoal.ts`.
+
+- Start with `/autogoal <task>`.
+- It persists the objective, injects hidden loop context, enables the `autogoal` tool, and auto-continues until verified complete, paused, dropped, blocked, or interrupted.
+- It uses bounded loop defaults: 12 autonomous turns per session, 2 no-progress turns, 3 repeated repair attempts, and 4 subagent jobs per run.
+- Context thresholds are 60% prepare, 75% checkpoint, and 85% checkpoint plus automatic new-session continuation.
+- Completion is gated by current-state evidence: changed files must be read after edits and a relevant validation command must pass before `autogoal({ op: "complete" })` succeeds.
+- Subagents are optional; scout/reviewer/verifier are allowed when useful, while worker subagents must use isolated worktrees.
+- Run artifacts are audit-only and live under `~/.pi/agent/workflow-runs/autogoal-<run-id>/`; checkpoints also live under `~/.pi/agent/autogoal/checkpoints/`.
+- Useful commands: `/autogoal status`, `/autogoal pause`, `/autogoal resume`, `/autogoal checkpoint`, `/autogoal drop`, `/autogoal auto on`, `/autogoal auto off`.
+
 ## Goal Mode
 
 Goal mode is provided by `goal-mode.ts`.
@@ -209,6 +223,7 @@ Suite skills currently include:
 
 Optional package-provided skills can include:
 
+- `figma`: Figma REST/API design exploration and design-to-code workflows from `pi-mono-figma`; not installed or loaded by default, enabled with `pi install npm:pi-mono-figma`.
 - `librarian`: library internals research with source citations.
 - `pi-subagents`: subagent delegation workflows.
 - `ast-grep`: AST-aware code search/replace guidance.
@@ -231,11 +246,12 @@ Global user package configuration is in `~/.pi/agent/settings.json`; project pac
 
 Current suite package:
 
-- `@lebronj/pi-suite`: bundles local extensions, prompts, suite skills, vendored `@jhp/pi-memory`, and optional package hooks for `pi-mcp-adapter`, `pi-subagents`, and `pi-web-access`.
+- `@lebronj/pi-suite`: bundles local extensions, prompts, suite skills, vendored `@jhp/pi-memory`, and optional package hooks for `pi-mcp-adapter`, `pi-subagents`, and `pi-web-access`. It does not install or load `pi-mono-figma` by default.
 
 Common project packages:
 
 - `@jhp/pi-memory`
+- `pi-mono-figma` (install and enable only on demand with `pi install npm:pi-mono-figma`)
 - `pi-web-access`
 - `pi-mcp-adapter`
 - `pi-subagents`
@@ -246,7 +262,8 @@ Bootstrap behavior:
 - Installs global `@earendil-works/pi-coding-agent`.
 - Writes the team OpenAI-compatible provider to `~/.pi/agent/models.json`.
 - Sets default provider/model in `~/.pi/agent/settings.json`.
-- Runs `pi install npm:@lebronj/pi-suite` by default.
+- Runs `pi install npm:@lebronj/pi-suite` by default; this does not install or load `pi-mono-figma`.
+- Prints follow-up instructions for enabling Figma later with `pi install npm:pi-mono-figma` and disabling it with `pi remove npm:pi-mono-figma`.
 - Creates `~/.pi/agent/memory` and links it into the workspace `.pi/memory` when safe.
 - Optionally initializes the local `~/.pi/agent/evolution` repo for memory/skill-draft snapshots; it never writes tokens or enables auto-push.
 - Links suite skills into the workspace `.pi/skills` when safe.