@oriro/orirocli 0.1.9 → 0.1.11

package/skills/summarize/SKILL.md

@@ -1,90 +1,90 @@
----
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-watermark: ORIRO
-name: summarize
-description: "Summarize or transcribe URLs, YouTube/videos, podcasts, articles, transcripts, PDFs, and local files."
-homepage: https://summarize.sh
-metadata:
-  {
-    "oriro":
-      {
-        "emoji": "🧾",
-        "requires": { "bins": ["summarize"] },
-        "install":
-          [
-            {
-              "id": "brew",
-              "kind": "brew",
-              "formula": "oriro/tap/summarize",
-              "bins": ["summarize"],
-              "label": "Install summarize (brew)",
-            },
-          ],
-      },
-  }
----
-
-# Summarize
-
-Fast CLI to summarize URLs, local files, and YouTube links.
-
-## When to use (trigger phrases)
-
-Use this skill immediately when the user asks any of:
-
-- "use summarize.sh"
-- "what's this link/video about?"
-- "summarize this URL/article"
-- "transcribe this YouTube/video" (best-effort transcript extraction; no `yt-dlp` needed)
-
-## Quick start
-
-```bash
-summarize "https://example.com"
-summarize "/path/to/file.pdf"
-summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto
-```
-
-## YouTube: summary vs transcript
-
-Best-effort transcript (URLs only):
-
-```bash
-summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto --extract
-```
-
-If the user asked for a transcript but it's huge, return a tight summary first, then ask which section/time range to expand.
-
-## Model + keys
-
-Set the API key for your chosen provider:
-
-- OpenAI: `OPENAI_API_KEY`
-- Anthropic: `ANTHROPIC_API_KEY`
-- xAI: `XAI_API_KEY`
-- Google: `GEMINI_API_KEY` (aliases: `GOOGLE_GENERATIVE_AI_API_KEY`, `GOOGLE_API_KEY`)
-
-Default model is `auto`; config may choose the provider/model.
-
-## Useful flags
-
-- `--length short|medium|long|xl|xxl|<chars>`
-- `--max-output-tokens <count>`
-- `--extract` (print extracted content, no LLM summary)
-- `--json` (machine readable)
-- `--firecrawl auto|off|always` (fallback extraction)
-- `--youtube auto` (Apify fallback if `APIFY_API_TOKEN` set)
-
-## Config
-
-Optional config file: `~/.summarize/config.json`
-
-```json
-{ "model": "openai/gpt-5.2" }
-```
-
-Optional services:
-
-- `FIRECRAWL_API_KEY` for blocked sites
-- `APIFY_API_TOKEN` for YouTube fallback
+---
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+watermark: ORIRO
+name: summarize
+description: "Summarize or transcribe URLs, YouTube/videos, podcasts, articles, transcripts, PDFs, and local files."
+homepage: https://summarize.sh
+metadata:
+  {
+    "oriro":
+      {
+        "emoji": "🧾",
+        "requires": { "bins": ["summarize"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "oriro/tap/summarize",
+              "bins": ["summarize"],
+              "label": "Install summarize (brew)",
+            },
+          ],
+      },
+  }
+---
+
+# Summarize
+
+Fast CLI to summarize URLs, local files, and YouTube links.
+
+## When to use (trigger phrases)
+
+Use this skill immediately when the user asks any of:
+
+- "use summarize.sh"
+- "what's this link/video about?"
+- "summarize this URL/article"
+- "transcribe this YouTube/video" (best-effort transcript extraction; no `yt-dlp` needed)
+
+## Quick start
+
+```bash
+summarize "https://example.com"
+summarize "/path/to/file.pdf"
+summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto
+```
+
+## YouTube: summary vs transcript
+
+Best-effort transcript (URLs only):
+
+```bash
+summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto --extract
+```
+
+If the user asked for a transcript but it's huge, return a tight summary first, then ask which section/time range to expand.
+
+## Model + keys
+
+Set the API key for your chosen provider:
+
+- OpenAI: `OPENAI_API_KEY`
+- Anthropic: `ANTHROPIC_API_KEY`
+- xAI: `XAI_API_KEY`
+- Google: `GEMINI_API_KEY` (aliases: `GOOGLE_GENERATIVE_AI_API_KEY`, `GOOGLE_API_KEY`)
+
+Default model is `auto`; config may choose the provider/model.
+
+## Useful flags
+
+- `--length short|medium|long|xl|xxl|<chars>`
+- `--max-output-tokens <count>`
+- `--extract` (print extracted content, no LLM summary)
+- `--json` (machine readable)
+- `--firecrawl auto|off|always` (fallback extraction)
+- `--youtube auto` (Apify fallback if `APIFY_API_TOKEN` set)
+
+## Config
+
+Optional config file: `~/.summarize/config.json`
+
+```json
+{ "model": "openai/gpt-5.2" }
+```
+
+Optional services:
+
+- `FIRECRAWL_API_KEY` for blocked sites
+- `APIFY_API_TOKEN` for YouTube fallback

