@pareto4/pp-core 1.5.1 → 1.5.3

package/pp-core/workflows/explore.md

@@ -1,6 +1,6 @@
 <purpose>
 Socratic ideation workflow. Guides the developer through exploring an idea via probing questions,
-offers mid-conversation research when useful, then routes crystallized outputs to GSD artifacts.
+offers mid-conversation research when useful, then routes crystallized outputs to pp-core artifacts.
 </purpose>
 
 <required_reading>
@@ -11,7 +11,7 @@ Read all files referenced by the invoking prompt's execution_context before star
 </required_reading>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-phase-researcher — Researches specific questions and returns concise findings
 </available_agent_types>
 

package/pp-core/workflows/extract-learnings.md

@@ -96,7 +96,7 @@ Each surprise entry must include:
 </step>
 
 <step name="capture_thought_integration">
-**What this step is:** `capture_thought` is an **optional convention**, not a bundled GSD tool. GSD does not ship one and does not require one. The step is a hook for users who run a memory / knowledge-base MCP server (for example ExoCortex-style servers, `claude-mem`, or `mem0`-style servers) that exposes a tool with this exact name. If any MCP server in the current session provides a `capture_thought` tool with the signature below, each extracted learning is routed through it with metadata. If no such tool is present, the step is a silent no-op — `LEARNINGS.md` is always the primary output.
+**What this step is:** `capture_thought` is an **optional convention**, not a bundled pp-core tool. pp-core does not ship one and does not require one. The step is a hook for users who run a memory / knowledge-base MCP server (for example ExoCortex-style servers, `claude-mem`, or `mem0`-style servers) that exposes a tool with this exact name. If any MCP server in the current session provides a `capture_thought` tool with the signature below, each extracted learning is routed through it with metadata. If no such tool is present, the step is a silent no-op — `LEARNINGS.md` is always the primary output.
 
 **Detection:** Check whether a tool named `capture_thought` is available in the current session. Do not assume any specific MCP server is connected.
 

package/pp-core/workflows/forensics.md

@@ -1,6 +1,6 @@
 # Forensics Workflow
 
-Post-mortem investigation for failed or stuck GSD workflows. Analyzes git history,
+Post-mortem investigation for failed or stuck pp-core workflows. Analyzes git history,
 `.planning/` artifacts, and file system state to detect anomalies and generate a
 structured diagnostic report.
 

package/pp-core/workflows/health.md

@@ -82,7 +82,7 @@ Parse JSON output:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD Health Check
+ pp-core Health Check
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Status: HEALTHY | DEGRADED | BROKEN
@@ -179,7 +179,7 @@ Report final status.
 | W008 | warning | config.json: workflow.nyquist_validation absent (defaults to enabled but agents may skip) | Yes |
 | W009 | warning | Phase has Validation Architecture in RESEARCH.md but no VALIDATION.md | No |
 | W018 | warning | MILESTONES.md missing entry for archived milestone snapshot | Yes (`--backfill`) |
-| W019 | warning | Unrecognized .planning/ root file — not a canonical GSD artifact | No |
+| W019 | warning | Unrecognized .planning/ root file — not a canonical pp-core artifact | No |
 | I001 | info | Plan without SUMMARY (may be in progress) | No |
 
 </error_codes>

package/pp-core/workflows/help/modes/brief.md

@@ -3,7 +3,7 @@ One-liner refresher for returning users. Output ONLY the `<reference>` content b
 </purpose>
 
 <reference>
-**GSD — top commands**
+**pp-core — top commands**
 
 ```text
 /pp:new-project           Initialize a project (greenfield)
@@ -11,7 +11,7 @@ One-liner refresher for returning users. Output ONLY the `<reference>` content b
 /pp:plan-phase <N>        Create a phase plan
 /pp:execute-phase <N>     Execute a phase
 /pp:progress              Where am I, what's next
-/pp:quick                 Small ad-hoc task with GSD guarantees
+/pp:quick                 Small ad-hoc task with pp-core guarantees
 /pp:fast "<task>"         Trivial inline task — no subagents
 /pp:debug "<symptom>"     Persistent debug session (survives /clear)
 /pp:capture               Save an idea / todo / note

package/pp-core/workflows/help/modes/default.md

@@ -1,11 +1,11 @@
 <purpose>
-One-page newcomer-oriented tour of GSD Core. Output ONLY the `<reference>` content below. No additions.
+One-page newcomer-oriented tour of pp-core. Output ONLY the `<reference>` content below. No additions.
 </purpose>
 
 <reference>
-# GSD Core — Git. Ship. Done.
+# pp-core — The Pareto delivery framework.
 
-Plan-driven development for solo agentic work with Claude Code. GSD Core turns a vague idea into a hierarchical plan, then executes it phase by phase with state tracking and atomic commits.
+Plan-driven development for solo agentic work with Claude Code. pp-core turns a vague idea into a hierarchical plan, then executes it phase by phase with state tracking and atomic commits.
 
 ## Start here (3 commands)
 
@@ -15,14 +15,14 @@ Plan-driven development for solo agentic work with Claude Code. GSD Core turns a
 /pp:execute-phase 1    # Execute all plans in the phase
 ```
 
