@leing2021/super-pi 0.22.1 → 0.23.1

package/extensions/super-pi-extension/model-sync.ts

@@ -1,204 +0,0 @@
-/**
- * CE Model & Thinking Strategy Bridge
- * 
- * 同步 super-pi 的 modelStrategy 和 thinkingStrategy 到 pi-subagents 的 agentOverrides
- * 确保阶段模型和 thinking 等级自动应用到对应的 CE Agent
- */
-
-import * as fs from "node:fs";
-import * as path from "node:path";
-import * as os from "node:os";
-
-// CE Stage to Agent mapping
-const STAGE_AGENT_MAP: Record<string, string[]> = {
-  "01-brainstorm": ["ce-scout", "ce-researcher"],
-  "02-plan": ["ce-planner"],
-  "03-work": ["ce-worker"],
-  "04-review": ["ce-reviewer"],
-  "05-learn": ["ce-oracle"],
-};
-
-// Default fallback
-const DEFAULT_MODEL = "claude-sonnet-4-20250514";
-const DEFAULT_THINKING = "medium";
-
-export interface ModelStrategyConfig {
-  [stage: string]: string;
-}
-
-export interface ThinkingStrategyConfig {
-  [stage: string]: string;
-}
-
-export interface SubagentAgentOverride {
-  model?: string;
-  thinking?: string;
-}
-
-export interface SubagentConfig {
-  agentOverrides?: Record<string, SubagentAgentOverride>;
-}
-
-export interface Settings {
-  modelStrategy?: ModelStrategyConfig;
-  thinkingStrategy?: ThinkingStrategyConfig;
-  subagents?: SubagentConfig;
-  [key: string]: unknown;
-}
-
-/**
- * Read settings from file
- */
-export function readSettings(filePath: string): Settings {
-  if (!fs.existsSync(filePath)) return {};
-  try {
-    return JSON.parse(fs.readFileSync(filePath, "utf-8"));
-  } catch {
-    return {};
-  }
-}
-
-/**
- * Write settings to file
- */
-export function writeSettings(filePath: string, settings: Settings): void {
-  fs.mkdirSync(path.dirname(filePath), { recursive: true });
-  fs.writeFileSync(filePath, JSON.stringify(settings, null, 2) + "\n", "utf-8");
-}
-
-/**
- * Sync modelStrategy and thinkingStrategy to subagents.agentOverrides
- * 
- * This ensures that when pi-subagents runs a CE agent,
- * it uses the model and thinking level configured for that stage.
- */
-export function syncStrategiesToAgentOverrides(settings: Settings): Settings {
-  const modelStrategy = settings.modelStrategy;
-  const thinkingStrategy = settings.thinkingStrategy;
-  
-  if (!modelStrategy && !thinkingStrategy) return settings;
-
-  // Initialize subagents if not present
-  const subagents = settings.subagents || { agentOverrides: {} };
-  const agentOverrides = subagents.agentOverrides || {};
-
-  // Build stage-based override for each agent
-  for (const [stage, agents] of Object.entries(STAGE_AGENT_MAP)) {
-    const model = modelStrategy?.[stage];
-    const thinking = thinkingStrategy?.[stage];
-    
-    if (model || thinking) {
-      for (const agent of agents) {
-        agentOverrides[agent] = {
-          ...agentOverrides[agent],
-          ...(model ? { model } : {}),
-          ...(thinking ? { thinking } : {}),
-        };
-      }
-    }
-  }
-
-  return {
-    ...settings,
-    subagents: {
-      ...subagents,
-      agentOverrides,
-    },
-  };
-}
-
-/**
- * Get the effective model for a stage
- */
-export function getStageModel(stage: string, settings: Settings): string {
-  if (settings.modelStrategy?.[stage]) {
-    return settings.modelStrategy[stage];
-  }
-
-  const agents = STAGE_AGENT_MAP[stage];
-  if (agents && settings.subagents?.agentOverrides) {
-    for (const agent of agents) {
-      const override = settings.subagents.agentOverrides[agent];
-      if (override?.model) {
-        return override.model;
-      }
-    }
-  }
-
-  return settings.modelStrategy?.default || DEFAULT_MODEL;
-}
-
-/**
- * Get the effective thinking level for a stage
- */
-export function getStageThinking(stage: string, settings: Settings): string {
-  if (settings.thinkingStrategy?.[stage]) {
-    return settings.thinkingStrategy[stage];
-  }
-
-  const agents = STAGE_AGENT_MAP[stage];
-  if (agents && settings.subagents?.agentOverrides) {
-    for (const agent of agents) {
-      const override = settings.subagents.agentOverrides[agent];
-      if (override?.thinking) {
-        return override.thinking;
-      }
-    }
-  }
-
-  return DEFAULT_THINKING;
-}
-
-/**
- * Auto-sync settings on startup
- */
-export function autoSyncSettings(projectRoot?: string): { home: boolean; project: boolean } {
-  const homeSettingsPath = path.join(os.homedir(), ".pi", "agent", "settings.json");
-  const projectSettingsPath = projectRoot 
-    ? path.join(projectRoot, ".pi", "settings.json")
-    : null;
-
-  let homeSynced = false;
-  let projectSynced = false;
-
-  // Sync home settings
-  const homeSettings = readSettings(homeSettingsPath);
-  const syncedHome = syncStrategiesToAgentOverrides(homeSettings);
-  if (JSON.stringify(homeSettings) !== JSON.stringify(syncedHome)) {
-    writeSettings(homeSettingsPath, syncedHome);
-    homeSynced = true;
-    console.log("[super-pi-extension] Synced modelStrategy + thinkingStrategy to agentOverrides");
-  }
-
-  // Sync project settings
-  if (projectSettingsPath && fs.existsSync(projectSettingsPath)) {
-    const projectSettings = readSettings(projectSettingsPath);
-    const syncedProject = syncStrategiesToAgentOverrides(projectSettings);
-    if (JSON.stringify(projectSettings) !== JSON.stringify(syncedProject)) {
-      writeSettings(projectSettingsPath, syncedProject);
-      projectSynced = true;
-      console.log("[super-pi-extension] Synced modelStrategy + thinkingStrategy (project)");
-    }
-  }
-
-  return { home: homeSynced, project: projectSynced };
-}
-
-/**
- * CLI helper to sync settings
- */
-export function syncSettingsCli(): void {
-  const cwd = process.cwd();
-  const result = autoSyncSettings(cwd);
-  if (result.home || result.project) {
-    console.log("[super-pi-extension] Settings synced successfully");
-  } else {
-    console.log("[super-pi-extension] No settings needed syncing");
-  }
-}
-
-// Run if called directly
-const isMain = process.argv[1] && process.argv[1].endsWith("model-sync.ts");
-if (isMain) {
-  syncSettingsCli();
-}

