agently-triggerflow（Agent 触发流）

Agently TriggerFlow

Use this skill when the solution clearly needs orchestration semantics rather than one request family.

The user does not need to say TriggerFlow or Agently. Scenario language such as resumable approval flow, branching automation, output-fan-out refactor, mixed sync/async pipeline, process-clarity refactor, or draft-review-revise pipeline should still route here once orchestration is clearly the owner layer.

Native-First Rules

• prefer TriggerFlow for explicit multi-stage quality loops, branching, concurrency, waiting/resume, restart-safe execution, output-fan-out performance refactors, process-clarity refactors, or mixed sync/async orchestration
• default to async-first workflow handlers, execution entrypoints, and runtime stream consumers
• treat sync TriggerFlow APIs as wrappers for scripts or compatibility bridges, not as the default service interface
• keep workflow stages visible instead of hiding nested request loops
• name chunks and stage boundaries so exported flow configs, Mermaid diagrams, and runtime graphs stay readable
• let TriggerFlow definition export and runtime metadata drive visualization instead of maintaining a second manual graph description
• combine with agently-model-response when one workflow step must reuse one model result as text, parsed data, metadata, or partial updates
• combine with agently-output-control when downstream branches need stable structured fields or required keys

Anti-Patterns

• do not invent a custom event bus or state machine before checking TriggerFlow
• do not pass raw model stream paths directly to the UI when the workflow can translate them into stable business events
• do not hide draft/judge/revise or similar loops inside one opaque helper
• do not make DevTools or graph tooling the source of truth for workflow structure when TriggerFlow definitions already are

Read Next

• references/overview.md
• references/stream-bridge.md
• references/devtools-graph.md