SKEIN

skein_reparent

Destructive

Move an EXISTING issue under a new parent. This is THE tool for re-parenting — skein_dep_add(type="parent-child") only ADDS a parent and rejects a second one with parent_already_set; setting the parent at creation uses parentId on skein_create. skein_reparent atomically replaces the issue's single parent-child edge in one SERIALIZABLE transaction (self-healing a double-parented child to exactly one edge), bumps the issue version, and emits issue.reparented plus the per-edge dependency.deleted / dependency.created audit rows. ANSWERS WITH AN ACKNOWLEDGEMENT by default — the id, the applied state and the new version, no issue card and no prose — so the expectedVersion cycle continues without a re-read; pass verbose for the full IssueDetail.

Required: id (the issue to move), newParentId (the new parent), and expectedVersion for optimistic concurrency. On version mismatch returns {error:"version_conflict", currentVersion:<int>} — re-read with skein_show and retry. The new parent must be in the SAME project (reparent_cross_project otherwise) and must not already be a descendant of the issue (dependency_cycle). An issue cannot be its own parent (reparent_self).

NOT lock-gated: reparent moves a graph edge (like skein_dep_add / skein_dep_remove), so a lock held by another session does not block it — concurrency is guarded by expectedVersion alone.

NOT idempotent: re-running with the same newParentId still performs a real move (DELETE+INSERT) and bumps the version — compare parentIdCurrent first if you want to avoid a no-op move. On success returns the acknowledgement (id, status, the new version); pass verbose for the full IssueDetail.

Post-action summary: report ✓ <id> re-parented under <newParentId> so the user can scan the move.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "newParentId": "<newParentId>",
      "expectedVersion": "<expectedVersion>"
    },
    "name": "skein_reparent"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Full hierarchical id of the issue to move (e.g. "demo-42" or "demo-42.1").
`verbose`	No	Return the full IssueDetail, prose included. Default false = acknowledgement: `id`, `ok`, `version` plus the post-state stamps that apply (`status`, `assignee`, lock / claim / close stamps) — no issue card and no free text. The version is always there, so the expectedVersion cycle needs no extra read. Details: skein_get_instructions.
`newParentId`	Yes	Full hierarchical id of the new parent. Must be in the same project and must not be a descendant of the issue.
`expectedVersion`	Yes	The version the agent expects on the issue. The move only proceeds when the live version matches; otherwise returns version_conflict with the live version.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive=true and idempotent=false, and the description goes well beyond them: SERIALIZABLE single-transaction edge replacement, self-healing of double-parented children, version bump, emitted issue.reparented and per-edge audit rows, and the fact that it is not lock-gated. It also states explicitly that re-running with the same newParentId performs a real DELETE+INSERT — the exact hazard destructiveHint only hints at.

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?

Front-loaded and well-sectioned, with the distinguishing claim first and constraints in scannable clauses. It is long, though, and the acknowledgement return shape is described twice (the ACKNOWLEDGEMENT paragraph and again at the end of the non-idempotence paragraph), plus echoed in the verbose schema description — trimming one would lose nothing.

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

Completeness5/5

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

With no output schema, the description carries the return contract and does so fully: default acknowledgement fields, the verbose IssueDetail escape hatch, and the shape of the version_conflict error. Concurrency, failure modes, and a post-action summary instruction are all covered for a destructive graph mutation.

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 would be 3, but the prose adds meaning the schema does not: expectedVersion drives optimistic concurrency with a documented {error:"version_conflict", currentVersion} payload, and newParentId carries the same-project and not-a-descendant invariants with their error codes. Marginal duplication with the schema's verbose description keeps it off a 5.

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 ('Move an EXISTING issue under a new parent') and explicitly separates itself from the two nearest siblings by name: skein_dep_add(type="parent-child") only adds and rejects a second parent, and creation-time parenting belongs to skein_create's parentId. The agent can pick the right tool without opening any schema.

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?

Gives explicit when-to-use, when-not-to-use (dep_add, create), and the preconditions that select alternatives: same-project requirement, no-descendant requirement, no self-parenting. It also tells the agent to compare parentIdCurrent first to avoid a no-op and to re-read with skein_show on version_conflict.

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

All SKEIN tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.