@matyah00/openpi 0.1.2

package/prompts/blueprint.md

@@ -0,0 +1,66 @@
+---
+description: Create an implementation blueprint before risky work
+category: planning
+aliases:
+  - plan
+---
+
+Create a concise implementation blueprint for:
+
+$ARGUMENTS
+
+Use `/add` for straightforward work. Use this blueprint when the change touches several files, changes contracts, changes data, has unclear risk, or needs approval before editing.
+
+If the request contains `--deep`, apply ultrathink mode:
+
+- gather more evidence before deciding
+- consider 2-3 approaches
+- trace downstream effects across APIs, data, tests, and UX
+- spend extra effort on parallel-safety and coupling analysis
+
+Process:
+
+1. If this is vague, switch to `/clarify` behavior first.
+2. If a spec is supplied, use `spec-reviewer` before planning.
+3. Use `env_scan`, `project_tree`, and `code_search_batch` to map impact.
+4. Identify files likely to change and tests likely to prove the change.
+5. Use `parallel_safety_check` when the plan has multiple independent milestones.
+6. Use `problem-architect` or `plan-reviewer` for high-risk plans.
+
+Output:
+
+```text
+Blueprint: {title}
+Risk: low | medium | high - {why}
+
+Goal:
+Non-goals:
+
+Evidence:
+- file:line - why it matters
+
+Approaches:
+1.
+2.
+3.
+
+Chosen approach:
+
+Milestones:
+1. {file:line or path} - {change} - {verification}
+
+Parallel waves:
+- Wave 1:
+- Wave 2:
+
+Risks:
+- {risk} - mitigation
+
+Verification:
+- {command or manual check}
+
+Approval gate:
+Await explicit approval before editing.
+```
+
+Do not edit files until the plan is clear.

package/prompts/clarify.md

@@ -0,0 +1,26 @@
+---
+description: Resolve ambiguity before planning or coding
+category: planning
+aliases:
+  - clear
+---
+
+Clarify this request before planning or implementation:
+
+$ARGUMENTS
+
+Work in read-only mode. Do not edit files.
+
+Process:
+
+1. Identify the goal, user, success state, and what is already specified.
+2. Use `env_scan`, `project_tree`, or `code_search_batch` only if project context is needed to ask better questions.
+3. Ask at most five unresolved questions, grouped by:
+   - goal
+   - scope boundary
+   - acceptance criteria
+   - failure modes
+   - constraints
+4. Do not ask implementation-detail questions unless they change user-visible behavior.
+
+Return a concise clarification brief with draft acceptance criteria and explicit open questions.

package/prompts/compress.md

@@ -0,0 +1,23 @@
+---
+description: Compress current task context into a continuation brief
+category: context
+aliases:
+  - prune
+---
+
+Compress the current task context into a continuation brief.
+
+Focus:
+
+1. Current objective.
+2. User constraints and preferences.
+3. Files changed or inspected.
+4. Important commands and outcomes.
+5. Decisions already made.
+6. Remaining work and risks.
+
+Use `spawn_agents` with `context-pruner` if the context is long. Do not solve new work.
+
+Additional focus:
+
+$ARGUMENTS

package/prompts/debate.md

@@ -0,0 +1,23 @@
+---
+description: Adversarial decision protocol for hard tradeoffs
+category: planning
+aliases:
+  - decide
+---
+
+Run an adversarial decision protocol for:
+
+$ARGUMENTS
+
+Use this only for decisions that are costly to reverse or where criteria conflict.
+
+Process:
+
+1. Frame the decision and list the options.
+2. State the decision criteria and their priority.
+3. Use `spawn_agents` with `thinker`, `red-team`, and `plan-reviewer` when useful.
+4. Steelman each option before comparing.
+5. Search for a third option or hybrid if both obvious options are weak.
+6. Return the winner, confidence, deciding evidence, and rollback plan.
+
+Do not edit files.

package/prompts/deep.md

