supipowers 0.4.0 → 0.6.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "supipowers",
-  "version": "0.4.0",
-  "description": "OMP-native workflow extension inspired by Superpowers.",
+  "version": "0.6.0",
+  "description": "OMP-native workflow extension inspired by supipowers.",
   "type": "module",
   "scripts": {
     "test": "vitest run",
@@ -13,7 +13,7 @@
     "omp-extension",
     "workflow",
     "agent",
-    "superpowers"
+    "supipowers"
   ],
   "license": "MIT",
   "bin": {

package/skills/context-mode/SKILL.md

@@ -0,0 +1,38 @@
+# Context Mode — Tool Routing Instructions
+
+When context-mode sandbox tools are available, prefer them over raw tool calls to keep your context window lean.
+
+## Tool Selection Hierarchy
+
+Use context-mode tools in this priority order:
+
+1. **ctx_batch_execute** — for multi-step operations. Runs multiple commands and searches in a single call.
+   - Use when: you need to run 2+ commands, or combine a command with a search
+   - Example: checking a build AND searching for a symbol
+
+2. **ctx_search** — for querying previously indexed knowledge. No re-execution needed.
+   - Use when: you've already indexed data and need to find something in it
+   - Example: finding a function definition you indexed earlier
+
+3. **ctx_execute / ctx_execute_file** — for single commands or file processing.
+   - Use when: running one command whose output would be large
+   - Example: listing a directory, reading a large log file
+
+4. **Raw Bash/Read/Grep** — only when necessary.
+   - Use when: editing files (Read before Edit), running build/test commands where real-time output matters, or when the output is known to be small
+
+## Forbidden Patterns
+
+- Do NOT use Bash for `curl`/`wget`/HTTP requests — use `ctx_fetch_and_index` instead
+- Do NOT use Read for analyzing large files (>100 lines) — use `ctx_execute_file` to process and summarize
+- Do NOT use Bash for directory listings with >20 expected files — use `ctx_execute`
+
+## Output Constraints
+
+- Keep tool output responses under 500 words when possible
+- Write large artifacts (generated code, data dumps) to files rather than returning them inline
+- Prefer structured summaries over raw output
+
+## Sub-Agent Awareness
+
+These routing instructions apply within sub-agent sessions. When you are a sub-agent dispatched by supipowers, follow the same tool preference hierarchy.

package/skills/qa-strategy/SKILL.md

@@ -1,32 +1,114 @@
 ---
 name: qa-strategy
-description: QA test planning for comprehensive coverage
+description: E2E product testing strategy using Playwright — flow-based, autonomous, close to human interaction
 ---
 
-# QA Strategy Skill
+# E2E Product Testing Strategy
 
-## Test Pyramid
+## Core Principle
 
-1. **Unit tests**: Fast, isolated, cover individual functions
-2. **Integration tests**: Test component interactions
-3. **E2E tests**: Test user-facing flows end-to-end
+Test the product the way a user uses it. Every test simulates a real user flow — navigating, clicking, filling forms, waiting for responses. If a human wouldn't do it, don't test it here.
 
-## When to Write What
+**This is NOT for unit or integration tests.** This pipeline tests complete user journeys through the running application.
 
-- New function → unit test
-- New API endpoint → integration test
-- New user flow → E2E test
-- Bug fix → regression test at the appropriate level
+## Flow Discovery
 
-## Coverage Priorities
+Before writing tests, understand what the product does:
 
-Focus testing effort on:
-1. Business logic (highest value)
-2. Error handling paths
-3. Edge cases in input validation
-4. Integration points (API boundaries, DB queries)
+1. **Scan routes and pages** — every URL a user can visit is a potential flow entry point
+2. **Identify forms** — login, signup, search, create, edit — these are high-value interaction points
+3. **Map navigation** — how does a user get from page A to page B? What's the happy path?
+4. **Find auth boundaries** — what's public vs protected? Test both sides
+5. **Check CRUD operations** — can you create, read, update, delete the core entities?
 
-Don't test:
-- Framework boilerplate
-- Simple getters/setters
-- Third-party library behavior
+## Flow Prioritization
+
+| Priority | Description | Examples |
+|----------|-------------|---------|
+| **Critical** | Revenue or access blocking | Login, checkout, payment |
+| **High** | Core product value | Create/edit main entities, dashboard |
+| **Medium** | Secondary features | Settings, profile, search |
+| **Low** | Nice-to-have | Theme toggle, tooltips |
+
+Test critical and high flows first. Skip low flows if hitting the token budget.
+
+## Playwright Best Practices
+
+### Locators (prefer resilient selectors)
+
+```typescript
+// GOOD — role-based, resilient to styling changes
+page.getByRole('button', { name: 'Submit' })
+page.getByLabel('Email')
+page.getByText('Welcome back')
+page.getByTestId('user-avatar')
+
+// BAD — fragile, breaks on refactoring
+page.locator('.btn-primary')
+page.locator('#submit-btn')
+page.locator('div > form > button:nth-child(2)')
+```
+
+### Assertions
+
+```typescript
+// Wait for navigation
+await expect(page).toHaveURL('/dashboard');
+
+// Wait for element visibility
+await expect(page.getByText('Success')).toBeVisible();
+
+// Wait for element to disappear (loading states)
+await expect(page.getByText('Loading...')).not.toBeVisible();
+```
+
+### Waiting
+
+```typescript
+// GOOD — wait for specific condition
+await page.waitForResponse(resp => resp.url().includes('/api/users'));
+await page.waitForLoadState('networkidle');
+
+// BAD — arbitrary delays
+await page.waitForTimeout(3000);
+```
+
+### Test Structure
+
+One flow per file. Each test in the flow tests a step or variant:
+
+```typescript
+test.describe('Checkout flow', () => {
+  test('adds item to cart', async ({ page }) => { ... });
+  test('fills shipping info', async ({ page }) => { ... });
+  test('completes payment', async ({ page }) => { ... });
+  test('shows confirmation', async ({ page }) => { ... });
+});
+```
+
+## What Makes a Good E2E Test
+
+| Quality | Good | Bad |
+|---------|------|-----|
+| **User-centric** | Tests what a user would do | Tests implementation details |
+| **Independent** | Each test can run alone | Tests depend on previous test state |
+| **Resilient** | Uses role/label selectors | Uses CSS classes or DOM structure |
+| **Fast-failing** | Fails clearly on the broken step | Fails on a timeout with no context |
+| **Readable** | Test name describes the user action | Test name is a technical description |
+
+## Common Pitfalls
+
+1. **Testing internal state** — don't check Redux store, localStorage, or cookies directly. Test what the user sees.
+2. **Flaky waits** — use `waitForResponse` or `waitForSelector`, never `waitForTimeout`.
+3. **Shared state** — each test should set up its own state. Don't rely on test execution order.
+4. **Over-testing** — one flow per critical path. Don't test every permutation of a form.
+5. **Ignoring error states** — test what happens when the API returns an error, the network is slow, or the user enters invalid data.
+
+## Regression Analysis
+
+When a previously-passing test fails:
+
+1. **Read the error** — what element wasn't found? What URL didn't match?
+2. **Check if the app changed** — did a route move? Did a button get renamed?
+3. **Distinguish bug from change** — if the app intentionally changed, the test needs updating. If not, it's a regression.
+4. **Record the finding** — update the flow matrix with the new status and reasoning.

package/src/commands/config.ts

@@ -1,6 +1,7 @@
 import type { ExtensionAPI, ExtensionContext } from "@oh-my-pi/pi-coding-agent";
 import { loadConfig, updateConfig } from "../config/loader.js";
 import { listProfiles } from "../config/profiles.js";
+import { checkInstallation } from "../context-mode/installer.js";
 import type { SupipowersConfig } from "../types.js";
 
 const FRAMEWORK_OPTIONS = [
@@ -126,7 +127,7 @@ function buildSettings(cwd: string): SettingDef[] {
   ];
 }
 
-export function handleConfig(ctx: ExtensionContext): void {
+export function handleConfig(pi: ExtensionAPI, ctx: ExtensionContext): void {
   if (!ctx.hasUI) {
     ctx.ui.notify("Config UI requires interactive mode", "warning");
     return;
@@ -179,13 +180,33 @@ export function handleConfig(ctx: ExtensionContext): void {
       }
     }
   })();
+
+  // Context-mode status (async, fire-and-forget)
+  checkInstallation(
+    (cmd: string, args: string[]) => pi.exec(cmd, args),
+    pi.getActiveTools(),
+  ).then((status) => {
+    const lines = [
+      "",
+      "Context Mode:",
+      `  CLI installed: ${status.cliInstalled ? "\u2713" + (status.version ? ` v${status.version}` : "") : "\u2717"}`,
+      `  MCP configured: ${status.mcpConfigured ? "\u2713" : "\u2717"}`,
+      `  Tools available: ${status.toolsAvailable ? "\u2713" : "\u2717"}`,
+    ];
+    if (!status.mcpConfigured && status.cliInstalled) {
+      lines.push("  \u2192 Run `omp mcp add context-mode` to enable");
+    }
+    ctx.ui.notify(lines.join("\n"), "info");
+  }).catch(() => {
+    // Silently ignore — context-mode status is optional
+  });
 }
 
 export function registerConfigCommand(pi: ExtensionAPI): void {
   pi.registerCommand("supi:config", {
     description: "View and manage Supipowers configuration",
     async handler(_args, ctx) {
-      handleConfig(ctx);
+      handleConfig(pi, ctx);
     },
   });
 }

package/src/commands/fix-pr.ts

@@ -172,7 +172,7 @@ export function registerFixPrCommand(pi: ExtensionAPI): void {
           content: [{ type: "text", text: prompt }],
           display: "none",
         },
-        { deliverAs: "steer" },
+        { deliverAs: "steer", triggerTurn: true },
       );
 
       notifyInfo(ctx, `Fix-PR started: PR #${prNumber}`, `${commentCount} comments to assess | session ${ledger.id}`);

package/src/commands/plan.ts

@@ -130,7 +130,7 @@ export function registerPlanCommand(pi: ExtensionAPI): void {
           content: [{ type: "text", text: prompt }],
           display: "none",
         },
-        { deliverAs: "steer" }
+        { deliverAs: "steer", triggerTurn: true }
       );
 
       notifyInfo(ctx, "Planning started", args ? `Topic: ${args}` : "Describe what you want to build");