【免费下载链接】SkillsAgent skills for designers and builders using Codex, Claude, Cursor, and other AI coding agents项目地址https://gitcode.com/gh_mirrors/skills48/Skills点击查看免费下载导读本文围绕 Skills 仓库面向 Codex、Claude、Cursor 等 AI 编码 Agent 的 Agent skills 集合中的publish-project-to-github技能完整讲解如何把一个已完成的本机 HTML/CSS/JavaScript 实验或小型 Web 项目打包成意图明确的 Git 仓库、创建公开或私有的 GitHub 仓库、编写有说服力的 README 与真实预览图、安全推送、为兼容项目配置 GitHub Pages 公开站点并在推送与部署之后回读验证外部状态。读完本文你将掌握一套可复用的发布前审计 → 本地验证 → 安全推送 → Pages 配置 → 外部状态回读的发布管线并理解其底层审计脚本与 Pages 参考文档的实现细节。该技能在仓库中的位置为 agent-skills/codex/publish-project-to-github/SKILL.md配套资源包括 审计脚本、GitHub Pages 参考文档、README 模板 以及 Agent 接口定义。技能定位与核心原则publish-project-to-github的触发场景非常明确当用户提出上传、发布、开源、分享或把一个本地 HTML/CSS/JavaScript 实验转成带在线演示的 GitHub 仓库时Agent 应加载并使用本技能。其description字段明确定义了使用边界——面向已完成的本地小项目输出物是带文档与实时演示的 GitHub 仓库。本技能最核心的设计理念是一条总纲把仓库创建、公开可见性和部署当作三扇相互独立的门一次成功的git push并不能证明公开站点可用。也就是说推送成功、Pages 已配置、Pages 构建成功、线上站点已核验是四个层次不同的状态任何一步都不能被上一步的结果替代。技能要求 Agent 在交付时明确区分这四种状态绝不把它们折叠成一个笼统的发布成功。另一个贯穿全文的准则是最小权限创建公开仓库必须得到用户明确授权用户明确提出公开分享、公开 URL、开源或等价表述未获明确授权时默认使用--private严禁 force-push、覆盖既有远程、擅自更改仓库可见性或替换已有 Pages 配置。第 1 步确定范围与权限发布前不要急于写代码先检查本地项目、仓库状态、远程与本地指令确认或谨慎推断以下事项确切的项目目录与预期纳入的文件清单仓库名称Repository与所有者Owner目标是公开还是私有是更新既有仓库还是新建仓库用户想要的是在线网站、仅源码托管还是两者都要。技能同时给出两条不可逾越的红线只有用户明确要求公开分享、公开 URL 或开源时才允许创建公开仓库否则在创建前必须先询问可见性偏好未经确切授权绝不 force-push、绝不覆盖既有远程、绝不更改仓库可见性、绝不替换已有 Pages 配置。第 2 步发布前审计Audit运行捆绑审计脚本在项目根目录运行仓库捆绑的审计脚本命令为bash agent-skills/codex/publish-project-to-github/scripts/audit_public_project.sh .注意原文档使用/path/to/publish-project-to-github/scripts/audit_public_project.sh作为占位路径在 Skills 仓库中该脚本的实际相对路径为 scripts/audit_public_project.sh。脚本接受一个可选参数作为项目目录默认为.因此从项目根目录运行时传.即可。技能强调脚本是辅助而非替代判断。运行后必须人工检查其输出而不是把脚本退出码当作唯一依据。审计脚本的源码级实现阅读 audit_public_project.sh 的源码可以发现它是一段set -euo pipefail的严格 Bash 脚本依赖ripgreprg完成文件扫描整个审计分五个维度1. 入口点识别。若根目录存在index.html判定入口点为静态首页若存在package.json判定为框架构建项目并提示验证构建产物与宿主兼容性两者都不存在时输出 WARNING。2. 敏感文件扫描。脚本用 ripgrep 枚举全部隐藏文件排除.git匹配以下模式即为 ERROR(^|/)(\.env($|\.)|\.npmrc$|\.pypirc$|id_(rsa|dsa|ecdsa|ed25519)$|.*\.(pem|p12|pfx|key)$)即.env系列、.npmrc、.pypirc、SSH 私钥id_rsa、id_dsa、id_ecdsa、id_ed25519以及.pem、.p12、.pfx、.key证书密钥文件命中即要求移除或明确审查。3. 凭据内容扫描。对文件内容做正则匹配排除.git、*.lock、package-lock.json、pnpm-lock.yaml、yarn.lock等锁文件(sk-[A-Za-z0-9_-]{20,}|gh[pousr]_[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN (RSA |OPENSSH |EC |DSA )?PRIVATE KEY-----)该模式覆盖 OpenAI 风格sk-密钥、GitHub 个人访问令牌ghp_/gho_/ghu_/ghs_/ghr_前缀、AWSAKIA访问密钥 ID 以及 PEM 私钥块任何命中都会使审计计为 ERROR。4. 个人路径扫描。匹配绝对用户路径/Users/...、/home/...、WindowsC:\Users\...命中输出 WARNING 要求审查。5. Git 状态检查。若目录已在 Git 工作树内进一步检查项目是否嵌套在更大的仓库根目录中此时提示 WARNING、列出git status --short、读取origin远程 URL未初始化则提示 Git state: not initialized。脚本末尾汇总Issues与Warnings计数Issues 0时输出RESULT: blocked并以退出码 1 终止发布否则输出RESULT: review warnings, then continue提示先人工复核警告项再继续。人工审查清单即便脚本通过技能仍要求人工把关以下发布阻断项API 密钥、令牌、私钥、密码或.env文件个人数据或私密客户信息运行期依赖的绝对本地文件系统路径未授权或无许可证的素材assets缺失的运行期文件对已存在仓库名的所有权不明确。此外需逐一审查所有外部运行时 URL 与生成素材并在 README 中如实声明项目所需的网络依赖。许可证检查发布前检查既有许可证。若用户明确希望他人复用或修改该项目且项目尚无许可证应询问用户选择哪种许可证而不是替用户发明一个若目标仅是公开浏览缺少许可证不阻断部署但必须在报告中说明复用权利未被显式授予。第 3 步选择打包模型技能针对三种典型场景给出不同的打包策略干净既有仓库Clean existing repository当既有 checkout 的远程、历史与被跟踪文件与目标公开项目一致时直接复用该 checkout只暂存stage请求的文件。混杂或不相关的 workspaceMixed or unrelated workspace当源工作区含有无关实验、删除、私有文件或历史时创建一个干净的项目目录或同级 checkout只拷贝预期的运行文件绝不为图方便把整个混杂文件夹一并发布。既有公开仓库Existing public repository改动前先检查其默认分支、Pages 来源、README、许可证与远程状态拉取或审慎协调分歧绝不用 force push 掩盖分歧。对于静态单文件实验技能给出了一个推荐的极简目录形态project-name/ ├── index.html ├── README.md ├── PROMPT.md # optional ├── assets/ # optional previews or runtime assets └── .gitignore第 4 步构建仓库展示README 与预览README 必须从真实项目出发编写而不是套模板。技能提供了 assets/README-template.md 作为起始结构而非最终成稿模板中所有占位符PROJECT_NAME、ONE_SENTENCE_DESCRIPTION、PUBLIC_URL、REPOSITORY_URL、PROJECT_PREVIEW.jpg等都必须基于项目证据逐一改写。一份合格的 README 应包含项目名称 一句具体描述体验的话顶部附近放在线演示链接在 GitHub 之外有用时再放仓库源码链接从实际运行项目截取的截图或短 GIF关键交互或特性对架构与非常规实现选择的简洁解释准确可运行的本地运行说明项目结构运行时依赖与网络要求当作品受参考启发时注明原创性、署名或非关联声明。针对 Agent 构建的项目可选用官方链接与可移植的构建/混搭 prompt展示如何用相关编码 Agent 重建或改造成该项目——但发布前必须核验官方 URL 仍有效。模板中## How it is made一节要求用两三个短段落讲清真实架构运行时、主要依赖、非常规实现选择、事实来源在哪里## Build or remix it一节在有用时链接可移植 prompt## Run locally一节必须给出确切的运行命令、所需版本、安装步骤、环境变量与网络依赖且绝不包含真实密钥## Design and attribution一节要求准确署名依赖、参考与素材若项目研究了某个可识别的产品或发行方应说明实现是原创且独立的而非暗示隶属关系。写作基调上技能明确要求避免空洞宣传词如 cutting-edge、stunning、production-ready优先用具体工艺与行为说话。第 5 步本地验证Verify locally启动真实运行时使用项目的真实运行时而非直接从磁盘打开基于模块的站点即不要用file://打开这无法证明 Pages 兼容性。对静态站点技能给出的命令是python3 -m http.server 4173 --bind 127.0.0.1验证清单启动后在浏览器中逐项检查初始渲染主要交互路径主要交互的返回、关闭或恢复路径常规桌面视口以及当项目为响应式时约390 × 844的窄视口README 中的每一条运行命令缺失文件与 404控制台错误与警告仓库子路径下的相对 URL例如/project-name/。使用的浏览器以用户要求或仓库指令为准README 预览图必须从该已验证的运行时截取。第 6 步提交并创建仓库前置检查GitHub CLI要求已安装 GitHub CLIgh并完成认证gh --version gh auth status名称可用性检查创建前先检查目标名称是否已被占用gh repo view OWNER/REPOSITORY初始化与提交只初始化并提交预期打包内容git init -b main git add -- README.md index.html .gitignore git diff --cached --check git commit -m Publish PROJECT_NAMEgit diff --cached --check用于检查暂存区是否存在空白错误。可选文件应显式追加到git add命令中而不是在混杂目录树里用git add -A取而代之。创建并推送审计与本地验证全部通过后才允许创建并推送gh repo create OWNER/REPOSITORY \ --public \ --source. \ --remoteorigin \ --push \ --description CONCRETE_DESCRIPTION要点未获公开授权时使用--private仓库已存在时应显式配置其远程并直接推送而不是重新创建--description必须填具体描述而不是空泛口号。第 7 步配置公开站点GitHub Pages按项目类型分类启用 Pages 前先对项目分类四类情况对应四种处理静态根目录Static root发布main分支与/目录静态 docs 目录Static docs folder发布main分支与/docs目录框架构建Framework build使用框架官方支持的 Pages 产物形态与当前官方 GitHub Actions 指南服务端、数据库或私有运行时GitHub Pages 不兼容——必须说明阻塞原因且只有获得用户授权才能改用其他托管方案。改动 Pages 设置之前先阅读 references/github-pages.md。配置完成后将仓库 homepage 设为最终公开 URL并添加一组小而准确的发现话题topics。Pages 参考文档的源码级细节github-pages.md 给出了直接用gh api操作 Pages 的完整命令序列。新建静态根部署project_repoOWNER/REPOSITORY project_branchmain gh api --method POST repos/${project_repo}/pages \ -f source[branch]${project_branch} \ -f source[path]/在将括号视为 glob 的 shell 中必须为source[...]参数加引号。部署到/docs仅当该目录包含完整可部署站点时gh api --method POST repos/${project_repo}/pages \ -f source[branch]${project_branch} \ -f source[path]/docsPages 已存在时先读取当前配置仅当用户授权更改来源时才使用 PUT 更新端点gh api repos/${project_repo}/pages gh api --method PUT repos/${project_repo}/pages \ -f source[branch]${project_branch} \ -f source[path]/仓库元数据Pages 接受配置后把公开 URL 设为仓库 homepage并只添加准确的 topics——六个聚焦的 topics 远比一长串泛泛标签有用project_urlhttps://OWNER.github.io/REPOSITORY/ gh repo edit ${project_repo} --homepage ${project_url}构建状态回读gh api repos/${project_repo}/pages/builds/latest \ --jq {status,commit,updated_at,error}轮询应采用短且有界的时间间隔在built、errored或canceled状态时停止绝不让无限循环空转。built之后还要核验部署的 commit 与本地预期 commit 一致。仓库子路径陷阱项目站点从https://OWNER.github.io/REPOSITORY/提供服务而非域名根。因此必须优先使用相对资源 URLlink relstylesheet href./styles.css script typemodule src./app.js/script img src./assets/preview.jpg alt而根相对 URL如/assets/preview.jpg会解析到OWNER.github.io根在项目站点上几乎必然失效。深链、模块导入、worker、manifest、字体与 fetch 请求都可能存在同样的 base-path 问题需逐一测试。框架项目不要粘贴一份过时的通用 Actions workflow。先识别框架再对照其当前的官方 Pages 部署指南至少核验正确的构建命令、产物输出目录、仓库子路径或 base URL 配置、官方 Pages artifact action 版本以及是否需要 SPA fallback 路由。对 Next.js、Astro、Vite 等框架使用其支持的静态导出或 Pages adapter若应用需要服务端函数、数据库、认证回调或密钥级运行时变量Pages 就不是兼容的部署目标。常见故障排查参考文档专列四类配置后立即 404等待最新构建达到终态确认配置的源目录中存在index.html确认配置的分支存在于远程确认仓库可见性与账号的 Pages 可用性。HTML 能加载但资源失败检查网络与控制台错误将根相对路径替换为仓库感知的相对路径精确核对大小写GitHub 主机大小写敏感确认大文件或生成资产已被提交并推送。模块 MIME 或 import 错误确认被引用文件存在于部署 URL不要 import 本地文件系统路径使用浏览器兼容的 ES modules而非需要打包器的包名。自定义域名问题未经明确授权不得添加或更改自定义域名按当前官方文档核验 DNS 归属域名验证通过后保持强制 HTTPS 开启。第 8 步验证外部状态Read back推送与部署都是外部写入不能用 CLI 成功退出码作为唯一验证手段。技能要求回读所有外部变更gh repo view OWNER/REPOSITORY \ --json nameWithOwner,url,visibility,description,homepageUrl,defaultBranchRef gh api repos/OWNER/REPOSITORY/pages gh api repos/OWNER/REPOSITORY/pages/builds/latest等到 Pages 构建报告built或具体地失败之后打开公开 URL 核验最终 HTTPS URL 上 HTTP 导航成功预期的项目 UI 出现一个代表性交互能改变主应用状态并干净地返回或关闭资产在仓库子路径下正确解析无浏览器错误或警告README 中的链接均可解析。若公开页面是用户要求的交付物应保持页面打开供用户查看。第 9 步交付精确结果交付时需明确返回仓库 URL公开站点 URL若已创建commit 与分支Pages 构建状态实际运行过的检查项仍存在的依赖、许可或部署限制。核心要求是区分四种状态已推送pushed、Pages 已配置Pages configured、Pages 已构建Pages built、线上站点已核验live site verified绝不把它们合并成一个笼统的成功声明。失败规则Failure rules技能以一组硬性失败规则收束边界Agent 在整条管线中必须遵守保留无关的脏工作与历史不因发布而破坏不发布密钥若密钥已被提交任何推送前必须先将其从历史中移除当本地上下文无法确定 GitHub owner 或既有仓库目标时不臆测不用file://预览来声称 Pages 兼容性不用 CLI 成功退出码作为外部写入的唯一验证当 Pages 不兼容时不静默改用其他宿主。资源清单与总结publish-project-to-github技能文件夹在仓库中的结构如下agent-skills/codex/publish-project-to-github/ ├── SKILL.md # 技能主文档frontmatter 九步流程 失败规则 ├── agents/openai.yaml # Agent 接口定义display_name、short_description、default_prompt ├── scripts/audit_public_project.sh # 发布前审计脚本 ├── references/github-pages.md # GitHub Pages 配置与排障参考 └── assets/README-template.md # README 起始模板三条核心用法打包或发布前先运行 scripts/audit_public_project.sh配置或排查 Pages 前先读 references/github-pages.md从 assets/README-template.md 拷贝结构并用项目证据重写每一个占位符。本技能与 Skills 仓库的整体哲学一脉相承技能是操作规程operating procedures——明确何时使用、先做什么、采用什么默认值、避免哪些错误。publish-project-to-github正是这一哲学的落地把打包 → 审计 → 本地验证 → 推送 → 部署 → 回读核验这条极易出错的发布路径固化成可复用的九步流程让 Agent 在每次发布时都能稳定产出干净、安全、可验证的公开交付物。对设计师与开发者而言它把发布一个开源项目从一次性冒险变成了一道带审计门禁、带部署核验的标准流水线。赞分享【免费下载链接】SkillsAgent skills for designers and builders using Codex, Claude, Cursor, and other AI coding agents项目地址https://gitcode.com/gh_mirrors/skills48/Skills点击查看免费下载相关推荐EmDash 插件发布实战从本地 publish 到 GitHub Actions 自动化委托发布EmDash 插件发布实战从本地 publish 到 GitHub Actions 自动化委托发布 EmDash基于 Astro 的全栈 TypeScripCMS后端前端插件系统EmDash 沙箱插件发布实战从本地 publish 到 GitHub Actions 自动化委托发布EmDash 沙箱插件发布实战从本地 publish 到 GitHub Actions 自动化委托发布 本篇技术指南完整讲解 EmDash基于 AstroCMS后端前端插件系统Publish to Nexus 发布到 NexusGoReleaser 自定义发布器实战Publish to Nexus 发布到 NexusGoReleaser 自定义发布器实战 导读 本文是 GoReleaser 官方 Cookbook 中的一开发工具CI/CD构建工具上一篇如何在3分钟内完成Figma中文界面汉化设计师必备的终极完整指南下一篇如何将3DS游戏文件转为CIA格式3dsconv完整使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考