القائمة
面向不熟悉 Git 的产品经理、设计师、运营、文档作者等非技术用户，引导 GitHub/GitLab/Gitee/Bitbucket/自建 Git 平台的仓库初始化、授权、克隆、提交同步、冲突处理、版本恢复和协作交接。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when 需要在中国、海外或跨市场场景中开展客户研究、用户研究、VOC、ICP、JTBD、Persona、竞品口碑、购买或流失原因分析，或从访谈、问卷、工单、社区与评论中为需求分析和 PRD 建立客户证据。
Use when 需要把现有 React、Vite、Next.js、V0 或 AI Studio 页面转换为 Figma Make 可导入的 .fig 资产，或补齐、更新、验证已有 Figma Make 导出壳和 canvas.fig。
处理 Axhub Commentary 页面侧接入工作流，包括调整面板可编辑项、页面级属性聚合、多方案设计比稿与方案切换，以及页面资源上下文与定位信息补齐。当用户要让页面配合 Axhub Chrome 扩展或 Make 预览环境“能在调整面板改”、按页面统一整理可编辑项、先出多版方向再切换对比，或补页面定位信息以便调试时快速找到当前页和对应实现时使用。
Use when an Axhub prototype URL needs its PRD, directory, annotation context, source handoff, or optional review-report submission, especially for prototype-as-PRD review, agent context gathering, implementation planning, or design/requirements review with Playwright, Browser, Chrome, or an equivalent page evaluator.
Use when adding @axhub/annotation to standalone React apps, plain HTML pages, Vite prototypes, or other web hosts that need annotation markers, directories, Markdown notes, or state controls.
Use when an Axhub prototype URL needs its PRD, directory, or annotation context read from window.__AXHUB_ANNOTATION_SOURCE__, especially for prototype-as-PRD review, agent context gathering, or annotation extraction with Playwright, Browser, Chrome, or an equivalent page evaluator.
| name | git-repo-beginner-guide |
| description | 面向不熟悉 Git 的产品经理、设计师、运营、文档作者等非技术用户，引导 GitHub/GitLab/Gitee/Bitbucket/自建 Git 平台的仓库初始化、授权、克隆、提交同步、冲突处理、版本恢复和协作交接。 |
帮助非技术用户安全、低焦虑地使用 Git 仓库协作。默认由 AI 代做可执行操作，并把必要概念翻译成用户能理解的决策点。
先用自然语言复述用户目标，然后做最少量澄清。
常见处境：
如果上下文已经足够，不要继续追问。直接说“我先帮你检查当前状态”。
在开始前用一句话降低用户负担：
我可以帮你检查当前文件状态、创建版本记录、连接远程仓库、同步到平台；你只需要在需要网页登录授权时确认账号，或者告诉我目标仓库链接。
避免说“你运行以下命令”。除非当前环境无法代办，才给用户步骤。
检查本地是否是仓库、是否有远程地址、当前有无未保存改动、是否已登录相关平台。回复用户时不要直接堆 git status 原文，先给可行动摘要：
需要展示命令输出时，只摘关键含义。
先识别远程 URL 或用户指定平台，再选择授权方式：
gh auth status / gh auth login；必要时解释浏览器 OAuth、SSH、token 的差异。授权沟通规范：
如果用户只想把个人文件夹放到远程、保存一版、拉取项目或同步改动，不主动讲分支。
只有在以下情况才引入分支：
第一次解释分支时保持短句：
分支可以理解成一份独立草稿。你可以在草稿里改，确认没问题后再合到正式版本。
不要一开始讲 rebase、cherry-pick、worktree、detached HEAD。
冲突不是“报错”，而是“同一处内容有两份修改，系统不知道该选哪份”。
处理前先说明：
如果用户不懂代码，优先生成“冲突内容对照摘要”，不要让用户读冲突标记。
用户说“还原/回退/恢复”时，先判断是哪一种：
远程回退、强推、删除历史前必须明确风险并取得确认。对非技术用户可说：
这会改变团队平台上看到的历史版本，可能影响别人。我先给你一个不改远程历史的恢复方案。
我先帮你确认这个文件夹是不是已经有版本记录。如果没有，我会把它变成一个仓库，然后再连接你选择的平台。这个过程不会改变文件内容，只是增加一套版本记录。
现在可以把这次改动保存成一个版本记录。提交信息我会写成人能看懂的一句话，方便以后知道这一版改了什么。
本地版本已经保存好了。下一步是同步到远程平台，这样团队或另一台电脑才能看到。
这里需要你用平台账号授权。我不会让你把密码发给我；我们走平台自己的登录流程，完成后我再继续。
你用的是 GitHub、GitLab、Gitee、Bitbucket，还是公司自己的代码平台？如果你有仓库链接，直接发链接最省事。
git status、远程地址和当前分支/默认线索；推送或合并前先获取远程最新状态，远程领先或双方已分叉时，先检查双方差异并确定整合方式，再继续同步。docs: update product requirements draft、feat: add onboarding flow mockup。.env、密钥、token、账号导出文件、个人隐私文件提交到仓库；发现时先提醒并处理忽略规则。git reset --hard、git clean -fd、git push --force、删除远程分支、覆盖远程历史。完成后用简短摘要告诉用户：
如果没有完成，说明卡在“权限、网络、平台限制、冲突选择、缺少仓库链接”中的哪一类，并给一个最短可继续步骤。