package/skills/08-status/SKILL.md

@@ -1,41 +0,0 @@
----
-name: 08-status
-description: Inspect repo-local workflow artifacts and recommend the next Compound Engineering step.
----
-
-# Status
-
-Use this skill when the user wants to know the current state of the Compound Engineering workflow in this repository.
-
-## What to scan
-
-Use the `workflow_state` tool to get structured artifact state. It scans these repo-local locations:
-
-- `docs/brainstorms/`
-- `docs/plans/`
-- `docs/solutions/`
-- `.context/compound-engineering/`
-
-Use the `session_history` tool to check recent CE skill executions and their outcomes.
-
-If `workflow_state` is not available, fall back to `bash` with `ls` and `find` to check which directories and recent files exist, then use `read` on the most relevant recent artifact.
-
-## Recommendation logic
-
-- If there is no recent `docs/brainstorms/` artifact and the request is still ambiguous, recommend `01-brainstorm` next.
-- If a recent brainstorm exists but there is no matching plan in `docs/plans/`, recommend `02-plan` next.
-- If a recent plan exists and implementation appears incomplete, recommend `03-work` next.
-- If code has changed after planning, recommend `04-review` next.
-- If a problem was just solved and there is no matching learning in `docs/solutions/`, recommend `05-learn` next.
-- If multiple artifacts exist, summarize them briefly and name the single best next step.
-
-## Output format
-
-Return:
-
-- latest relevant brainstorm
-- latest relevant plan
-- latest relevant solution
-- latest relevant runtime artifact under `.context/compound-engineering/`
-- recommended next step
-- why this is the next step

