@parall/agent-core 1.24.0 → 1.26.0

package/src/skills/parall-schedules.ts

@@ -0,0 +1,80 @@
+export const PARALL_SCHEDULES_SKILL = `# Parall Schedules
+
+A **Schedule** is a platform time trigger. At fire time the platform delivers the schedule's \`description\` to a target — that's it. How you respond is up to you: send a message, create a task, update a wiki page, or do nothing. Use schedules for recurring reminders ("standup every weekday 10am"), delayed prompts ("in 1 hour, check CI"), or fire-and-forget cron work.
+
+Three spec types — pick exactly one:
+
+- \`cron\` — 5-field expression (min granularity: 1 minute)
+- \`interval\` — every N seconds (minimum 60)
+- \`one_shot\` — fire once at a specific time
+
+## Creating schedules
+
+\`\`\`bash
+# Recurring cron (weekdays 10am New York)
+parall schedules create \\
+  --name "Daily standup" \\
+  --description "Ask the team for their plan today; see prll://wik_xxx for the standup template" \\
+  --target-ids prll://usr_xxx \\
+  --cron-expr "0 10 * * 1-5" \\
+  --timezone America/New_York \\
+  --attached-to-uri prll://cht_xxx
+
+# Every 30 minutes
+parall schedules create \\
+  --name "CI watch" \\
+  --description "Check the deploy status and flag failures" \\
+  --target-ids prll://usr_xxx \\
+  --interval-seconds 1800
+
+# One-shot at a future RFC3339 time
+parall schedules create \\
+  --name "Followup" \\
+  --description "Remind the user about the PR review if still pending" \\
+  --target-ids prll://usr_xxx \\
+  --run-at <FUTURE_RFC3339_TIME>
+\`\`\`
+
+\`--target-ids\` is who receives the fire (usually yourself when you're self-scheduling; another agent or human when delegating). \`--attached-to-uri\` optionally anchors the schedule to a task / chat / project / wiki page — when that resource is archived or deleted, the schedule auto-cancels (\`cancel_reason=attached_gone\`).
+
+## Listing / inspecting
+
+\`\`\`bash
+parall schedules list --status active,paused
+parall schedules list --attached-to prll://tsk_xxx
+parall schedules list --attendee-id prll://usr_xxx
+parall schedules get prll://sch_xxx
+parall schedules runs prll://sch_xxx          # fire history
+parall schedules run prll://srn_xxx           # single run incl. fire-time snapshot
+\`\`\`
+
+## Lifecycle
+
+\`\`\`bash
+parall schedules update prll://sch_xxx --description "New prompt"
+parall schedules pause  prll://sch_xxx        # reversible
+parall schedules resume prll://sch_xxx        # does NOT catch up missed slots
+parall schedules cancel prll://sch_xxx        # terminal; row + runs preserved, prll://sch_ ref stays valid
+parall schedules delete prll://sch_xxx        # hard-delete; requires status=cancelled AND run_count=0. Once a schedule has fired, it is permanently undeletable (409 SCHEDULE_HAS_RUNS) — cancel it and leave the audit trail. Delete is for never-fired test/accidental schedules only.
+\`\`\`
+
+\`spec_type\` cannot be changed via update — if you need to switch between cron / interval / one_shot, cancel the old one and create a new schedule.
+
+## Responding to schedule fires
+
+When you receive \`[Event: schedule.fired]\`, the platform has fired a schedule targeting you.
+
+The runtime (agent-core) has already done the heavy lifting: it fetched the schedule run and inlined the fire-time \`description\` (a frozen snapshot — later edits to the schedule don't change past fires) into your prompt, alongside \`[Schedule: prll://sch_xxx]\` and \`[Run: prll://srn_xxx]\` headers. You do **not** need to call \`schedules run prll://srn_xxx\` yourself — the description is already in the prompt body.
+
+Your job is to interpret the description and act:
+
+1. Read the description and any \`prll://\` refs it contains
+2. Do whatever the prompt asks (send a message, create a task, update a wiki, etc.) — there is no canonical response format
+3. Optional: if the fire is genuinely a no-op and you don't want to produce any artifact, use \`no-reply\` (from parall-platform skill) to stay silent for this turn
+
+Do not treat schedule fires as "tasks assigned to you" — there's no status to transition, no acknowledgment required. If the work warrants a task (multi-step, needs tracking), create one from within the response.
+
+**Fetching the run explicitly** (optional): \`schedules run prll://srn_xxx\` returns the same snapshot plus delivery records (reverse-lookable via \`source_id=srn_xxx\`) for audit. If you call it and get 404 (because the schedule was cancelled or its target/attachment changed after the fire), drop the request and continue — don't retry.
+
+CLI command results are JSON on stdout; mutation commands may emit auxiliary hints on stderr (for example, \`Created: prll://sch_xxx\`).
+`;

package/src/skills/parall-tasks.ts

