360 Secure SkillHub
360 安全技能中心

fight-video-create-skill

核心功能分两类:一是依据用户锁定的人物、武器等要素,结合内置场景、招式等资料库,生成合规的战斗剧情、动作链与分镜;二是可吸收用户资料,按规范入库并维护路由元。适用于打斗剧情构思、动作设计及资料库扩充,输入为打斗构想或资料文件,输出对应创作内容或入库汇报,全程不生成模型提示词。

wangminrui2022
wangminrui2022
热度 7.62
最近更新 2026-09-19 11:12:50
分类:创作依赖:代码执行 / 读写文件 / 内部调用大模型应用场景:故事创作 / 数据处理 / 工作流 / 模板 ...

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add fight-video-create-skill
Metadata
name
fight-video-create-skill
description
Minimax H3文生视频、图生视频动作武打提示词生成,将用户的打斗构想通过场景、动作分镜方案、招式库、技能库和示例剧本的多层关键词检索,编译为可靠的战斗剧情、动作链、空间路线与动作分镜;也可将用户提供的一个或多个资料文件按用途吸收到 reference 资料库并维护路由元。用于打斗剧情构思、动作设计、招式设计、条件型技能设计、战斗分镜、资料入库或扩充打斗资料库;不负责提示词生成。

战斗设计、动作分镜与资料吸收

核心约束

  • 以用户锁定的人物、关系、武器、能力、动作顺序、胜负、时长、画幅、媒介和结尾为最高优先级。
  • 本 Skill 只交付战斗剧情、动作设计、空间调度与动作分镜,不生成任何模型或平台的提示词。
  • 提示词包装、模型或平台语法、生成参数、负面词、字幕/声音指令和成片提示语不得写入 reference/;吸收来源包含这些内容时必须先剥离。
  • 先路由、后读正文。不得预读所有资料后凭印象强行关联。
  • 自动匹配必须至少命中路由元中的一个关键词;零命中即视为无匹配。
  • 命中数越多排名越高;同命中数再按强字段权重和路由元裁决规则排序。
  • 一次只加载一个主动作/分镜方案。其他方案只作为可选项列出,用户确认前不混读、不拼接协议。
  • 参考资料提供机制、结构和质量标准,不覆盖用户锁定事实。
  • 不输出内部推理。应清楚说明选用了哪些资料、如何使用,以及哪些部分为全新设计。

路径与工具

资料固定存放在当前 Skill 内,从仓库根目录使用以下路径:

  • 场景:.cursor/skills/fight-video-create-skill/reference/scenes/00-路由元.json
  • 动作/分镜方案:.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/00-路由元.json
  • 招式:.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/招式库/00-路由元.json
  • 技能:.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/技能库/00-路由元.json
  • 示例剧本:.cursor/skills/fight-video-create-skill/reference/example-scripts/00-路由元.json

执行确定性检索:

python -X utf8 .cursor/skills/fight-video-create-skill/scripts/route_reference.py <scenes|design|moves|skills|scripts> --query "用户原文与提炼关键词"

资料入库或路由变更后执行:

python -X utf8 .cursor/skills/fight-video-create-skill/scripts/validate_routes.py

检索结果中的 eligible 只包含至少命中一个关键词的候选;available 用于展示所有可手动选择的方案,不代表自动匹配成功。技能库例外:只按“单体”或“群体”召回宽松候选,primary 固定为空;selection_notice 中的二级条件只用于选中后的提醒,不参与匹配或排序。

意图路由

先判断任务类型:

  1. 用户提供构想并要战斗剧情、动作设计或动作分镜:执行“创作流程”。
  2. 用户提供一个或多个文件并要求吸收、学习、入库、更新资料:执行“资料吸收流程”。
  3. 两者同时存在:先完成资料吸收并校验,再用更新后的资料执行创作流程。
  4. 意图不清或文件用途不唯一:先询问,不擅自入库。

创作流程

0. 提炼创作卡

