skill-authoring-workflow

Help implement the Seizu skill authoring request the request input carries.

Inputs — the values arrive in the ## Inputs block below these instructions: They are inputs to THIS skill, not arguments to any tool.

• request — the skillset or skill authoring change to design or apply.
• target_skillset_id — the existing or proposed skillset id, if known.
• target_skill_id — the existing or proposed skill id, if known.
• dry_run — when true, produce payloads without writing anything.

Never pass request, target_skillset_id, target_skill_id, or dry_run as parameters to a skillsets__* tool — they are not recognized tool fields. When you call a tool, map target_skillset_id to the tool's skillset_id and target_skill_id to the tool's skill_id. Use dry_run only to decide whether to call a write tool at all; never send it as a tool argument.

Tool arguments — use exactly these field names and no others:

• skillsets__create: skillset_id, name, description, enabled
• skillsets__update: skillset_id, name, description, enabled, comment
• skillsets__create_skill: skillset_id, skill_id, name, template, description, parameters, triggers, tools_required, enabled
• skillsets__update_skill: skillset_id, skill_id, name, template, description, parameters, triggers, tools_required, enabled, comment
• toolsets__create: toolset_id, name, description, enabled
• toolsets__update: toolset_id, name, description, enabled, comment
• toolsets__create_tool: toolset_id, tool_id, name, description, cypher, parameters, enabled
• toolsets__update_tool: toolset_id, tool_id, name, description, cypher, parameters, enabled, comment name and template are required on every create_skill and update_skill call; name and cypher are required on every create_tool and update_tool call. parameters is a list of objects shaped {name, type, description, required, default}.

Full-object writes: skillsets__update, skillsets__update_skill, toolsets__update, and toolsets__update_tool REPLACE the stored record. Any optional field you omit resets to its default (enabled -> true, parameters / triggers / tools_required -> empty). Always call the matching get tool first (skillsets__get / skillsets__get_skill / toolsets__get / toolsets__get_tool) and resend the complete merged object, keeping every existing field you are not deliberately changing.

Cypher tools: toolsets__create_tool / toolsets__update_tool carry a read-only cypher query. A write or invalid query is rejected by the create/update call, and creating a tool is a mutating (approval-gated) action — never spend an approval on a query you have not checked. Before any tool create/update with cypher:

1. Call graph__schema to see available node labels, relationship types, property keys, and indexes.
2. Call graph__validate_query with the tool's exact cypher. If valid is false, fix the query and re-validate; do not call create_tool/update_tool until it is valid.
3. Call graph__explain and read the returned plan. Prefer queries that match an indexed label/property (see the indexes from graph__schema) and avoid full scans (e.g. AllNodesScan, or a label scan over a large label); adjust the query to use an index where possible, and surface any unavoidable full scan as a risk.
4. Keep the tool's parameters in sync with the cypher: every $param the query references MUST be declared in parameters (with a type), and remove any declared parameter the new query no longer uses. create_tool/update_tool rejects a query that references an undeclared parameter (it would otherwise fail every call), so when you change a query's parameters you must update the parameters list in the same write. Only after the cypher validates and the plan is acceptable, call create_tool/update_tool.

Operating rules:

• Treat dry_run=true as plan-only. Do not call create or update tools in dry-run mode; produce the exact proposed payloads instead.
• Treat dry_run=false as an apply request: after inspecting current state and validating cypher, you MUST call the create/update tools in this same run. Do not stop after validation or after presenting payloads — produce the output sections AND apply the changes in one pass. (Writes are confirmation-gated, so the user still approves each mutation.) The default is to apply; only use dry_run=true when the request explicitly asks for a preview or plan.
• Never delete a skillset or skill from this workflow. If deletion seems necessary, recommend it separately and require explicit user confirmation outside this skill.
• Preserve existing enabled state unless the request explicitly says otherwise.
• Use lower_snake_case IDs, at most 31 characters each (so the full skillset__skill / toolset__tool name stays under the 64-char limit). Do not rename IDs unless the user explicitly requests a migration.
• Keep templates actionable: include required tool order, output format, evidence rules, and limits.
• Every tool named in a template's workflow must appear in tools_required unless it is only mentioned as an example.