daycare-cli 0.0.0-canary.00a24ac

package/dist/skills/development/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: development
+description: Software development workflows for multi-agent parallel work. Use when asked to develop code, fix bugs, implement features, or work on any codebase task. Covers checkout, worktree isolation, syncing with remote, and PR creation.
+---
+
+# Development Workflow
+
+Multi-agent development workflow. Multiple agents may be working on the same repository simultaneously — always assume you are not alone.
+
+## 1. Checkout the Repository
+
+Clone or locate the repository in `~/develop/`. Each agent gets its own checkout to avoid conflicts with other agents.
+
+```bash
+# If no checkout exists yet, clone into a uniquely named folder
+cd ~/develop
+git clone <repo-url> <project>-<agent-or-task-name>
+
+# Example
+git clone git@github.com:org/repo.git repo-fix-auth
+```
+
+Multiple agents can clone into `~/develop/` at the same time — each uses a distinct folder name. Never reuse another agent's checkout folder.
+
+If the checkout already exists (you created it earlier), reuse it.
+
+## 2. Sync Before Any Work
+
+Always fetch and rebase before starting work. Do this frequently — before new tasks, before committing, and before creating PRs.
+
+```bash
+git fetch origin
+git rebase origin/main
+```
+
+If rebase conflicts arise, resolve them or abort and re-clone. Never force-push to `main`.
+
+Sync again after finishing work and before pushing, to minimize merge conflicts.
+
+## 3. Create a Worktree for Your Task
+
+Inside your checkout, create a git worktree for the task. This isolates your branch from other agents who may also be working in the same checkout.
+
+```bash
+# From the checkout root
+git worktree add .worktrees/<task-branch-name> -b <task-branch-name>
+cd .worktrees/<task-branch-name>
+```
+
+Work exclusively inside the worktree directory. The `.worktrees/` folder keeps all worktrees organized under the checkout.
+
+When done with a task, clean up:
+
+```bash
+cd ../..
+git worktree remove .worktrees/<task-branch-name>
+```
+
+## 4. Develop and Commit
+
+Work inside the worktree. Follow the project's conventions for commits, builds, and tests. Commit frequently — small, focused commits are easier to review and rebase.
+
+## 5. Push and Create a PR
+
+Push the worktree branch and open a PR from it. Never push directly to `main`.
+
+```bash
+# Sync before pushing
+git fetch origin
+git rebase origin/main
+
+# Push
+git push -u origin <task-branch-name>
+
+# Create PR
+gh pr create --title "feat: describe the change" --body "$(cat <<'EOF'
+## Summary
+- What changed and why
+
+## Test plan
+- [ ] Tests pass
+- [ ] Manual verification
+EOF
+)"
+```
+
+Each task gets its own PR. If multiple agents work on related tasks, each creates a separate PR from its own worktree branch.
+
+## Summary
+
+```
+~/develop/
+└── repo-<task>/                 # per-agent checkout
+    ├── .worktrees/
+    │   ├── fix-auth/            # worktree for task A
+    │   └── add-metrics/         # worktree for task B (different agent)
+    └── (main working tree)      # avoid working here directly
+```
+
+Key rules:
+- **Separate checkouts** in `~/develop/` — one per agent
+- **Worktrees** in `.worktrees/` — one per task branch
+- **Sync often** — `git fetch origin && git rebase origin/main` before and after work
+- **Separate PRs** — one per task, pushed from the worktree branch
+- **Never push to main** — always use feature branches and PRs

package/dist/skills/memory-document/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: memory-document
+description: Write docs like code — Minto pyramid, MECE sections, BFO ontology, Mermaid diagrams, ground truth sources. Applies to any .md file.
+version: "2.0.0"
+---
+
+## How to Write a Document
+
+Write docs like code. Fractal structure where each level is complete. No redundancy — reference, don't repeat. Every claim has a source.
+
+```mermaid
+graph TD
+    Thesis[Thesis: 1 sentence] --> Overview[Overview: 1 paragraph]
+    Overview --> Diagrams[Mermaid: TD + LR]
+    Diagrams --> Sections[MECE Sections 1.0–7.0]
+    Sections --> Details[¶1, ¶2, ¶3 per section]
+    Sources[Ground Truth] --> Sections
+    Sources --> Details
+```
+
+## 1.0 The Stack
+
+Six rules. Use internal names here for clarity — don't leak them into the actual doc output.
+
+¶1 **Minto** — top-down. Thesis → overview → sections → details. Reader gets the point before the evidence.
+
+¶2 **MECE** — sections don't overlap, but cover everything. 3–7 top-level sections. If you can't draw a clean boundary between two sections, merge them.
+
+¶3 **BFO** — separate what exists (continuants) from what happens (occurrents). TD diagrams for structure, LR diagrams for process. This isn't decoration — it forces you to find the real shape of your content.
+
+¶4 **Fractal** — each subsection mirrors the whole. Own thesis sentence, own diagram if needed, own numbered paragraphs. Expand only if it earns the depth.
+
+¶5 **DRY** — each fact once. Cross-reference with §X.Y, don't restate.
+
+¶6 **Ground truth** — every claim traces to a source. URL, file path, query, session ID, person. No source = no claim. See §4.0.
+
+## 2.0 Structure
+
+¶1 **Thesis** — one sentence. Specific outcome with who/what/when. Must preview the MECE sections that follow.
+
+¶2 **Overview** — one paragraph expanding the thesis. Introduces each major section like a function docstring listing its parameters.
+
+¶3 **Mermaid diagrams** — go right after the overview, before §1.0. Structure (TD) before process (LR). See §3.0.
+
+¶4 **Sections** — numbered 1.0, 2.0, 3.0. Subsections 1.1, 1.2. State ordering logic upfront (importance / chronology / dependency). Continuant sections get noun titles, occurrent sections get verb titles.
+
+¶5 **Paragraphs** — numbered ¶1, ¶2, ¶3 within each section. Order: general → specific, or problem → solution, or setup → action → result.
+
+¶6 **Coherence** — if thesis says "planning, execution, monitoring", the doc must have all three. No surprise sections, no missing ones.
+
+¶7 **Big docs** — over ~10 pages, split into linked files with proper relative paths.
+
+## 3.0 Mermaid Diagrams
+
+Every doc gets at least one diagram. Complex docs need both TD and LR.
+
+¶1 **Headers required** — every diagram gets a bold header before the code block. Format: `**[Specific Description] ([Type] - [Direction]):**`. "Skill Package Structure (Continuant - TD)" not "System Structure".
+
+¶2 **Continuant (TD/TB)** — what exists. Nodes are nouns (Database, API, User). Edges are "contains", "depends on", "is part of". Use for architecture, data models, component trees.
+
+¶3 **Occurrent (LR)** — what happens. Nodes are verbs or states (Extract, Validate, Deploy). Edges are temporal — "then", "triggers", "flows to". Use for pipelines, workflows, request flows.
+
+¶4 **Participation (optional)** — how continuants participate in occurrents. User triggers Pipeline which updates Database. TD or LR depending on emphasis.
+
+¶5 **Sizing** — 5–12 nodes per diagram. More than that, split. Short labels (1–3 words). Label edges only when the relationship isn't obvious.
+
+¶6 **Placement** — primary diagrams after overview, before §1.0. Section-level diagrams inline where needed. One diagram per abstraction level — deeper sections get smaller, focused diagrams.
+
+¶7 **Structure first** — when showing both, continuant (TD) before occurrent (LR).
+
+## 4.0 Ground Truth
+
+Every piece of information traces to its source. No exceptions.
+
+### Patterns
+
+¶1 **External** — `**Source:** [Title](URL) (accessed YYYY-MM-DD)`
+
+¶2 **Code** — `**Source:** path/to/file.py:123-145 (function calculate_metrics)`
+
+¶3 **Session** — `**Generated by:** Claude Code session abc123 by Name (YYYY-MM-DD)`
+
+¶4 **LLM reasoning** — `**LLM Analysis:** Based on ¶1 + ¶3` — flag synthesis explicitly, don't present it as source data.
+
+¶5 **Query** — `**Query:** SELECT ... (YYYY-MM-DD)` with result and date. Data changes; timestamp matters.
+
+¶6 **Human** — `**Expert input:** Name (Role), discussed YYYY-MM-DD`
+
+¶7 **Meeting** — `**Source:** Gong call gong_123456 with Client (YYYY-MM-DD)` with key takeaway.
+
+### Where to Put It
+
+¶1 **Doc-level** — primary source right after the thesis in the overview.
+
+¶2 **Section-level** — at top of section if the whole section comes from one source.
+
+¶3 **Inline** — next to specific claims: "churn is 12% (**Source:** `SELECT AVG(churn_rate)...` 2025-11-10)".
+
+¶4 **Mixed** — multiple sources in one paragraph, attribute each piece separately.
+
+### Rules
+
+- Dates mandatory. Always YYYY-MM-DD.
+- URLs must work. Use archive.org if original might vanish.
+- Code refs need line numbers or function names, not just file paths.
+- "Based on research" is not a source. Name it.
+- Synthesis presented as fact is a violation. Flag LLM reasoning.
+
+## Checklist
+
+Paste at doc end. Tick before shipping.
+
+**Structure:**
+- [ ] Thesis: one sentence previewing all sections
+- [ ] Overview: one paragraph introducing each section
+- [ ] Mermaid: at least one; complex docs get TD + LR
+- [ ] MECE: 3–7 sections, no overlap, full coverage
+- [ ] Ordering stated: ¶1 of each section explains sequence logic
+- [ ] Paragraph numbering: ¶1, ¶2, ¶3 throughout
+- [ ] Coherence: thesis matches actual sections
+
+**Content:**
+- [ ] DRY: each fact once, §X.Y cross-references elsewhere
+- [ ] Dense: no filler words, but enough to execute
+- [ ] Labels: noun titles for continuants, verb titles for occurrents
+
+**Ground Truth:**
+- [ ] Primary source in overview
+- [ ] Section sources attributed
+- [ ] Inline sources on specific claims
+- [ ] LLM reasoning flagged
+- [ ] Code refs have line numbers
+- [ ] All dates present
+- [ ] URLs tested