@@ -0,0 +1,36 @@
+---
+description: Deep evidence-led reasoning for hard bugs, architecture, or plans
+category: planning
+aliases:
+  - think
+  - ultrathink
+---
+
+Use ultrathink mode for this task:
+
+$ARGUMENTS
+
+Process:
+
+1. Interpret whether this wraps another command. If it starts with `/blueprint`, `/add`, `/fix`, `/debate`, `/ship`, or another command, follow that command's workflow with deep mode enabled.
+2. Gather evidence first with `env_scan`, `project_tree`, `code_search_batch`, or `spawn_agents` using `file-picker` and `code-searcher`.
+3. Consider at least 2-3 plausible approaches or root causes before choosing.
+4. Trace downstream effects across files, APIs, data, tests, UX, and operations.
+5. Use `spawn_agents` with `thinker` only after evidence is available.
+6. If a plan is produced, use `plan-reviewer` to challenge assumptions, order, tests, and risks.
+7. Return a concrete next patch or decision, not generic advice.
+
+Separate confirmed facts from inference. Include file paths and validation steps.
+
+Output contract:
+
+```text
+Deep read: {one-line task interpretation}
+Decision: {chosen path or answer}
+Why:
+- {evidence-backed reason}
+- {tradeoff}
+Next: {verification command or implementation step}
+```
+
+Do not expose hidden reasoning. Keep the final output concise.

package/prompts/deps.md

@@ -0,0 +1,24 @@
+---
+description: Audit dependency manifests, lockfiles, loose pins, and update risk
+category: quality
+aliases:
+  - dependencies
+---
+
+Audit dependencies for:
+
+$ARGUMENTS
+
+Process:
+
+1. Run `dependency_inventory`.
+2. Use `env_scan` to confirm package managers and frameworks.
+3. If the user explicitly asks for live vulnerability or outdated checks, run the project-native audit command only after confirming it is safe for this repo.
+4. Classify findings:
+   - patch update: low risk
+   - minor update: medium risk
+   - major update: high risk, needs migration plan
+   - missing lockfile: supply-chain risk
+   - loose pin: review risk
+
+Return tables for outdated/risk/unused or say exactly which checks were not run.

package/prompts/explore.md

@@ -0,0 +1,22 @@
+---
+description: Map relevant files and code paths before implementation
+category: discovery
+aliases:
+  - x
+---
+
+Explore the project for this task:
+
+$ARGUMENTS
+
+Use Pi-native discovery:
+
+1. Use `project_tree` for a compact structure map if the relevant area is unclear.
+2. Use `code_search_batch` for symbols, routes, config keys, errors, and user-facing strings.
+3. Use `spawn_agents` when useful:
+   - `directory-lister` for repository shape
+   - `glob-matcher` for file pattern discovery
+   - `code-searcher` for exact search evidence
+   - `librarian` for source-grounded explanation
+
+Return relevant files, line references, tests to run, and what remains unknown. Do not edit files.

package/prompts/ghost-test.md

@@ -0,0 +1,22 @@
+---
+description: Check test integrity for reward-hacking and vacuous pass patterns
+category: quality
+aliases:
+  - test-integrity
+---
+
+Check test integrity for:
+
+$ARGUMENTS
+
+Process:
+
+1. Run `ghost_test_scan`.
+2. Inspect any suspicious files before drawing conclusions.
+3. If the user asks for a canary test, explain the exact temporary test file and command first; do not leave the canary file behind.
+4. Classify verdict:
+   - CLEAN: no static reward-hack patterns found
+   - SUSPICIOUS: static patterns found, needs inspection
+   - COMPROMISED: a canary that must fail unexpectedly passes
+
+Report exact file:line findings and the verification commands used.

package/prompts/goal.md

@@ -0,0 +1,26 @@
+---
+description: Manage durable Pi-native task goals in .pi/memory/goals.md
+category: context
+aliases:
+  - goals
+---
+
+Manage goals for this session:
+
+$ARGUMENTS
+
+Use `goal_state`:
+
+- list goals when no clear action is supplied
+- set a goal when the user gives a new objective
+- complete a goal only when verification is done
+- block a goal only when the blocker is concrete and repeated
+
+Goal records must include:
+
+1. objective
+2. current status
+3. evidence or verification
+4. next action
+
+Do not mark a goal complete just because work paused.

package/prompts/parallel.md