package/skills/08-status/references/artifact-locations.md

@@ -1,10 +0,0 @@
-# Artifact Locations
-
-| Artifact | Path |
-|---|---|
-| Brainstorm | `docs/brainstorms/` |
-| Plan | `docs/plans/` |
-| Solution | `docs/solutions/` |
-| Runtime | `.context/compound-engineering/` |
-
-Use `bash` with `ls` and `find` to scan these paths.

package/skills/09-help/SKILL.md

@@ -1,37 +0,0 @@
----
-name: 09-help
-description: Explain when to use each Compound Engineering Phase 1 skill and how they connect.
----
-
-# Help
-
-Use this skill when the user asks how to use the package, which workflow step comes next, or which Compound Engineering skill fits the current task.
-
-## Phase 1 skill guide
-
-- `01-brainstorm` — use when the request is ambiguous, needs requirements discovery, or the user has a new idea. Three modes: CE requirements discovery (adding features), Startup Diagnostic (YC-style forcing questions for new products/startups), Builder Mode (side projects, hackathons, learning).
-- `02-plan` — use when requirements are clear enough to turn into implementation units. After planning, user can optionally run a CEO-style strategic review or strict review (error maps, failure modes, test diagrams).
-- `03-work` — use when there is a plan or a tightly scoped task ready for controlled execution.
-- `04-review` — use after code changes to produce structured findings. After code review, user can optionally extend to browser-based QA testing (find visual/functional bugs with agent-browser) and regression test generation.
-- `05-learn` — use after solving a problem so the repo gains a durable learning in `docs/solutions/`.
-- `08-status` — use when the user wants to know which artifact already exists and what the next workflow step should be.
-
-## Recommended flow
-
-1. Start with `01-brainstorm` when the problem is still fuzzy or you have a new idea.
-   - **Startup founders** get the YC-style diagnostic: demand reality, status quo, narrowest wedge.
-   - **Side project builders** get generative brainstorming: coolest version, fastest path to ship.
-   - **Feature additions** get the standard CE requirements discovery.
-2. Move to `02-plan` once the desired behavior is clear.
-   - Optionally run **CEO Review** to challenge premises, map alternatives, check dream-state alignment.
-   - Or **Strict Review** for full error maps, failure modes, and test diagrams.
-3. Use `03-work` to execute the plan.
-4. Run `04-review` after implementation.
-   - Optionally extend to **Browser QA** for visual and functional bug finding.
-   - Or **Browser QA + Regression Tests** to also generate automated test coverage.
-5. Capture key learnings with `05-learn`.
-6. Use `08-status` at any point to inspect repo-local workflow state.
-
-## Output
-
-When responding, explain the smallest useful next step instead of forcing the full sequence.

package/skills/09-help/references/workflow-sequence.md

@@ -1,9 +0,0 @@
-# Workflow Sequence
-
-1. `01-brainstorm` → clarify the problem (CE mode / Startup Diagnostic / Builder Mode)
-2. `02-plan` → break it into concrete units (optionally + CEO Review / Strict Review)
-3. `03-work` → execute the plan
-4. `04-review` → inspect the changes (optionally + Browser QA / QA + Regression Tests)
-5. `05-learn` → save key learnings
-
-Use `08-status` at any point to see where you are.

package/skills/10-rules/SKILL.md

