/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.
$ npx -y skills add shiwenwen/hope-agent --skill ha-workflow-script --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ha-workflow-script
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
ha-workflow-script.SKILL.mdname: ha-workflow-script
description: "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."
paths: ["*.rs", "*.ts", "*.tsx", "*.js", "*.jsx", "*.py", "*.go", "*.java", "*.kt", "*.swift", "*.c", "*.cpp", "*.h", "*.rb", "*.php", "*.sh"]
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."
Read more
name: ha-workflow-script description: "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." paths: ["*.rs", "*.ts", "*.tsx", "*.js", "*.jsx", "*.py", "*.go", "*.java", "*.kt", "*.swift", "*.c", "*.cpp", "*.h", "*.rb", "*.php", "*.sh"]
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."
🦭 会记忆、能持续推进目标、会动态编排多 Agent 的跨端桌面 AI 助手,也可服务化常驻 NAS / 云端 | A cross-device desktop AI agent with memory, autonomous goals, dynamic workflows, and headless deployment
Repo: shiwenwen/hope-agent
Other skills on hope-agent.
- /email-draft
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.
Open skill - /feishu
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 +
Open skill - /ha-browser
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
Open skill - /ha-code-review
Hope-native review of uncommitted, staged, commit, branch, or PR changes: discover concrete regressions, independently verify candidates, and report actionable findings first without speculative noise.
Open skill - /ha-coding-common
Hope-native baseline for implementing, fixing, refactoring, and maintaining code: inspect the repository first, protect user changes, keep scope narrow, and finish with direct evidence.
Open skill - /ha-coding-plan
Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks, define verification, then continue execution when allowed.
Open skill

