Guidewright Capture 的目标是为 Web 应用产出逐步操作文档页面，其中每一步都配有一张带红色边框的截图，红框精确圈出用户需要点击的元素。红框是渲染进实时页面的 DOM 覆盖层，而不是事后画在图片上的，因此它会随截图缩放并准确落在目标元素上，无需猜测像素坐标。该技能与产品无关，可以对任意应用进行文档化，并写入你维护的文档站点，默认假设使用 Docusaurus 风格的文档仓库，路径与约定可按自身环境调整。
三条覆盖一切的原则。第一，记录真实用户实际走的路径。功能通常有多种进入方式（工具栏按钮、右键菜单、键盘快捷键、设置深链），应选择最相关、最易被发现的路径，即典型用户首先会用的那一条，而不是自动化中最容易点击的元素；若发现更短或更明显的路径应切换过去；当两条路径都很常见时，记录主要路径并在提示中提及替代方案。第二，为从未见过该界面的人写作。读者可能对产品和同类软件完全陌生，因此文档需适用于任何熟练程度：用可见标签称呼按钮，说明其位置，逐步写清每次点击，不假设读者懂术语；短句、平实用词、每步一个动作，入门级清晰度是默认要求。第三，坚持一种 Diátaxis 类型——你写的是 how-to。该技能产出的是操作指南：一份让读者按步骤完成一个真实任务的配方，不讲授理论，也不穷尽罗列选项。最常见的文档腐坏方式是混合类型：解释混入步骤，或试图记录每个字段。应保持步骤纯粹，把原因、背景和概念放入简短的 :::note / :::tip 或链接的解释页，把详尽的选项列表放入参考页。如果被要求文档化的内容没有可操作的具体 UI 任务（属于概念性内容），它就不是截图型 how-to，应说明并建议改用解释页。
该技能会替你决定记什么、怎么记。给定一个功能、一个 PR 或一段代码差异，先识别流程：阅读 diff / 变更文件，判断哪个 UI 功能是新增或变更的，并转换为面向用户的点击路径（用户触碰的页面、按钮和对话框序列）。然后判断是新建页面还是刷新：在文档内容目录中搜索是否已有覆盖该流程的页面。若已存在则阅读它——它已包含规范步骤序列和文字，重新对照当前 UI 走一遍同样步骤并刷新截图，仅在 UI 真正变化处修改文字；若不存在则在正确分区按约定和相邻页面的步骤结构撰写新页面。接着行走并捕获：驱动实时 UI，为每一步在点击目标上带红框截图。最后将页面写入文档仓库，使其可提交或发起 PR。若对哪个流程或分区存疑，向用户提一个问题，不要跨多个可能功能猜测。
红框机制是本技能准确性的关键。它可通过 Chrome DevTools MCP 或 Playwright MCP 工作，两者方式相同：对页面做快照，driver 会把快照中的确切元素作为实时元素句柄传回注入的函数（Chrome DevTools 在 evaluate_script 的 args 中传 uid；Playwright 在 browser_evaluate 的 target 中传 ref）。你通过注入 DOM 覆盖层为该元素加框，从而保证是正确的元素。在 Playwright 上必须通过 DOM 注入加框，绝不能从坐标绘制——Playwright 红框“总是不准”的原因是依据边界框（browser_snapshot 的框、highlight 辅助）的坐标在页面滚动后发生偏移；通过 browser_evaluate 注入覆盖层则依据元素自身的实时矩形定位，因此与 Chrome DevTools 一样准确。同时应截取页面（不带目标）——元素目标截图会把覆盖层裁掉。每一步遵循同样的五个动作：快照并找到该步点击的元素；对该元素求值，先 scrollIntoView({block:'center'}) 再注入与 getBoundingClientRect() 同尺寸的 fixed 定位红框覆盖层；把视口（绝不用 fullPage，固定覆盖层在长页面上会错位）截图保存到文档图片目录；再次求值移除覆盖层，避免渗入下一张截图；点击同一元素推进流程。红框是浏览器渲染进页面的真实 DOM 元素，因此落点精准并随截图缩放，两种 driver 结果一致。该机制已在 Playwright MCP 上端到端实测，并在长页面滚动元素、设备像素比 1 和 2 下压力测试为 0 像素偏差。两种 driver 都必须遵守的一条规则是：截视口，绝不 fullPage。
输出约定需匹配现有文档站点。写之前先读目标分区中的相邻页面并匹配其风格。以下约定假设 Docusaurus，其他生成器可调整，但不管什么技术栈都重要的部分包括：页面文件，每个任务一个页面，例如 <docs-repo>/docs/<Section>/How to <Thing>.md，使用你站点所用的 frontmatter，典型 Docusaurus 头部包含 title、sidebar_position、description（一句话、利于 SEO）与 keywords。截图保存到站点的静态图片文件夹，每个页面一个文件夹（例如 <docs-repo>/static/img/<doc_slug>/<name>.png），引用时使用站点期望的路径，并配以说明高亮内容的描述性 alt 文本。步骤使用 ## Step N: <祈使句标题>，带编号的子指令，截图紧接其所说明的指令之后。提示与注意事项使用生成器的标注（Docusaurus 为 :::tip / :::note / :::caution）。文字应简洁并使用第二人称“你”，其余遵循项目内部风格指南。
开始写入前应先建立隔离的 git worktree。该技能会写入文档仓库——新增或编辑一个 .md 页面以及一个 PNG 文件夹——而你可能与其他做同样工作的 agent 并行运行。若两人在同一检出中撰写或刷新文档，会互相覆盖文件、分支和图片文件夹。共享的主检出很可能是另一个 agent 的活动工作区，应视为不可触碰，并为自己新建一个。应在独立的 git worktree 中工作：若 superpowers:using-git-worktrees 技能可用（检查技能列表）就用它，它会为你设置隔离工作区；若未安装，值得向用户推荐（这是最干净的路径），但并非必需：一条普通的 git worktree add ../<repo>-wt-<slug> <base-branch> 即可提供同样隔离。这是文件系统层面的事，与下面的浏览器层面分开。worktree 防止并行写文件冲突，但对共享浏览器配置没有作用——那里的规则仍是同一时间只用一个 driver。
安全运行实时 UI 的注意事项（驱动浏览器前阅读）。该技能需要浏览器驱动 MCP——Chrome DevTools MCP 或 Playwright MCP，它是快照、注入红框覆盖层和截取截图的手段。开始行走前需确认其中之一确实可用：Chrome DevTools MCP 的工具以 mcp__...chrome-devtools__* 命名（take_snapshot、evaluate_script、take_screenshot、click）；Playwright MCP 的工具以 mcp__...playwright__* 命名（browser_snapshot、browser_evaluate、browser_take_screenshot、browser_click）。两者都可用时，让运行该技能的人选择——询问使用哪个 driver，或遵从已指定的那个，他们可能有可用环境或偏好，且红框方法在两者下完全相同，这是他们而非你硬编码的决定。只有其一可用时直接使用。若两者都没有，应停止并强烈建议用户安装/启用其一（chrome-devtools-mcp 或 Playwright MCP 服务器），而不是伪造截图或手工画框——该技能的全部价值在于准确真实的截图，只有通过这些 MCP 才能实现，没有则不要继续。
浏览器配置也可能与其他 agent 共享，开发栈可能对资源敏感，应遵守：在启动应用/开发栈并驱动 UI 前与用户确认；为行走启动，结束后拆除，不要投机性启动。不要杀死或争抢共享浏览器，复用已打开的页面，不要重新启动配置；若已被其他 agent 使用（例如 Playwright 报告“Browser is already in use”），应等待或协调，不要强占。不要自动生成一群各自驱动浏览器的 agent——针对一个共享配置同一时间只用一个 driver。登录凭据和环境 URL 向用户索取，绝不要读取 .env 或其他密钥文件来获取。
工作流清单：确认浏览器驱动 MCP（Chrome DevTools 或 Playwright）可用，若不可用则停止并建议用户启用；为文档仓库建立隔离 git worktree，避免与其他 agent 的文件冲突；根据 PR/diff/功能确定流程，决定新建页面还是刷新（搜索文档内容目录）；若刷新，阅读现有页面以获取规范步骤；与用户确认后，确保应用和浏览器 MCP 已启动并登录；每一步执行：快照 → 找到元素 → 高亮（覆盖层）→ 视口截图到页面图片文件夹 → 移除覆盖层 → 点击推进；撰写/更新 .md 页面，包含 frontmatter、## Step N 章节和符合上述约定的图片引用；告知用户写了什么，并提醒其拆除技术栈。