-Existing codebase? Run `/pp:map-codebase` first to ground GSD in your code.
+Existing codebase? Run `/pp:map-codebase` first to ground pp-core in your code.
 
 ## Common commands
 
 | Command | Purpose |
 |---|---|
 | `/pp:progress` | Where am I, what's next — also routes freeform intent with `--do "..."` |
-| `/pp:quick` | Small ad-hoc task with GSD guarantees (planning dir + atomic commit) |
+| `/pp:quick` | Small ad-hoc task with pp-core guarantees (planning dir + atomic commit) |
 | `/pp:fast "<task>"` | Trivial inline change — no subagents, ≤3 file edits |
 | `/pp:discuss-phase <N>` | Capture vision and decisions before planning |
 | `/pp:debug "<symptom>"` | Persistent debug session, survives `/clear` |
@@ -42,9 +42,9 @@ Existing codebase? Run `/pp:map-codebase` first to ground GSD in your code.
 
 Topics: `workflow` · `planning` · `execute` · `quick` · `debug` · `capture` · `ship` · `config` · `milestones` · `spike` · `sketch` · `review` · `audit` · `progress`
 
-## Update GSD
+## Update pp-core
 
 ```bash
-npx @opengsd/pp-core@latest
+npx @pareto4/pp-core@latest
 ```
 </reference>

package/pp-core/workflows/help/modes/full.md

@@ -1,11 +1,11 @@
 <purpose>
-Display the complete GSD Core command reference. Output ONLY the reference content. Do NOT add project-specific analysis, git status, next-step suggestions, or any commentary beyond the reference.
+Display the complete pp-core command reference. Output ONLY the reference content. Do NOT add project-specific analysis, git status, next-step suggestions, or any commentary beyond the reference.
 </purpose>
 
 <reference>
-# GSD Core Command Reference
+# pp-core Command Reference
 
-**GSD Core** (Git. Ship. Done.) creates hierarchical project plans optimized for solo agentic development with Claude Code.
+**pp-core** (The Pareto delivery framework.) creates hierarchical project plans optimized for solo agentic development with Claude Code.
 
 ## Quick Start
 
@@ -15,10 +15,10 @@ Display the complete GSD Core command reference. Output ONLY the reference conte
 
 ## Staying Updated
 
-GSD evolves fast. Update periodically:
+pp-core evolves fast. Update periodically:
 
 ```bash
-npx @opengsd/pp-core@latest
+npx @pareto4/pp-core@latest
 ```
 
 ## Core Workflow
@@ -128,9 +128,9 @@ Usage: `/pp:execute-phase 5 --wave 2`
 ### Smart Router
 
 **`/pp:progress --do "<description>"`**
-Route freeform text to the right GSD command automatically.
+Route freeform text to the right pp-core command automatically.
 
-- Analyzes natural language input to find the best matching GSD command
+- Analyzes natural language input to find the best matching pp-core command
 - Acts as a dispatcher — never does the work itself
 - Resolves ambiguity by asking you to pick between top matches
 - Use when you know what you want but don't know which `/pp-*` command to run
@@ -142,7 +142,7 @@ Usage: `/pp:progress --do "I want to start a new milestone"`
 ### Quick Mode
 
 **`/pp:quick [--full] [--validate] [--discuss] [--research]`**
-Execute small, ad-hoc tasks with GSD guarantees but skip optional agents.
+Execute small, ad-hoc tasks with pp-core guarantees but skip optional agents.
 
 Quick mode uses the same system with a shorter path:
 - Spawns planner + executor (skips researcher, checker, verifier by default)
