@esoteric-logic/praxis-harness 1.2.1 → 2.0.0

package/README.md

@@ -8,7 +8,7 @@ A layered harness for [Claude Code](https://docs.anthropic.com/en/docs/claude-co
 
 Praxis gives Claude Code a three-layer operating system:
 
-**Universal base** — always loaded. [GSD](https://github.com/gsd-build/get-shit-done) structures work (spec → plan → execute → verify). [Superpowers](https://github.com/obra/superpowers) enforces quality (TDD, debugging, code review). [Ralph](https://github.com/snarktank/ralph) runs autonomous execution loops.
+**Universal base** — always loaded. Praxis structures work (discuss → plan → execute → verify → simplify → ship). Built-in quality enforcement (debugging, code review, simplification).
 
 **AI-Kits** — activated on demand via `/kit:<name>`. Each kit bundles domain-specific rules, skills, MCP servers, and slash commands. Activate the web-designer kit and your components get design system enforcement, accessibility auditing, and production lint. Deactivate with `/kit:off`.
 
@@ -31,32 +31,23 @@ npx praxis-harness uninstall   # remove Praxis-owned files from ~/.claude/
 
 ## After install
 
-Open Claude Code and run:
-
-```
-/plugin marketplace add obra/superpowers-marketplace
-/plugin install superpowers@superpowers-marketplace
-/plugin marketplace add snarktank/ralph
-/plugin install ralph-skills@ralph-marketplace
-```
-
-Verify with `/help` — you should see GSD, Superpowers, and Praxis commands.
+Verify with `/help` — you should see Praxis commands (`/discuss`, `/execute`, `/verify`, `/plan`, `/ship`, `/kit:*`).
 
 ## Workflow
 
-The standard GSD workflow for feature development:
+The standard Praxis workflow for feature development:
 
 ```
 /standup           → orient (reads status.md, surfaces stale state)
-/gsd:discuss       → frame the problem (SPEC questions, scope guard)
+/discuss       → frame the problem (conversational, scope guard)
 /discover          → research options with confidence levels (before /spec)
-/gsd:plan-phase    → plan milestones (with dependency ordering + boundaries)
-/gsd:execute       → implement one milestone at a time (file-group isolation)
-/gsd:verify        → validate (test/lint/typecheck/build, self-review, UNIFY)
+/plan    → plan milestones (with dependency ordering + boundaries)
+/execute       → implement one milestone at a time (file-group isolation)
+/verify        → validate (test/lint/typecheck/build, self-review, UNIFY)
 /session-retro     → capture learnings, update vault
 ```
 
-For pure bugfixes: `/debug` (test-first debugging, skips GSD).
+For pure bugfixes: `/debug` (test-first debugging, skips the full loop).
 For code review: `/review` (launches subagent review at any time).
 For technical research: `/discover` (structured options evaluation before decisions).
 
@@ -64,10 +55,10 @@ For technical research: `/discover` (structured options evaluation before decisi
 
 | Command | Purpose |
 |---------|---------|
-| `gsd-discuss` | Frame the problem, SPEC questions, scope guard |
-| `gsd-execute` | Implement one milestone with file-group isolation + boundary enforcement |
-| `gsd-verify` | Validate milestone (test/lint/build), self-review, UNIFY phase summary |
-| `ralph` | Autonomous multi-story execution from a PRD |
+| `discuss` | Conversational problem framing, SPEC synthesis, scope guard |
+| `execute` | Implement one milestone with file-group isolation + boundary enforcement |
+| `verify` | Validate milestone (test/lint/build), self-review, UNIFY phase summary |
+
 | `plan` | Create a dated work plan with milestone dependencies + checkpoints |
 | `spec` | Create a structured spec or ADR with conflict detection |
 | `discover` | Structured technical discovery with confidence-rated options |
@@ -86,17 +77,6 @@ Key additions in this version:
 - **context-management** — context brackets (FRESH/MODERATE/DEPLETED/CRITICAL) adapt behavior to session stage
 - **vault** — Obsidian vault integration
 
-## Ralph
-
-Ralph is the autonomous execution mode for multi-story work. Use it when you have >5 independent stories that don't require human checkpoints.
-
-1. Write a PRD using `/prd-writer` (structured story format with file groups and estimates)
-2. Run `/ralph` to begin autonomous execution
-3. Each story runs in a fresh context with its own verify cycle
-4. Blocked stories are recorded and skipped — reported at run end
-
-Ralph is not a replacement for GSD — it runs GSD internally per story. Use GSD for work that needs cross-story reasoning or architectural decisions.
-
 ## Architecture
 
 ```
@@ -108,7 +88,7 @@ Ralph is not a replacement for GSD — it runs GSD internally per story. Use GSD
 │  Skills chain + domain rules + MCPs    │
 ├────────────────────────────────────────┤
 │  Universal base (always loaded)        │
-│  GSD → Superpowers → Ralph             │
+│  Praxis workflow engine                 │
 ├────────────────────────────────────────┤
 │  Vault layer                           │
 │  Obsidian                              │
@@ -118,7 +98,7 @@ Ralph is not a replacement for GSD — it runs GSD internally per story. Use GSD
 └────────────────────────────────────────┘
 ```
 
-**Workflow hierarchy:** GSD owns the outer loop (discuss → plan → execute → verify). Superpowers enforces quality inside execution (TDD, review, debug). Ralph runs autonomous multi-story iterations. Kits inject domain context into this workflow — they don't replace it.
+**Workflow hierarchy:** Praxis owns the outer loop (discuss → plan → execute → verify → simplify → ship). Kits inject domain context into this workflow — they don't replace it.
 
 ## Available kits
 

package/base/CLAUDE.md

@@ -13,14 +13,11 @@ You are a senior engineering partner. Think before you build. Verify before you
 - Every option presented MUST include a recommendation and why.
 
 ## Workflow Hierarchy
-- **GSD** owns the outer loop: discuss → plan → execute → verify → simplify → ship.
-  Always start feature work with GSD.
-- **Superpowers** enforces quality inside execution (TDD, review, debug).
-  Its skills auto-activate — never invoke them alongside GSD phases.
-- **Ralph** runs autonomous multi-story iterations from the terminal.
+- **Praxis** owns the outer loop: discuss → plan → execute → verify → simplify → ship.
+  Always start feature work with `/discuss` or `/next`.
 - **Kits** inject domain context into this workflow — they don't replace it.
-- Never invoke `/superpowers:write-plan` alongside `/gsd:plan-phase`.
-- Pure bugfixes: skip GSD, use Superpowers debugging directly.
+- Pure bugfixes: skip the full loop, use `/debug` directly.
+- Trivial changes (typos, config): use `/fast` to skip planning.
 - After every implementation: run `/simplify` to clean up code before verify.
 - Use `/verify-app` for end-to-end checks, `/ship` when ready to commit+push+PR.
 
@@ -40,7 +37,7 @@ permanent institutional memory. Don't wait for session-retro — fix the rule im
 ## Non-Negotiables (fire every session)
 
 **Before any non-trivial task:**
-- WHAT / DONE-WHEN / CONSTRAINTS / NON-GOALS — answer all four before starting.
+- PROBLEM / DELIVERABLE / ACCEPTANCE / BOUNDARIES — answer all four before starting.
 
 **Stop-and-Fix Rule:** Validation fails → fix now → re-validate → proceed.
 If cannot fix in 3 attempts: STOP. Report What / So What / Now What.
@@ -92,8 +89,7 @@ Missing servers are non-blocking — features degrade gracefully.
 
 ## After Compaction — Bootstrap
 1. Read project CLAUDE.md (always first)
-2. Check `claude-progress.json` — if `.ralph_state.current_story` is set: read it NOW, it is authoritative
-3. Active task? → read active plan current milestone only
+2. Active task? → read active plan current milestone only
    No active task? → read `status.md`
 4. Load rules only for what the current task touches:
    - Terraform/Azure → `~/.claude/rules/terraform.md`
@@ -137,7 +133,7 @@ Kit manifests live in `~/.claude/kits/<name>/KIT.md`.
 | `~/.claude/rules/communication.md` | Client writing, no AI attribution |
 | `~/.claude/rules/vault.md` | Second brain integration — Obsidian vault |
 | `~/.claude/rules/architecture.md` | ADR format, What/So What/Now What, risk docs |
-| `~/.claude/rules/context-management.md` | GSD/Ralph anti-rot, context reset protocol |
+| `~/.claude/rules/context-management.md` | Context anti-rot, context reset protocol |
 
 ### Scoped — load only when paths match
 | File | Loads when |

package/base/commands/context-reset.md

@@ -52,7 +52,6 @@ Update `status.md` with current What / So What / Now What:
 **Step 5 — Update claude-progress.json**
 Write a session snapshot to `claude-progress.json`:
 - Update `last_session` with current date and a note about the context reset
-- If Ralph is active: preserve `ralph_state` exactly as-is
 
 **Step 6 — Instruct the user**
 Print:

package/base/commands/debug.md

@@ -1,5 +1,5 @@
 ---
-description: Structured test-first debugging. Reproduce the bug, write a failing test, isolate root cause, fix, verify. Use for pure bugfixes — skips GSD phases.
+description: Structured test-first debugging. Reproduce the bug, write a failing test, isolate root cause, fix, verify. Use for pure bugfixes — skips the full loop.
 ---
 
 You are running structured debugging.
@@ -58,6 +58,6 @@ Before touching any implementation code:
 **Rules:**
 - Never fix without first reproducing.
 - Never say "fixed" without showing the test passing.
-- Skips GSD phases — for pure bugfixes only.
-- If the "bug" is actually a feature gap: redirect to `/gsd:discuss`.
-- If the fix touches >5 files: it is not a bugfix. Use GSD.
+- Skips the full loop — for pure bugfixes only.
+- If the "bug" is actually a feature gap: redirect to `/discuss`.
+- If the fix touches >5 files: it is not a bugfix. Use the full loop.

package/base/commands/discover.md

@@ -41,9 +41,9 @@ You are running a structured technical discovery.
   ---
   ```
 - Include all options evaluated, recommendation, and confidence
-- Report: "Discovery written. Run `/spec` to formalize as ADR, or `/gsd:discuss` to proceed."
+- Report: "Discovery written. Run `/spec` to formalize as ADR, or `/discuss` to proceed."
 
 **Rules:**
 - Discovery is research, not implementation. Zero code output.
 - If the question is already answered by an existing spec: point to it instead.
-- Fills the gap between `/gsd:discuss` (problem framing) and `/spec` (formal decision).
+- Fills the gap between `/discuss` (problem framing) and `/spec` (formal decision).

package/base/commands/discuss.md

@@ -0,0 +1,94 @@
+---
+description: Entry point for all feature work. Conversational problem framing — listen first, then synthesize scope. Use before /plan.
+---
+
+You are starting the discuss phase — a conversation to frame the problem before planning.
+
+**Step 1 — Load minimal context**
+- Read vault_path from `~/.claude/praxis.config.json`
+- Detect project from CWD matching `local_path` in vault `_index.md`
+- If no project detected: ask which project before continuing
+- Read `{vault_path}/status.md` — current state and blockers
+- If `current_plan:` is set: skim the active plan objectives only
+- Read `~/.claude/rules/profile.md` — user context (soft-fail if unconfigured)
+
+Do NOT load rules, kit context, or session history at this phase.
+
+**Step 2 — Listen**
+Ask ONE open question: "What are we working on?"
+Wait for the user to describe the problem in their own words.
+Do NOT present a template or form. Let them talk.
+
+**Step 3 — Search for related work**
+After the user describes the task, search vault for prior art:
+Run: `obsidian search query="{topic}" limit=5`
+If related specs, plans, or research exist: mention them briefly.
+If nothing exists: proceed silently.
+
+**Step 4 — Clarify gaps conversationally**
+From the user's description, identify which of these four dimensions are unclear:
+- **PROBLEM**: Why are we doing this? What's broken or missing?
+- **DELIVERABLE**: What concrete thing will exist when done?
+- **ACCEPTANCE**: What specific checks prove completion?
+- **BOUNDARIES**: What's in scope and what's out?
+
+Ask ONLY about what's missing or ambiguous — do not re-ask what the user already stated.
+Frame questions naturally, not as a checklist. Examples:
+- "What's the actual problem this solves?"
+- "What does 'done' look like for this?"
+- "Anything we should explicitly leave out?"
+
+If the user's initial description covers all four: skip to Step 5.
+
+**Step 5 — Synthesize and frame**
+Write a SPEC block that captures the four dimensions from the conversation:
+
+```
+SPEC
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+PROBLEM:      {why we're doing this}
+DELIVERABLE:  {concrete output}
+ACCEPTANCE:   {checks that prove completion}
+BOUNDARIES:
+  In:  {what's in scope}
+  Out: {what's explicitly excluded}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+Then output a 1-paragraph problem framing (max 200 words):
+- What exists today (from status.md / vault search)
+- What gap or need the user described
+- Recommendation: proceed to `/plan` or write a `/spec` first
+
+**Step 5b — Persist to vault**
+- Write the SPEC block to `{vault_path}/plans/{YYYY-MM-DD}_{slug}-context.md` with frontmatter:
+  ```yaml
+  ---
+  tags: [context, {project-slug}]
+  date: {YYYY-MM-DD}
+  source: agent
+  ---
+  ```
+- Append one-line summary to `{vault_path}/notes/discussion-log.md`:
+  `{date} | {project} | {problem summary} | → /plan`
+- If `discussion-log.md` doesn't exist: create it with a `# Discussion Log` header.
+- The `/plan` command reads this file if the conversation SPEC block is lost to compaction.
+
+**Step 5c — Scope guard**
+- If the framing implies >5 milestones or >3 file groups: flag as scope explosion
+  risk and recommend splitting before `/plan`.
+- After framing: list what is NOT being decided in this discuss phase.
+- Never output implementation code, pseudocode, or file-level changes.
+  This phase produces a problem statement, not a solution.
+
+**Step 6 — Handoff**
+End with: "Run `/plan` to continue, or `/spec` if this needs a design spec first."
+
+The SPEC block from Step 5 is the artifact that `/plan` consumes — it replaces
+the need for `/plan` to re-ask what the task is.
+
+**Rules:**
+- This is a conversation, not a form. Listen first, synthesize second.
+- Problem framing is a paragraph, not a design doc.
+- If scope exceeds 5 milestones: recommend splitting into multiple passes.
+- The SPEC block is the discuss→plan handoff artifact. `/plan` reads it from conversation.

package/base/commands/{gsd-execute.md → execute.md}

@@ -2,13 +2,15 @@
 description: Implementation phase — loads scoped context and works one milestone at a time. Use after plan is approved.
 ---
 
-You are executing the GSD implementation phase.
+You are executing the implementation phase.
 
 **Step 1 — Load implementation context**
 - Read vault_path from `~/.claude/praxis.config.json`
 - Read `{vault_path}/status.md` → get `current_plan:`
-- Read the active plan file — focus on the CURRENT milestone only (not full plan)
-- If no active plan: STOP. Tell user to run `/gsd:discuss` first.
+- Read the active plan file:
+  - `## SPEC` section → PROBLEM, DELIVERABLE, ACCEPTANCE, BOUNDARIES (the contract)
+  - Current milestone steps and acceptance criteria only (not full plan)
+- If no active plan: STOP. Tell user to run `/discuss` first.
 
 **Step 2 — Load scoped rules**
 Load ONLY rules relevant to files being touched in this milestone:
@@ -45,14 +47,8 @@ When the milestone is complete:
 1. Write a brief summary to the active plan file under the milestone entry
 2. Confirm actual diff matches declared file group
 3. Output ONE recommendation — no menu, no alternatives:
-   `Next: /gsd:verify` followed by one sentence explaining why
-   Example: "Next: /gsd:verify — 3 files changed in declared group, tests and lint needed"
-
-**Step 5 — Ralph handoff trigger**
-If remaining milestones >5 and all are independent (no cross-milestone reasoning):
-- After `/gsd:verify` passes (not during Step 4), append:
-  "Also consider: /ralph — {n} independent milestones remaining"
-- Never surface Ralph before verify completes.
+   `Next: /verify` followed by one sentence explaining why
+   Example: "Next: /verify — 3 files changed in declared group, tests and lint needed"
 
 **Rules:**
 - Never skip a milestone or reorder without approval.

package/base/commands/fast.md

@@ -0,0 +1,26 @@
+---
+description: Skip planning for trivial changes. Edit, verify, commit. Use for typos, config tweaks, single-line fixes, and other changes too small for a plan.
+---
+
+You are running a fast task — no planning, just edit/verify/commit.
+
+**Step 1 — Understand the change**
+The user describes the change inline (e.g., `/fast fix typo in README`).
+If no description provided: ask "What's the change?"
+
+**Step 2 — Make the edit**
+Apply the change directly. No SPEC, no plan, no milestones.
+Keep the diff minimal — if the change touches >3 files, stop and suggest `/quick` instead.
+
+**Step 3 — Verify**
+Run lint and test commands from project CLAUDE.md `## Commands` section.
+Show output. If failing: fix immediately.
+
+**Step 4 — Commit**
+On pass: commit with conventional commit format.
+No vault writes, no status.md update, no plan file.
+
+**Rules:**
+- This is for genuinely trivial changes. If you need to think about the approach, use `/quick`.
+- Maximum 3 files changed. Beyond that: escalate to `/quick` or `/discuss`.
+- Pre-commit checks (secrets, identity) still apply — never skip those.

package/base/commands/kit.md

@@ -18,7 +18,7 @@ If `~/.claude/praxis.config.json` has `installed_kits`, cross-reference to show
 
 1. Check if `~/.claude/kits/<name>/KIT.md` exists. If not: report "Kit not found. Run /kit:list."
 2. Read `KIT.md` manifest to get skills_chain, rules, and mcp_servers.
-3. **Idempotency check**: If this kit is already active in the current session, report "Kit already active" and do nothing. This is critical for Ralph integration where every iteration may re-activate.
+3. **Idempotency check**: If this kit is already active in the current session, report "Kit already active" and do nothing.
 4. Print the skills chain:
    ```
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
@@ -44,7 +44,7 @@ If `~/.claude/praxis.config.json` has `installed_kits`, cross-reference to show
 1. Report which kit is being deactivated.
 2. Unload kit-specific rules from the active context.
 3. Note: MCP servers persist globally — they are not unregistered on deactivation.
-4. Print: `✓ Kit deactivated. Universal base (GSD + Superpowers) still active.`
+4. Print: `✓ Kit deactivated. Praxis base workflow still active.`
 
 ## /kit:update <name>
 

package/base/commands/next.md

@@ -0,0 +1,31 @@
+---
+description: Auto-advance to the next workflow phase. Reads status.md loop_position and plan state to determine what comes next. Use anytime to keep moving.
+---
+
+You are advancing the Praxis workflow to the next phase.
+
+**Step 1 — Read current state**
+- Read vault_path from `~/.claude/praxis.config.json`
+- Read `{vault_path}/status.md` → get `loop_position` and `current_plan`
+- If `current_plan` is set: read the plan file — check milestone completion status
+
+**Step 2 — Determine next action**
+
+| loop_position | Plan state | Action |
+|---------------|------------|--------|
+| IDLE | No plan | Ask "What are we working on?" — behave like `/discuss` |
+| IDLE | Plan exists, incomplete milestones | "Existing plan has work remaining. Resume?" → `/execute` |
+| IDLE | Plan exists, all milestones done | "Plan complete. Run `/ship` to commit+push+PR?" |
+| DISCUSS | — | "Discuss complete. Run `/plan` to create the work plan." → invoke `/plan` |
+| PLAN | — | "Plan ready. Run `/execute` to start implementation." → invoke `/execute` |
+| EXECUTE | — | "Milestone complete. Run `/verify` to validate." → invoke `/verify` |
+| VERIFY | Last verify passed | "Verified. Run `/simplify` to clean up, then `/ship`." → invoke `/simplify` |
+| VERIFY | Last verify failed | "Verification failed. Fix the issue, then run `/verify` again." |
+
+**Step 3 — Update loop_position**
+After invoking the next command, update `status.md` → `loop_position` to reflect the new phase.
+
+**Rules:**
+- Always show one clear next action — no menus.
+- If state is ambiguous (e.g., status.md is stale): read the plan file to determine actual progress.
+- This command is a convenience — it never skips phases or bypasses verification.

package/base/commands/plan.md

@@ -4,19 +4,36 @@ description: Create a dated work plan for the current project. Writes to vault p
 
 You are creating a work plan for the current project.
 
-**Step 1 — Detect project**
+**Step 1 — Detect project and read SPEC**
 - Read vault_path from `~/.claude/praxis.config.json`
 - Match CWD to `local_path` in vault `_index.md`
 - Read `status.md` — check if `current_plan:` is already set
 - If current_plan is set: warn. Ask if starting a new plan or updating the existing one.
 
-**Step 2 — Gather plan details**
-Ask in a single message:
-- What is the task or feature this plan covers?
-- What is the target completion date (or "open" if no deadline)?
-- Any known blockers or dependencies upfront?
+**Step 1b — Consume discuss output**
+Check the conversation for a SPEC block from `/discuss`:
+```
+SPEC
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+PROBLEM:      ...
+DELIVERABLE:  ...
+ACCEPTANCE:   ...
+BOUNDARIES:
+  In:  ...
+  Out: ...
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+- If a SPEC block exists in conversation: use it as the plan's objective, acceptance criteria, and boundaries.
+  Do NOT re-ask what the task is.
+- If no SPEC block in conversation: check vault for `{vault_path}/plans/*-context.md` (most recent).
+  If found and recent (today): read it and use as the SPEC source.
+- If no SPEC block found anywhere (plan invoked directly): ask in a single message:
+  - What is the task or feature this plan covers?
+  - What is the target completion date (or "open" if no deadline)?
+  - Any known blockers or dependencies upfront?
 
-**Step 3 — Build the plan**
+**Step 2 — Build the plan**
 
 ```markdown
 ---
@@ -32,6 +49,14 @@ source: agent
 ## Objective
 One sentence.
 
+## SPEC
+PROBLEM: {from SPEC block or user input}
+DELIVERABLE: {from SPEC block or user input}
+ACCEPTANCE: {from SPEC block or user input}
+BOUNDARIES:
+  In: {from SPEC block or user input}
+  Out: {from SPEC block or user input}
+
 ## Context
 Why this work is happening now.
 
@@ -66,7 +91,7 @@ Checkpoint types:
 - `checkpoint: human-verify` — user must validate output before proceeding
 - No annotation = autonomous (default)
 
-**Step 3b — Dependency and boundary validation**
+**Step 2b — Dependency and boundary validation**
 After building the milestone list:
 - Scan for circular dependencies (topological sort). If cycle detected:
   report the cycle and ask user to break it.
@@ -79,9 +104,9 @@ After building the milestone list:
 - Validate checkpoints: milestones with architectural decisions or user-facing output
   should be annotated as `checkpoint: decision` or `checkpoint: human-verify`.
 
-**Step 4 — Write and wire**
+**Step 3 — Write and wire**
 - Write to: `{vault_path}/plans/{YYYY-MM-DD}_{kebab-title}.md`
-- Update `status.md`: set `current_plan:`, update `last_updated`, update `## Now What`
+- Update `status.md`: set `current_plan:`, update `last_updated`, set `loop_position: PLAN`, update `## Now What`
 - Update `claude-progress.json` milestones array
 - Report:
 ```
@@ -89,3 +114,6 @@ After building the milestone list:
 ✓ status.md:      current_plan updated
 ✓ progress.json:  milestone added
 ```
+
+The plan file now contains the SPEC — `/execute` reads it directly.
+No information is lost at the discuss→plan→execute boundary.

package/base/commands/quick.md

@@ -0,0 +1,40 @@
+---
+description: Ad-hoc task with full quality guarantees in a single compressed flow. Use for tasks that need planning but aren't worth the full loop.
+---
+
+You are running a quick task — full guarantees, compressed flow.
+
+**Step 1 — Capture the task**
+The user describes the task inline with the command (e.g., `/quick add error handling to the API route`).
+If no description provided: ask "What's the task?"
+
+**Step 2 — Inline SPEC**
+Synthesize from the description (do not ask the user to fill out a form):
+- PROBLEM: why this needs doing
+- DELIVERABLE: what will change
+- ACCEPTANCE: how to verify
+- BOUNDARIES: what's out of scope
+
+Output the SPEC block, then proceed immediately — no separate discuss or plan phase.
+
+**Step 3 — Inline plan**
+Generate a 1-3 milestone plan. Do NOT write to vault — keep it in conversation only.
+Each milestone: description + files + verification command.
+
+**Step 4 — Execute**
+Implement each milestone in sequence. Follow the same rules as `/execute`:
+- Declare file group before editing
+- One milestone at a time
+- No scope expansion without approval
+
+**Step 5 — Verify**
+After all milestones: run lint + test. Show output.
+If failing: fix immediately (stop-and-fix rule applies).
+
+**Step 6 — Commit**
+On pass: commit with conventional commit format. Update `status.md` briefly.
+
+**Rules:**
+- This is a compressed full loop, not a shortcut that skips verification.
+- No vault plan file written — this is for tasks that don't need persistent tracking.
+- If the task turns out to need >3 milestones: stop and suggest `/discuss` instead.

package/base/commands/review.md

@@ -1,5 +1,5 @@
 ---
-description: Manual code review trigger. Launches a subagent to review a diff for bugs, security, and convention violations. Use independently of GSD phases.
+description: Manual code review trigger. Launches a subagent to review a diff for bugs, security, and convention violations. Use independently of Praxis phases.
 ---
 
 You are running a manual code review.
@@ -75,7 +75,7 @@ CLEAN
 - Vault indexing is automatic.
 
 **Rules:**
-- Works independently of GSD phases.
+- Works independently of Praxis phases.
 - Never skip the subagent — review must come from fresh context.
 - Subagent receives zero conversation history.
 - If no project CLAUDE.md exists: proceed with base rules only.

package/base/commands/ship.md

@@ -71,4 +71,4 @@ Checks:  secrets ✓  lint ✓  types ✓  tests ✓
 - Never skip pre-flight checks. They are the safety net.
 - Never force-push without explicit user approval.
 - If the diff touches >20 files: warn about PR size and suggest splitting.
-- This command is the end of a GSD cycle — run after `/gsd:verify` passes.
+- This command is the end of a Praxis cycle — run after `/verify` passes.

package/base/commands/spec.md

@@ -1,9 +1,14 @@
 ---
-description: Create a structured spec or ADR for the current project. Writes directly to vault specs/ directory. Use for any significant decision, design, or work item that needs documentation before implementation.
+description: Create a structured spec or ADR for the current project. Writes to vault specs/ directory. Use for architecture decisions, technical designs, and risk documentation — NOT for task framing (use /discuss for that).
 ---
 
 You are creating a spec for the current project.
 
+**When to use /spec vs /discuss:**
+- `/discuss` frames a task — "what are we building and why?" Produces a SPEC block for `/plan`.
+- `/spec` documents a decision or design — "what did we decide and what are the consequences?"
+  Use for ADRs, technical specs, and risk entries that outlive the current task.
+
 **Step 1 — Identify project context**
 - Read vault_path from `~/.claude/praxis.config.json`
 - Detect project from CWD matching `local_path` in vault `_index.md`
@@ -13,7 +18,7 @@ You are creating a spec for the current project.
 **Step 2 — Gather spec details**
 Ask the following in a single message:
 - What is this spec for? (one sentence)
-- Type: ADR (architecture decision) / PLAN (work plan) / RISK (risk register entry) / SPEC (technical spec)
+- Type: ADR (architecture decision) / RISK (risk register entry) / SPEC (technical spec)
 - Is there an existing related spec in `specs/`? (run `obsidian search query="{topic}" limit=3` first)
 
 **Step 2b — Cross-spec conflict check**
@@ -32,11 +37,12 @@ After the vault search from Step 2, check for conflicts with accepted ADRs:
 - Never silently create a spec that contradicts an accepted ADR.
 - If no conflicts: proceed silently.
 
-**Step 3 — Answer the four SPEC questions**
-- **WHAT**: Concrete deliverable
-- **DONE-WHEN**: Specific checks that prove completion
-- **CONSTRAINTS**: Performance, compatibility, compliance requirements
-- **NON-GOALS**: What this explicitly does NOT include
+**Step 3 — Capture the decision or design**
+For ADR: What was decided, what context drove it, what alternatives were considered.
+For SPEC: What is being built, what constraints apply, what the design looks like.
+For RISK: What the risk is, what triggers it, what mitigates it.
+
+Synthesize from the conversation — do not present a blank form to fill out.
 
 **Step 4 — Write the spec**
 

package/base/commands/standup.md

@@ -7,16 +7,10 @@ You are generating a standup summary for the current project.
 **Step 1 — Load project state**
 Read vault_path from `~/.claude/praxis.config.json`. Then read in order (detect from CWD — do not ask):
 1. `{vault_path}/_index.md` → project name, stack, goals
-1b. `{vault_path}/claude-progress.json` → check `ralph_state`
 2. `{vault_path}/status.md` → current_plan, last_updated, What/So What/Now What
 3. `{vault_path}/tasks.md` → Active, Blocked sections
 4. If `current_plan` is set → read `{vault_path}/plans/{current_plan}` → Milestones, Blockers
 
-**Ralph state check:**
-- If `.ralph_state.current_story` is set: note "Ralph iteration active" for output
-- Use `completed_stories` count and `last_iteration` alongside `status.md`
-- If `status.md` last_updated is stale but `ralph_state.last_iteration` is recent: suppress stale warning
-
 **Step 2 — Output standup format**
 
 ```
@@ -30,10 +24,6 @@ Read vault_path from `~/.claude/praxis.config.json`. Then read in order (detect
   IN PROGRESS
   {active plan name} — {next milestone}
 
-  RALPH STATUS
-  {current story if active, or "No Ralph iteration running"}
-  Completed: {n} stories | Last: {last_iteration}
-
   BLOCKED
   {blocker with owner if known}
 

package/base/commands/{gsd-verify.md → verify.md}

@@ -2,7 +2,7 @@
 description: Validation phase — runs test/lint/typecheck/build and reports PASS or FAIL. Use after each milestone completion.
 ---
 
-You are running the GSD verification phase for the current milestone.
+You are running the verification phase for the current milestone.
 
 **Step 1 — Run validation sequence**
 Execute in order, showing actual output (never assertions):
@@ -21,13 +21,14 @@ If no commands are defined: warn and ask user for the correct commands.
 
 **Step 3 — On PASS**
 1. Update the active plan file: mark milestone status as complete
-2. Prompt: "Milestone verified. Ready to commit — proceed?"
-3. After commit: check if more milestones remain
-   - Yes → "Run `/gsd:execute` for the next milestone."
-   - No → "All milestones complete. Running self-review."
+2. Commit immediately — verification passed, no permission needed.
+   Use conventional commit format. See git-workflow.md.
+3. Check if more milestones remain:
+   - Yes → "Milestone committed. Run `/execute` for the next milestone."
+   - No → "All milestones committed. Running self-review."
 4. After ALL milestones: trigger Self-Review Protocol
    - Launch a subagent to review the full diff as a critical code reviewer
-   - Subagent receives ONLY: the diff, the SPEC, relevant rules files
+   - Subagent receives ONLY: the diff, the SPEC (from plan file `## SPEC` section), relevant rules files
    - Address all Critical and Major findings before reporting done
 
 **Step 3b — UNIFY (mandatory after all milestones verified)**