Agent Skills › anymouschina/TapCanvas › tapcanvas-public-chat

tapcanvas-public-chat

GitHub

定义TapCanvas多步创作协作原则，明确Web、API与Agent职责边界及画布操作规范。

apps/agents-cli/skills/tapcanvas-public-chat/SKILL.md anymouschina/TapCanvas

Trigger Scenarios

用户在对话中发起多步创作请求需协调前端上下文与后端约束进行Agent编排

Install

npx skills add anymouschina/TapCanvas --skill tapcanvas-public-chat -g -y

More Options

Non-standard path

npx skills add https://github.com/anymouschina/TapCanvas/tree/main/apps/agents-cli/skills/tapcanvas-public-chat -g -y

Use without installing

npx skills use anymouschina/TapCanvas@tapcanvas-public-chat

指定 Agent (Claude Code)

npx skills add anymouschina/TapCanvas --skill tapcanvas-public-chat -a claude-code -g -y

安装 repo 全部 skill

npx skills add anymouschina/TapCanvas --all -g -y

预览 repo 内 skill

npx skills add anymouschina/TapCanvas --list

SKILL.md

Frontmatter

{
    "name": "tapcanvas-public-chat",
    "description": "定义 TapCanvas agents chat 运行时协作原则：web 收集上下文，hono-api 注入硬约束，agents 自主决策，skills 提供方法论。此 skill 只负责协作原则，不负责直接调用 TapCanvas `\/public\/*` API；凡是实际发请求，统一改用 `tapcanvas-api`。"
}

TapCanvas Public Chat

注意：

本 skill 不是 API 调用器。
凡是要实际请求 TapCanvas /public/* 接口，统一使用 tapcanvas-api。
不要在这里重新定义 apiKey、apiBaseUrl、endpoint 映射或请求脚本。

何时使用

用户在 /public/chat 或 Web 对话助手里发起多步创作请求
任务需要同时理解前端上下文、后端硬约束与 agents 自主编排边界

输入证据

用户请求与会话上下文
chatContext 中的显式事实
项目/flow/node/book/material 等工具结果

执行原则

web 只负责收集真实上下文并执行合法 plan
hono-api 只负责权限、协议、事实性、失败策略与审计
agents-cli 主代理负责意图识别、取证规划、技能加载、子代理拆分与结果汇总
后端 system prompt 只承载身份、事实 briefing、协议与失败约束；业务方法论以本 skill 及同组 runtime skills 为准
对显式、确定性的画布改动请求（如添加空文本节点、重命名节点、连接节点、更新少量已知字段），若当前 project/flow 作用域与目标足够明确，优先直接调用 tapcanvas_flow_patch 执行，不要退化成让用户手动操作
tapcanvas_flow_patch 现支持 deleteNodeIds 与 deleteEdgeIds。删节点时必须传真实 node id，且会级联删除关联边；只想断开连线时优先用 deleteEdgeIds
若同一轮 tapcanvas_flow_patch 同时包含 createNodes 与 createEdges，凡是会被边引用的新节点都必须先写显式稳定 id；label 绝不是 node id
若 tapcanvas_flow_patch.createNodes 会写入分组结构（创建 groupNode，或给节点写 parentId），要把组节点放在子节点前面，并把组内子节点按你期望的最终视觉顺序依次写入；运行时会按该顺序做 parent-first 重排与组内紧凑排列
kind=storyboard 是前端“分镜编辑”图片网格，不是镜头脚本容器；若本轮只有逐镜头文本、beat list 或章节拆解而没有镜头图，应创建 kind=storyboardScript 或 kind=text 节点，而不是把长段文字塞进 storyboard 的 content/prompt/text
只有在你明确提供 storyboardEditorCells，或用户明确要求“空白分镜板/空网格占位”时，才创建 kind=storyboard；否则默认视为节点类型选择错误
若当前明确选中了 kind=image / imageEdit 节点，且用户目标是“完善/优化/改写当前图片节点提示词”，先读取 tapcanvas_node_context_bundle_get 获取节点现有 prompt/systemPrompt/negativePrompt、结果图、上下游与 diagnostics，再决定改写范围；不要只根据选中态猜字段
对“优化当前图片节点提示词”这类针对既有节点的确定性修改，优先直接回写当前节点，而不是默认新建平行节点；只有用户明确要求分叉、保留旧版或另起一版时，才创建新节点
回写既有图片节点提示词时，优先用 tapcanvas_flow_patch.patchNodeData，并显式传 allowOverwrite=true，避免因为已有 prompt/systemPrompt/negativePrompt 被 409 拦下
kind=text 的节点允许为空内容占位；若用户明确要求“空文本节点/空白文本节点”，不要把 prompt / text 当成必填项
对“添加空白文本节点”这类确定性写入，优先使用 tapcanvas_flow_patch.createNodes；最小可用示例：{"createNodes":[{"type":"taskNode","position":{"x":0,"y":0},"data":{"kind":"text","label":"空白文本","nodeWidth":380,"nodeHeight":360}}]}。空占位时可省略 prompt / text / textResults
对 chapter-grounded 的 image / storyboard / composeVideo / video 写入，必须在同一轮 patch 内同步提交 data.productionMetadata；禁止先落节点、下一轮再补 metadata
SOP、创作方法论、提示词方法、连续性方法都属于 skill，而不是常驻 system prompt
事实判断必须来自实时工具结果，不得来自 docs/assets/ai-metadata
若本轮没有真实执行、没有真实生成、也没有返回合法 <tapcanvas_canvas_plan>，不得写成“已落地”“已完成”