> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/talus-docs-v2.1.0/guides/tap-development/dag-and-skill-config.md). # Configure DAG and Skill {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Produce a Talus Agent Package (TAP) DAG and skill configuration whose Tool bindings, inputs, and authority expectations can be validated before publication. {% endhint %} The Move package now compiles and exposes `transfer_vertex::execute`. Before we publish, we need to teach the workflow about it. That happens in two files: * `dag.json` — the workflow definition. We tell it about the on-chain vertex, its FQN, and which entry ports we'll feed at execute time. * `skill.tap.json` — the Talus Agent Package (TAP) skill manifest. We point it at the DAG and keep the rest of the requirements at scaffold defaults. The CLI resolves the sibling `tap/` package automatically. Both files were created by `nexus tap scaffold` with off-chain-tool defaults. We're going to overwrite them. ### 1. Rewrite `dag.json` The scaffold writes a one-vertex DAG referencing a placeholder off-chain weather tool. Replace it with our on-chain transfer vertex: ```json { "vertices": [ { "kind": { "variant": "on_chain", "tool_fqn": "tutorial.local.transfer_vertex@1" }, "name": "transfer_vertex", "entry_ports": [{ "name": "0" }, { "name": "1" }] } ], "edges": [] } ``` What's going on: * **`variant: "on_chain"`** flips the vertex kind. The workflow runtime will expect an on-chain Move tool registered under the FQN below. * **`tool_fqn: "tutorial.local.transfer_vertex@1"`** is the FQN you set in the Move source and that the registration on the next page will use. The Move source, the DAG, and the on-chain Tool registration must all agree on this string. * **`name: "transfer_vertex"`** is the vertex name inside the DAG. It's what we type when we feed inputs at execute time (`--input-json '{"transfer_vertex": {...}}'`). * **`entry_ports`** lists the inputs the workflow will collect from the invoker. Port `"0"` is the `state` object and port `"1"` is the recipient address. `UIDRequirements`, `OnchainToolResult`, and `TxContext` are framework inputs and do not appear as entry ports, so the user inputs line up with `execute(requirements, result, state, recipient, ctx)`. You're not declaring types here; the leader reads the registered tool's input schema at runtime and validates the entry-port JSON against it. #### 2. Rewrite `skill.tap.json` ```json { "name": "tutorial transfer", "dag_path": "dag.json", "requirements": { "input_commitment": [1], "payment_policy": "UserFunded", "schedule_policy": "Once", "fixed_tools": [] }, "shared_objects": [], "interface_revision": { "inner": 1 } } ``` Field by field: * **`dag_path`** is relative to this file. The TAP package is always the sibling `tap/` directory for this CLI workflow. * **`requirements.input_commitment`** is an opaque byte vector in the local config. The later `nexus tap create-skill-artifact` command derives the on-chain artifact commitment from the published DAG's actual entry inputs, so do not hand-copy this placeholder into an artifact. * **`payment_policy: "UserFunded"`** allows an address-funded Task to reserve MIST from the configured signer's Nexus SUI balance. The alternative shape is `{"AgentFunded": {"max_budget_mist": }}`, which draws from the Agent's payment vault and caps its budget. * **`schedule_policy: "Once"`** permits one-shot scheduling. Recurring skills use `{"Recurring": {"min_interval_ms": , "max_occurrences": }}`. * **`fixed_tools: []`** means this skill records no required Tool FQNs. Fixed tools are FQN registration dependencies, not authorization grant lists or a proof that a Tool remains in the selected DAG; verify DAG vertices and Tool IDs separately. * **`shared_objects: []`** leaves reusable shared-object aliases empty because this guide supplies `TutorialState` directly in Task inputs. * **`interface_revision.inner: 1`** is the Talus Agent skill interface generation used by this guide; `nexus tap update-skill` advances a live skill revision when its DAG or requirements change. #### 3. Dry-run Run the local dry-run to confirm the DAG, the on-chain Tool reference, and the skill requirements all line up: ```bash nexus tap dry-run --config skill.tap.json ``` You should see the validation summary again — no chain calls happen. This local check parses the config and DAG and validates the TAP manifest/source layout. Registration later derives the Tool schema from Move, and DAG publication binds the vertex to that registered schema. > Note: `dry-run` does **not** publish or execute the Move Tool. The Tool only runs after a Task Occurrence is dispatched and a leader creates its Execution. #### 4. What changed You now have: * A `dag.json` whose only vertex is the on-chain transfer tool we wrote. * A `skill.tap.json` whose `payment_policy` makes the invoker pay for each execution, whose `schedule_policy` keeps everything single-shot, and whose `fixed_tools` requirement is empty. * A `validate-skill` and `dry-run` that both pass. Everything is still local — nothing has touched the chain yet. The next page publishes the Move package, registers the on-chain Tool, publishes the DAG, creates its artifact, and binds the Agent. Next: [Publish, register, bind](/talus-docs-v2.1.0/guides/tap-development/publish-register-bind.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.talus.network/talus-docs-v2.1.0/guides/tap-development/dag-and-skill-config.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.