daycare-cli 0.0.0-canary.db7089a

package/dist/skills/skills/app-creator/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: app-creator
+description: Guide for creating effective apps. Use when users want to create a new app or update an existing app with APP.md, PERMISSIONS.md, allow and deny rules, and sandboxed execution.
+license: Complete terms in LICENSE.txt
+---
+
+# App Creator
+
+This skill provides guidance for creating effective Daycare apps.
+
+## About Apps
+
+Apps are sandboxed tool wrappers discovered from
+`workspace/apps/<app-id>/APP.md` and `workspace/apps/<app-id>/PERMISSIONS.md`.
+Each app is exposed as a callable tool named `app_<name>`.
+
+On invocation, an app runs as a constrained app agent and each tool call is reviewed
+against the app's allow/deny rules before execution.
+
+### What Apps Provide
+
+1. Isolated capabilities with explicit boundaries
+2. Rule-reviewed tool execution on every app tool call
+3. Persistent app state in `data/`
+4. Reusable app behavior via clear metadata and strict rules
+
+## Core Principles
+
+### Start Narrow
+
+Default to restrictive rules and small scope. Add capabilities only when they are
+required by real usage.
+
+### Keep Rules Concrete
+
+Write allow/deny rules in specific, testable language. Prefer concrete constraints
+(paths, hosts, command families) over vague policy statements.
+
+### Preserve Isolation
+
+Design around Daycare app boundaries:
+
+- App writes only to `workspace/apps/<app-id>/data/`
+- App manifest and bundled files are read-only to the app
+- Non-app agents should not read/write app directories
+
+## Anatomy of an App
+
+Every app consists of required `APP.md` and `PERMISSIONS.md` files plus optional bundled resources:
+
+```text
+app-id/
+├── APP.md (required)
+│   ├── YAML frontmatter (required)
+│   │   ├── name: (required, username-style; this is the app id)
+│   │   ├── title: (required, human-readable)
+│   │   ├── description: (required)
+│   │   └── model: (optional)
+│   └── Markdown body (required)
+│       └── Full body is system prompt
+├── PERMISSIONS.md (required)
+│   └── Markdown body (required)
+│       ├── ## Source Intent
+│       └── ## Rules
+│           ├── ### Allow
+│           └── ### Deny
+├── data/ (required runtime writable state)
+└── scripts/ (optional read-only helpers)
+```
+
+### APP.md (required)
+
+Every `APP.md` consists of:
+
+- **Frontmatter** (YAML): `name`, `title`, `description`, optional `model`.
+- **Body** (Markdown): full body is the system prompt.
+
+When parsing or writing `APP.md`:
+
+- Never parse frontmatter manually
+- Never write frontmatter manually
+- Always use `gray-matter` for parse and stringify flows
+
+### Example APP.md
+
+```markdown
+---
+name: github-reviewer
+title: GitHub Reviewer
+description: Reviews pull requests and drafts feedback
+model: default
+---
+
+You review pull requests and provide concrete, actionable feedback.
+```
+
+### Example PERMISSIONS.md
+
+```markdown
+## Source Intent
+
+Review pull requests and draft actionable feedback while preserving repository safety.
+
+## Rules
+
+### Allow
+- Read files in the workspace
+- Run read-only git commands
+
+### Deny
+- Write outside data/
+- Delete files
+- Rewrite git history
+```
+
+## App Creation Process
+
+App creation involves these steps:
+
+1. Understand concrete app use cases
+2. Plan boundaries and reusable app resources
+3. Initialize the app in workspace
+4. Edit `APP.md`, `PERMISSIONS.md`, and app resources
+5. Validate behavior and safety
+6. Iterate based on real usage
+
+Follow these steps in order, skipping only if there is a clear reason.
+
+### Step 1: Understand with Concrete Examples
+
+Collect examples that should be handled by the app and examples that should be denied
+or handled elsewhere.
+
+Capture:
+
+- expected input/output shape
+- required tool classes (`read`, `write`, `edit`, `exec`)
+- safety boundaries and failure modes
+
+### Step 2: Plan Boundaries and Resources
+
+Before creating files, define:
+
+- app id and scope
+- success criteria
+- rule matrix (allow/deny/conditional)
+- persistent state model for `data/`
+
+Consult references:
+
+- **Workflow design**: `references/workflows.md`
+- **Rule design and anti-patterns**: `references/rules-patterns.md`
+
+### Step 3: Initialize App in Workspace
+
+Create the app structure:
+
+```bash
+mkdir -p workspace/apps/<app-id>/data
+mkdir -p workspace/apps/<app-id>/scripts
+```
+
+Then create `APP.md` and `PERMISSIONS.md` with required sections.
+
+### Step 4: Edit APP.md, PERMISSIONS.md, and Resources
+
+Write clear metadata in `APP.md` and clear source intent + allow/deny rules in `PERMISSIONS.md`.
+
+If scripts are needed, keep them minimal and app-specific.
+
+### Step 5: Validate Behavior and Safety
+
+Validation checklist:
+
+- Frontmatter has valid `name`, `title`, `description` (optional `model`)
+- APP.md body is non-empty and contains the system prompt
+- Tool name maps cleanly to `app_<name>`
+- Writes are limited to `data/`
+- Allow rules cover intended workflows
+- Deny rules block destructive actions
+- Error messages are actionable when calls are denied
+
+Run tests and typecheck after changes.
+
+### Step 6: Iterate
+
+After real usage:
+
+1. Capture failures and unnecessary denials
+2. Tighten prompt and rules
+3. Re-test representative workflows
+4. Keep changes small and reversible
+
+## Practical Guidance
+
+### Keep Apps Single-Purpose
+
+If one app starts owning unrelated workflows, split it into multiple apps.
+
+### Prefer Stable Rules
+
+Write rules that remain understandable months later and are tied to observable behavior.
+
+### Keep Runtime Rule Changes Aligned
+
+If rules are modified at runtime via app rule tools, keep `PERMISSIONS.md` and runtime
+behavior consistent.