@@ -0,0 +1,42 @@
+---
+description: Plan or run safe parallel agent work with ownership checks
+category: workflow
+aliases:
+  - wave
+---
+
+Prepare parallel execution for:
+
+$ARGUMENTS
+
+Use parallel execution only when milestones are independent.
+
+Process:
+
+1. Identify candidate milestones and likely files for each.
+2. Use `problem-architect` or `code-searcher` if file ownership is unclear.
+3. Run `parallel_safety_check` with milestone ids, files, dependencies, and statuses.
+4. If conflicts exist, return the sequential order instead of forcing parallelism.
+5. If safe, use `spawn_agents` with `mode: "parallel"` and project role agents.
+6. Do not commit, merge, push, delete branches, or create worktrees unless the user explicitly asks.
+
+Output:
+
+```text
+Parallel verdict: PARALLEL_SAFE | SEQUENTIAL_REQUIRED
+
+Milestones:
+- id - title - files - validation
+
+Conflicts:
+-
+
+Dispatch plan:
+- Wave 1:
+- Wave 2:
+
+Merge/validation gate:
+- {commands or review steps}
+```
+
+Never say parallel work is safe without a file-ownership and dependency check.

package/prompts/plan-team.md

@@ -0,0 +1,31 @@
+---
+description: Create a team-oriented implementation plan using Pi-native agents
+category: planning
+aliases:
+  - plan-team
+  - team-plan
+---
+
+Create a planning-only implementation blueprint for:
+
+$ARGUMENTS
+
+Use the Pi-native team model:
+
+- Available specialist roles live in `agents/*.md`.
+- Team sets live in `agents/teams.yaml`.
+- Sequential workflows live in `agents/agent-chain.yaml`.
+- The dispatcher can use `dispatch_agent`.
+- The chain runner can use `run_chain`.
+
+Plan format:
+
+1. Task type and complexity.
+2. Relevant files and source-truth checks.
+3. Recommended team or chain.
+4. Step-by-step tasks with dependencies.
+5. Agent assignment per task.
+6. Verification commands.
+7. Risks and fallback plan.
+
+Planning only. Do not implement until the plan is accepted.

package/prompts/prime.md

@@ -0,0 +1,17 @@
+---
+description: Load project orientation before work
+category: workflow
+aliases:
+  - orient
+---
+
+Orient yourself in this repository before making changes.
+
+1. Inspect the project file tree.
+2. Read the main project instruction files if present: `AGENTS.md`, `README.md`, `.pi/settings.json`.
+3. Identify the package manager, test commands, and main source directories.
+4. Summarize the purpose, stack, entry points, and any safety rules before implementation.
+
+User request:
+
+$ARGUMENTS

package/prompts/review.md

@@ -0,0 +1,23 @@
+---
+description: Review code or changes for bugs and missing tests
+name: code-review
+category: quality
+aliases:
+  - rv
+---
+
+Review the target code or current changes.
+
+Focus on:
+
+1. Bugs and behavioral regressions.
+2. Security or data-loss risks.
+3. Missing tests.
+4. API or workflow contract breaks.
+5. Unnecessary complexity.
+
+Lead with findings ordered by severity and include file/line references when available.
+
+Scope:
+
+$ARGUMENTS

package/prompts/sentinel.md

@@ -0,0 +1,29 @@
+---
+description: Read-only security and environment safety scan
+category: security
+aliases:
+  - security-scan
+---
+
+Run a read-only safety scan for:
+
+$ARGUMENTS
+
+Process:
+
+1. Run `secret_scan`.
+2. Run `dependency_inventory`.
+3. Run `ghost_test_scan` if test trust matters.
+4. Use `code_search_batch` for high-risk patterns:
+   - `eval(`
+   - `child_process.exec`
+   - `shell=True`
+   - `dangerouslySetInnerHTML`
+   - `pickle.load`
+   - `yaml.load`
+   - `ignore previous instructions`
+5. Use `spawn_agents` with `security-auditor` for a full read-only review when available.
+
+Never print full secret values. Redact findings.
+
+Return score, blocking findings, high/medium/low findings, and required fixes before ship.

package/prompts/ship.md

