workflow-builder
GitHub用于构建一次性工作流适配器，明确调度独立操作。强调单次执行、无重试机制及最小化脚本原则，防止演变为复杂编排框架。适用于需要显式控制操作执行与错误报告的场景。
Trigger Scenarios
Install
npx skills add boshu2/agentops --skill workflow-builder -g -y
SKILL.md
Frontmatter
{
"name": "workflow-builder",
"description": "Scaffold an explicit one-shot workflow Triggers: \"build a workflow adapter\", \"scaffold a one-shot workflow\"."
}
Workflow Builder — one-shot adapter authoring
Build a thin adapter only when a caller needs to dispatch an explicit set of independent operations. A workflow is convenience code, never a correctness or lifecycle authority.
At-most-once dispatch over explicit inputs is the whole safety argument: a workflow that cannot retry or select work cannot compound a failure, so the worst case is one reported error per operation.
Named failure mode — framework gravity: a one-shot script growing config files, plugin hooks, and a state store until it is an unrequested orchestrator.
Anti-pattern: adding retry-on-failure "just for robustness". Corrective: report the per-operation error and stop; the caller owns whether anything runs again.
Contract
- Inputs, executors, write scopes, and outputs are supplied explicitly.
- Each operation is dispatched at most once.
- Parallel operations must have caller-proven disjoint write scopes.
- The workflow reports per-operation output or error and then stops.
- It contains no work selection, retry, budget, queue, tracker, validation, Git, integration, closure, release, or delivery logic.
- Optional substrate state cannot be translated into RPI or verdict state.
Prefer the smallest script supported by the target runtime. Include a dry-run or fixture demonstrating exact dispatch count and failure reporting. Do not create a new framework or SDK abstraction unless the caller explicitly requests one.
Version History
-
7b07a7d
Current 2026-08-19 22:04
修复技能元数据保留问题，增强YAML验证及回归测试覆盖。
- 3f402e5 2026-07-24 22:11
