@chankov/agent-skills 0.2.0 → 0.3.0

package/.versions/0.3.0/skills/designing-agents/pi-harness-authoring.md

@@ -0,0 +1,213 @@
+# Authoring a pi Harness
+
+Reference for the harness branch of the `designing-agents` skill. Read this before writing
+any file under `.pi/harnesses/`. It is the harness equivalent of `docs/skill-anatomy.md`.
+
+## What a harness is
+
+A pi harness is a TypeScript pi extension that reshapes a whole session. The 15 in
+`.pi/harnesses/` were ported from `disler/pi-vs-claude-code`; `docs/pi-extensions.md` is
+their catalog. A harness can:
+
+- replace the footer or status line — `minimal`, `tool-counter`
+- gate every tool call and block or confirm it — `damage-control`, `tilldone`, `purpose-gate`
+- register a new tool or `/command` — `tilldone`, `system-select`, `session-replay`
+- inject text into the system prompt — `purpose-gate`, `system-select`
+- orchestrate sub-agents — `agent-team`, `agent-chain`, `subagent-widget`, `pi-pi`
+- add cross-agent messaging — `coms`, `coms-net`
+
+### Harness vs. utility extension — where it lives
+
+pi auto-discovers and loads **every** directory under `.pi/extensions/`. The three there
+(`mcp-bridge`, `chrome-devtools-mcp`, `compact-and-continue`) are always-on utilities that
+coexist. Harnesses are different: they are **mutually exclusive** — two that both replace
+the footer fight, two that register the same CLI flag abort startup. So harnesses live in
+`.pi/harnesses/`, which pi does **not** auto-discover, and load one (or two stacked) at a
+time via `pi -e <path>`. Never put a harness under `.pi/extensions/`.
+
+## Directory anatomy
+
+Every harness is a directory with exactly three files:
+
+```
+.pi/harnesses/<name>/
+  index.ts        # the extension
+  package.json    # four fields, identical shape for every harness
+  README.md       # the discovery surface
+```
+
+### package.json
+
+Identical shape for every harness — only `name` changes:
+
+```json
+{
+  "name": "agent-skills-pi-<name>",
+  "private": true,
+  "type": "module",
+  "main": "index.ts"
+}
+```
+
+Runtime dependencies are **not** declared here. Shared deps (`@sinclair/typebox`, `yaml`)
+live in `.pi/harnesses/package.json` and are installed once by `just install`. The
+`@mariozechner/pi-*` packages are provided by the pi runtime. If a harness needs a new
+dependency, add it to `.pi/harnesses/package.json`, not the per-harness file.
+
+## The ExtensionAPI surface
+
+`index.ts` exports a default function that receives the `ExtensionAPI`:
+
+```ts
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+
+export default function (pi: ExtensionAPI) {
+  // register handlers, tools, and commands here
+}
+```
+
+Use only events and methods confirmed in an existing harness — a misspelled event name
+fails silently. The list below is what the 15 ported harnesses use.
+
+### Events — `pi.on(event, handler)`
+
+Handlers are `async (event, ctx) => …`.
+
+| Event | Fires when | The handler can |
+|---|---|---|
+| `session_start` | A session opens | Initialise state; set footer / widget / status; scan files |
+| `session_switch` / `session_fork` / `session_tree` | The user navigates session history | Reconstruct state from `ctx.sessionManager` |
+| `input` | The user submits a prompt | Return `{ action: "continue" }` or `{ action: "handled" }` to swallow it |
+| `before_agent_start` | Just before the model runs | Return `{ systemPrompt }` to replace or extend the system prompt |
+| `tool_call` | The agent calls any tool | Return `{ block: false }`, or `{ block: true, reason }` to gate it |
+| `agent_end` | The agent finishes a turn | Nudge with `pi.sendMessage`; refresh UI |
+
+### Registering tools and commands
+
+- `pi.registerTool({ name, label, description, parameters, execute, renderCall, renderResult })`
+  — `parameters` is a TypeBox schema (`import { Type } from "@sinclair/typebox"`). The
+  `description` is read by the model, so write it the way you'd write a skill description.
+  `execute` is `async (toolCallId, params, signal, onUpdate, ctx) => { content, details }`.
+- `pi.registerCommand("name", { description, handler })` — adds a `/name` slash command;
+  `handler` is `async (args, ctx) => …`.
+
+### Other pi methods
+
+- `pi.getActiveTools()` / `pi.setActiveTools(names)` — read or restrict the tool set
+- `pi.sendMessage(msg, { triggerTurn })` — inject a message, optionally starting a turn
+- `pi.appendEntry(type, data)` — write a custom entry into the session log
+
+### The context object — `ctx`
+
+- `ctx.cwd` — project root
+- `ctx.model` — active model (`ctx.model?.id`)
+- `ctx.getContextUsage()` — `{ percent }` context-window usage
+- `ctx.getSystemPrompt()` — the current system prompt
+- `ctx.sessionManager.getBranch()` — session entries, for state reconstruction
+- `ctx.abort()` — abort the current turn
+- `ctx.hasUI` — false in headless runs; guard UI-only commands with it
+- `ctx.ui.setFooter(fn)` / `setWidget(id, fn, opts)` / `setStatus(text, id)` — UI surfaces
+- `ctx.ui.notify(text, level)` — transient message (`info` | `warning` | `error` | `success`)
+- `ctx.ui.confirm(title, body, opts)` — yes/no dialog
+- `ctx.ui.select(title, options)` — pick-one dialog
+- `ctx.ui.input(title, placeholder)` — text-input dialog
+- `ctx.ui.custom(fn)` — full-screen overlay component
+
+UI rendering uses `@mariozechner/pi-tui` helpers (`Text`, `Container`, `DynamicBorder`,
+`truncateToWidth`, `visibleWidth`, `matchesKey`). Render against pi's active theme — do
+not ship theme files (the ported harnesses had their theme code stripped).
+
+## index.ts skeleton
+
+The minimum viable harness — adapt to the chosen surface:
+
+```ts
+/**
+ * <Name> — <one-line purpose>
+ *
+ * <2-3 lines on what it does and why.>
+ *
+ * Usage: pi -e .pi/harnesses/<name>/index.ts
+ */
+
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+
+export default function (pi: ExtensionAPI) {
+  pi.on("session_start", async (_event, ctx) => {
+    // initialise state, set UI surfaces
+  });
+
+  // add a tool_call gate / registerTool / registerCommand as the purpose requires
+}
+```
+
+## Copy the closest existing harness
+
+Do not write from scratch. Pick the nearest pattern and adapt it:
+
+| If the harness… | Study | Approx. lines |
+|---|---|---|
+| Replaces the footer with status | `minimal` | 30 |
+| Counts or summarises tool calls | `tool-counter`, `tool-counter-widget` | 70–100 |
+| Gates the session on a precondition | `purpose-gate` | 80 |
+| Blocks tool calls from a rules file | `damage-control` | 200 |
+| Adds a `/command` that picks from files | `system-select` | 165 |
+| Registers a tool + gate + multi-surface UI | `tilldone` | 720 |
+| Orchestrates sub-agents | `agent-team`, `agent-chain`, `subagent-widget` | large |
+
+Start from the smallest one that has the surface you need.
+
+## README.md template
+
+The README is the discovery surface — keep it to these sections, matching the others in
+`.pi/harnesses/`:
+
+```markdown
+# <name>
+
+<One-line subtitle.>
+
+## What it does
+
+<1-2 short paragraphs: the session surface it changes and why it is useful.>
+
+## Commands & tools
+
+<List each `/command` and registered tool — or "None — <surface> only.">
+
+## Requires
+
+<Files, env vars, or a sibling harness it stacks with. Omit the section if nothing.>
+
+## Usage
+
+\`\`\`bash
+pi -e .pi/harnesses/<name>/index.ts
+\`\`\`
+```
+
+A ported harness also carries an attribution blockquote and an "Upstream changes" section.
+A **new** harness authored in this repo needs neither.
+
+## Wiring — three edits beyond the directory
+
+1. **`justfile`** — add a recipe under the matching `# -----` category header:
+   ```
+   # <Name>: <short description>
+   ext-<name>:
+       pi -e .pi/harnesses/<name>/index.ts
+   ```
+   If the harness has no footer of its own, stack `minimal`:
+   `pi -e .pi/harnesses/<name>/index.ts -e .pi/harnesses/minimal/index.ts`.
+2. **`docs/pi-extensions.md`** — add one row to the catalog table:
+   `| [<name>](../.pi/harnesses/<name>/README.md) | <Category> | <what it does> | `just ext-<name>` |`.
+   Categories in use: UI, Focus, Safety, Orchestration, Messaging.
+3. **`.pi/harnesses/package.json`** — add any new runtime dependency (only if one is needed).
+
+## Verify the harness runs
+
+```bash
+just install                          # only if a dependency was added
+pi -e .pi/harnesses/<name>/index.ts    # launches without error
+just ext-<name>                        # the recipe works
+```