@@ -440,7 +440,7 @@ Create a clean branch for pull requests by filtering out .planning/ commits.
 
 - Classifies commits: code-only (include), planning-only (exclude), mixed (include sans .planning/)
 - Cherry-picks code commits onto a clean branch
-- Reviewers see only code changes, no GSD artifacts
+- Reviewers see only code changes, no pp-core artifacts
 
 Usage: `/pp:pr-branch` or `/pp:pr-branch main`
 
@@ -499,7 +499,7 @@ Configure workflow toggles and model profile interactively.
 Usage: `/pp:settings`
 
 **`/pp:config [--profile <profile> | --advanced | --integrations]`**
-Configure GSD beyond the basic settings: model profile, advanced tuning, and third-party integrations.
+Configure pp-core beyond the basic settings: model profile, advanced tuning, and third-party integrations.
 
 - `--profile <profile>` — quick switch model profile (`quality | balanced | budget | inherit`)
 - `--advanced` — power-user tuning: plan bounce, timeouts, branch templates, cross-AI execution (replaces the former `pp-settings-advanced`)
@@ -538,7 +538,7 @@ Archive accumulated phase directories from completed milestones.
 Usage: `/pp:cleanup`
 
 **`/pp:help [--brief | --full | <topic> | --brief <topic>]`**
-Show GSD command help at the tier you ask for.
+Show pp-core command help at the tier you ask for.
 
 - `--brief` — one-liner refresher of the top commands (~10 lines)
 - *(no flag)* — one-page newcomer tour (default)
@@ -555,9 +555,9 @@ Usage: `/pp:help debug`
 Usage: `/pp:help --brief debug`
 
 **`/pp:update [--sync] [--reapply] [--next | --rc]`**
-Update GSD to latest version with changelog preview.
+Update pp-core to latest version with changelog preview.
 
