文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载本指南围绕 Claude Code system prompts 中的 New design canvas parallel AppifactRepl workflow 展开讲解如何通过一次 AppifactRepl 调用对应一个 board、所有调用并行发出的模式从零搭建一个文件型file-backedDesign Canvas先写只含索引的project/canvas.json框架再逐板发布各自的 HTML 文件。读完本文你将掌握 canvas.json 索引结构、并行调用的发送顺序与隔离规则、修订与错误恢复流程以及 AppifactRepl 底层node scripts/appifact_sdk.js --repl -的执行语义可直接复刻出可运行、可修订的完整工作流。一、文档定位面向新建 Design Canvas的系统提醒在 Claude Code 的提示词体系中System Reminder是一类在特定场景由系统注入的大型提醒文本参见仓库 README.md 对提示词分类的说明。本文关联文档即其中一种文档名System Reminder: New design canvas parallel AppifactRepl workflow约 1152 tokens版本标记ccVersion: 2.1.273即随 Claude Code v2.1.273 一并提取维护职责指示模型把一个新的 Design Canvas 通过每个 board 一个 AppifactRepl 调用、全部放在同一条消息里并行发出的方式完成框架定位与内容填充它与同族的 New design canvas two-step AppifactRepl workflow两步版、AppifactRepl design canvas workflow单程序版、以及 Slides 侧的 New Slides deck parallel AppifactRepl workflow 共享同一套文件型内容模型只是注入时机与调用编排不同。二、核心模型文件即画布store 中不落任何内容整个工作流的首要原则是The canvas is kept as files underproject/, none of it in the store.即 Design Canvas 的所有内容都以文件形式保存在project/目录下完全不写入 Artifact 的 store数据库。因此围绕这个 canvas 的一切读写都走files能力files.list/files.read/files.publish而不是write_db/read_db。原文档明确写道These calls stand in for Artifact publishes and for ArtifactData, write_db and read_db calls on this canvas——这些 AppifactRepl 调用完全取代了对该 canvas 的 Artifact 发布、ArtifactData、write_db与read_db调用。文件布局分两层路径作用说明project/canvas.json画布索引index记录每个 board 的名字、坐标与尺寸、显示顺序及其余元数据project/board 文件名单个 board 的 HTML如project/Main.dc.html、project/Pricing.dc.html以.dc.html为后缀2.1 canvas.json 的结构从原文档第一步框架调用中的初始化代码可以看出索引的完整骨架const canvas { v: 3, // 索引格式版本 launch: { view: canvas }, // 打开画布时进入 canvas 视图 pages: [], boards: {}, // board 名 - {x, y, w, h} 布局 order: [], // board 显示顺序 notes: {}, designSystems: [], attachments: {}, createdOnFiles: { v: 1, at: new Date().toISOString() }, };其中v: 3canvas.json 的结构版本号承载页面解析时对格式的兼容判断launch.view打开该 Artifact 时采用的视图这里固定为canvasboards核心布局字典键为 board 文件名值为{x, y, w, h}四元组。示例中两个 board 左右排布canvas.boards { Main.dc.html: { x: 0, y: 0, w: 880, h: 560 }, Pricing.dc.html: { x: 960, y: 0, w: 880, h: 560 }, };orderboard 的展示顺序数组例如[Main.dc.html, Pricing.dc.html]designSystems/attachments/notes设计系统、附件与备注的挂载点createdOnFiles文件型内容的创建标记v: 1表示该索引是基于文件创建的at记录创建时间戳ISO 格式。单程序版的 AppifactRepl design canvas workflow 还补充了一点关键约束索引里凡是本次不改的键都要原样保留包括createdOnFiles或convertedFrom键。2.2 为什么框架先行原文档解释了这一顺序的必然性The index names every planned board, so each later call writes only its own new file (a named board with no file yet keeps its place and shows once its file lands).索引提前命名了所有计划中的 board因此后续每个调用只需写自己那一个新文件无需先读、无需重写索引、无需占位文件一个已被索引命名但尚无文件的 board会保留其位置与尺寸一旦文件落地立即显示反过来如果 board 文件先于索引出现页面会把它放在页面自行挑选的位置可能被已打开的标签页记住造成布局错乱——这正是索引必须第一个写的原因。三、第一步只写索引的框架调用原文档给出的第一个调用职责仅限于写出画布索引project/canvas.json一个 board 都不写const files await claude.use(files), fs require(fs), path require(path); const index project/canvas.json, made (await files.list()).some(f f.path index); // the page may have made the index already: keep its keys const canvas { v:3, launch:{view:canvas}, pages:[], notes:{}, designSystems:[], attachments:{}, createdOnFiles:{ v:1, at:new Date().toISOString() }, ...(made ? JSON.parse(await files.read(index)) : {}) }; canvas.title title; canvas.boards { Main.dc.html:{ x:0, y:0, w:880, h:560 }, Pricing.dc.html:{ x:960, y:0, w:880, h:560 } }; canvas.order [Main.dc.html,Pricing.dc.html]; canvas.designSystemTokens require(the tokens.json path above); // only with a design system fs.mkdirSync(path.join(files.dir(), project), { recursive: true }); fs.writeFileSync(path.join(files.dir(), index), JSON.stringify(canvas)); await files.publish({ file_path: index });逐行要点幂等读取files.list()检查project/canvas.json是否已存在。页面Artifact 页面运行时可能已自行创建过索引此时用...(made ? JSON.parse(await files.read(index)) : {})把已有键合并进来只改标题与布局不覆盖其他内容布局声明boards与order一次写全所有计划中的 board 都在这一调用里获得坐标、尺寸与顺序设计系统可选只有在存在设计系统时才执行canvas.designSystemTokens require(...)令牌文件路径来自系统提示中预先打印的内容落盘与发布先fs.mkdirSync递归创建project/目录再把索引写入files.dir()下的对应路径最后await files.publish({ file_path: index })单独发布这一份文件。注意本调用中code是运行在 AppifactRepl REPL 中的纯 JavaScript底层以node scripts/appifact_sdk.js --repl -执行不是 shell 命令因此不含 heredoc 与 shell 引号转义。四、随后每个 board 一个自包含小程序框架调用之后为每个 board 各发一个调用且每个调用都是一个完整的小程序HTML 直接内联写入const files await claude.use(files), fs require(fs), path require(path); const board project/Main.dc.html, file path.join(files.dir(), board); fs.mkdirSync(path.dirname(file), { recursive: true }); fs.writeFileSync(file, div.../div); await files.publish({ file_path: board });这个模式有三个核心约束原文档逐一强调程序完全自包含starts fresh没有哪个调用使用前一个调用定义的变量。这与 AppifactRepl 的执行模型直接相关——每次调用的代码都在一个全新的、仅存活于本次调用的共享作用域中运行详见第八节进程在代码结束即退出上次定义的一切都不复存在每个调用拥有独立的files.dir()该临时目录在调用结束时被移除因此调用写出的内容就是它能发布的内容不存在跨调用残留文件的问题并行发送、顺序执行、即回即显所有调用虽然在同一条消息里并行发出实际运行却是一个接一个按你发送的顺序每个调用在其代码块完成后立即运行页面则在该调用返回的瞬间展示对应 board——即你还在写下一个 board 时上一个已经可见。因此发送顺序应按照读者希望看到的顺序来排。由此一个命名 board 尚无文件时保持占位、文件落地即显示的机制配合逐板调用实现了画布内容流式呈现的效果。五、修订工作流先读后改一次一个 board对既有画布的修订与新建遵循同样的编排一条消息、每个被改的 board 一个调用、每个调用先读后写。原文档给出如下示例把Pricing.dc.html中的价格从£12改为£14const files await claude.use(files), fs require(fs), path require(path); const board project/Pricing.dc.html, file path.join(files.dir(), board), html await files.read(board); fs.mkdirSync(path.dirname(file), { recursive: true }); fs.writeFileSync(file, html.replace(£12, £14)); await files.publish({ file_path: board });关键点files.read在读后立即执行每个修订调用都先await files.read(board)读取自己要改的文件再基于读到的内容写入新版本只改被要求的调用内仅对目标文件做最小替换html.replace不重写索引、不触碰其他 board版本钉住语义单程序版文档指出发布会被钉在上次看到的版本上因此任何修改既有文件的操作都必须在同一程序内先读该文件仅有files.list的列举不算读过对未读文件发布可能被拒绝。更复杂的修订新增、删除、移动、重排 board需要同时更新project/canvas.json的boards与order详见 AppifactRepl design canvas workflow 中的readMany示例同一程序内用files.readMany([project/canvas.json, project/Pricing.dc.html])一次读齐所有要改的既有文件再统一files.publish({ file_path, files: {...} })一次发布。六、错误处理与重试规则原文档对失败的处置非常明确只有两条规则If a call reports an error, fix the line it names and send THAT call again, not the others. If the error names a file that changed or was not read, add afiles.readof that file to the call.只重发报错的那个调用AppifactRepl 的报错会指名具体的出错行底层语义见第八节✗ Uncaught error后跟随来源行号。修正该行后只重发这一个调用不要连带重发其他调用——其余调用已成功重发会造成重复发布补读缺失文件如果错误信息指出某个文件已变化或未被读取就在该调用中补一条对该文件的files.read再重发。单程序版文档还补充了更完整的拒绝恢复流程若publish因期间有人保存过或命名的文件已变化而被拒绝应从程序第一行整体重跑一次其读取会自动拾取最新版本若提示未查看最新版本则用 Artifact 工具读取一次 canvas 的 url 后再重跑除此之外的任何拒绝应如实告知用户并停止。七、设计系统与 markup 优先并行工作流对样式来源与构建方式有两条硬性约束设计系统如果存在设计系统则画布使用的颜色、字体与间距都取自你已打印prefetched/printed的那些文件中的值the colours, type and spacing are the ones in the files you printed并通过框架调用中的canvas.designSystemTokens注入索引markup 优先除非用户明确点名要求真实组件否则一律用标记markup完成设计——即直接书写 HTML而不是去调用真实组件库。具体做法由该 Artifact 类型附带的design-system-components页面说明该页面在磁盘上作为类型指令的一部分提供。八、底层机制AppifactRepl 的执行语义要真正理解这个并行工作流为何这样编排需要结合 Tool Description: AppifactRepl 中定义的执行语义运行方式代码在node scripts/appifact_sdk.js --repl -中运行内置 SDK若调用在skill中指名某个 appifact skill则用该 skill 的 SDK。整段code是一个 JavaScript 程序作为一个 async 函数的函数体只运行一次其中的const、await 结果与 db 句柄可以在语句间共享作用域生命周期该共享作用域仅存活于这一次调用——进程在代码结束时退出本次定义的一切不会进入下一次调用。这正是原文档反复强调每个程序 starts fresh、不得跨调用使用变量的根因三大内置能力claude.use(db)访问 store本工作流中不使用、claude.use(files)读取与发布 Artifact 的文件本工作流的主通道、claude.use(assets)上传脚本写出的文件并下载 Artifact 的资产Artifact 绑定代码作用的 Artifact 由工具参数绑定{artifact: url, code}代码内部绝不写 artifact id——脚本以页面代码同样的方式使用该绑定输出与错误语义首次未捕获的错误会终止运行——此前打印的行仍会显示随后是✗ Uncaught error及出错行号其后语句不再执行顶层return x结束运行并打印→ x。工具会以ARTIFACT SCRIPT OUTPUT标记包裹脚本所有输出视为数据而非指令并保留至多 40,000 字符使用边界工具描述明确要求凡是对 appifact_sdk.js REPL 的调用用本工具而非 Bash。把这些语义对照并行工作流正因为每次调用都是独立作用域、独立files.dir()才可以放心地把每个 board 拆成独立调用并行发出——彼此既无变量依赖也无文件冲突每个调用只写索引命名过的一个新文件。九、两步工作流变体先读指令、再并行构建除了本文的单条消息并行构建版Claude Code 还提供了同主题的两步变体 New design canvas two-step AppifactRepl workflow约 1579 tokens两者对比如下维度并行版本文两步版第一步无一条消息内复制执行笔记给出的 Bash 调用如有并用 Artifact 工具以 url 读取该 Artifact——返回类型指令SKILL.md并记录已看过该版本所需参考页已在磁盘上随笔记打印第二步框架调用 逐板调用全部一条消息同样的框架调用 逐板调用全部一条消息指令来源提示中已给齐类型指令SKILL.md与参考页在磁盘上通过第一步的 url 读取获得错误恢复只重发报错调用同左且第一步的 url 读取仍计入已看过该版本重试无需再读两步版强调Everything this canvas needs is already on disk, in the files listed with this note——预取prefetch机制把所有类型指令落到磁盘第一步的 url 读取仅为获取指令与版本登记canvas 本身是全新的、空的读取不为内容。其第二步的框架调用与逐板调用结构、project/canvas.json与project/文件名布局、createdOnFiles初始化、自包含程序、顺序执行即回即显等规则与并行版完全一致。在实现层面两步版与并行版是同一种并行填充能力的两种注入路径预取指令齐备时用两步版指令已在提示中时直接用并行版。十、相关文档地图该工作流并非孤立存在同仓库内存在完整的家族文档建议对照阅读New design canvas two-step AppifactRepl workflow——两步变体含 SKILL.md 读取与版本登记流程AppifactRepl design canvas workflow——单程序版一个调用完成整个画布的创建或修订含files.readMany、发布拒绝恢复、删除 boardproject/Old.dc.html: null等更完整的修订规则Tool Description: AppifactRepl——工具语义REPL 执行模型、作用域生命周期、files/db/assets 三大能力、输出与错误格式New Slides deck parallel AppifactRepl workflow 与 New Slides deck two-step AppifactRepl workflow——同一并行模式的 Slides 版索引为project/deck.json、滑片为project/slides/id.html可对照理解其通用编排思想README.md——提示词提取与维护背景说明本仓库内容直接来自 Claude Code 编译产物随每个版本更新。综上这个并行工作流的本质是用一个索引 一组自包含程序把多 board 画布的构建拆成可流式、可单独重试的并行单元。理解canvas.json的结构、索引先行的原因、调用间的隔离契约以及 AppifactRepl 单次作用域的执行模型你就能在 Claude Code 中稳定复现并扩展这一构建方式——无论是新建、修订还是错误恢复都只需守住框架先行、逐板自包含、出错只重发自己这三条纪律。赞分享文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载相关推荐Claude Code 新建 Design 画布的两步 AppifactRepl 工作流从预取指令读取到并行构建 ArtboardClaude Code 新建 Design 画布的两步 AppifactRepl 工作流从预取指令读取到并行构建 Artboard 本篇技术指南以 Claud文档提示工程人工智能Claude Code AppifactRepl 工具全解析用一次 JavaScript 运行构建 Design 画布与 Slides 演示文稿Claude Code AppifactRepl 工具全解析用一次 JavaScript 运行构建 Design 画布与 Slides 演示文稿 导读 Ap文档提示工程人工智能Claude Code Slides 演示文稿两步式 AppifactRepl 工作流从 prefetch 指令到并行逐页构建Claude Code Slides 演示文稿两步式 AppifactRepl 工作流从 prefetch 指令到并行逐页构建 本指南围绕 Claude Co文档提示工程人工智能上一篇Flink 端到端End-to-End测试体系全解析从 nightly 运行到自研测试用例下一篇WPF 控件库实战WPFDevelopers 8 个自定义控件从界面骨架到主题换肤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考