ha-workflow-script
Hope-native authoring and review for durable workflow.js runs: deterministic host APIs, typed child results, bounded parallel/pipeline execution, budgets, replay-safe identity, staged consumption, and honest closure.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/ha-workflow-script && cp -r /tmp/ha-workflow-script/skills/ha-workflow-script ~/.claude/skills/ha-workflow-scriptSKILL.md
# Hope Workflow Script Use this for script-first dynamic Workflow authoring or repair. Workflow Mode lets the model decide whether orchestration helps; the user should not need to write `workflow.js` or enter a special coding mode. ## Boundary - A Workflow is one durable, observable execution run. - A Goal owns the durable outcome and completion criteria. - A Loop schedules another trigger; do not implement recurrence inside a Workflow script. - Task handles expose progress; they are not op identities. - Permissions, approvals, isolation, quotas, and closure gates are enforced by the runtime, not by this text. ## Deterministic Runtime - Export `default async function main(workflow)` and finish with `workflow.finish(result)`. - Runtime op identity comes from deterministic execution position. `label` is display-only and never an id. - Keep the script hash fixed for a run. Edited-script resume may reuse only the safe matching prefix allowed by runtime provenance. - Use `workflow.now()` and `workflow.random(seed)` instead of ambient time or randomness. - No raw filesystem, process, environment, network, dynamic import, `eval`, or `Function`; use approved host APIs. ## Recommended Shape 1. Validate `workflow.meta`, `workflow.args`, scope, criteria, and budget. 2. Create user-visible tasks and retain returned task handles. 3. Observe current state through read/search host APIs. 4. Choose sequential, `parallel`, or `pipeline` execution based on dependency shape and cost. 5. Consume child results at useful checkpoints, steer or cancel when evidence changes, then run targeted validation. 6. Finish with result, artifacts, verification, and residual risk. ## Child Agents And Typed Results - Use `outputSchema` when the parent needs machine-consumable fields. - Keep `schemaRetries` bounded and reserve output tokens before spawn. - Treat repair output as structure repair, not permission to redo or expand the task. - Default write-capable work to isolated worktrees. Use `isolation: "shared_read_only"` only for genuinely read-only work; the runtime hard tool set is the security boundary. - Child completion is an input to synthesis, not proof that the Workflow or Goal is complete. ## Parallelism And Stage Consumption - `workflow.parallel(...)` fits bounded independent work followed by a barrier. - `workflow.pipeline(...)` fits a bounded window where fast results should be consumed and replenished before slow children finish. - `workflow.waitAny(...)` supports staged decisions. - `workflow.waitAll(...)` is valid when the task truly requires a barrier; status mode observes without consuming output. - `workflow.agentResult(...)` reads a child result; use `agentStatus`, steering, cancellation, or additional spawn when the plan must adapt. - Check `workflow.budgetStatus()` before expanding fan-out. Never create unbounded fan-out, recursive Workflow execution, or a fixed wait-all policy for every task. ## Replay And Closure - Materialize fan-out inputs and keep callback order deterministic. - Update tasks by handle, never by label. - Preserve typed result provenance and partial failures during synthesis. - `workflow.finish()` cannot honestly complete while owned children remain non-terminal; if the runtime budget expires, return blocked rather than a false success. - A completed Workflow must still provide a user-meaningful result to the main Agent; the completion registration itself is not the answer. ## Review Checklist - Are all side effects behind host APIs and permission gates? - Are identity, inputs, fan-out, time, and randomness replay-safe? - Are isolation and output schemas appropriate? - Can useful partial results be consumed without busy waiting? - Are budget, validation, failure, and stop conditions explicit? - Does the final result distinguish child completion from outcome completion? ## Smoke Prompts - "Draft a replay-safe workflow.js with typed parallel reviewers." - "Use pipeline consumption instead of waiting for every child." - "Review this Workflow for budget, isolation, and closure bugs."
>
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a pre-send self-check.
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Discover and install third-party skills from external registries when the user needs a capability that no currently-active skill covers. Trigger when: (1) the user explicitly asks 'find a skill for X', 'is there a skill that does X', 'install a skill to X', (2) the user requests a well-known integration (Slack, Notion, Trello, GitHub, Hue, Sonos, iMessage, weather, TTS, transcription …) that isn't in the active skill catalog, (3) you are about to hand-write ad-hoc shell / API code for a domain that almost certainly has a published skill. Do NOT trigger if an active skill already covers the need — scan the visible skill catalog first.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background jobs) directly via the `exec` tool to investigate problems, analyze usage, and locate root causes. Trigger on: user reports something broken / failing / slow / stuck / not responding ('X 不工作', 'X 报错', 'X 卡住', '为什么 X 失败', 'why did X fail', 'show me the logs', 'check what happened'); ad-hoc data analysis ('this week's token usage', '最近调用最多的工具', 'how many subagent runs failed', 'tool error rate', 'find sessions where X happened'); verifying a fix ('did the error stop after I changed Y'). Use BEFORE asking the user to paste log snippets — the data is on disk, query it directly. Read-only — SELECT only, never UPDATE/DELETE/INSERT/DROP.
Hope Agent native macOS desktop control — the standard `mac_control` status / diagnostics / apps / dock / spaces / snapshot / visual / windows / menu / clipboard / dialog loop, target-first action rules, no-blind-coordinate policy, and recovery for stale AX/window/menu/dialog state. Load whenever using `mac_control`, or when the user asks to control local Mac apps, Dock, Spaces, click/type/menu/window/dialog/clipboard, automate Finder/TextEdit/System Settings, visually locate UI, or says 控制 Mac, macOS 自动化, 点按钮, 打开应用, Dock, Space, 关闭窗口, 菜单点击, 视觉定位.
Self-understanding and issue reporting for Hope Agent itself. Use when the user asks how Hope Agent works internally, asks about its own source code/docs/runtime behavior, reports a bug/failure/slowness/crash, asks to diagnose logs, or asks to create/submit a GitHub issue for a bug, feature request, or improvement (including when there is no bug). Chinese triggers: 自查, 了解自己, 自我诊断, 排查 Hope Agent, 提交 issue, 需求 issue, 功能改进.