package/.versions/0.3.0/skills/documentation-and-adrs/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: documentation-and-adrs
+description: Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
+---
+
+# Documentation and ADRs
+
+## Overview
+
+Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase.
+
+## When to Use
+
+- Making a significant architectural decision
+- Choosing between competing approaches
+- Adding or changing a public API
+- Shipping a feature that changes user-facing behavior
+- Onboarding new team members (or agents) to the project
+- When you find yourself explaining the same thing repeatedly
+
+**When NOT to use:** Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes.
+
+## Architecture Decision Records (ADRs)
+
+ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write.
+
+### When to Write an ADR
+
+- Choosing a framework, library, or major dependency
+- Designing a data model or database schema
+- Selecting an authentication strategy
+- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
+- Choosing between build tools, hosting platforms, or infrastructure
+- Any decision that would be expensive to reverse
+
+### ADR Template
+
+Store ADRs in `docs/decisions/` with sequential numbering:
+
+```markdown
+# ADR-001: Use PostgreSQL for primary database
+
+## Status
+Accepted | Superseded by ADR-XXX | Deprecated
+
+## Date
+2025-01-15
+
+## Context
+We need a primary database for the task management application. Key requirements:
+- Relational data model (users, tasks, teams with relationships)
+- ACID transactions for task state changes
+- Support for full-text search on task content
+- Managed hosting available (for small team, limited ops capacity)
+
+## Decision
+Use PostgreSQL with Prisma ORM.
+
+## Alternatives Considered
+
+### MongoDB
+- Pros: Flexible schema, easy to start with
+- Cons: Our data is inherently relational; would need to manage relationships manually
+- Rejected: Relational data in a document store leads to complex joins or data duplication
+
+### SQLite
+- Pros: Zero configuration, embedded, fast for reads
+- Cons: Limited concurrent write support, no managed hosting for production
+- Rejected: Not suitable for multi-user web application in production
+
+### MySQL
+- Pros: Mature, widely supported
+- Cons: PostgreSQL has better JSON support, full-text search, and ecosystem tooling
+- Rejected: PostgreSQL is the better fit for our feature requirements
+
+## Consequences
+- Prisma provides type-safe database access and migration management
+- We can use PostgreSQL's full-text search instead of adding Elasticsearch
+- Team needs PostgreSQL knowledge (standard skill, low risk)
+- Hosting on managed service (Supabase, Neon, or RDS)
+```
+
+### ADR Lifecycle
+
+```
+PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
+```
+
+- **Don't delete old ADRs.** They capture historical context.
+- When a decision changes, write a new ADR that references and supersedes the old one.
+
+## Inline Documentation
+
+### When to Comment
+
+Comment the *why*, not the *what*:
+
+```typescript
+// BAD: Restates the code
+// Increment counter by 1
+counter += 1;
+
+// GOOD: Explains non-obvious intent
+// Rate limit uses a sliding window — reset counter at window boundary,
+// not on a fixed schedule, to prevent burst attacks at window edges
+if (now - windowStart > WINDOW_SIZE_MS) {
+  counter = 0;
+  windowStart = now;
+}
+```
+
+### When NOT to Comment
+
+```typescript
+// Don't comment self-explanatory code
+function calculateTotal(items: CartItem[]): number {
+  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
+}
+
+// Don't leave TODO comments for things you should just do now
+// TODO: add error handling  ← Just add it
+
+// Don't leave commented-out code
+// const oldImplementation = () => { ... }  ← Delete it, git has history
+```
+
+### Document Known Gotchas
+
+```typescript
+/**
+ * IMPORTANT: This function must be called before the first render.
+ * If called after hydration, it causes a flash of unstyled content
+ * because the theme context isn't available during SSR.
+ *
+ * See ADR-003 for the full design rationale.
+ */
+export function initializeTheme(theme: Theme): void {
+  // ...
+}
+```
+
+## API Documentation
+
+For public APIs (REST, GraphQL, library interfaces):
+
+### Inline with Types (Preferred for TypeScript)
+
+```typescript
+/**
+ * Creates a new task.
+ *
+ * @param input - Task creation data (title required, description optional)
+ * @returns The created task with server-generated ID and timestamps
+ * @throws {ValidationError} If title is empty or exceeds 200 characters
+ * @throws {AuthenticationError} If the user is not authenticated
+ *
+ * @example
+ * const task = await createTask({ title: 'Buy groceries' });
+ * console.log(task.id); // "task_abc123"
+ */
+export async function createTask(input: CreateTaskInput): Promise<Task> {
+  // ...
+}
+```
+
+### OpenAPI / Swagger for REST APIs
+
+```yaml
+paths:
+  /api/tasks:
+    post:
+      summary: Create a task
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateTaskInput'
+      responses:
+        '201':
+          description: Task created
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/Task'
+        '422':
+          description: Validation error
+```
+
+## README Structure
+
+Every project should have a README that covers:
+
+```markdown
+# Project Name
+
+One-paragraph description of what this project does.
+
+## Quick Start
+1. Clone the repo
+2. Install dependencies: `npm install`
+3. Set up environment: `cp .env.example .env`
+4. Run the dev server: `npm run dev`
+
+## Commands
+| Command | Description |
+|---------|-------------|
+| `npm run dev` | Start development server |
+| `npm test` | Run tests |
+| `npm run build` | Production build |
+| `npm run lint` | Run linter |
+
+## Architecture
+Brief overview of the project structure and key design decisions.
+Link to ADRs for details.
+
+## Contributing
+How to contribute, coding standards, PR process.
+```
+
+## Changelog Maintenance
+
+For shipped features:
+
+```markdown
+# Changelog
+
+## [1.2.0] - 2025-01-20
+### Added
+- Task sharing: users can share tasks with team members (#123)
+- Email notifications for task assignments (#124)
+
+### Fixed
+- Duplicate tasks appearing when rapidly clicking create button (#125)
+
+### Changed
+- Task list now loads 50 items per page (was 20) for better UX (#126)
+```
+
+## Documentation for Agents
+
+Special consideration for AI agent context:
+
+- **CLAUDE.md / rules files** — Document project conventions so agents follow them
+- **Spec files** — Keep specs updated so agents build the right thing
+- **ADRs** — Help agents understand why past decisions were made (prevents re-deciding)
+- **Inline gotchas** — Prevent agents from falling into known traps
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. |
+| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. |
+| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. |
+| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
+| "Comments get outdated" | Comments on *why* are stable. Comments on *what* get outdated — that's why you only write the former. |
+
+## Red Flags
+
+- Architectural decisions with no written rationale
+- Public APIs with no documentation or types
+- README that doesn't explain how to run the project
+- Commented-out code instead of deletion
+- TODO comments that have been there for weeks
+- No ADRs in a project with significant architectural choices
+- Documentation that restates the code instead of explaining intent
+
+## Verification
+
+After documenting:
+
+- [ ] ADRs exist for all significant architectural decisions
+- [ ] README covers quick start, commands, and architecture overview
+- [ ] API functions have parameter and return type documentation
+- [ ] Known gotchas are documented inline where they matter
+- [ ] No commented-out code remains
+- [ ] Rules files (CLAUDE.md etc.) are current and accurate