@@ -0,0 +1,30 @@
+---
+description: Pre-ship gate for tests, security, dependency risk, and git readiness
+category: quality
+aliases:
+  - preflight
+---
+
+Run a pre-ship gate for:
+
+$ARGUMENTS
+
+Do not commit or push unless the user explicitly asks for that exact action.
+
+Gate:
+
+1. Run `env_scan`.
+2. Run `secret_scan`; blocking findings stop ship.
+3. Run `ghost_test_scan`; suspicious findings require inspection.
+4. Run `dependency_inventory`; missing lockfiles or loose pins become risk notes.
+5. Inspect `git status --short` and `git diff --stat`.
+6. Run the smallest relevant test/build/typecheck commands from project scripts.
+7. Use `spawn_agents` with `problem-architect` for risk scan and `reviewer` for diff review when useful.
+
+Output:
+
+- Ship verdict: GO | BLOCKED | RISK ACCEPTANCE NEEDED
+- Changed files
+- Commands run and exact outcomes
+- Blocking issues
+- Commit message suggestion if GO

package/prompts/snapshot.md

@@ -0,0 +1,26 @@
+---
+description: Write a mid-session checkpoint to survive context compaction
+category: context
+aliases:
+  - checkpoint
+---
+
+Write a Pi-native session snapshot.
+
+Topic:
+
+$ARGUMENTS
+
+Process:
+
+1. Use `session_state` to read current goals and latest checkpoint.
+2. Summarize only durable context needed to continue.
+3. Use `write_snapshot` with:
+   - current task
+   - decisions
+   - known context
+   - next actions
+   - risks
+4. Print the checkpoint path and content.
+
+Do not solve new work during snapshotting.

package/prompts/spec.md

@@ -0,0 +1,58 @@
+---
+description: Write a structured feature spec before planning or coding
+category: planning
+aliases:
+  - requirements
+---
+
+Write a structured spec for:
+
+$ARGUMENTS
+
+Use source-grounded context only where helpful:
+
+1. Run `env_scan` for stack context if this is a codebase task.
+2. Use `code_search_batch` to find related existing behavior.
+3. If requirements are vague, switch to `/clarify` behavior first.
+4. Use `spawn_agents` with `spec-reviewer` for the final gate when available.
+
+Spec format:
+
+```markdown
+# Spec: {feature title}
+status: draft | ready-for-plan
+
+## Goal
+{who uses this, what problem it solves, and why now}
+
+## User Stories
+- As a {user}, I want {action} so that {outcome}
+
+## Acceptance Criteria
+1. Given {precondition}, when {action}, then {expected outcome}
+2. Given {precondition}, when {action}, then {expected outcome}
+3. Given {precondition}, when {action}, then {expected outcome}
+
+## Data Model Changes
+{changes or "none"}
+
+## API / Interface Changes
+{changes or "none"}
+
+## Out of Scope
+- {explicit exclusion}
+
+## Failure Modes
+| Scenario | Expected behavior |
+| --- | --- |
+
+## Constraints
+- Security:
+- Performance:
+- Compatibility:
+
+## Open Questions
+- [ ] {question or "none"}
+```
+
+Do not write implementation code.

package/prompts/test.md

@@ -0,0 +1,13 @@
+---
+description: Run or design focused verification for a change
+category: quality
+aliases:
+  - verify
+---
+
+Verify this change or behavior:
+
+$ARGUMENTS
+
+Find the smallest meaningful test path first, then expand only if the blast radius requires it.
+Report exact commands, outcomes, and remaining unverified risk.

package/prompts/validate.md

@@ -0,0 +1,19 @@
+---
+description: Select and run targeted validation for current work
+category: quality
+aliases:
+  - check
+---
+
+Validate the current work or this scope:
+
+$ARGUMENTS
+
+Process:
+
+1. Identify the smallest useful validation commands.
+2. Use `spawn_agents` with `tester` or `basher` for isolated validation when helpful.
+3. Use `reviewer` after validation if code changed.
+4. Report exact commands, outcomes, important output lines, and remaining risk.
+
+Do not edit files unless I explicitly ask for fixes.