从自然语言静默提炼:

  • 锁定事实:人物、敌我、武器、能力、必备动作、顺序、胜负、对白、时长、比例、媒介、结尾。
  • 设计关键词:题材、时代、场所、对战规模、战斗方式、武学/兵器、动作密度、写实程度、空间机制、镜头诉求、情绪、结局。
  • 缺口:只有会影响路线选择或成稿可靠性的必要信息。

不要让用户填写内部表格。若缺少时长和比例且不影响设计,可先采用资料方案默认值并在交付中声明。

1. 场景抽取

先判断用户是否已给出可执行场景。场景至少应包含明确地点或空间类型;仅有“古代”“赛博朋克”“仙侠”等题材不算完整场景。

已有场景:尊重用户场景,直接进入阶段 2;不要为了使用资料而替换场景。

没有场景:

  1. 用用户原文与场景相关提炼词检索 scenes。
  2. 有命中时,只读取排名第一的主场景;混合题材确有必要时最多再读一个辅助场景。
  3. 从资料中提取空间锚点、路线限制、可交互物、材质与光色,重新设计为适配当前剧情的场景,不复制无关角色或情节。
  4. 零命中时明确写“场景资料无关键词命中,将进行原创场景设计”,再按人物能力、战斗方式和情绪设计最小充分场景。

2. 动作与分镜方案

  1. 用用户原文、创作卡关键词和阶段 1 的场景摘要检索 design。
  2. 若有命中,向用户展示:
    • 推荐方案:名称、文件、命中词、推荐原因;
    • 其他方案:从 available 列出其名称与定位;
    • 选择项:采用推荐方案 / 改用其他方案 / 用户输入自定义方案。
  3. 必须等待用户确认。确认前不读取任何方案正文。
  4. 用户确认后只读取所选方案正文。用户主动改选零命中方案属于手动覆盖,应说明“按用户指定使用”,不得伪称自动匹配。
  5. 若零命中,提供两项:用户输入设计方案 / 智能体原创方案。不得把通用方案当作无条件回退;只有它也至少命中一个关键词时才能自动推荐。
  6. 读取所选方案后,将其编译为当前项目的动作因果、空间路线、镜头结构和连续性约束,不照抄与当前剧情冲突的默认角色、镜头数、时长或结尾。

2A. 招式检索与合理性门禁

仅当用户要求具体招式、武学绑定、逐招拆解、兵器技法或动作链需要专业技法支撑时执行:

  1. 用角色、身体条件、武器、主战距离、环境、对手和目标检索 moves。
  2. 只读取有关键词命中的候选,通常 1 个主文件,必要时最多 2 个互补文件。
  3. 对每个候选招式检查:
    • 角色是否掌握或能够合理使用;
    • 武器形制、肢体条件与主战距离是否兼容;
    • 当前姿态能否进入,上一动作末态能否衔接;
    • 场景是否提供所需空间、支点和落点;
    • 在目标时长内能否完成起势、接触、反馈和结果;
    • 是否破坏用户锁定的动作顺序、胜负或写实程度。
  4. 合理性高才选用并具体化身体路径、接触点和结果;合理性低则弃用,不为命中资料强改剧情。
  5. 全部候选不合理时,按同等生物力学完整度原创招式。
  6. 路由或索引提及但磁盘不存在的专项文件只能报告缺失,不得伪造其内容。

2B. 技能检索与特殊条件门禁