package/skills/taskflow/SKILL.md

@@ -1,153 +1,153 @@
----
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-watermark: ORIRO
-disable-model-invocation: true
-name: taskflow
-description: "Coordinate multi-step detached tasks as one durable TaskFlow job with owner context, state, waits, and child tasks."
-metadata: { "oriro": { "emoji": "🪝" } }
----
-
-# TaskFlow
-
-Use TaskFlow when a job needs to outlive one prompt or one detached run, but you still want one owner session, one return context, and one place to inspect or resume the work.
-
-## When to use it
-
-- Multi-step background work with one owner
-- Work that waits on detached ACP or subagent tasks
-- Jobs that may need to emit one clear update back to the owner
-- Jobs that need small persisted state between steps
-- Plugin or tool work that must survive restarts and revision conflicts cleanly
-
-## What TaskFlow owns
-
-- flow identity
-- owner session and requester origin
-- `currentStep`, `stateJson`, and `waitJson`
-- linked child tasks and their parent flow id
-- finish, fail, cancel, waiting, and blocked state
-- revision tracking for conflict-safe mutations
-
-It does **not** own branching or business logic. Put that in Lobster, acpx, or the calling code.
-
-## Current runtime shape
-
-Canonical plugin/runtime entrypoint:
-
-- `api.runtime.tasks.flow`
-- `api.runtime.taskFlow` still exists as an alias, but `api.runtime.tasks.flow` is the canonical shape
-
-Binding:
-
-- `api.runtime.tasks.flow.fromToolContext(ctx)` when you already have trusted tool context with `sessionKey`
-- `api.runtime.tasks.flow.bindSession({ sessionKey, requesterOrigin })` when your binding layer already resolved the session and delivery context
-
-Managed-flow lifecycle:
-
-1. `createManaged(...)`
-2. `runTask(...)`
-3. `setWaiting(...)` when waiting on a person or an external system
-4. `resume(...)` when work can continue
-5. `finish(...)` or `fail(...)`
-6. `requestCancel(...)` or `cancel(...)` when the whole job should stop
-
-## Design constraints
-
-- Use **managed** TaskFlows when your code owns the orchestration.
-- One-task **mirrored** flows are created by core runtime for detached ACP/subagent work; this skill is mainly about managed flows.
-- Treat `stateJson` as the persisted state bag. There is no separate `setFlowOutput` or `appendFlowOutput` API.
-- Every mutating method after creation is revision-checked. Carry forward the latest `flow.revision` after each successful mutation.
-- `runTask(...)` links the child task to the flow. Use it instead of manually creating detached tasks when you want parent orchestration.
-
-## Example shape
-
-```ts
-const taskFlow = api.runtime.tasks.flow.fromToolContext(ctx);
-
-const created = taskFlow.createManaged({
-  controllerId: "my-plugin/inbox-triage",
-  goal: "triage inbox",
-  currentStep: "classify",
-  stateJson: {
-    businessThreads: [],
-    personalItems: [],
-    eodSummary: [],
-  },
-});
-
-const classify = taskFlow.runTask({
-  flowId: created.flowId,
-  runtime: "acp",
-  childSessionKey: "agent:main:subagent:classifier",
-  runId: "inbox-classify-1",
-  task: "Classify inbox messages",
-  status: "running",
-  startedAt: Date.now(),
-  lastEventAt: Date.now(),
-});
-
-if (!classify.created) {
-  throw new Error(classify.reason);
-}
-
-const waiting = taskFlow.setWaiting({
-  flowId: created.flowId,
-  expectedRevision: created.revision,
-  currentStep: "await_business_reply",
-  stateJson: {
-    businessThreads: ["slack:thread-1"],
-    personalItems: [],
-    eodSummary: [],
-  },
-  waitJson: {
-    kind: "reply",
-    channel: "slack",
-    threadKey: "slack:thread-1",
-  },
-});
-
-if (!waiting.applied) {
-  throw new Error(waiting.code);
-}
-
-const resumed = taskFlow.resume({
-  flowId: waiting.flow.flowId,
-  expectedRevision: waiting.flow.revision,
-  status: "running",
-  currentStep: "finalize",
-  stateJson: waiting.flow.stateJson,
-});
-
-if (!resumed.applied) {
-  throw new Error(resumed.code);
-}
-
-taskFlow.finish({
-  flowId: resumed.flow.flowId,
-  expectedRevision: resumed.flow.revision,
-  stateJson: resumed.flow.stateJson,
-});
-```
-
-## Keep conditionals above the runtime
-
-Use the flow runtime for state and task linkage. Keep decisions in the authoring layer:
-
-- `business` -> post to Slack and wait
-- `personal` -> notify the owner now
-- `later` -> append to an end-of-day summary bucket
-
-## Operational pattern
-
-- Store only the minimum state needed to resume.
-- Put human-readable wait reasons in `blockedSummary` or structured wait metadata in `waitJson`.
-- Use `getTaskSummary(flowId)` when the orchestrator needs a compact health view of child work.
-- Use `requestCancel(...)` when a caller wants the flow to stop scheduling immediately.
-- Use `cancel(...)` when you also want active linked child tasks cancelled.
-
-## Examples
-
-- See `skills/taskflow/examples/inbox-triage.lobster`
-- See `skills/taskflow/examples/pr-intake.lobster`
-- See `skills/taskflow-inbox-triage/SKILL.md` for a concrete routing pattern
+---
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+watermark: ORIRO
+disable-model-invocation: true
+name: taskflow
+description: "Coordinate multi-step detached tasks as one durable TaskFlow job with owner context, state, waits, and child tasks."
+metadata: { "oriro": { "emoji": "🪝" } }
+---
+
+# TaskFlow
+
+Use TaskFlow when a job needs to outlive one prompt or one detached run, but you still want one owner session, one return context, and one place to inspect or resume the work.
+
+## When to use it
+
+- Multi-step background work with one owner
+- Work that waits on detached ACP or subagent tasks
+- Jobs that may need to emit one clear update back to the owner
+- Jobs that need small persisted state between steps
+- Plugin or tool work that must survive restarts and revision conflicts cleanly
+
+## What TaskFlow owns
+
+- flow identity
+- owner session and requester origin
+- `currentStep`, `stateJson`, and `waitJson`
+- linked child tasks and their parent flow id
+- finish, fail, cancel, waiting, and blocked state
+- revision tracking for conflict-safe mutations
+
+It does **not** own branching or business logic. Put that in Lobster, acpx, or the calling code.
+
+## Current runtime shape
+
+Canonical plugin/runtime entrypoint:
+
+- `api.runtime.tasks.flow`
+- `api.runtime.taskFlow` still exists as an alias, but `api.runtime.tasks.flow` is the canonical shape
+
+Binding:
+
+- `api.runtime.tasks.flow.fromToolContext(ctx)` when you already have trusted tool context with `sessionKey`
+- `api.runtime.tasks.flow.bindSession({ sessionKey, requesterOrigin })` when your binding layer already resolved the session and delivery context
+
+Managed-flow lifecycle:
+
+1. `createManaged(...)`
+2. `runTask(...)`
+3. `setWaiting(...)` when waiting on a person or an external system
+4. `resume(...)` when work can continue
+5. `finish(...)` or `fail(...)`
+6. `requestCancel(...)` or `cancel(...)` when the whole job should stop
+
+## Design constraints
+
+- Use **managed** TaskFlows when your code owns the orchestration.
+- One-task **mirrored** flows are created by core runtime for detached ACP/subagent work; this skill is mainly about managed flows.
+- Treat `stateJson` as the persisted state bag. There is no separate `setFlowOutput` or `appendFlowOutput` API.
+- Every mutating method after creation is revision-checked. Carry forward the latest `flow.revision` after each successful mutation.
+- `runTask(...)` links the child task to the flow. Use it instead of manually creating detached tasks when you want parent orchestration.
+
+## Example shape
+
+```ts
+const taskFlow = api.runtime.tasks.flow.fromToolContext(ctx);
+
+const created = taskFlow.createManaged({
+  controllerId: "my-plugin/inbox-triage",
+  goal: "triage inbox",
+  currentStep: "classify",
+  stateJson: {
+    businessThreads: [],
+    personalItems: [],
+    eodSummary: [],
+  },
+});
+
+const classify = taskFlow.runTask({
+  flowId: created.flowId,
+  runtime: "acp",
+  childSessionKey: "agent:main:subagent:classifier",
+  runId: "inbox-classify-1",
+  task: "Classify inbox messages",
+  status: "running",
+  startedAt: Date.now(),
+  lastEventAt: Date.now(),
+});
+
+if (!classify.created) {
+  throw new Error(classify.reason);
+}
+
+const waiting = taskFlow.setWaiting({
+  flowId: created.flowId,
+  expectedRevision: created.revision,
+  currentStep: "await_business_reply",
+  stateJson: {
+    businessThreads: ["slack:thread-1"],
+    personalItems: [],
+    eodSummary: [],
+  },
+  waitJson: {
+    kind: "reply",
+    channel: "slack",
+    threadKey: "slack:thread-1",
+  },
+});
+
+if (!waiting.applied) {
+  throw new Error(waiting.code);
+}
+
+const resumed = taskFlow.resume({
+  flowId: waiting.flow.flowId,
+  expectedRevision: waiting.flow.revision,
+  status: "running",
+  currentStep: "finalize",
+  stateJson: waiting.flow.stateJson,
+});
+
+if (!resumed.applied) {
+  throw new Error(resumed.code);
+}
+
+taskFlow.finish({
+  flowId: resumed.flow.flowId,
+  expectedRevision: resumed.flow.revision,
+  stateJson: resumed.flow.stateJson,
+});
+```
+
+## Keep conditionals above the runtime
+
+Use the flow runtime for state and task linkage. Keep decisions in the authoring layer:
+
+- `business` -> post to Slack and wait
+- `personal` -> notify the owner now
+- `later` -> append to an end-of-day summary bucket
+
+## Operational pattern
+
+- Store only the minimum state needed to resume.
+- Put human-readable wait reasons in `blockedSummary` or structured wait metadata in `waitJson`.
+- Use `getTaskSummary(flowId)` when the orchestrator needs a compact health view of child work.
+- Use `requestCancel(...)` when a caller wants the flow to stop scheduling immediately.
+- Use `cancel(...)` when you also want active linked child tasks cancelled.
+
+## Examples
+
+- See `skills/taskflow/examples/inbox-triage.lobster`
+- See `skills/taskflow/examples/pr-intake.lobster`
+- See `skills/taskflow-inbox-triage/SKILL.md` for a concrete routing pattern