package/skills/bowser/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: bowser
+description: Headless browser automation using Playwright CLI. Use when you need headless browsing, parallel browser sessions, UI testing, screenshots, web scraping, or browser automation that can run in the background. Keywords - playwright, headless, browser, test, screenshot, scrape, parallel.
+allowed-tools: Bash
+---
+
+# Playwright Bowser
+
+## Purpose
+
+Automate browsers using `playwright-cli` — a token-efficient CLI for Playwright. Runs headless by default, supports parallel sessions via named sessions (`-s=`), and doesn't load tool schemas into context.
+
+## Key Details
+
+- **Headless by default** — pass `--headed` to `open` to see the browser
+- **Parallel sessions** — use `-s=<name>` to run multiple independent browser instances
+- **Persistent profiles** — cookies and storage state preserved between calls
+- **Token-efficient** — CLI-based, no accessibility trees or tool schemas in context
+- **Vision mode** (opt-in) — set `PLAYWRIGHT_MCP_CAPS=vision` to receive screenshots as image responses in context instead of just saving to disk
+
+## Sessions
+
+**Always use a named session.** Derive a short, descriptive kebab-case name from the user's prompt. This gives each task a persistent browser profile (cookies, localStorage, history) that accumulates across calls.
+
+```bash
+# Derive session name from prompt context:
+# "test the checkout flow on mystore.com" → -s=mystore-checkout
+# "scrape pricing from competitor.com"    → -s=competitor-pricing
+# "UI test the login page"               → -s=login-ui-test
+
+playwright-cli -s=mystore-checkout open https://mystore.com --persistent
+playwright-cli -s=mystore-checkout snapshot
+playwright-cli -s=mystore-checkout click e12
+```
+
+Managing sessions:
+```bash
+playwright-cli list                                     # list all sessions
+playwright-cli close-all                                # close all sessions
+playwright-cli -s=<name> close                          # close specific session
+playwright-cli -s=<name> delete-data                    # wipe session profile
+```
+
+## Quick Reference
+
+```
+Core:       open [url], goto <url>, click <ref>, fill <ref> <text>, type <text>, snapshot, screenshot [ref], close
+Navigate:   go-back, go-forward, reload
+Keyboard:   press <key>, keydown <key>, keyup <key>
+Mouse:      mousemove <x> <y>, mousedown, mouseup, mousewheel <dx> <dy>
+Tabs:       tab-list, tab-new [url], tab-close [index], tab-select <index>
+Save:       screenshot [ref], pdf, screenshot --filename=f
+Storage:    state-save, state-load, cookie-*, localstorage-*, sessionstorage-*
+Network:    route <pattern>, route-list, unroute, network
+DevTools:   console, run-code <code>, tracing-start/stop, video-start/stop
+Sessions:   -s=<name> <cmd>, list, close-all, kill-all
+Config:     open --headed, open --browser=chrome, resize <w> <h>
+```
+
+## Workflow
+
+1. Derive a session name from the user's prompt and open with `--persistent` to preserve cookies/state. Always set the viewport via env var at launch:
+```bash
+PLAYWRIGHT_MCP_VIEWPORT_SIZE=1440x900 playwright-cli -s=<session-name> open <url> --persistent
+# or headed:
+PLAYWRIGHT_MCP_VIEWPORT_SIZE=1440x900 playwright-cli -s=<session-name> open <url> --persistent --headed
+# or with vision (screenshots returned as image responses in context):
+PLAYWRIGHT_MCP_VIEWPORT_SIZE=1440x900 PLAYWRIGHT_MCP_CAPS=vision playwright-cli -s=<session-name> open <url> --persistent
+```
+
+3. Get element references via snapshot:
+```bash
+playwright-cli snapshot
+```
+
+4. Interact using refs from snapshot:
+```bash
+playwright-cli click <ref>
+playwright-cli fill <ref> "text"
+playwright-cli type "text"
+playwright-cli press Enter
+```
+
+5. Capture results:
+```bash
+playwright-cli screenshot
+playwright-cli screenshot --filename=output.png
+```
+
+6. **Always close the session when done.** This is not optional — close the named session after finishing your task:
+```bash
+playwright-cli -s=<session-name> close
+```
+
+## Configuration
+
+If a `playwright-cli.json` exists in the working directory, use it automatically. If the user provides a path to a config file, use `--config path/to/config.json`. Otherwise, skip configuration — the env var and CLI defaults are sufficient.
+
+```json
+{
+  "browser": {
+    "browserName": "chromium",
+    "launchOptions": { "headless": true },
+    "contextOptions": { "viewport": { "width": 1440, "height": 900 } }
+  },
+  "outputDir": "./screenshots"
+}
+```
+
+## Full Help
+
+Run `playwright-cli --help` or `playwright-cli --help <command>` for detailed command usage.
+
+See [docs/playwright-cli.md](docs/playwright-cli.md) for full documentation.