@@ -1,76 +0,0 @@
----
-name: 10-rules
-description: "Progressively load project coding rules on demand. Auto-triggered by plan, work, and review skills, or run manually with /skill:10-rules."
----
-
-# Rules
-
-Rules are loaded from two locations with clear priority:
-
-1. **Project-level** `{repo-root}/rules/` — if it exists, takes priority. Users maintain this themselves; survives `pi update`.
-2. **Package-level** `rules/` in the super-pi package — built-in defaults, used when no project-level override exists.
-
-Detection: check `{repo-root}/rules/` first. If a file exists at the project level for the topic being loaded, use it. Otherwise fall back to the package-level copy.
-
-## Core rule
-
-Do not load the entire rules tree by default. Read only the files needed for the current task.
-
-## Pre-flight: what to load by phase
-
-### Before planning (02-plan)
-
-Read at minimum:
-- `rules/common/development-workflow.md`
-- `rules/common/testing.md`
-- **Detect the active language** from the project: check for `tsconfig.json` → typescript, `package.json` (without tsconfig) → javascript, `Cargo.toml` → rust, `go.mod` → golang, `pubspec.yaml` → dart, `pom.xml`/`build.gradle` → java, `*.sln`/`*.csproj` → csharp, `Package.swift` → swift, `requirements.txt`/`pyproject.toml`/`setup.py` → python, `composer.json` → php, `Makefile.PL`/`cpanfile` → perl, `build.gradle.kts` → kotlin. Load all files in the matching language directory (e.g. `rules/typescript/`).
-- `rules/web/` files if the task involves frontend/browser concerns
-
-### Before implementation (03-work)
-
-Read the common minimum above, plus:
-- **Detect the active language** from the project: check for `tsconfig.json` → typescript, `package.json` (without tsconfig) → javascript, `Cargo.toml` → rust, `go.mod` → golang, `pubspec.yaml` → dart, `pom.xml`/`build.gradle` → java, `*.sln`/`*.csproj` → csharp, `Package.swift` → swift, `requirements.txt`/`pyproject.toml`/`setup.py` → python, `composer.json` → php, `Makefile.PL`/`cpanfile` → perl, `build.gradle.kts` → kotlin. Load all files in the matching language directory.
-- `rules/web/` files if the task involves frontend/browser concerns
-
-### Before review (04-review)
-
-Read at minimum:
-- `rules/common/code-review.md`
-- **Detect the active language** from the changed files: use the same language detection as above. Load all files in the matching language directory.
-- `rules/web/` files if the review involves frontend/browser changes
-
-## Progressive loading order
-
-1. **Workflow** — `common/development-workflow.md`
-2. **Testing/TDD** — `common/testing.md`
-3. **Scenario** — `web/*` only if frontend is relevant
-4. **Language** — matching language directory only
-5. **Additional** — security, performance, patterns, hooks, coding-style — only when the task calls for it
-
-## Rule precedence
-
-When the same topic exists at multiple layers, higher priority wins:
-
-```
-language-specific > web > common
-```
-
-Override mapping by topic:
-- `common/testing.md` ← `web/testing.md` ← `<lang>/testing.md`
-- `common/coding-style.md` ← `web/coding-style.md` ← `<lang>/coding-style.md`
-- `common/patterns.md` ← `web/patterns.md` ← `<lang>/patterns.md`
-- `common/security.md` ← `web/security.md` ← `<lang>/security.md`
-- `common/hooks.md` ← `web/hooks.md` ← `<lang>/hooks.md`
-
-## Available layers
-
-- `common/` — always relevant baseline (10 files)
-- `typescript/`, `python/`, `cpp/`, `csharp/`, `dart/`, `golang/`, `java/`, `kotlin/`, `perl/`, `php/`, `rust/`, `swift/` — language-specific overrides (5 files each)
-- `web/` — frontend/web scenario (7 files, includes additive-only `design-quality.md` and `performance.md`)
-
-## Output expectation
-
-When rules are loaded, state briefly:
-- which rule files were loaded
-- which are acting as overrides
-- what constraints they impose on the current task