仅当角色需要独立能力机制,且该机制不能由招式库中的具体武学、兵器技法、身体路径或连续招式表达时执行:

  1. 先招式、后技能:先完成阶段 2A 的招式库检索与合理性判断;招式库已有或可通过吸收形成的内容不得改从技能库重复取用。
  2. 根据能力作用目标提炼且只提炼“单体”或“群体”,用该范围词检索 skills;不得把特殊法器、身体部位、介质、状态或发动动作加入技能匹配查询。
  3. 技能检索只做宽松候选召回,不采用 primary,也不得因路由编号靠前自动选中。向用户或当前智能体展示候选名称、能力定位和适用边界后再选择。
  4. 选中候选后,必须展示该项 selection_notice 中的:
    • secondary_keywords:特殊法器、身体部位、介质、状态或控制接口;
    • condition_prompt:发动前必须满足的条件;
    • condition_options:可创造条件、可行替代和放弃选项;
    • move_library_exclusions:与招式库的互斥边界。
  5. 若二级条件已经满足,才读取技能正文并应用;若未满足,让用户或智能体明确选择:创造合理条件 / 采用允许的替代条件 / 不采纳该技能。不得静默补设关键法器、身体结构、血契、介质或科技装备。
  6. 技能只补充“前置 → 发动 → 作用 → 终止”的能力机制。具体起势、身体路径、兵器接触、受力反馈和动作衔接仍从招式库获取或按同等完整度原创。
  7. 所有候选条件不兼容时放弃技能库,不为使用资料而修改用户锁定事实。

3. 剧情设计

  1. 用用户原文、创作卡和已确认动作方案检索 scripts。
  2. 有命中时读取排名第一的案例;只有宽泛题材且前两名确实互补时才读取第二个。
  3. 设计前明确告知用户:“将参考《文件名》的结构进行仿写/改编,不复用其专有角色与无关情节。”
  4. 只借用可迁移的剧情机制:冲突升级、攻防转折、空间阶段、高潮接口、结尾结构和时长组织。
  5. 不复制案例的专有角色、连续句子、独特设定或与用户输入冲突的胜负。
  6. 零命中时明确写“示例剧本无关键词命中,剧情将全新设计”。

4. 编译成稿

根据用户要求输出战斗剧情、动作设计或动作分镜。用户未指定格式时,按以下结构交付:

  1. 采用依据:已确认方案、场景参考、招式来源、案例参考及原创部分。
  2. 剧情设计:目标、冲突、升级、转折、胜负因果和结尾。
  3. 角色动作签名:起手、距离、移动、主战、破招、受击与终结。
  4. 动作设计:动作目的 → 起势/轨迹 → 对手响应 → 接触/落空/格挡 → 受力反馈 → 位移/状态结果 → 下一动作条件。
  5. 空间路线:起点、转向点、终点、环境机制和观察轴。
  6. 分镜表:时间段|叙事目的|景别与机位|人物位置|动作与攻防|主运镜及终点|接力状态|环境反馈。
  7. 连续性约束:角色/武器状态稳定、无身体融合、无回合制复位、无随机越轴、视觉效果不遮挡关键接触。

成稿必须满足:开场快速进入有效动作;重要动作有因果与结果;上一段末态成为下一段起点;一打多不排队;终结来自前文破绽;最后一帧仍有主体、摄影机或环境余波运动。

资料吸收流程

1. 识别与确认用途

逐个读取用户文件,建立清单:文件名、格式、主题、可复用内容、建议目标、重复/冲突风险。按主要用途分类:

  • 场景、空间、环境调度 → .cursor/skills/fight-video-create-skill/reference/scenes/
  • 动作导演规则、分镜方案、镜头协议 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/
  • 具体武学、兵器、招式、连招、身法 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/招式库/
  • 无法转成招式、但具备独立前置、发动、作用与终止机制的能力 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/技能库/
  • 完整剧情、案例脚本、战斗结构拆解 → .cursor/skills/fight-video-create-skill/reference/example-scripts/

一个文件有多个用途时,优先拆成职责单一的资料;无法无损拆分时询问用户。不得仅因主题相近就覆盖现有文件。

完成识别与分类后,必须先向用户输出确认清单,至少包含:每个文件的拟入库位置、主要用途、可复用内容摘要、重复或冲突风险,以及需要拆分或用户决定的事项。明确写出“以上识别结果和入库用途待确认”;在用户确认、修正或补充前,不得读取目标目录路由元、相近资料或必要索引,也不得执行去重、整合或写入。

2. 去重与整合