package/dist/skills/skills/app-creator/references/rules-patterns.md

@@ -0,0 +1,36 @@
+# App Rules Patterns
+
+Use this reference when writing `## Rules` sections in `PERMISSIONS.md`.
+
+## Rule writing checklist
+
+- Keep one constraint per rule line.
+- Use concrete nouns and verbs.
+- Prefer explicit path and host constraints.
+- State prohibited destructive operations directly.
+- Avoid broad, ambiguous phrases.
+
+## Good allow examples
+
+- Allow reading files under workspace root.
+- Allow running `git status`, `git diff`, and `git show`.
+- Allow writing only under `workspace/apps/<app-id>/data/`.
+
+## Good deny examples
+
+- Deny deleting files.
+- Deny changing git history (`git reset`, `git rebase`, forced pushes).
+- Deny writes outside `data/`.
+- Deny network access except approved hosts.
+
+## Anti-patterns
+
+- "Be safe."
+- "Only do reasonable things."
+- "Avoid dangerous commands when possible."
+
+These are hard to evaluate consistently and should be replaced with explicit constraints.
+
+## Reviewability heuristic
+
+A rule is strong when a reviewer can answer "allowed or denied?" without guessing.

package/dist/skills/skills/app-creator/references/workflows.md

@@ -0,0 +1,32 @@
+# App Workflows
+
+Use this reference when designing end-to-end app workflows from user prompt to final result.
+
+## Minimal workflow pattern
+
+1. Define the task in one sentence.
+2. Identify required tools and data reads.
+3. Apply allow/deny constraints before execution.
+4. Execute tool calls through review middleware.
+5. Return concise final output with rationale.
+
+## Decision checkpoints
+
+- **Before first call**: Is the requested action in app scope?
+- **Before each tool call**: Does allow/deny policy permit it?
+- **After denial**: Can the app adapt with a safer alternative?
+- **Before response**: Is output complete and actionable?
+
+## Escalation pattern
+
+If the app cannot complete safely:
+
+1. Explain what was blocked.
+2. Explain why it was blocked.
+3. Offer a safe alternative path.
+
+## Stable workflow guidance
+
+- Prefer deterministic steps over open-ended exploration.
+- Keep tool-call count low for predictable latency.
+- Avoid mixing unrelated responsibilities in one app flow.

