Skip to main content
Glama
Sign In
Vibeflow

Vibeflow

by zorcec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update task

update_task

Update existing tasks in Vibeflow by modifying status, title, description, and task links. Use this tool to add comments or provide a verification verdict to manage the task lifecycle.

Instructions

Update an existing task. Supports status changes, title/description updates, adding comments, and changing the task's links (parent/relates/blocks). Pass fields (e.g. ["id","status"]) for a compact answer instead of the full task object; pass dryRun to preview the edit without writing anything, and branch to record the work branch (required on the review transition when the project sets createBranch). REVIEW GATE (same rules as vibeflow tasks --edit, same codes): status "review" REQUIRES comment (refused REVIEW_COMMENT_REQUIRED); an ANNOTATED task (url + selector) additionally REQUIRES a verdict (setVerify pass/fail/cannot — refused VERIFY_REQUIRED); commitMessage is REQUIRED when auto-commit is ON (refused COMMIT_MESSAGE_REQUIRED); a Research task must NOT carry a verdict (refused RESEARCH_VERIFY_NOT_ALLOWED — submit Research with its .md report, no verdict). Pass setVerify to record your verification verdict: "pass" attests the task IS implemented correctly (verified=true, green badge — required for annotated tasks at the review transition, which vibeflow verify never sets itself), "fail" records that it is NOT implemented correctly (verified=false, amber badge, the review gate rejects it), and "cannot" clears the verdict back to absent (no badge) for a task that cannot be assessed here — "cannot" REQUIRES verifyReason, which is recorded in the task's activity. Use it to change a task you already hold; use add_comment to discuss without changing fields, and verify_task to actually RUN visual verification (a verdict here records an assessment, it runs nothing).

LINKS — everything merges, and clearLinks is the only destructive path. links and addLinks both MERGE: a link you do not name is PRESERVED, and re-sending a link that is already there is a no-op, so neither of them can destroy a link by being incomplete. removeLinks removes exactly the taskId+type pairs you name and leaves every other link alone. clearLinks: true is the ONLY way to remove links wholesale — to drop a single link, name that taskId+type in removeLinks rather than editing links. Omitting all four fields leaves links untouched. The CLI's --set-parent/--relates/--blocks/--unrelates/--unblocks behave the same way (each is surgical and preserves every link it does not name), so the CLI and MCP surfaces now agree on link semantics.

Input Schema

NameRequiredDescriptionDefault
idYesTask id — a full id, or any unique prefix of one, of the task to update. An id that matches nothing is refused with TASK_NOT_FOUND and changes nothing.
linksNoADD the listed links without touching the rest (merge, same as the CLI's --relates/--blocks). A pair already present is a no-op. `links: []` is REFUSED — use clearLinks:true to clear. Combining `links` with `addLinks` merges their union once.
titleNoReplacement title. Omit to keep the current one.
branchNoBranch for this task's work. REQUIRED on the review transition when the project sets createBranch (refused BRANCH_REQUIRED); stored as branchName.
dryRunNoPreview only: validate the edit and report what WOULD change without writing the task file.
fieldsNoReturn only these task fields (e.g. ["id","status"]) instead of the full task object — a status flip need not cost a full ticket dump. Omit for the full object.
parentNoSet/replace the parent task link (full id or unique prefix; same as the CLI's --set-parent). Empty string clears the parent (same as --no-parent). Applied after clearLinks/links/addLinks/removeLinks.
statusNoNew status. Moving to review triggers the review gate (comment, and for annotated tasks a verdict, may be required).
commentNoComment to attach (same as the CLI's --comment). REQUIRED when status is "review" — the review transition is refused with REVIEW_COMMENT_REQUIRED without one.
addLinksNoADD links without touching the rest (merge). Same semantics as `links` — sending both merges their union once. Use clearLinks:true to drop the whole set.
setVerifyNoYour verification verdict: "pass" = the task IS implemented correctly (required for an annotated task at review), "fail" = it is NOT (the review gate blocks it), "cannot" = unverifiable here, which REQUIRES verifyReason. Omit to leave any stored verdict untouched.
clearLinksNoRemove EVERY link from the task. Applied BEFORE the merge: clearLinks -> (links + addLinks) -> removeLinks. `true` clears; `false` or absent is a no-op.
descriptionNoReplacement task body. Omit to keep the current one.
removeLinksNoREMOVE the listed links without touching the rest. Applied after clearLinks and after the links/addLinks merge.
verifyReasonNoWhy the task cannot be verified. REQUIRED with setVerify:"cannot", and refused as E_USAGE on its own — a reason belongs to a "cannot" verdict.
commitMessageNoCommit message for the review auto-commit (same as the CLI's --commit-message). REQUIRED when status is "review" and auto-commit is ON (refused with COMMIT_MESSAGE_REQUIRED); ignored when auto-commit is off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.22.0
    • addedInput schema / properties / branch / description
      Added value: +"Branch for this task's work. REQUIRED on the review transition when the project sets createBranch (refused BRANCH_REQUIRED); stored as branchName."
    • addedInput schema / properties / description / description
      Added value: +"Replacement task body. Omit to keep the current one."
    • addedInput schema / properties / dryRun / description
      Added value: +"Preview only: validate the edit and report what WOULD change without writing the task file."
    • addedInput schema / properties / status / description
      Added value: +"New status. Moving to review triggers the review gate (comment, and for annotated tasks a verdict, may be required)."
    • addedInput schema / properties / title / description
      Added value: +"Replacement title. Omit to keep the current one."
  2. Changed5 schema fields changedv0.21.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / comment / description
      Added value: +"Comment to attach (same as the CLI's --comment). REQUIRED when status is \"review\" — the review transition is refused with REVIEW_COMMENT_REQUIRED without one."
    • addedInput schema / properties / commitMessage / description
      Added value: +"Commit message for the review auto-commit (same as the CLI's --commit-message). REQUIRED when status is \"review\" and auto-commit is ON (refused with COMMIT_MESSAGE_REQUIRED); ignored when auto-commit is off."
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Return only these task fields (e.g. [\"id\",\"status\"]) instead of the full task object — a status flip need not cost a full ticket dump. Omit for the full object.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / parent
      Added value: +{
+  "description": "Set/replace the parent task link (full id or unique prefix; same as the CLI's --set-parent). Empty string clears the parent (same as --no-parent). Applied after clearLinks/links/addLinks/removeLinks.",
+  "type": "string"
+}
  3. First observedv0.20.0

TDQS

A3.9/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare destructiveHint=false, but the description says clearLinks is 'the only destructive path' and that clearLinks removes EVERY link from the task. That is a direct contradiction of the structured safety metadata, so it must be scored 1 despite the otherwise rich detail about gates, error codes, and merge behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the review-gate rules are organized with clear caps and error codes. It is long, but the complexity justifies most of the length; the repeated CLI cross-references are the main trimmable content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter mutation tool with no output schema and several hard gates, the description covers the critical preconditions, error codes, and interaction rules an agent needs. It is nearly complete, though the destructiveHint contradiction undermines trust in the safety profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful cross-parameter semantics: it explains that links/addLinks merge and preserve unnamed links, that clearLinks is the only wholesale removal path, and that clearLinks is applied before the merge sequence. This helps an agent reason about link operations beyond the individual field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource and enumerates the editable facets (status, title/description, comments, links). It explicitly distinguishes itself from add_comment and verify_task, so an agent can select it without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool versus add_comment (discuss without changing fields) and verify_task (actually run visual verification). It also specifies when dryRun, fields, branch, and the review-gate parameters matter, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools