scaffold-repository

设置仓库

除下文指定的使用者拉取请求模板外，请以 patinaproject/skills 当前根目录中的内容作为文件内容来源。阅读 core-baseline.txt，了解必需的文件清单；阅读 audit-checklist.md，了解所有必需的检查。

在 patinaproject/skills 以外运行时，使用以下命令获取单个源文件：

gh api repos/patinaproject/skills/contents/<path> --jq .content | base64 -d

对于多个文件，请使用浅克隆临时仓库：

git clone --depth 1 https://github.com/patinaproject/skills.git /tmp/patinaproject-skills-reference

如果网络和本地检出都不可用，请向用户索取参考仓库的副本。不要凭记忆重建文件。

选择工作类型

如果目标是一个 Git 仓库，且没有任何 Patina 文件（例如 AGENTS.md、commitlint.config.js 或 package.json 中的标准脚本），请使用新仓库设置流程。

如果这些文件中有任何一个已存在，请使用现有仓库更新流程。

新仓库

1. 阅读 core-baseline.txt，并从当前 Patina 仓库复制所有必需文件。
2. 根据下方的输入填写特定于仓库的值。
3. 省略仅用于 marketplace 的测试和维护文件。清单中已将其排除。
4. 运行 pnpm install，以创建 pnpm-lock.yaml 并配置 Husky。
5. 暂存创建的文件，但不要提交，以便用户自行创建首次提交。

现有仓库

1. 完整阅读 audit-checklist.md，并运行所有适用的检查。
2. 使用 audit-checklist.md 中的差异名称和定义，使报告符合其规定的输出格式。
3. 对于每项差异，说明建议的更改，并展示相对于当前 Patina 文件的统一差异。
4. 在更改任何现有文件之前，请让用户对每条建议选择接受、跳过或延后。没有非交互式覆盖模式。
5. 按照 audit-checklist.md 规定的顺序呈现更改：提交和拉取请求规则、包和技能工具、仓库文档、GitHub 工作流，然后是移除已弃用的设置。
6. 如果接受的更改修改了非空的 skills-lock.json，运行 pnpm skills:install，确认项目本地技能出现在 npx --yes skills@latest list --json 的结果中，并包含刷新的 .agents/skills/ 目录和 .claude/skills/ 链接。

如果目标仓库是 patinaproject/skills，也要执行相同的审计检查。

仓库输入

尽可能从 origin 读取仓库所有者和名称。从 git config user.name 和 git config user.email 读取作者姓名和电子邮件。使用该电子邮件作为公开的安全联系邮箱。如果未配置姓名或电子邮件，请停止。

使用 gh api user --jq .login 解析作者的 GitHub 用户名。如果失败，请询问 Author GitHub handle for the package author URL?，不要提供默认值。

对于无法确定的值，请询问用户：

值	默认值
仓库所有者	origin 中的所有者
仓库名称	origin 中的名称
单行描述	无
可见性	public
代码所有者	@<owner>
安全联系邮箱	配置的 Git 电子邮件
作者姓名	配置的 Git 姓名
作者电子邮件	配置的 Git 电子邮件
作者 GitHub 用户名	当前已认证的 GitHub 用户

将作者姓名、电子邮件和 https://github.com/<author-handle> 写入 package.json 的作者字段。仓库 URL 仍使用仓库所有者和名称。

必需文件行为

core-baseline.txt 是 scripts/verify-baseline.sh 使用的文件列表。请使用此文件，而不要在此技能中复制第二份列表。

有四个条目需要特殊处理：

• 从 pr-body-template.md 复制 .github/pull_request_template.md。按其中的说明，要求同时提供 GitHub 和 Linear 关闭引用。通过目标仓库的跟踪器适配器和关联的问题数据获取对应的 ID，然后根据其集成方式和关闭引用检查验证引用格式。
• 如果目标中没有 opening-a-pr 操作手册，请调整复制的 AGENTS.md 和 CONTRIBUTING.md，将目标当前启用的工作流指定为正文约定。如果不存在正文约定，则由作者决定正文结构。模板仅负责提醒添加关闭引用。
• 仅为公开仓库创建 SECURITY.md。
• 将真实的跟踪器说明保存在 docs/agents/issue-tracker.md。创建 docs/issue-tracker.md，并将其设为指向 agents/issue-tracker.md 的相对链接。

不要将市场维护测试、生成的技能链接或发布工作流复制到普通仓库。根据目标仓库实际接收的文件调整复制的工作流。

默认的 .claude/settings.json 中，enabledPlugins 对象为空。它仍会将 bash scripts/worktree-setup.sh 注册为 SessionStart 启动钩子。Codex 环境会从其 [setup] 区块运行同一脚本。项目之后可以启用插件。

提交格式、拉取请求格式、Markdown lint、包脚本、已提交的本地技能、Agent 说明、问题跟踪、发布、操作固定、标签和工作流权限，请使用当前文件和 audit-checklist.md 中的检查项。不要凭记忆复述这些可能变化的细节。

GitHub 合并设置

如有 gh，请检查当前设置：

gh api "repos/<owner>/<repo>" --jq '{allow_squash_merge, allow_merge_commit, allow_rebase_merge, squash_merge_commit_title, squash_merge_commit_message, delete_branch_on_merge, allow_update_branch}'

对于没有 gh 的公开仓库，请使用公共 API 和 curl。如果仓库是私有的，且无法使用经过身份验证的工具，请向用户展示预期值，并请他们检查 GitHub 设置。

预期值：

设置	值
Squash 合并	开启
Merge commits	关闭
Rebase 合并	关闭
Squash 标题	PR_TITLE
Squash 消息	COMMIT_MESSAGES
合并后删除分支	开启
建议更新分支	开启
发布不可变性	开启

报告检查设置的方式以及所有差异。更改设置前请征得确认。获得确认后，使用以下命令更新受支持的值：

gh api -X PATCH "repos/<owner>/<repo>" \
  -F allow_squash_merge=true \
  -F allow_merge_commit=false \
  -F allow_rebase_merge=false \
  -F squash_merge_commit_title=PR_TITLE \
  -F squash_merge_commit_message=COMMIT_MESSAGES \
  -F delete_branch_on_merge=true \
  -F allow_update_branch=true

必须在 GitHub 的 Settings、General、Releases 下启用发布不可变性。常规仓库 API 不会公开此设置。

还要应用 audit-checklist.md 中的仓库设置检查，包括工作流写入权限、发布标签的签名规则，以及保留标签 autorelease: pending。进行普通问题或拉取请求工作时，切勿添加或移除 Release Please 标签。

验证结果

先运行文件存在性检查。即使没有复制任何必需文件，其他工具也可能通过。

bash <skill-directory>/scripts/verify-baseline.sh --public
# Use --private for a private repository.
pnpm install
pnpm exec commitlint --help
pnpm lint:md
echo "feat: bad" | pnpm exec commitlint
echo "feat: #1 ok" | pnpm exec commitlint

错误的提交消息必须验证失败。包含 #1 的公开示例必须验证通过。私有仓库请使用该仓库的私有问题格式。

将 <skill-directory> 解析为此技能的安装目录。从目标仓库运行验证脚本，或将目标仓库根目录作为最后一个参数传入。任何路径缺失都应视为设置失败。

提交 Markdown 更改之前，请运行：

pnpm exec markdownlint-cli2 --fix "**/*.md"

将私有仓库改为公开

用户要求将私有仓库设为公开时，请阅读可见性迁移说明。更改问题跟踪方式或 Git 历史不同于常规仓库更新，需要单独制定并审查计划。

最终报告

对于新仓库，列出暂存的文件以及用户仍需提供的值。对于现有仓库，按批次列出已接受、已跳过和已延期的更改。包括未通过的检查、GitHub 设置差异，以及所有未完成事项所需的确切用户操作。