package/dist/skills/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/skills/scheduling/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: scheduling
+description: Schedule recurring or time-based tasks. Use for alarms, reminders, periodic reviews, automated reports, or any task that should run at specific times or intervals.
+---
+
+# Scheduling
+
+Daycare supports two scheduling mechanisms: **cron** for precise timing and **heartbeats** for periodic check-ins.
+
+## When to Use Cron
+
+Use cron when:
+- Exact timing matters (e.g., "every day at 9am")
+- Tasks need their own isolated agent and memory
+- One-off scheduled tasks (with `deleteAfterRun`)
+- Tasks that produce artifacts in a dedicated workspace
+
+**Cron tools:** `cron_add`, `cron_read_task`, `cron_read_memory`, `cron_write_memory`, `cron_delete_task`
+
+### Cron Routing
+
+Cron tasks run in their own dedicated cron agent by default. If you want the cron
+notification to land in an existing agent (e.g. a user chat), include `agentId`
+in `cron_add` to route the prompt to that agent instead.
+
+## When to Use Heartbeats
+
+Use heartbeats when:
+- Approximate timing is acceptable (~30 minute intervals)
+- Tasks need ongoing context from the main agent
+- Prompts evolve over time and need periodic review
+- Lightweight status checks or reminders
+
+**Heartbeat tools:** `heartbeat_add`, `heartbeat_run`, `heartbeat_remove` (use `topology` to inspect tasks)
+
+## Optional Exec Gate
+
+Both cron and heartbeat tasks can define an optional `gate` command to decide
+whether to run the LLM. The command runs first; exit code `0` means "run" and
+non-zero means "skip." This keeps checks cheap (ex: HTTP health check before notifying).
+Trimmed gate output is appended to the prompt under `[Gate output]`.
+Gates run within the target agent permissions. If `gate.permissions` are not already
+allowed, a system message is posted and the task still runs (the gate is treated as
+successful).
+
+`gate` supports:
+- `command` (required)
+- `cwd`, `timeoutMs`, `env`
+- `permissions` (required tags; must already be allowed by the target agent)
+- `packageManagers` (`dart` | `dotnet` | `go` | `java` | `node` | `php` | `python` | `ruby` | `rust`; auto-adds language ecosystem hosts; requires `@network`)
+- `allowedDomains` (network allowlist; requires `@network`)
+
+## Examples
+
+**Cron with routing + gate (`TASK.md` frontmatter):**
+
+```yaml
+---
+name: API health
+schedule: "*/10 * * * *"
+agentId: cu3ql2p5q0000x5p3g7q1l8a9
+gate:
+  command: "curl -fsS https://api.example.com/healthz >/dev/null"
+  packageManagers:
+    - node
+  allowedDomains:
+    - api.example.com
+---
+If the API is down, notify me with a short summary.
+```
+
+## Selection Examples
+
+### Choose Cron
+
+| User Input | Why Cron |
+|------------|----------|
+| "Remind me every day at 9am to check my emails" | Specific time (9am daily) |
+| "Run a backup script every Sunday at midnight" | Exact schedule needed |
+| "Send me a weather report every morning at 7:30" | Precise daily timing |
+| "Every hour, check if the server is up" | Strict hourly repetition |
+| "At 5pm on weekdays, summarize my tasks" | Complex schedule (weekdays only) |
+| "Once tomorrow at noon, remind me about the meeting" | One-off scheduled task |
+| "Every 15 minutes, poll the API for updates" | Precise interval timing |
+| "On the 1st of each month, generate a report" | Calendar-based schedule |
+
+### Choose Heartbeats
+
+| User Input | Why Heartbeat |
+|------------|---------------|
+| "Periodically check on my project status" | Ongoing review, flexible timing |
+| "Keep an eye on my git branches" | Continuous monitoring, evolving context |
+| "Remind me about my todos from time to time" | Lightweight, approximate timing |
+| "Check in on code quality occasionally" | Periodic review that needs reasoning |
+| "Monitor my open PRs and update me" | Ongoing task that evolves |
+| "Review my notes and suggest improvements" | Needs main agent context |
+| "Periodically summarize what I've been working on" | Flexible interval, ongoing |
+| "Keep track of my daily progress" | Continuous, evolving check-in |
+
+### Ambiguous Cases
+
+| User Input | Resolution |
+|------------|------------|
+| "Remind me about X regularly" | Ask: need exact times? Cron. Flexible? Heartbeat. |
+| "Check something every day" | Ask: specific time? Cron. Anytime during day? Heartbeat. |
+| "Monitor Y" | Heartbeat (monitoring implies ongoing, evolving context) |
+| "Schedule Z" | Cron (scheduling implies specific timing) |
+
+## Workflow
+
+**For cron tasks:**
+1. Determine the schedule (cron expression: `minute hour day month weekday`)
+2. Use `cron_add` with name, schedule, and prompt (optional `agentId` + `gate`)
+3. Each task gets isolated agent, memory file, and workspace
+
+**For heartbeats:**
+1. Run `topology` to see existing heartbeat tasks and ownership
+2. Use `heartbeat_add` with title and prompt (optional `gate`)
+3. Use `heartbeat_run` to trigger immediately
+4. Use `heartbeat_remove` for cleanup
+
+## Key Differences
+
+| Feature | Cron | Heartbeats |
+|---------|------|------------|
+| Timing | Exact (cron expression) | ~30 minute intervals |
+| Agent | Isolated per task | Shared main agent |
+| Memory | Persistent `MEMORY.md` | Main agent context |
+| Workspace | Dedicated `files/` dir | None |
+| One-off | Yes (`deleteAfterRun`) | No |
+| Best for | Time-sensitive tasks | Ongoing reviews |