package/skills/taskflow/examples/inbox-triage.lobster

@@ -1,33 +1,33 @@
-# Illustrative Lobster authoring example for a TaskFlow-style inbox triage job.
-# Swap the placeholder commands for your own tools or scripts.
-
-name: inbox-triage
-steps:
-  - id: fetch
-    command: gog.gmail.search --query 'newer_than:1d' --max 20
-
-  - id: classify
-    command: >-
-      oriro.invoke --tool llm-task --action json --args-json
-      '{"prompt":"Classify each inbox item as business, personal, or later. Return one JSON object per item with route and summary.","thinking":"low","schema":{"type":"object","properties":{"items":{"type":"array"}},"required":["items"],"additionalProperties":false}}'
-    stdin: $fetch.stdout
-
-  - id: post_business
-    command: slack-route --bucket business
-    stdin: $classify.stdout
-    condition: $classify.json.items[0].route == "business"
-
-  - id: wait_for_business_reply
-    command: echo '{"status":"waiting","reason":"slack_reply"}'
-    condition: $classify.json.items[0].route == "business"
-
-  - id: notify_personal
-    command: >-
-      oriro.invoke --tool message --action send --args-json
-      '{"provider":"telegram","to":"owner-thread","content":"Personal inbox item needs attention."}'
-    condition: $classify.json.items[0].route == "personal"
-
-  - id: stash_for_eod
-    command: summary-append --bucket eod
-    stdin: $classify.stdout
-    condition: $classify.json.items[0].route == "later"
+# Illustrative Lobster authoring example for a TaskFlow-style inbox triage job.
+# Swap the placeholder commands for your own tools or scripts.
+
+name: inbox-triage
+steps:
+  - id: fetch
+    command: gog.gmail.search --query 'newer_than:1d' --max 20
+
+  - id: classify
+    command: >-
+      oriro.invoke --tool llm-task --action json --args-json
+      '{"prompt":"Classify each inbox item as business, personal, or later. Return one JSON object per item with route and summary.","thinking":"low","schema":{"type":"object","properties":{"items":{"type":"array"}},"required":["items"],"additionalProperties":false}}'
+    stdin: $fetch.stdout
+
+  - id: post_business
+    command: slack-route --bucket business
+    stdin: $classify.stdout
+    condition: $classify.json.items[0].route == "business"
+
+  - id: wait_for_business_reply
+    command: echo '{"status":"waiting","reason":"slack_reply"}'
+    condition: $classify.json.items[0].route == "business"
+
+  - id: notify_personal
+    command: >-
+      oriro.invoke --tool message --action send --args-json
+      '{"provider":"telegram","to":"owner-thread","content":"Personal inbox item needs attention."}'
+    condition: $classify.json.items[0].route == "personal"
+
+  - id: stash_for_eod
+    command: summary-append --bucket eod
+    stdin: $classify.stdout
+    condition: $classify.json.items[0].route == "later"