package/dist/skills/permanent-agent-creator/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: permanent-agent-creator
+description: Guide for creating and updating permanent agents with stable names, dedicated system prompts, and optional workspace folders.
+license: Complete terms in LICENSE.txt
+---
+
+# Permanent Agent Creator
+
+This skill provides guidance for creating and updating permanent agents.
+
+## About Permanent Agents
+
+Permanent agents are background agents with stable identities. They are created once and reused across sessions, with a dedicated system prompt that can be updated over time.
+
+### What Permanent Agents Provide
+
+1. Stable identity - predictable agent ids you can reference later
+2. Dedicated system prompts - durable instructions for specialized roles
+3. Optional workspace folders - focused file scopes inside the main workspace
+4. Reusable collaboration - multiple agents can coordinate through a named helper
+
+## Core Principles
+
+### Keep Prompts Focused
+
+Permanent agents should be narrow and durable. Prefer a short system prompt that captures role, constraints, and communication style.
+Avoid task-specific instructions that should live in the user request instead.
+
+### Stable Names Matter
+
+Names are how humans recognize agents. Pick a short, descriptive name and avoid frequent renames.
+If a name needs to change, update it deliberately alongside the system prompt.
+
+### Scope Workspace When Needed
+
+Only assign a workspace subfolder when the agent needs a dedicated area (e.g., a specific project or dataset).
+Default to the main workspace when no isolation is required.
+
+## Workflow
+
+1. **Gather inputs**
+   - Agent name
+   - Short description
+   - System prompt
+   - Optional workspace subfolder
+
+2. **Create or update**
+   Use `create_permanent_agent` with the collected inputs. Reusing a name updates the existing agent.
+
+3. **Share the agent id**
+   Store the returned agent id and use `send_agent_message` to coordinate with it.
+
+## Example
+
+Create a release helper:
+
+```
+create_permanent_agent({
+  name: "Release Tracker",
+  description: "Tracks release readiness and reports risks.",
+  systemPrompt: "You track release status, summarize risks, and report progress to the main agent.",
+  workspaceDir: "release-notes"
+})
+```
+
+Then delegate work:
+
+```
+send_agent_message({
+  agentId: "<agent-id>",
+  text: "Summarize the latest release checklist status."
+})
+```

