feat(M2): Documentation flow, accuracy, consistency cleanup, and cross-platform shell portability

2026-05-03 20:14:44 -05:00
parent 0443381aa0
commit be993429c1
59 changed files with 1898 additions and 385 deletions
@@ -10,6 +10,7 @@ Create and maintain a local plan folder under `ai_plan/` at project root.
 ## Overview

 This skill wraps the current Superpowers flow for the Cursor Agent CLI (`cursor-agent`):
+
 1. Design first with `superpowers:brainstorming`
 2. Then build an implementation plan with `superpowers:writing-plans`
 3. Review the plan iteratively with a second model/provider
@@ -20,6 +21,7 @@ This skill wraps the current Superpowers flow for the Cursor Agent CLI (`cursor-
 ## Prerequisite Check (MANDATORY)

 Required:
+
 - Cursor Agent CLI: `cursor-agent --version` (install via `curl https://cursor.com/install -fsS | bash`). The binary is `cursor-agent` (installed to `~/.local/bin/`). Some environments alias it as `cursor agent` (subcommand of the Cursor IDE CLI) — both forms work, but this skill uses `cursor-agent` throughout.
 - `jq` (required only if using `cursor` as the reviewer CLI): `jq --version` (install via `brew install jq` or your package manager)
 - Superpowers repo: `https://github.com/obra/superpowers`
@@ -51,9 +53,11 @@ If any dependency is missing, stop and return:
 ## Process

 ### Phase 1: Analyze
+
 - Explore the codebase and existing patterns.

 ### Phase 2: Gather Requirements
+
 - Ask questions one at a time until user says ready.
 - Confirm scope, constraints, success criteria, dependencies.

@@ -71,7 +75,6 @@ For shorthand `pi/<pi-model-name>`, split only on the first slash when the prefi

 When `REVIEWER_CLI=pi`, the reviewer model is configured independently from the model running this workflow. If the model/provider is unavailable, surface helper stderr/status and use `pi --list-models [search]` to inspect configured models.

-
 If the user has already specified a reviewer CLI and model (e.g., "create a plan, review with codex o4-mini"), use those values. Otherwise, ask:

 1. **Which CLI should review the plan?**
@@ -113,6 +116,7 @@ REVIEW_ID=$(uuidgen | tr '[:upper:]' '[:lower:]' | head -c 8)
 ```

 Use for temp artifacts:
+
 - `/tmp/plan-${REVIEW_ID}.md`
 - `/tmp/plan-review-${REVIEW_ID}.md`
 - `/tmp/plan-review-${REVIEW_ID}.json` (Cursor only)
@@ -172,6 +176,7 @@ VERDICT: APPROVED
 ```

 Rules:
+
 - Order findings from `P0` to `P3`.
 - `P0` = total blocker, `P1` = major risk, `P2` = must-fix before approval, `P3` = cosmetic / nice to have.
 - Use `- None.` when a severity has no findings.
@@ -194,7 +199,6 @@ Write the reviewer invocation to `/tmp/plan-review-${REVIEW_ID}.sh` as a bash sc
 set -euo pipefail
 ```

-
 **If `REVIEWER_CLI` is `pi`:**

 Fresh call every round (Pi reviewer calls do not use session resume):
@@ -309,6 +313,7 @@ Rules:
 For `cursor`, the command script writes raw JSON to `/tmp/plan-review-${REVIEW_ID}.json`. Do not run `jq` extraction until after the helper or fallback execution completes.

 Notes on Cursor flags:
+
 - `--mode=ask` — read-only mode, no file modifications
 - `--trust` — trust workspace without prompting (required for non-interactive use)
 - `-p` / `--print` — non-interactive mode, output to stdout
@@ -333,6 +338,7 @@ fi
 Run the helper in the foreground and watch its live stdout for `state=in-progress` heartbeats. If your agent environment buffers command output until exit, start the helper in the background and poll `/tmp/plan-review-${REVIEW_ID}.status` separately instead of treating heartbeats as post-hoc-only data.

 After the command completes:
+
 - If `REVIEWER_CLI=cursor`, extract the final review text:

 ```bash
@@ -356,14 +362,14 @@ cp /tmp/plan-review-${REVIEW_ID}.runner.out /tmp/plan-review-${REVIEW_ID}.md
   - `/tmp/plan-review-${REVIEW_ID}.runner.out`
 3. Present review to the user:

-```
+```markdown
 ## Plan Review — Round N (reviewer: ${REVIEWER_CLI} / ${REVIEWER_MODEL})

 [Reviewer feedback]
 ```

-4. While the reviewer is still running, keep waiting as long as fresh `state=in-progress note="In progress N"` heartbeats continue to appear roughly once per minute.
-5. Check verdict:
+1. While the reviewer is still running, keep waiting as long as fresh `state=in-progress note="In progress N"` heartbeats continue to appear roughly once per minute.
+2. Check verdict:
   - **VERDICT: APPROVED** with no `P0`, `P1`, or `P2` findings → proceed to Phase 7 (Initialize workspace)
   - **VERDICT: APPROVED** with only `P3` findings → optionally fix the `P3` items if they are cheap and safe, then proceed
   - **VERDICT: REVISE** or any `P0`, `P1`, or `P2` finding → go to Step 5
@@ -378,7 +384,7 @@ Address the reviewer findings in priority order (`P0` → `P1` → `P2`, then `P

 Summarize revisions for the user:

-```
+```markdown
 ### Revisions (Round N)
 - [Change and reason, one bullet per issue addressed]
 ```
@@ -389,7 +395,6 @@ If a revision contradicts the user's explicit requirements, skip it and note it

 Rewrite `/tmp/plan-review-${REVIEW_ID}.sh` for the next round. The script should contain the reviewer invocation only; do not run it directly.

-
 **If `REVIEWER_CLI` is `pi`:**

 Fresh call with prior-round context (Pi reviewer calls do not use session resume):
@@ -473,7 +478,7 @@ Return to Step 4.

 #### Step 7: Present Final Result

-```
+```markdown
 ## Plan Review — Final (reviewer: ${REVIEWER_CLI} / ${REVIEWER_MODEL})

 **Status:** Approved after N round(s)
@@ -500,16 +505,19 @@ If the round failed, produced empty output, or reached operator-decision timeout
 ### Phase 7: Initialize Local Plan Workspace (MANDATORY)

 At project root:
+
 1. Ensure `ai_plan/` exists. Create it if missing.
 2. Ensure `.gitignore` contains `/ai_plan/`.
 3. If `.gitignore` was changed, commit that change immediately (local commit only).

 Recommended commit message:
+
 - `chore(gitignore): ignore ai_plan local planning artifacts`

 ### Phase 8: Generate Plan Files (MANDATORY)

 Create `ai_plan/YYYY-MM-DD-<short-title>/` with all files below:
+
 1. `original-plan.md` - copy of original planner-generated plan.
 2. `final-transcript.md` - copy of final planning transcript used to reach approved plan.
 3. `milestone-plan.md` - full implementation spec (from template).
@@ -546,6 +554,7 @@ fi
 ```

 Rules:
+
 - Telegram is the only supported notification path. Do not use desktop notifications, `say`, email, or any other notifier.
 - Notification failures are non-blocking, but they must be surfaced to the user.
 - Before stopping for any user interaction, approval, or manual decision, send a Telegram summary first if configured.
@@ -569,12 +578,14 @@ Rules:
 ## Tracker Discipline (MANDATORY)

 Before starting any story:
+
 1. Open `story-tracker.md`
 2. Mark story `in-dev`
 3. Add notes if relevant
 4. Then begin implementation

 After completing any story:
+
 1. Mark story `completed`
 2. Add commit hash in Notes
 3. Review pending stories
@@ -634,4 +645,5 @@ After completing any story:
 - [ ] Telegram notification attempted if configured

 ## Exit Triggers for Question Phase
+
 User says: "ready", "done", "let's plan", "proceed", "enough questions"
@@ -64,15 +64,19 @@ Work from this folder (`ai_plan/YYYY-MM-DD-<short-title>/`) and always follow th
 ## Full Context Reproduction

 ### Project Overview
+
 [What this project/feature is about]

 ### User Requirements
+
 [All gathered requirements]

 ### Scope
+
 [In scope / out of scope]

 ### Dependencies
+
 [External dependencies, prerequisites, related systems]

 ---
@@ -80,16 +84,19 @@ Work from this folder (`ai_plan/YYYY-MM-DD-<short-title>/`) and always follow th
 ## Key Specifications

 ### Type Definitions
+
 ```typescript
 // Copy-paste ready type definitions
 ```

 ### Enums & Constants
+
 ```typescript
 // All enums/constants needed
 ```

 ### API Endpoints
+
 ```typescript
 // Request/response shapes
 ```
@@ -107,16 +114,19 @@ Work from this folder (`ai_plan/YYYY-MM-DD-<short-title>/`) and always follow th
 ## Verification Commands

 ### Lint (changed files first)
+
 ```bash
 # example: <lint-command> <changed-file-1> <changed-file-2>
 ```

 ### Typecheck
+
 ```bash
 # example: <typecheck-command>
 ```

 ### Tests (target changed scope first)
+
 ```bash
 # example: <test-command> <related spec/file>
 ```
@@ -1,11 +1,13 @@
 # [Plan Title]

 ## Overview
+
 - **Goal:** [One sentence describing the end state]
 - **Created:** YYYY-MM-DD
 - **Status:** In Progress | Complete

 ## Planning Guardrails
+
 - This plan assumes design was validated before implementation planning.
 - Skills are invoked via workspace discovery (`.cursor/skills/`).
 - Milestones require verification + local commits + explicit approval before proceeding.
@@ -13,37 +15,46 @@
 ## Context

 ### Requirements
+
 [Gathered requirements from user questions]

 ### Constraints
+
 [Technical, business, or timeline constraints]

 ### Success Criteria
+
 [How we know this is complete]

 ## Architecture

 ### Design Decisions
+
 [Key architectural choices and rationale]

 ### Component Relationships
+
 [How pieces fit together]

 ### Data Flow
+
 [How data moves through the system]

 ## Milestones

 ### M1: [Name]
+
 **Description:** [What this milestone achieves]

 **Acceptance Criteria:**
+
 - [ ] [Criterion 1]
 - [ ] [Criterion 2]

 **Stories:** S-101, S-102, S-103...

 **Milestone Completion Rule (MANDATORY):**
+
 - Run lint/typecheck/tests for changed files.
 - Commit locally (DO NOT push).
 - Stop and ask user for feedback.
@@ -53,15 +64,18 @@
 ---

 ### M2: [Name]
+
 **Description:** [What this milestone achieves]

 **Acceptance Criteria:**
+
 - [ ] [Criterion 1]
 - [ ] [Criterion 2]

 **Stories:** S-201, S-202, S-203...

 **Milestone Completion Rule (MANDATORY):**
+
 - Run lint/typecheck/tests for changed files.
 - Commit locally (DO NOT push).
 - Stop and ask user for feedback.
@@ -73,16 +87,19 @@
 ## Technical Specifications

 ### Types & Interfaces
+
 ```typescript
 // Key type definitions (or equivalent language constructs)
 ```

 ### API Contracts
+
 ```typescript
 // Endpoint signatures, request/response shapes (if applicable)
 ```

 ### Constants & Enums
+
 ```typescript
 // Shared constants (if applicable)
 ```
@@ -99,6 +116,7 @@
 ## Related Plan Files

 This file is part of the plan folder under `ai_plan/`:
+
 - `original-plan.md` - Original approved plan (reference for original intent)
 - `final-transcript.md` - Final planning transcript (reference for rationale/context)
 - `milestone-plan.md` - This file (full specification)
@@ -1,12 +1,14 @@
 # Story Tracker: [Plan Title]

 ## Progress Summary
+
 - **Current Milestone:** M1
 - **Stories Complete:** 0/N
 - **Milestones Approved:** 0/M
 - **Last Updated:** YYYY-MM-DD

 ## Tracking Guardrails
+
 - Update status immediately when work starts (`in-dev`) and when work completes (`completed`).
 - Require explicit user approval at each milestone boundary before continuing.
 - Do not push until all milestones are approved and permission is explicitly granted.
@@ -52,15 +54,18 @@
 ## Update Instructions (MANDATORY)

 Before starting any story:
+
 1. Mark story as `in-dev`
 2. Update "Last Updated"

 After completing any story:
+
 1. Mark story as `completed`
 2. Add local commit hash to Notes
 3. Update "Stories Complete" and "Last Updated"

 At milestone boundary:
+
 1. Run lint/typecheck/tests for changed files
 2. Commit (no push)
 3. Request feedback
@@ -69,4 +74,5 @@ At milestone boundary:
 6. Continue only after approval

 After all milestones approved:
+
 - Ask permission to push and then mark plan completed.