package/skills/taskflow/examples/pr-intake.lobster

@@ -1,32 +1,32 @@
-# Illustrative Lobster authoring example for a TaskFlow-style PR intake lane.
-# Replace the placeholder commands with repo-specific tooling.
-
-name: pr-intake
-steps:
-  - id: fetch
-    command: gh pr list --repo owner/repo --state open --json number,title,body,headRefName
-
-  - id: classify
-    command: >-
-      oriro.invoke --tool llm-task --action json --args-json
-      '{"prompt":"Classify each PR as close, request_changes, refactor, or maintainer_review. Return intent and recommended next action.","thinking":"low","schema":{"type":"object","properties":{"items":{"type":"array"}},"required":["items"],"additionalProperties":false}}'
-    stdin: $fetch.stdout
-
-  - id: close_low_signal
-    command: pr-close-low-signal
-    stdin: $classify.stdout
-    condition: $classify.json.items[0].nextAction == "close"
-
-  - id: request_changes
-    command: pr-request-changes
-    stdin: $classify.stdout
-    condition: $classify.json.items[0].nextAction == "request_changes"
-
-  - id: refactor_branch
-    command: pr-refactor-branch
-    stdin: $classify.stdout
-    condition: $classify.json.items[0].nextAction == "refactor"
-
-  - id: escalate
-    command: echo '{"status":"notify","target":"maintainer"}'
-    condition: $classify.json.items[0].nextAction == "maintainer_review"
+# Illustrative Lobster authoring example for a TaskFlow-style PR intake lane.
+# Replace the placeholder commands with repo-specific tooling.
+
+name: pr-intake
+steps:
+  - id: fetch
+    command: gh pr list --repo owner/repo --state open --json number,title,body,headRefName
+
+  - id: classify
+    command: >-
+      oriro.invoke --tool llm-task --action json --args-json
+      '{"prompt":"Classify each PR as close, request_changes, refactor, or maintainer_review. Return intent and recommended next action.","thinking":"low","schema":{"type":"object","properties":{"items":{"type":"array"}},"required":["items"],"additionalProperties":false}}'
+    stdin: $fetch.stdout
+
+  - id: close_low_signal
+    command: pr-close-low-signal
+    stdin: $classify.stdout
+    condition: $classify.json.items[0].nextAction == "close"
+
+  - id: request_changes
+    command: pr-request-changes
+    stdin: $classify.stdout
+    condition: $classify.json.items[0].nextAction == "request_changes"
+
+  - id: refactor_branch
+    command: pr-refactor-branch
+    stdin: $classify.stdout
+    condition: $classify.json.items[0].nextAction == "refactor"
+
+  - id: escalate
+    command: echo '{"status":"notify","target":"maintainer"}'
+    condition: $classify.json.items[0].nextAction == "maintainer_review"