package/dist/skills/psql/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: psql
+description: Work with user-scoped PostgreSQL databases (PGlite). Use when the user asks to store structured data, create tables, query rows, track records, build a database, or manage any tabular/relational information. Covers database creation, additive schema design, CRUD operations, and SQL queries.
+---
+
+# PSQL Databases
+
+Daycare provides user-scoped PostgreSQL databases powered by PGlite. Each user can create multiple named databases with declarative schemas and full SQL query support.
+
+## Tools
+
+| Tool | Purpose |
+|------|---------|
+| `psql_db_create` | Create a new named database |
+| `psql_db_list` | List all databases for the current user |
+| `psql_schema` | Declare or extend a table's schema (additive only) |
+| `psql_data` | Add, update, or delete rows |
+| `psql_query` | Run read-only SQL queries |
+
+## Core Concepts
+
+### Additive Schema Model
+
+Schemas are **additive only** — you can add tables and columns but never drop or rename them. This guarantees data safety and keeps migrations simple.
+
+Every table automatically gets **system columns** managed by the engine:
+
+| System Column | Type | Description |
+|---------------|------|-------------|
+| `id` | text | Stable row identity (auto-generated UUID on add) |
+| `version` | integer | Monotonic version number per row id |
+| `valid_from` | integer | Unix ms when this version became active |
+| `valid_to` | integer? | Unix ms when this version was superseded (null = current) |
+| `created_at` | integer | Unix ms when the row was first created |
+| `updated_at` | integer | Unix ms when this version was written |
+
+You only declare your **user columns**. System columns are added automatically.
+
+### Supported Column Types
+
+| Type | PostgreSQL | Use For |
+|------|------------|---------|
+| `text` | `text` | Strings, names, descriptions, URLs |
+| `integer` | `bigint` | Whole numbers, counts, unix timestamps |
+| `real` | `double precision` | Decimal numbers, prices, measurements |
+| `boolean` | `boolean` | Flags, toggles |
+| `jsonb` | `jsonb` | Nested objects, arrays, flexible data |
+
+### Versioned Row History
+
+Every update creates a **new version** of the row. The previous version is marked with a `valid_to` timestamp. This means:
+
+- Updates never destroy data — old versions are preserved.
+- You can query historical state by filtering on `valid_from`/`valid_to`.
+- The current version always has `valid_to IS NULL`.
+
+Deletes mark the current version with a `valid_to` timestamp, so deleted rows no longer appear in `valid_to IS NULL` queries.
+
+## Workflow
+
+### 1. Create a Database
+
+```
+psql_db_create(name: "my-project")
+→ { id: "abc123", name: "my-project" }
+```
+
+Use a descriptive name. The returned `id` is needed for all subsequent operations.
+
+### 2. Define Tables
+
+Declare tables one at a time. Each call to `psql_schema` is idempotent — re-declaring existing columns is safe (as long as the type matches).
+
+```
+psql_schema(
+  dbId: "abc123",
+  table: "contacts",
+  comment: "People and organizations the user interacts with. Used to look up contact info, track relationships, and filter by company or role.",
+  fields: [
+    { name: "name", type: "text", comment: "Full display name of the person or organization. Used as the primary label in listings and search results." },
+    { name: "email", type: "text", comment: "Primary email address for reaching this contact. Nullable because some contacts are tracked before email is known.", nullable: true },
+    { name: "company", type: "text", comment: "Company or organization this contact belongs to. Used to group contacts by employer and filter by affiliation.", nullable: true },
+    { name: "tags", type: "jsonb", comment: "Freeform classification tags stored as a JSON array of strings (e.g. [\"friend\", \"eng\"]). Used for flexible filtering and grouping beyond fixed columns.", nullable: true }
+  ]
+)
+```
+
+**Every field needs a `comment` that explains intent, not just the data type.** Good comments describe *why* this field exists and *how* it will be used — not just *what* it stores. This helps the model make better decisions about which columns to query and how to present results.
+
+| Bad comment | Good comment |
+|-------------|--------------|
+| "The user's email." | "Primary email for reaching this contact. Nullable because some contacts are added before email is exchanged." |
+| "Price value." | "Unit price in USD before tax. Used to compute order totals and displayed on invoices." |
+| "Status flag." | "Whether the task is currently actionable. Set to false when completed or deferred, used to filter active work views." |
+| "Created timestamp." | "When the project was first registered. Used to sort by age and compute time-to-completion metrics." |
+
+The same principle applies to the **table comment** — describe the purpose and how the table fits into the user's workflow.
+
+To add columns later, call `psql_schema` again with the same table name and the new fields included. Existing columns are left unchanged.
+
+### 3. Add Data
+
+```
+psql_data(
+  dbId: "abc123",
+  op: {
+    op: "add",
+    table: "contacts",
+    data: { name: "Alice", email: "alice@example.com", tags: ["friend", "eng"] }
+  }
+)
+→ { id: "row-uuid", name: "Alice", ... }
+```
+
+The `id` is auto-generated. Only provide your user columns in `data`.
+
+### 4. Update Data
+
+```
+psql_data(
+  dbId: "abc123",
+  op: {
+    op: "update",
+    table: "contacts",
+    id: "row-uuid",
+    data: { company: "Acme Inc" }
+  }
+)
+```
+
+Partial updates are supported — only include fields you want to change. A new version is created; the old version is preserved.
+
+### 5. Delete Data
+
+```
+psql_data(
+  dbId: "abc123",
+  op: {
+    op: "delete",
+    table: "contacts",
+    id: "row-uuid"
+  }
+)
+```
+
+Soft-deletes the row by closing the current version (sets `valid_to`). The record stays in history but no longer appears in `valid_to IS NULL` queries.
+
+### 6. Query Data
+
+Use standard SQL. Results are returned as an array of row objects.
+
+```
+psql_query(
+  dbId: "abc123",
+  sql: "SELECT id, name, email FROM contacts WHERE valid_to IS NULL ORDER BY name",
+  params: []
+)
+```
+
+**Always filter for current rows** with `valid_to IS NULL` unless you specifically want historical data.
+
+## Query Patterns
+
+### Get all current rows from a table
+
+```sql
+SELECT * FROM contacts
+WHERE valid_to IS NULL
+ORDER BY created_at DESC
+```
+
+### Search by field value
+
+```sql
+SELECT * FROM contacts
+WHERE valid_to IS NULL
+  AND email = $1
+```
+
+Use `$1`, `$2`, etc. for parameterized queries and pass values in the `params` array.
+
+### Count rows
+
+```sql
+SELECT COUNT(*) as total FROM contacts
+WHERE valid_to IS NULL
+```
+
+### Query JSONB fields
+
+```sql
+-- Check if a tag exists in a JSONB array
+SELECT * FROM contacts
+WHERE valid_to IS NULL
+  AND tags @> '["friend"]'::jsonb
+
+-- Extract a nested JSONB field
+SELECT name, tags->>'role' as role FROM contacts
+WHERE valid_to IS NULL
+```
+
+### View row history
+
+```sql
+-- All versions of a specific row
+SELECT * FROM contacts
+WHERE id = $1
+ORDER BY version ASC
+```
+
+### Aggregate queries
+
+```sql
+SELECT company, COUNT(*) as count
+FROM contacts
+WHERE valid_to IS NULL
+GROUP BY company
+ORDER BY count DESC
+```
+
+## Schema Design Guidelines
+
+### Naming
+
+- Table names: lowercase, plural, underscores (`order_items`, `project_tasks`)
+- Column names: lowercase, underscores (`first_name`, `due_date`)
+- Be descriptive but concise
+
+### When to Use JSONB
+
+Use `jsonb` for:
+- Variable-length lists (tags, labels, categories)
+- Nested objects that don't need their own table
+- Data whose shape varies per row
+- Metadata or extra attributes
+
+Use regular columns for:
+- Fields you filter or sort on frequently
+- Fields with a fixed, known type
+- Fields that benefit from type validation
+
+### Nullable Columns
+
+Mark a column `nullable: true` when:
+- The value is optional (not every row will have it)
+- The value may not be known at creation time
+- The column is added to an existing table (existing rows will have null)
+
+### Separate Tables vs JSONB
+
+Use separate tables when:
+- You need to query the related data independently
+- The relationship is many-to-many
+- You need referential integrity
+
+Use JSONB when:
+- The nested data is always read/written with the parent
+- The structure is simple (lists of strings, small config objects)
+- You won't need to join on the nested data
+
+## Tips
+
+- **Check existing databases first**: call `psql_db_list` before creating a new database — the user may already have one.
+- **Schema is in the system prompt**: when databases exist, their schema appears in the system prompt so you already know the table structure.
+- **Idempotent schema**: re-applying the same `psql_schema` call is safe, so you can include full table definitions in automation without worrying about duplicates.
+- **Parameterized queries**: always use `$1`, `$2` params instead of string interpolation to avoid SQL injection.
+- **JSONB for flexibility**: when the user's data doesn't fit a rigid schema, use a `jsonb` column for the flexible parts.