用户确认用途后:

  1. 先读取目标目录路由元、相近资料和必要索引。
  2. 若内容可能属于招式或技能,必须先按招式库入库条件判断:能转成具体武学、兵器技法、身体路径、接触结果或连续动作链的内容进入招式库;只有无法满足这些条件、但具备独立“前置 → 发动 → 作用 → 终止”机制的内容才进入技能库。
  3. 将新信息分为:新增事实、已有重复、与现有规则冲突、低可信或不可执行内容。
  4. 招式库与技能库互斥:招式库已有或可收录的机制不得在技能库重复建档;已存在技能后来能被完整转换为招式时,迁移到招式库并删除技能侧重复内容。
  5. 重复内容不重复入库;新内容合并到职责最接近的文件,独立主题才新建文件。
  6. 保留来源说明和用户提供的关键语义;不要把推断伪装成原资料事实。
  7. 冲突时保留用户明确指示;未明确时并列记录适用条件,不静默覆盖。

3. 更新路由元

任何新增、删除、改名、拆分、合并或定位变化都同步维护目标目录的 00-路由元.json:

  • meta.inventory_count、meta.last_verified;
  • routes、inventory;
  • 自然、可检索且区分度高的关键词;
  • 场景的 retrieval_hint,动作方案的 plot_signatures/avoid_when/conflict_resolution,案例的 script_types/scene_signatures,招式的 technique_signatures/avoid_when,技能的 range_keywords/secondary_keywords/condition_prompt/condition_options/ability_signatures/move_library_exclusions/avoid_when。

关键词必须来自用户可能输入的自然表达。宽泛词不能单独造成误路由。新增目标至少有一个关键词,且文件必须真实存在。技能库是唯一例外:range_keywords 只能是“单体”或“群体”,并允许宽松召回;secondary_keywords 及其他条件字段绝不参与检索。

4. 动作方案的特殊同步

只要吸收内容涉及 .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/ 或会改变动作、剧情、分镜的通用规则:

  1. 更新对应专项方案或新增方案;
  2. 同步更新 .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/互补融合大杂烩版本.md;
  3. 只把可跨题材复用、与现有系统互补的规则提炼进综合版,不粘贴整份原文;
  4. 保持综合版“稳定连续、动作因果、空间路线、武学选招、镜头接力、视觉反馈、质量门禁”的职责结构;
  5. 若改动 frontmatter 中的内容定位,按项目规则递增 version。

招式资料变更还要同步 招式库/00-招式库索引.md;技能资料变更还要同步 技能库/00-技能库索引.md,并重新检查与招式库的互斥关系。若分类文件仍声明来自 武打skill.md,必须同步源文件或明确改写来源,禁止索引与实际来源失真。

5. 验证与汇报

  1. 运行路由校验器,修复全部错误后再交付。
  2. 用每个新增路由的 1 个强关键词执行检索烟测,确认可命中正确目标。
  3. 汇报:吸收了什么、存放位置、去掉了哪些重复、如何处理冲突、更新了哪些路由、综合版更新点、校验结果。

禁止事项

  • 生成、改写或适配任何模型或平台的提示词。
  • 将提示词包装、模型/平台语法、生成参数、负面词、字幕/声音指令或成片提示语写入资料库。
  • 零关键词命中却声称“匹配到资料”。
  • 为了利用资料而更改用户指定角色、武器、动作顺序或胜负。
  • 未经确认混合多个动作方案的默认协议。
  • 只列招式名,不写身体路径、接触、反馈与后续条件。
  • 把示例剧本仿写成换名字的复制品,或不告知用户使用了案例参考。
  • 入库后不更新路由元、库存数量、索引或综合版。
  • 将招式库已有或可收录的内容重复写入技能库,或跳过招式库优先判断。
  • 用特殊法器、身体部位、介质或状态等二级条件匹配技能;选中技能后不提示条件就直接采用。
  • 引用不存在的资料文件,或根据文件名伪造缺失内容。