skills/agently-dynamic-task/SKILL.md
Use when the user needs Agently TaskDAG / Dynamic Task, model-generated or app-submitted DAG planning, TaskDAG validation, DynamicTaskResolver handlers, TaskDAGExecutor execution, or the Agently.create_dynamic_task compatibility facade. TaskDAG is the DAG foundation capability; Dynamic Task is the convenience facade over it and uses TriggerFlow as the execution substrate.
npx skillsauth add agentera/agently-skills agently-dynamic-taskInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill when the problem is a dynamic task graph: a model or application submits DAG data that must be planned, validated, pruned, resolved to handlers, and executed.
TaskDAG is the Agently DAG foundation capability. Dynamic Task is the current
compatibility and convenience facade over TaskDAG planning and execution, not a
TriggerFlow sub-API and not the strategic Agent task lifecycle. TriggerFlow is
the execution substrate under TaskDAGExecutor, while
Agently.create_dynamic_task(...) and agent.create_dynamic_task(...) remain
compact app-facing facade entrypoints.
Agently.create_dynamic_task(...) or agent.create_dynamic_task(...) when ordinary app code wants the compact facadeagent.create_task(...) or agent.create_task_loop(...) as the outer
AgentExecution owner and expose the DAG as an explicitly enabled Agent
candidate; do not turn the Dynamic Task facade into the long-running AgentTask lifecycle
ownerAgentlyTaskDAGPlanner, TaskDAGValidator, DynamicTaskResolver, and TaskDAGExecutor only when staged control is requiredplan=<TaskDAG> when the caller already owns the DAG and should skip model planningTaskDAG.from_yaml(...) or TaskDAG.from_json(...) when the submitted DAG is a reviewed config artifactinputs placeholders for small runtime wiring:
${INIT} / ${INIT.foo} for initial graph input,
${DEPS.task_id.path} for dependency results, ${STATE...} for
execution-local state, and ${TRIGGER...} for the raw TriggerFlow trigger
payload. Slot names are case-insensitive, but examples should use uppercase.
Whole-string placeholders preserve the original value type; embedded
placeholders stringify into the surrounding text. Missing runtime paths fail
closed during executionagent.create_execution(), let
${INIT...} read use_dynamic_task(graph_input=...) when explicit, otherwise
the frozen execution prompt input slot, then {"target": task_target}; do
not add a second inputs.input or task-local prompt mapping surfaceplanner=<agent-or-provider-settings> when the model must generate the DAGmodel=<agent-or-provider-settings> for model task execution resourceshandlers={"risk_check_handler": handler} for local/custom tasks; handler names should be explicit and usually end in _handleractions=... or skills=... only when the planner should be allowed to use those task kinds; do not expose them by defaultoutput_schema or node-level inputs.output_schemainputs.output_format by result type when the plan is
generated or submitted: omit it to let the request read
prompt.default_output_format (global default json); use json for compact machine-control data, action
arguments, routing flags, standalone booleans/numbers, strict extraction,
model judges, and dense all-typed arrays/objects; xml_field for flat string long
text/code/HTML/SVG/Markdown/SQL/templates; explicit hybrid for long
prose/code fields mixed with typed list/object/boolean/number fields when
retry latency is acceptable; explicit flat_markdown only for legacy
section-header compatibility; explicit yaml_literal only
when a YAML target document is intentionally desired; auto only when
structural schema-driven selection and retry latency are acceptable after the
target model has passed representative stability checks. qwen2.5:7b checks
found hybrid can omit section headers or echo old scaffold comments into text
fieldsTaskDAGValidator reject duplicate ids, missing dependencies, cycles, unsupported required task kinds, schema-version mismatches, unsafe side-effect policy, and unknown required handlers before execution${INIT...} / ${DEPS...} placeholders for small declarative input
wiring; for larger transformations, keep the logic in a handler or model taskvalidate or emit as ordinary task kindsSubmitted DAG:
from agently import Agently
async def risk_check_handler(context):
return {
"task_id": context.task.id,
"deps": dict(context.dependency_results),
}
task = Agently.create_dynamic_task(
target="review policy",
plan={
"graph_id": "review",
"task_schema_version": "task_dag/v1",
"tasks": [
{"id": "extract", "kind": "local", "binding": "risk_check_handler"},
{
"id": "final",
"kind": "local",
"binding": "risk_check_handler",
"depends_on": ["extract"],
"inputs": {
"source": "${INIT}",
"extract_result": "${DEPS.extract}",
},
},
],
"semantic_outputs": {"final": "final"},
},
handlers={"risk_check_handler": risk_check_handler},
)
snapshot = await task.async_start(timeout=10)
result = snapshot["semantic_outputs"]["final"]
Config-backed submitted DAG:
from agently import Agently
from agently.core import TaskDAG
graph = TaskDAG.from_yaml("plans/review.yaml")
task = Agently.create_dynamic_task(
target="review policy",
plan=graph,
handlers={"risk_check_handler": risk_check_handler},
)
snapshot = await task.async_run(graph_input={"doc": "policy"}, timeout=10)
Use TaskDAG.from_json(...) for JSON/JSON5 files or raw content. Both loaders
support task_dag_key_path="plans.review" for selecting one DAG from a larger
config. Use graph.get_yaml(path) or graph.get_json(path) to export a
normalized graph.
Auto-planned DAG:
from agently import Agently
task = Agently.create_dynamic_task(
target=user_goal,
planner=planner_agent,
model=worker_agent,
output_schema={
"answer": (str, "final user-facing answer", True),
},
)
graph = await task.async_plan(max_retries=3)
task.validate(graph, strict_schema_version=True)
snapshot = await task.async_run(graph_input={"goal": user_goal}, timeout=30)
Lower-level integration:
from agently.builtins.plugins import AgentlyTaskDAGPlanner
from agently.core import DynamicTaskResolver, TaskDAGExecutor, TaskDAGValidator
resolver = DynamicTaskResolver({"risk_check_handler": risk_check_handler})
validator = TaskDAGValidator(resolver)
planner = AgentlyTaskDAGPlanner(validator=validator)
graph = await planner.async_plan(planner_agent, {"target": "review policy"})
validation = validator.validate(graph, strict_schema_version=True)
snapshot = await TaskDAGExecutor(resolver, validator=validator).async_run(graph)
Planner plugins and planner prompts must declare:
task_dag/v1The facade planner should wire .output(planner.output_schema(), format="json"), required
planner.ensure_keys(), and .validate(planner.validate_output) so structural
problems become model-output validation failures before execution. Compile/run
still revalidates the graph.
Layer ownership:
TaskDAG / TaskDAGNode data contracts and YAML/JSON graph config belong to agently.types.dataTaskDAGExecutor, TaskDAGValidator, and DynamicTaskResolver belong to coreAgentlyTaskDAGPlanner owns planner output schema, ensure keys, and planner instructions as a plugin concernAgently.create_dynamic_task(...) and agent.create_dynamic_task(...) are the app-facing facade entrypointsjson.loads(...), regex marker splits, or code-block extraction when Agently output schemas can own the shapeactions or skills to the planner by defaultTaskDAGExecutor from ordinary app code when Agently.create_dynamic_task(...) is enoughrisk_check; use risk_check_handler or another name that describes the callable rolereferences/overview.mdexamples/minimal.pytools
Use when the user wants to build, initialize, validate, optimize, or refactor a model-powered assistant, internal tool, automation, evaluator, or workflow from a business scenario or common problem statement, including project-structure refactors or starter skeletons that may separate model setup, prompt config, and orchestration, even if the request also mentions a UI, app shell, or local model service such as Ollama, and it is still unclear whether the solution should stay a single request, add supporting capabilities, or become orchestration. The user does not need to mention Agently explicitly.
tools
Use when the user wants Agently runtime extension capabilities: Action Runtime, built-in action packages, legacy tool compatibility, MCP access, Execution Environment lifecycle, FastAPIHelper or streaming API exposure, auto-function helpers, KeyWaiter, or optional agently-devtools observation, evaluation, and playground integration.
development
Use when the user is shaping Agently request-side behavior: model setup, settings files, prompt management, structured output, response reuse, streaming consumption, session memory, embeddings, knowledge-base indexing, retrieval, or retrieval-backed answers within one request family.
development
Use when the user needs workflow orchestration such as branching, concurrency, approvals, waiting and resume, runtime stream, restart-safe execution, mixed sync/async function or module orchestration, event-driven fan-out, process-clarity refactors that make stages explicit, performance-oriented refactors that collapse split requests, or workflow definitions and chunk-level runtime metadata that must stay visible for debugging and visualization. The user does not need to say TriggerFlow explicitly.