-- `--sync` — sync managed GSD skills across runtime roots (replaces the former `pp-sync-skills`)
+- `--sync` — sync managed pp-core skills across runtime roots (replaces the former `pp-sync-skills`)
 - `--reapply` — reapply local modifications after an update (replaces the former `pp-reapply-patches`)
 - `--next` (alias `--rc`) — install/refresh from the `@next` RC dist-tag instead of `@latest` (ADR #660); omit for the stable channel
 
@@ -565,7 +565,7 @@ Update GSD to latest version with changelog preview.
 - Displays changelog entries for versions you've missed
 - Highlights breaking changes
 - Confirms before running install
-- Better than raw `npx @opengsd/pp-core`
+- Better than raw `npx @pareto4/pp-core`
 
 Usage: `/pp:update`
 
@@ -602,7 +602,7 @@ The commands above cover the most common day-to-day flows. Every command listed
 ### Diagnostics & Maintenance
 
 - **`/pp:health [--repair] [--context]`** — Diagnose planning directory health and optionally repair issues.
-- **`/pp:forensics [problem description]`** — Post-mortem investigation for failed GSD workflows; diagnoses what went wrong.
+- **`/pp:forensics [problem description]`** — Post-mortem investigation for failed pp-core workflows; diagnoses what went wrong.
 - **`/pp:undo --last N | --phase NN | --plan NN-MM`** — Safe git revert. Roll back phase or plan commits using the phase manifest with dependency checks.
 - **`/pp:docs-update [--force] [--verify-only]`** — Generate or update project documentation verified against the codebase.
 - **`/pp:extract-learnings <phase>`** — Extract decisions, lessons, patterns, and surprises from completed phase artifacts.
@@ -619,7 +619,7 @@ The commands above cover the most common day-to-day flows. Every command listed
 ### Workflow & Orchestration
 
 - **`/pp:manager [--analyze-deps]`** — Interactive command center for managing multiple phases from one terminal. `--analyze-deps` scans ROADMAP phases for dependency relationships before parallel execution.
-- **`/pp:workspace [--new | --list | --remove] [name]`** — Manage GSD workspaces: create, list, or remove isolated workspace environments.
+- **`/pp:workspace [--new | --list | --remove] [name]`** — Manage pp-core workspaces: create, list, or remove isolated workspace environments.
 - **`/pp:workstreams`** — Manage parallel workstreams: list, create, switch, status, progress, complete, and resume.
 - **`/pp:review-backlog`** — Review and promote backlog items to active milestone.
 - **`/pp:milestone-summary [version]`** — Generate a comprehensive project summary from milestone artifacts for team onboarding and review.

package/pp-core/workflows/help.md

@@ -1,5 +1,5 @@
 <purpose>
-Display GSD command help at the tier the user asked for. Output ONLY the reference content of the chosen mode. Do NOT add project-specific analysis, git status, next-step suggestions, or any commentary beyond the reference.
+Display pp-core command help at the tier the user asked for. Output ONLY the reference content of the chosen mode. Do NOT add project-specific analysis, git status, next-step suggestions, or any commentary beyond the reference.
 </purpose>
 
 <progressive_disclosure>

package/pp-core/workflows/import.md

@@ -14,7 +14,7 @@ Display the stage banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► IMPORT
+ pp-core ► IMPORT
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -27,14 +27,14 @@ Parse `$ARGUMENTS` to determine the execution mode:
 - If `--from` is present: extract FILEPATH (the next token after `--from`), set MODE=plan
 - If `--prd` is present: display message that `--prd` is not yet implemented and exit:
   ```
-  GSD > --prd mode is planned for a future release. Use --from to import plan files.
+  pp-core > --prd mode is planned for a future release. Use --from to import plan files.
   ```
 - If neither flag is found: display usage and exit:
 
 ```
 Usage: /pp:import --from <path>
 
-  --from <path>   Import an external plan file into GSD format
+  --from <path>   Import an external plan file into pp-core format
 ```
 
 **Validate the file path:**
@@ -74,7 +74,7 @@ Load project context for conflict detection:
 2. Read `.planning/PROJECT.md` — extract project constraints, tech stack, scope boundaries.
    **If PROJECT.md does not exist:** skip constraint checks that rely on it and display:
    ```
-   GSD > Note: No PROJECT.md found. Conflict checks against project constraints will be skipped.
+   pp-core > Note: No PROJECT.md found. Conflict checks against project constraints will be skipped.
    ```
 3. Read `.planning/REQUIREMENTS.md` — extract existing requirements for overlap and contradiction checks.
    **If REQUIREMENTS.md does not exist:** skip requirement conflict checks and continue.
@@ -93,7 +93,7 @@ Store loaded context for conflict detection in the next step.
 Read the imported file at FILEPATH.
 
 Determine the format:
-- **GSD PLAN.md format**: Has YAML frontmatter with `phase:`, `plan:`, `type:` fields
+- **pp-core PLAN.md format**: Has YAML frontmatter with `phase:`, `plan:`, `type:` fields
 - **Freeform document**: Any other format (markdown spec, design doc, task list, etc.)
 
 Extract from the imported content:
@@ -147,7 +147,7 @@ If user selects "Abort": exit cleanly with message "Import cancelled."
 
 <step name="plan_convert">
 
-Convert the imported content to GSD PLAN.md format.
+Convert the imported content to pp-core PLAN.md format.
 
 Ensure the PLAN.md has all required frontmatter fields:
 ```yaml
@@ -166,9 +166,9 @@ must_haves:
 ```
 
 **Reject PBR naming conventions in source content:**
-If the imported plan references PBR plan naming (e.g., `PLAN-01.md`, `plan-01.md`), rename all references to GSD `{NN}-{MM}-PLAN.md` convention during conversion.
+If the imported plan references PBR plan naming (e.g., `PLAN-01.md`, `plan-01.md`), rename all references to pp-core `{NN}-{MM}-PLAN.md` convention during conversion.
 
-Apply GSD naming convention for the output filename:
+Apply pp-core naming convention for the output filename:
 - Format: `{NN}-{MM}-PLAN.md` (e.g., `04-01-PLAN.md`)
 - NEVER use `PLAN-01.md`, `plan-01.md`, or any other format
 - NN = phase number (zero-padded), MM = plan number within the phase (zero-padded)
@@ -202,7 +202,7 @@ Print: "Delegating to pp-plan-checker (runs in a subagent — no output until it
 ```
 Agent({
   subagent_type: "pp-plan-checker",
-  prompt: "Validate: .planning/phases/{phase}/{plan}-PLAN.md — check frontmatter completeness, task structure, and GSD conventions. Report any issues."
+  prompt: "Validate: .planning/phases/{phase}/{plan}-PLAN.md — check frontmatter completeness, task structure, and pp-core conventions. Report any issues."
 })
 ```
 
@@ -234,7 +234,7 @@ pp_run query commit "docs({phase}): import plan from {basename FILEPATH}" --file
 Display completion:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► IMPORT COMPLETE
+ pp-core ► IMPORT COMPLETE
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -250,7 +250,7 @@ Do NOT:
 - Violate the shared conflict-engine contract in `references/doc-conflict-engine.md` (no markdown tables, no new severity labels, no bypass of the BLOCKER gate)
 - Write PLAN.md files as `PLAN-01.md` or `plan-01.md` — always use `{NN}-{MM}-PLAN.md`
 - Use `pbr:plan-checker` or `pbr:planner` — use `pp-plan-checker` and `pp-planner`
-- Write `.planning/.active-skill` — this is a PBR pattern with no GSD equivalent
+- Write `.planning/.active-skill` — this is a PBR pattern with no pp-core equivalent
 - Reference `pbr-tools`, `pbr:`, or `PLAN-BUILD-RUN` anywhere
 - Write any PLAN.md file when blockers exist — the safety gate must hold
 - Skip path validation on the --from file argument

package/pp-core/workflows/inbox.md

@@ -103,7 +103,7 @@ For each classified issue, review against its template requirements.
 - **Gate check:** If PR exists linking this issue, does issue have `approved-enhancement`?
 
 **Bug Report Review Checklist:**
-- [ ] GSD Version provided
+- [ ] pp-core Version provided
 - [ ] Runtime selected
 - [ ] OS selected
 - [ ] Node.js version provided
@@ -239,7 +239,7 @@ Produce a structured triage report:
 
 ```
 ===================================================================
-  GSD INBOX TRIAGE — {repo} — {date}
+  pp-core INBOX TRIAGE — {repo} — {date}
 ===================================================================
 
 SUMMARY
@@ -317,12 +317,12 @@ Label recommendations:
 **If --close-incomplete:**
 For issues scoring below 50% completeness:
 ```bash
-gh issue close {number} --comment "Closed by GSD inbox triage: this issue is missing required fields per the issue template. Missing: {list}. Please reopen with a complete submission. See CONTRIBUTING.md for requirements."
+gh issue close {number} --comment "Closed by pp-core inbox triage: this issue is missing required fields per the issue template. Missing: {list}. Please reopen with a complete submission. See CONTRIBUTING.md for requirements."
 ```
 
 For PRs with gate violations:
 ```bash
-gh pr close {number} --comment "Closed by GSD inbox triage: this PR does not meet the issue-first requirement. {specific violation}. See CONTRIBUTING.md for the correct process."
+gh pr close {number} --comment "Closed by pp-core inbox triage: this PR does not meet the issue-first requirement. {specific violation}. See CONTRIBUTING.md for the correct process."
 ```
 
 Always confirm with the user before closing anything:

package/pp-core/workflows/ingest-docs.md

@@ -15,7 +15,7 @@ Display the stage banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► INGEST DOCS
+ pp-core ► INGEST DOCS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -127,7 +127,7 @@ De-duplicate the union (a file matched by multiple patterns is one doc).
 **Cap:** hard limit of 50 docs per invocation (documented v1 constraint). If the discovered set exceeds 50:
 
 ```
-GSD > Discovered {N} docs, which exceeds the v1 cap of 50.
+pp-core > Discovered {N} docs, which exceeds the v1 cap of 50.
       Use --manifest to narrow the set to ≤ 50 files, or run
       /pp:ingest-docs again with a narrower <path>.
 ```
@@ -222,7 +222,7 @@ Apply the safety semantics from `references/doc-conflict-engine.md`. Operation n
 Render the report to the user, then display:
 
 ```
-GSD > BLOCKED: {N} blockers must be resolved before ingest can proceed.
+pp-core > BLOCKED: {N} blockers must be resolved before ingest can proceed.
 ```
 
 Exit WITHOUT writing PROJECT.md, REQUIREMENTS.md, ROADMAP.md, or STATE.md. The staging intel files remain for inspection. The safety gate holds — no destination files are written when blockers exist.
@@ -238,7 +238,7 @@ On Abort: exit cleanly with "Ingest cancelled. Staged intel preserved at `.plann
 
 **If BLOCKERS = 0 and WARNINGS = 0:**
 
-Proceed to routing silently, or optionally display `GSD > No conflicts. Auto-resolved: {N}.`
+Proceed to routing silently, or optionally display `pp-core > No conflicts. Auto-resolved: {N}.`
 
 </step>
 
@@ -312,7 +312,7 @@ Display completion:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► INGEST DOCS COMPLETE
+ pp-core ► INGEST DOCS COMPLETE
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 

package/pp-core/workflows/list-workspaces.md

@@ -1,5 +1,5 @@
 <purpose>
-List all GSD workspaces found in ~/pp-workspaces/ with their status.
+List all pp-core workspaces found in ~/pp-workspaces/ with their status.
 </purpose>
 
 <required_reading>
@@ -36,9 +36,9 @@ Done.
 Display a table:
 
 ```
-GSD Workspaces (~/pp-workspaces/)
+pp-core Workspaces (~/pp-workspaces/)
 
-| Name | Repos | Strategy | GSD Project |
+| Name | Repos | Strategy | pp-core Project |
 |------|-------|----------|-------------|
 | feature-a | 3 | worktree | Yes |
 | feature-b | 2 | clone | No |
@@ -52,6 +52,6 @@ For each workspace, show:
 - **Name** — directory name
 - **Repos** — count from init data
 - **Strategy** — from WORKSPACE.md
-- **GSD Project** — whether `.planning/PROJECT.md` exists (Yes/No)
+- **pp-core Project** — whether `.planning/PROJECT.md` exists (Yes/No)
 
 </process>

package/pp-core/workflows/manager.md

@@ -39,7 +39,7 @@ Display startup banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► MANAGER
+ pp-core ► MANAGER
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  {milestone_version} — {milestone_name}
@@ -90,7 +90,7 @@ Example output:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► DASHBOARD
+ pp-core ► DASHBOARD
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ████████████░░░░░░░░ 60%  (3/5 phases)
  ◆ Background: Planning Phase 4
@@ -193,7 +193,7 @@ Continue:
   → Discuss Phase 35 (inline)
 ```
 
-**Auto-refresh:** If background agents are running (`is_active` is true for any phase), set a 60-second auto-refresh cycle. After presenting the action menu, if no user input is received within 60 seconds, automatically refresh the dashboard. This interval is configurable via `manager_refresh_interval` in GSD config (default: 60 seconds, set to 0 to disable).
+**Auto-refresh:** If background agents are running (`is_active` is true for any phase), set a 60-second auto-refresh cycle. After presenting the action menu, if no user input is received within 60 seconds, automatically refresh the dashboard. This interval is configurable via `manager_refresh_interval` in pp-core config (default: 60 seconds, set to 0 to disable).
 
 Present via AskUserQuestion:
 - **question:** "What would you like to do?"
@@ -270,7 +270,7 @@ Then loop back to dashboard step.
 Agent(
   description="Plan phase {N}: {phase_name}",
   run_in_background=true,
-  prompt="You are running the GSD plan-phase workflow for phase {N} of the project.
+  prompt="You are running the pp-core plan-phase workflow for phase {N} of the project.
 
 Working directory: {cwd}
 Phase: {N} — {phase_name}
@@ -324,7 +324,7 @@ Then loop back to dashboard step.
 Agent(
   description="Execute phase {N}: {phase_name}",
   run_in_background=true,
-  prompt="You are running the GSD execute-phase workflow for phase {N} of the project.
+  prompt="You are running the pp-core execute-phase workflow for phase {N} of the project.
 
 Working directory: {cwd}
 Phase: {N} — {phase_name}
@@ -400,7 +400,7 @@ Display final status with progress bar:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► SESSION END
+ pp-core ► SESSION END
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  {milestone_version} — {milestone_name}

package/pp-core/workflows/map-codebase.md

@@ -7,7 +7,7 @@ Output: .planning/codebase/ folder with 7 structured documents about the codebas
 </purpose>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-codebase-mapper — Maps project structure and dependencies
 </available_agent_types>
 
@@ -440,5 +440,5 @@ End workflow.
 - All 7 codebase documents exist
 - No empty documents (each should have >20 lines)
 - Clear completion summary with line counts
-- User offered clear next steps in GSD style
+- User offered clear next steps in pp-core style
 </success_criteria>

package/pp-core/workflows/mvp-phase.md

@@ -1,5 +1,5 @@
 <purpose>
-Guide the user through MVP-mode planning for a phase. Prompts for an "As a / I want to / So that" user story, runs SPIDR splitting check on the story, writes the result to ROADMAP.md, and delegates to `/gsd plan-phase` (which auto-detects MVP via the roadmap mode field shipped in PRD Phase 1).
+Guide the user through MVP-mode planning for a phase. Prompts for an "As a / I want to / So that" user story, runs SPIDR splitting check on the story, writes the result to ROADMAP.md, and delegates to `/pp:plan-phase` (which auto-detects MVP via the roadmap mode field shipped in PRD Phase 1).
 </purpose>
 
 <required_reading>
@@ -23,9 +23,9 @@ Extract the phase number from `$ARGUMENTS` (integer or decimal like `2.1`). Opti
 If no argument:
 ```
 ERROR: Phase number required
-Usage: /gsd mvp-phase <phase-number>
-Example: /gsd mvp-phase 1
-Example: /gsd mvp-phase 2.1
+Usage: /pp:mvp-phase <phase-number>
+Example: /pp:mvp-phase 1
+Example: /pp:mvp-phase 2.1
 ```
 Exit.
 
@@ -54,7 +54,7 @@ else
 fi
 ```
 
-If `PHASE_FOUND` is `false`: error and exit. Suggest `/gsd add-phase` or `/gsd insert-phase` to create the phase first.
+If `PHASE_FOUND` is `false`: error and exit. Suggest `/pp:phase` or `/pp:phase` to create the phase first.
 
 **Status guard.** If the phase is `in_progress` (has plans but not complete) or `completed`, refuse unless `--force` is in `$ARGUMENTS`:
 
@@ -63,7 +63,7 @@ ERROR: Phase ${PHASE} is currently ${STATUS}.
 Converting an active or completed phase to MVP mode mid-flight will
 invalidate any existing plans and summaries.
 
-To proceed anyway: /gsd mvp-phase ${PHASE} --force
+To proceed anyway: /pp:mvp-phase ${PHASE} --force
 ```
 
 **Already-MVP guard.** If `PHASE_MODE` is already `mvp`, surface this and ask whether to re-prompt the user story or abort:
@@ -155,7 +155,7 @@ d) Produce a split proposal. Example:
 
 Use `AskUserQuestion` [Accept / Modify / Reject].
 
-- **Accept**: `USER_STORY` becomes the first split's story (`${HAPPY_STORY}` in the example). Surface the remaining splits as a list of `/gsd add-phase` invocations the user can run after this command completes — do NOT auto-create the new phases (preserve user control over numbering).
+- **Accept**: `USER_STORY` becomes the first split's story (`${HAPPY_STORY}` in the example). Surface the remaining splits as a list of `/pp:phase` invocations the user can run after this command completes — do NOT auto-create the new phases (preserve user control over numbering).
 - **Modify**: re-prompt the splits one more time, then accept or reject.
 - **Reject**: revert `USER_STORY` to the original, proceed without splitting.
 
@@ -194,9 +194,9 @@ Assert:
 
 If either assertion fails, surface the discrepancy to the user and exit. Do not proceed to plan-phase delegation with a half-applied write.
 
-## 7. Delegate to /gsd plan-phase
+## 7. Delegate to /pp:plan-phase
 
-Invoke `/gsd plan-phase ${PHASE}` (no flags). Phase 1's MVP_MODE resolution chain (CLI flag → roadmap mode → config → false) will detect the new `**Mode:** mvp` line and run plan-phase in vertical-slice mode automatically.
+Invoke `/pp:plan-phase ${PHASE}` (no flags). Phase 1's MVP_MODE resolution chain (CLI flag → roadmap mode → config → false) will detect the new `**Mode:** mvp` line and run plan-phase in vertical-slice mode automatically.
 
 The Walking Skeleton gate (also from Phase 1) will fire automatically if `${PHASE} == "01"` and there are zero prior phase summaries.
 
@@ -209,11 +209,11 @@ If SPIDR produced a split in step 4, append a final user-facing message:
 > Your original story was split. The first slice is now planned via plan-phase.
 > To create the remaining slice(s) as new phases, run:
 >
-> - `/gsd add-phase` — for the next slice: «${SPLIT_2_STORY}»
-> - `/gsd add-phase` — for the next slice: «${SPLIT_3_STORY}»
+> - `/pp:phase` — for the next slice: «${SPLIT_2_STORY}»
+> - `/pp:phase` — for the next slice: «${SPLIT_3_STORY}»
 >
 > Each will be added to the end of the current milestone. You can then run
-> `/gsd mvp-phase <new-phase-number>` on each to plan them as MVP slices."
+> `/pp:mvp-phase <new-phase-number>` on each to plan them as MVP slices."
 
 ## 9. Exit