@chankov/agent-skills 0.3.0 → 0.3.2

package/.versions/0.3.2/.pi/harnesses/tilldone/package.json

@@ -0,0 +1,6 @@
+{
+  "name": "agent-skills-pi-tilldone",
+  "private": true,
+  "type": "module",
+  "main": "index.ts"
+}

package/.versions/0.3.2/.pi/harnesses/tool-counter/README.md

@@ -0,0 +1,31 @@
+# tool-counter
+
+Rich two-line custom footer.
+
+> Ported from [`pi-vs-claude-code`](https://github.com/disler/pi-vs-claude-code) by [disler](https://github.com/disler) (MIT). See the [extension catalog](../../../docs/pi-extensions.md).
+
+## What it does
+
+Replaces the pi footer with two information-dense lines:
+
+- **Line 1** — model + context meter on the left; tokens in/out + cost on the right
+- **Line 2** — cwd (and git branch) on the left; a per-tool call tally on the right
+
+It accumulates token and cost figures by traversing the session branch, and updates the
+branch display on `onBranchChange`.
+
+## Commands & tools
+
+None — footer only.
+
+## Usage
+
+```bash
+pi -e .pi/harnesses/tool-counter/index.ts
+```
+
+## Upstream changes
+
+- Theme integration removed — the `themeMap.ts` import and the `applyExtensionDefaults()`
+  call were stripped (this repo does not ship pi themes). The footer renders against pi's
+  active theme.

package/.versions/0.3.2/.pi/harnesses/tool-counter/index.ts

@@ -0,0 +1,100 @@
+/**
+ * Tool Counter — Rich two-line custom footer
+ *
+ * Line 1: model + context meter on left, tokens in/out + cost on right
+ * Line 2: cwd (branch) on left, tool call tally on right
+ *
+ * Demonstrates: setFooter, footerData.getGitBranch(), onBranchChange(),
+ * session branch traversal for token/cost accumulation.
+ *
+ * Usage: pi -e extensions/tool-counter.ts
+ */
+
+import type { AssistantMessage } from "@mariozechner/pi-ai";
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import { truncateToWidth, visibleWidth } from "@mariozechner/pi-tui";
+import { basename } from "node:path";
+
+export default function (pi: ExtensionAPI) {
+	const counts: Record<string, number> = {};
+
+	pi.on("tool_execution_end", async (event) => {
+		counts[event.toolName] = (counts[event.toolName] || 0) + 1;
+	});
+
+	pi.on("session_start", async (_event, ctx) => {
+		ctx.ui.setFooter((tui, theme, footerData) => {
+			const unsub = footerData.onBranchChange(() => tui.requestRender());
+
+			return {
+				dispose: unsub,
+				invalidate() {},
+				render(width: number): string[] {
+					// --- Line 1: cwd + branch (left), tokens + cost (right) ---
+					let tokIn = 0;
+					let tokOut = 0;
+					let cost = 0;
+					for (const entry of ctx.sessionManager.getBranch()) {
+						if (entry.type === "message" && entry.message.role === "assistant") {
+							const m = entry.message as AssistantMessage;
+							tokIn += m.usage.input;
+							tokOut += m.usage.output;
+							cost += m.usage.cost.total;
+						}
+					}
+
+					const fmt = (n: number) => n < 1000 ? `${n}` : `${(n / 1000).toFixed(1)}k`;
+					const dir = basename(ctx.cwd);
+					const branch = footerData.getGitBranch();
+
+					// --- Line 1: model + context meter (left), tokens + cost (right) ---
+					const usage = ctx.getContextUsage();
+					const pct = usage ? usage.percent : 0;
+					const filled = Math.round(pct / 10) || 1;
+					const bar = "#".repeat(filled) + "-".repeat(10 - filled);
+					const model = ctx.model?.id || "no-model";
+
+					const l1Left =
+						theme.fg("dim", ` ${model} `) +
+						theme.fg("warning", "[") +
+						theme.fg("success", "#".repeat(filled)) +
+						theme.fg("dim", "-".repeat(10 - filled)) +
+						theme.fg("warning", "]") +
+						theme.fg("dim", " ") +
+						theme.fg("accent", `${Math.round(pct)}%`);
+
+					const l1Right =
+						theme.fg("success", `${fmt(tokIn)}`) +
+						theme.fg("dim", " in ") +
+						theme.fg("accent", `${fmt(tokOut)}`) +
+						theme.fg("dim", " out ") +
+						theme.fg("warning", `$${cost.toFixed(4)}`) +
+						theme.fg("dim", " ");
+
+					const pad1 = " ".repeat(Math.max(1, width - visibleWidth(l1Left) - visibleWidth(l1Right)));
+					const line1 = truncateToWidth(l1Left + pad1 + l1Right, width, "");
+
+					// --- Line 2: cwd + branch (left), tool tally (right) ---
+					const l2Left =
+						theme.fg("dim", ` ${dir}`) +
+						(branch
+							? theme.fg("dim", " ") + theme.fg("warning", "(") + theme.fg("success", branch) + theme.fg("warning", ")")
+							: "");
+
+					const entries = Object.entries(counts);
+					const l2Right = entries.length === 0
+						? theme.fg("dim", "waiting for tools ")
+						: entries.map(
+							([name, count]) =>
+								theme.fg("accent", name) + theme.fg("dim", " ") + theme.fg("success", `${count}`)
+						).join(theme.fg("warning", " | ")) + theme.fg("dim", " ");
+
+					const pad2 = " ".repeat(Math.max(1, width - visibleWidth(l2Left) - visibleWidth(l2Right)));
+					const line2 = truncateToWidth(l2Left + pad2 + l2Right, width, "");
+
+					return [line1, line2];
+				},
+			};
+		});
+	});
+}

package/.versions/0.3.2/.pi/harnesses/tool-counter/package.json

@@ -0,0 +1,6 @@
+{
+  "name": "agent-skills-pi-tool-counter",
+  "private": true,
+  "type": "module",
+  "main": "index.ts"
+}

package/.versions/0.3.2/.pi/harnesses/tool-counter-widget/README.md

@@ -0,0 +1,27 @@
+# tool-counter-widget
+
+Tool-call counts in a widget above the editor.
+
+> Ported from [`pi-vs-claude-code`](https://github.com/disler/pi-vs-claude-code) by [disler](https://github.com/disler) (MIT). See the [extension catalog](../../../docs/pi-extensions.md).
+
+## What it does
+
+Shows a persistent, live-updating widget above the editor with per-tool call counts, each
+tool tinted with its own background colour — e.g. `Tools (12): [Bash 3] [Read 7] [Write 2]`.
+Unlike [`tool-counter`](../tool-counter/README.md), which is a full footer, this is a
+compact widget you can stack with other footers.
+
+## Commands & tools
+
+None — widget only.
+
+## Usage
+
+```bash
+pi -e .pi/harnesses/tool-counter-widget/index.ts
+```
+
+## Upstream changes
+
+- Theme integration removed — the `themeMap.ts` import and the `applyExtensionDefaults()`
+  call were stripped (this repo does not ship pi themes).

package/.versions/0.3.2/.pi/harnesses/tool-counter-widget/index.ts

@@ -0,0 +1,66 @@
+/**
+ * Tool Counter Widget — Tool call counts in a widget above the editor
+ *
+ * Shows a persistent, live-updating widget with per-tool background colors.
+ * Format: Tools (N): [Bash 3] [Read 7] [Write 2]
+ *
+ * Usage: pi -e extensions/tool-counter-widget.ts
+ */
+
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import { Box, Text } from "@mariozechner/pi-tui";
+
+const palette = [
+	[12, 40, 80],    // deep navy
+	[50, 20, 70],    // dark purple
+	[10, 55, 45],    // dark teal
+	[70, 30, 10],    // dark rust
+	[55, 15, 40],    // dark plum
+	[15, 50, 65],    // dark ocean
+	[45, 45, 15],    // dark olive
+	[65, 18, 25],    // dark wine
+];
+
+function bg(rgb: number[], s: string): string {
+	return `\x1b[48;2;${rgb[0]};${rgb[1]};${rgb[2]}m${s}\x1b[49m`;
+}
+
+export default function (pi: ExtensionAPI) {
+	const counts: Record<string, number> = {};
+	const toolColors: Record<string, number[]> = {};
+	let total = 0;
+	let colorIdx = 0;
+
+	pi.on("tool_execution_end", async (event) => {
+		if (!(event.toolName in toolColors)) {
+			toolColors[event.toolName] = palette[colorIdx % palette.length];
+			colorIdx++;
+		}
+		counts[event.toolName] = (counts[event.toolName] || 0) + 1;
+		total++;
+	});
+
+	pi.on("session_start", async (_event, ctx) => {
+		ctx.ui.setWidget("tool-counter", (_tui, theme) => {
+			const text = new Text("", 1, 1);
+
+			return {
+				render(width: number): string[] {
+					const entries = Object.entries(counts);
+					const parts = entries.map(([name, count]) => {
+						const rgb = toolColors[name];
+						return bg(rgb, `\x1b[38;2;220;220;220m  ${name} ${count}  \x1b[39m`);
+					});
+					text.setText(
+						theme.fg("accent", `Tools (${total}):`) +
+						(entries.length > 0 ? " " + parts.join(" ") : "")
+					);
+					return text.render(width);
+				},
+				invalidate() {
+					text.invalidate();
+				},
+			};
+		});
+	});
+}

package/.versions/0.3.2/.pi/harnesses/tool-counter-widget/package.json

@@ -0,0 +1,6 @@
+{
+  "name": "agent-skills-pi-tool-counter-widget",
+  "private": true,
+  "type": "module",
+  "main": "index.ts"
+}

package/.versions/0.3.2/.pi/prompts/build.md

@@ -0,0 +1,24 @@
+---
+description: Implement the next task incrementally — build, test, verify, request review
+---
+
+Load and follow the `incremental-implementation` and `test-driven-development` skills before proceeding.
+
+Pick the next pending task from the plan. For each task:
+
+1. Read the task's acceptance criteria
+2. Load relevant context (existing code, patterns, types)
+3. Write a failing test for the expected behavior (RED)
+4. Implement the minimum code to pass the test (GREEN)
+5. Run the full test suite to check for regressions
+6. Run the build to verify compilation
+7. Present the Standard Slice Summary and ask the user to choose between:
+   - **Approve & continue** — proceed to the next slice
+   - **Request changes** — revise within the same slice, then re-summarize and re-ask
+   - **Compact & continue** — call `request_compaction` (from the `compact-and-continue` extension) with a self-contained `continuationPrompt` describing the remaining slices and the next concrete action, then end the turn so compaction runs; pi will auto-resume from the continuation prompt
+   - **Stop here** — leave changes unstaged and end the session
+   Use the `ask_user` tool (from `pi-ask-user`) when available; otherwise ask in chat. Wait for an explicit choice — do not proceed on silence. If the `request_compaction` tool is not registered (extension not installed), omit the "Compact & continue" option.
+8. Leave changes unstaged; the user handles staging and commits manually
+9. Mark the task complete and move to the next one only after approval
+
+If any step fails, load and follow the `debugging-and-error-recovery` skill.

package/.versions/0.3.2/.pi/prompts/code-simplify.md

@@ -0,0 +1,22 @@
+---
+description: Simplify code for clarity and maintainability — reduce complexity without changing behavior
+---
+
+Load and follow the `code-simplification` skill before proceeding.
+
+Simplify recently changed code (or the specified scope) while preserving exact behavior:
+
+1. Read the repository agent guide and study project conventions
+2. Identify the target code — recent changes unless a broader scope is specified
+3. Understand the code's purpose, callers, edge cases, and test coverage before touching it
+4. Scan for simplification opportunities:
+   - Deep nesting → guard clauses or extracted helpers
+   - Long functions → split by responsibility
+   - Nested ternaries → if/else or switch
+   - Generic names → descriptive names
+   - Duplicated logic → shared functions
+   - Dead code → remove after confirming
+5. Apply each simplification incrementally — run tests after each change
+6. Verify all tests pass, the build succeeds, and the diff is clean
+
+If tests fail after a simplification, revert that change and reconsider. Load and follow `code-review-and-quality` to review the result.

package/.versions/0.3.2/.pi/prompts/doctor-agent-skills.md

@@ -0,0 +1,13 @@
+---
+description: Scan agent-skills install targets for broken symlinks and stale persona references, then offer repairs
+---
+
+Load and follow Step 5 (Doctor preflight) of the `guided-workspace-setup` skill — without running the rest of the install flow. Use this when the user wants the repair pass on its own; the full `/setup-agent-skills` flow runs the same scan automatically as soon as it detects prior install state.
+
+Walk every install-target directory the chosen coding agent uses (`agents/`, `.claude/agents/`, `.opencode/agents/`, `.codex/agents/`, `.gemini/agents/`, `.github/agents/`, `.pi/agents/` and `pi-pi/`, `.claude/skills/`, `.opencode/skills/`, `.pi/skills/`, `.agents/skills`, `.claude/commands/`, `.opencode/commands/`, `.pi/prompts/`, `.claude/references/`, `.claude/hooks/`). For each broken symlink, resolve where it pointed, look for a canonical replacement in the source `agents/` and `skills/` trees, and offer to repoint or delete. Common stale names from the pre-merge persona layout: `reviewer` → `code-reviewer`, `red-team` → `security-auditor`.
+
+Also flag and offer to rewrite any YAML configs (`teams.yaml`, `agent-chain.yaml`, etc.) that still reference removed persona names.
+
+Present findings as a `# | Path | Issue | Suggested fix` table and ask the user to pick which fixes to apply.
+
+Never overwrite a regular file — only act on symlinks whose target is missing. Report `repaired`, `deleted`, and `skipped` counts, and append a `## doctor-runs` line to `.ai/agent-skills-setup.md` with the date, agent, phase (`standalone`), and counts.

package/.versions/0.3.2/.pi/prompts/plan.md

@@ -0,0 +1,16 @@
+---
+description: Break work into small verifiable tasks with acceptance criteria and dependency ordering
+---
+
+Load and follow the `planning-and-task-breakdown` skill before proceeding.
+
+Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
+
+1. Enter plan mode — read only, no code changes
+2. Identify the dependency graph between components
+3. Slice work vertically (one complete path per task, not horizontal layers)
+4. Write tasks with acceptance criteria and verification steps
+5. Add checkpoints between phases
+6. Present the plan for human review
+
+Save the plan to the location the `planning-and-task-breakdown` skill defines (default `docs/plans/{area}/PLAN-{prd-name}-{phase}.md`, with the task list embedded — no separate todo file; overridable per project via `.ai/agent-skills-overrides.md`). Match the project's existing `docs`/`Docs` capitalization.

package/.versions/0.3.2/.pi/prompts/review.md

@@ -0,0 +1,16 @@
+---
+description: Conduct a five-axis code review — correctness, readability, architecture, security, performance
+---
+
+Load and follow the `code-review-and-quality` skill before proceeding.
+
+Review the current changes (staged or recent commits) across all five axes:
+
+1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
+2. **Readability** — Clear names? Straightforward logic? Well-organized?
+3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
+4. **Security** — Input validated? Secrets safe? Auth checked? Load and follow the `security-and-hardening` skill where relevant.
+5. **Performance** — No N+1 queries? No unbounded ops? Load and follow the `performance-optimization` skill where relevant.
+
+Categorize findings as Critical, Important, or Suggestion.
+Output a structured review with specific file:line references and fix recommendations.

package/.versions/0.3.2/.pi/prompts/setup-agent-skills.md

@@ -0,0 +1,19 @@
+---
+description: Guided setup — install agent-skills artifacts into a workspace for a chosen coding agent
+---
+
+Load and follow the `guided-workspace-setup` skill before proceeding.
+
+Run the guided install for a target workspace. If the user passed a workspace path, use it; otherwise ask for it. Detect the running coding agent and confirm it with the user.
+
+Analyse the workspace. If prior install state is found (`.ai/agent-skills-setup.md` or a populated agent directory), run the **Doctor preflight** first (Step 5) — scan for broken symlinks and stale persona references, present findings as a table, and apply the fixes the user picks before continuing.
+
+Then present the install menu as **one multi-select per group** (18 groups across skills, personas, commands, pi extensions/harnesses, references, hooks) with `★` marking recommendations. Each group renders as a `Pick | Item | Status | Rec | Purpose` table; every row carries an explicit status text — `installed · up to date`, `installed · outdated`, `installed · modified`, `not installed`, or `broken · skipped in preflight`. Installed items are **pre-checked `[x]`** so unchecking = remove; not-installed items start `[ ]`. Per-group reply shortcuts: `all`, `recommended` (adds `★` items on top of the pre-selection — never unticks installed ones), `none`, `keep` (accept the pre-selection unchanged), or a list of picks. Never offer `setup`, `doctor`, or `guided-workspace-setup` — those are installer-only and live in the source agent-skills repo.
+
+Unchecking an installed item means *remove it*, but **removal is scoped**: only act on items whose name is in the agent-skills inventory **and** that are recorded in `## install-status` (or are symlinks resolving into the source repo). User-authored skills, custom commands, third-party plugins, and unrelated settings/env keys are left untouched and logged as "Skipped — not owned by agent-skills".
+
+**No cross-tool substitution.** Each row is offered only when the source file the chosen agent needs already exists — for `pi`, that means `.pi/prompts/<name>.md`, `.pi/extensions/<name>/`, etc. Never fall back to `.claude/commands/` (or another agent's tree) to satisfy a pi prompt request; items missing their per-agent source are filtered out of the menu entirely.
+
+**No mid-apply overwrite prompts.** The Step 6 status text already warns that `installed · modified` rows will have local edits overwritten if kept ticked. The user's tick is the consent; the Step 9 confirmation is the single gate. During apply, refresh ticked items unconditionally — never pause to ask "should I overwrite this file?". Genuine errors (permission denied, missing source) still stop and report.
+
+Offer override sections for the workspace's `.ai/agent-skills-overrides.md` based on the analysis, and record what was installed in `.ai/agent-skills-setup.md`. Summarise the full plan and wait for explicit confirmation before writing anything, then perform the setup, re-scan for any new breakage, and report what changed.

package/.versions/0.3.2/.pi/prompts/ship.md

@@ -0,0 +1,17 @@
+---
+description: Run the pre-launch checklist and prepare for production deployment
+---
+
+Load and follow the `shipping-and-launch` skill before proceeding.
+
+Run through the complete pre-launch checklist:
+
+1. **Code Quality** — Tests pass, build clean, lint clean, no TODOs, no console.logs
+2. **Security** — npm audit clean, no secrets in code, auth in place, headers configured
+3. **Performance** — Core Web Vitals good, no N+1 queries, images optimized, bundle sized
+4. **Accessibility** — Keyboard nav works, screen reader compatible, contrast adequate
+5. **Infrastructure** — Env vars set, migrations ready, monitoring configured
+6. **Documentation** — README current, ADRs written, changelog updated
+
+Report any failing checks and help resolve them before deployment.
+Define the rollback plan before proceeding.

package/.versions/0.3.2/.pi/prompts/spec.md

@@ -0,0 +1,15 @@
+---
+description: Start spec-driven development — write a structured specification before writing code
+---
+
+Load and follow the `spec-driven-development` skill before proceeding.
+
+Begin by understanding what the user wants to build. Ask clarifying questions about:
+1. The objective and target users
+2. Core features and acceptance criteria
+3. Tech stack preferences and constraints
+4. Known boundaries (what to always do, ask first about, and never do)
+
+Then generate a structured spec covering all six core areas: objective, commands, project structure, code style, testing strategy, and boundaries.
+
+Save the spec to the location the `spec-driven-development` skill defines (default `docs/prds/{area}/PRD{n}-{topic}.md`; overridable per project via `.ai/agent-skills-overrides.md`). Confirm with the user before proceeding.

package/.versions/0.3.2/.pi/prompts/test.md

@@ -0,0 +1,19 @@
+---
+description: Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern.
+---
+
+Load and follow the `test-driven-development` skill before proceeding.
+
+For new features:
+1. Write tests that describe the expected behavior (they should FAIL)
+2. Implement the code to make them pass
+3. Refactor while keeping tests green
+
+For bug fixes (Prove-It pattern):
+1. Write a test that reproduces the bug (must FAIL)
+2. Confirm the test fails
+3. Implement the fix
+4. Confirm the test passes
+5. Run the full test suite for regressions
+
+For browser-related issues, also load and follow the `browser-testing-with-devtools` skill and verify with Chrome DevTools MCP.

package/.versions/0.3.2/.pi/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.

package/.versions/0.3.2/.version

@@ -0,0 +1 @@
+0.3.2

package/.versions/0.3.2/agents/builder.md

@@ -0,0 +1,6 @@
+---
+name: builder
+description: Implementation and code generation
+tools: read,write,edit,bash,grep,find,ls
+---
+You are a builder agent. Implement the requested changes thoroughly. Write clean, minimal code. Follow existing patterns in the codebase. Test your work when possible.

package/.versions/0.3.2/agents/code-reviewer.md

@@ -0,0 +1,93 @@
+---
+name: code-reviewer
+description: Senior code reviewer that evaluates changes across five dimensions — correctness, readability, architecture, security, and performance. Use for thorough code review before merge.
+tools: read,bash,grep,find,ls
+---
+
+# Senior Code Reviewer
+
+You are an experienced Staff Engineer conducting a thorough code review. Your role is to evaluate the proposed changes and provide actionable, categorized feedback.
+
+## Review Framework
+
+Evaluate every change across these five dimensions:
+
+### 1. Correctness
+- Does the code do what the spec/task says it should?
+- Are edge cases handled (null, empty, boundary values, error paths)?
+- Do the tests actually verify the behavior? Are they testing the right things?
+- Are there race conditions, off-by-one errors, or state inconsistencies?
+
+### 2. Readability
+- Can another engineer understand this without explanation?
+- Are names descriptive and consistent with project conventions?
+- Is the control flow straightforward (no deeply nested logic)?
+- Is the code well-organized (related code grouped, clear boundaries)?
+
+### 3. Architecture
+- Does the change follow existing patterns or introduce a new one?
+- If a new pattern, is it justified and documented?
+- Are module boundaries maintained? Any circular dependencies?
+- Is the abstraction level appropriate (not over-engineered, not too coupled)?
+- Are dependencies flowing in the right direction?
+
+### 4. Security
+- Is user input validated and sanitized at system boundaries?
+- Are secrets kept out of code, logs, and version control?
+- Is authentication/authorization checked where needed?
+- Are queries parameterized? Is output encoded?
+- Any new dependencies with known vulnerabilities?
+
+### 5. Performance
+- Any N+1 query patterns?
+- Any unbounded loops or unconstrained data fetching?
+- Any synchronous operations that should be async?
+- Any unnecessary re-renders (in UI components)?
+- Any missing pagination on list endpoints?
+
+## Output Format
+
+Categorize every finding:
+
+**Critical** — Must fix before merge (security vulnerability, data loss risk, broken functionality)
+
+**Important** — Should fix before merge (missing test, wrong abstraction, poor error handling)
+
+**Suggestion** — Consider for improvement (naming, code style, optional optimization)
+
+## Review Output Template
+
+```markdown
+## Review Summary
+
+**Verdict:** APPROVE | REQUEST CHANGES
+
+**Overview:** [1-2 sentences summarizing the change and overall assessment]
+
+### Critical Issues
+- [File:line] [Description and recommended fix]
+
+### Important Issues
+- [File:line] [Description and recommended fix]
+
+### Suggestions
+- [File:line] [Description]
+
+### What's Done Well
+- [Positive observation — always include at least one]
+
+### Verification Story
+- Tests reviewed: [yes/no, observations]
+- Build verified: [yes/no]
+- Security checked: [yes/no, observations]
+```
+
+## Rules
+
+1. Review the tests first — they reveal intent and coverage
+2. Read the spec or task description before reviewing code
+3. Every Critical and Important finding should include a specific fix recommendation
+4. Don't approve code with Critical issues
+5. Acknowledge what's done well — specific praise motivates good practices
+6. If you're uncertain about something, say so and suggest investigation rather than guessing
+7. Do NOT modify files — the reviewer's output is the report, not edits. Surface fixes as recommendations for the author or a follow-up agent.

package/.versions/0.3.2/agents/documenter.md

@@ -0,0 +1,6 @@
+---
+name: documenter
+description: Documentation and README generation
+tools: read,write,edit,grep,find,ls
+---
+You are a documentation agent. Write clear, concise documentation. Update READMEs, add inline comments where needed, and generate usage examples. Match the project's existing doc style.