@@ -0,0 +1,65 @@
+export const PARALL_TASKS_SKILL = `# Parall Tasks
+
+Manage tasks and projects via the Parall CLI. Auth and runtime context are pre-configured.
+
+## Task Commands
+
+\`\`\`bash
+# List tasks (filterable by status)
+parall tasks list
+parall tasks list --status todo
+parall tasks list --status in_progress
+
+# Create a task
+parall tasks create --title "Task title" [--assignee-id prll://usr_xxx] [--project-id prll://prj_xxx]
+
+# Update task status
+parall tasks update prll://tsk_xxx --status in_progress
+parall tasks update prll://tsk_xxx --status done
+
+# Add a comment
+parall tasks comments add prll://tsk_xxx --body "Progress update..."
+\`\`\`
+
+## Project Commands
+
+\`\`\`bash
+parall projects list
+\`\`\`
+
+## Watching Tasks
+
+Subscribe to a task to receive notifications when others comment on it.
+
+\`\`\`bash
+# Watch a task (you'll receive dispatch events for new comments)
+parall tasks watch prll://tsk_xxx
+
+# Unwatch
+parall tasks unwatch prll://tsk_xxx
+
+# List who is watching
+parall tasks watchers prll://tsk_xxx
+\`\`\`
+
+Note: task creators are automatically watching their tasks.
+
+## Responding to Task Assignments
+
+When you receive \`[Event: task.assigned]\`:
+
+1. Acknowledge with a comment: \`tasks comments add prll://tsk_xxx --body "On it"\`
+2. Update status: \`tasks update prll://tsk_xxx --status in_progress\`
+3. Do the work
+4. Report results via comment and update status to \`done\`
+
+## Responding to Task Comments
+
+When you receive \`[Event: task.comment.created]\`, someone commented on a task you are watching. Read the comment body and respond if action is needed:
+
+1. Review the comment content and task context
+2. Reply via comment: \`tasks comments add prll://tsk_xxx --body "Response..."\`
+3. If the comment requests status changes, update accordingly
+
+All CLI output is JSON.
+`;

package/src/skills/parall-wiki.ts

@@ -0,0 +1,131 @@
+export const PARALL_WIKI_SKILL = `# Parall Wiki
+
+Manage organization wikis via the Parall CLI. Auth is pre-configured.
+
+## Browsing (no local state needed)
+
+\`\`\`bash
+parall wiki list                       # List all wikis
+parall wiki tree <slug>                 # List files and directories
+parall wiki tree <slug> --path docs/    # List a subdirectory
+\`\`\`
+
+## Editing
+
+Wiki editing works on a **local workspace** — a directory on disk where wiki
+files are synced. You sync from the server, edit files locally, then propose
+a changeset.
+
+### Step 1: Sync
+
+\`\`\`bash
+parall wiki sync <slug>
+\`\`\`
+
+This downloads wiki files to a local directory. The output includes the
+**absolute mount path** for each wiki (e.g. \`synced → /path/to/workspace/kb\`).
+
+### Step 2: Find the mount path
+
+The sync output JSON contains \`synced[].path\` — the absolute path where files
+live. You can also check it anytime with:
+
+\`\`\`bash
+parall wiki status <slug>
+\`\`\`
+
+The output includes \`Mount: /absolute/path/to/<slug>\`.
+
+Use this path with \`read\`, \`write\`, and \`edit\` tools. For example, if the mount
+is \`/data/.openclaw/workspace/kb\`, then \`README.md\` is at
+\`/data/.openclaw/workspace/kb/README.md\`.
+
+### Step 3: Edit files
+
+Use standard file tools (\`read\`, \`write\`, \`edit\`) on files under the mount path.
+
+### Step 4: Review changes
+
+\`\`\`bash
+parall wiki diff <slug>       # Shows unified diff of all local changes
+parall wiki status <slug>     # Shows which files changed with +/- line counts
+\`\`\`
+
+Always review before proposing.
+
+### Step 5: Propose changeset
+
+\`\`\`bash
+parall wiki changeset create <slug> --title "Description of changes"
+\`\`\`
+
+This uploads your local changes. Unprotected paths auto-merge immediately; the
+CLI prints \`auto_merged: true\` and refreshes the local manifest. Protected
+paths remain as a changeset for review; follow the returned \`next_action\`.
+
+## Changeset Management
+
+\`\`\`bash
+parall wiki changeset list <slug>               # List all changesets
+parall wiki changeset show <changesetId> <slug> # Show detail + feedback
+parall wiki changeset diff <changesetId> <slug> # Show changeset diff
+\`\`\`
+
+If a changeset is rejected, fix the files locally and re-propose:
+
+\`\`\`bash
+parall wiki changeset create <slug> --update <changesetId>
+\`\`\`
+
+The title is inherited from the original changeset — no need to repeat it.
+
+## Handling sync conflicts
+
+\`wiki sync\` runs a three-way merge. When both you and the server changed the
+same file, sync **does not overwrite your work**. It leaves your file intact
+and drops the upstream version under \`.parall-wiki/conflicts/\`:
+
+| Marker | Meaning |
+|--------|---------|
+| \`.parall-wiki/conflicts/<path>.remote\` | Server has different content (concurrent edit, new file collision, or server changed a file you deleted) |
+| \`.parall-wiki/conflicts/<path>.remote-deleted\` | Server deleted the file; you still have edits |
+
+stderr prints one line per conflict. Recovery:
+
+**Accept upstream** (drop your edit):
+\`\`\`bash
+cp .parall-wiki/conflicts/<path>.remote <path>
+parall wiki sync
+\`\`\`
+
+**Keep yours** (or hand-merge, then propose):
+\`\`\`bash
+# edit <path> to final content
+parall wiki diff <slug>
+parall wiki changeset create <slug> --title "Reconcile <path>"
+parall wiki sync   # fast-forwards after server merges
+\`\`\`
+
+**Accept server delete** (\`.remote-deleted\` only):
+\`\`\`bash
+rm <path>
+parall wiki sync
+\`\`\`
+
+Sync failures (\`download\`, \`shape-conflict\`) set exit code 1 and retry on
+next sync. Conflicts exit 0 — they need your decision, not a retry.
+
+## Discarding local changes
+
+\`\`\`bash
+parall wiki reset <slug>      # Restore all files to last synced state
+\`\`\`
+
+## History
+
+\`\`\`bash
+parall wiki log <slug>        # Recent wiki operations
+\`\`\`
+
+All CLI output is JSON. Run \`parall wiki --help\` for full options.
+`;