repos

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Repos

仓库（Repos）

Command-driven GitHub repository management. Parse the first token as a command when it matches the table; otherwise map clear intent.

Default secrets path is Pulumi ESC (OIDC +

pulumi/esc-action

) — not long-lived

secrets.*

in GitHub unless the user explicitly wants classic repo secrets.

命令驱动的 GitHub 仓库管理。当第一个标记匹配表格中的命令时，将其解析为命令；否则根据明确意图进行映射。

默认密钥方案为 Pulumi ESC（OIDC +

pulumi/esc-action

）—— 除非用户明确要求使用传统的仓库密钥，否则不使用 GitHub 中长期有效的

secrets.*

密钥。

Operating contract

操作契约

Shared by every DecisionNerd/dev-skills skill. Canonical copy:

handbook/concepts/14-operating-contract.md

Define done first. Before using tools, write the finish line in one or two lines: the acceptance criteria (existing issue AC, BDD scenarios, tests, or contract when they exist; otherwise propose them and say where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on work you did not verify.
Requested scope sets the finish line. A question ("is it ready?", "why is it broken?", "what next?") ends with the answer and a
```
Next:
```
line naming the exact next invoke. An outcome request ("fix", "finish", "land", "#42") continues through the chain (diagnose → fix → test → check-readiness → merge-it) until the outcome or a real blocker. Do not end a turn with "Do you want me to…?" for in-scope, in-repo work.
Stop only for real blockers. Stop and ask only when you cannot continue without the user, or before: deleting data or unmerged work, force-push or history rewrite, changing anything outside this repository (GitHub objects, deployments, live data, production or paid resources, external services), or leaving the requested scope, unless the user's request already named that exact action. Keep the harness's permission prompts for risky commands. Otherwise keep going and put status notes in the same message as the next action.
Ask well, once. For a genuine question use the harness's structured question tool when it has one (Claude Code:
```
AskUserQuestion
```
; Codex:
```
request_user_input
```
when the current mode supports it) with concrete options; otherwise plain text with numbered options. Treat the answer as settled; do not re-open earlier verdicts, plans, or answers unless asked.
Fan out when work is parallel. Use subagents for independent reads (repo survey, evidence gathering, per-option research, per-area audits) and for independent verification (a reviewer that did not write the change). Writes stay single-owner per path set and sequential. Brief every child with goal, done-when, constraints, must-not, and return shape; verify each child's result before consolidating. Use Claude Code's
```
Workflow
```
tool only for orchestration across many subagents that truly needs it; it is expensive.
Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents (Claude Code
```
CLAUDE_CODE_SUBAGENT_MODEL
```
or a CLAUDE.md rule; Codex
```
agents.default_subagent_model
```
or a role's
```
agents.<name>.config_file
```
; Cursor a custom subagent's
```
model:
```
frontmatter), follow it and do not pass a model. Otherwise: mechanical search or inventory → fast/cheap (Claude Code
```
haiku
```
); implementation and evidence gathering → mid (
```
sonnet
```
); planning, review, adversarial verification → top (
```
opus
```
or
```
fable
```
). In Claude Code set it with the
```
Agent
```
tool
```
model
```
param or agent frontmatter
```
model:
```
; in Codex pass a spawn model or set
```
model
```
in the role's config file; in Cursor set
```
model:
```
(default
```
inherit
```
) in
```
.cursor/agents/*.md
```
. Where the harness cannot choose, children inherit the parent model or the harness picks one (Cursor's built-in Explore/Bash/Browser subagents pick per subtask); say which in the status note.
Keep a checklist on long runs. For more than about five steps or work that crosses skills, keep
```
TASKS.md
```
at the repo root and tick items as they finish. Do not commit it unless the repo already tracks one.
Close every run with three headings.
```
Blocked on me
```
(the one genuine question or blocker, else "none");
```
Changed
```
(files, commits, GitHub objects, deploys, else "nothing");
```
Found
```
(evidence, verdict, and
```
Next: <exact invoke>
```
).

所有 DecisionNerd/dev-skills 技能通用。规范副本：

handbook/concepts/14-operating-contract.md

。

先定义完成标准。 使用工具前，用一两行写出终点：验收标准（若存在现有 issue 的 AC、BDD 场景、测试或契约，则使用这些；否则提出验收标准并说明应存放的位置）以及证明完成的证据。在报告完成前重新检查。永远不要对未验证的工作报告完成。
请求的范围决定终点。 问题（“准备好了吗？”、“为什么坏了？”、“下一步是什么？”）以答案和明确指向下一次调用的
```
Next:
```
行结束。结果请求（“修复”、“完成”、“落地”、“#42”）会沿着链条（诊断 → 修复 → 测试 → 就绪检查 → 合并）持续推进，直到达成结果或遇到真正的阻塞。对于范围内的仓库内工作，不要以“你想要我…吗？”结束一轮对话。
仅在遇到真正阻塞时停止。 仅当没有用户就无法继续时，或在以下操作之前才停止并询问：删除数据或未合并的工作、强制推送或历史重写、修改本仓库之外的任何内容（GitHub 对象、部署、实时数据、生产或付费资源、外部服务），或者超出请求范围——除非用户的请求已经明确指定了该操作。对于风险命令，保留运行框架的权限提示。否则继续推进，并在包含下一步操作的同一消息中附上状态说明。
一次问清楚。 对于真正的问题，如果运行框架有结构化提问工具（Claude Code：
```
AskUserQuestion
```
；Codex：在当前模式支持时使用
```
request_user_input
```
），则使用该工具并提供具体选项；否则使用带编号选项的纯文本。将答案视为最终结论；除非被要求，否则不要重新讨论之前的结论、计划或答案。
并行工作时拆分任务。 对于独立读取任务（仓库调研、证据收集、各选项研究、各领域审计）和独立验证（未编写变更的评审者），使用子Agent。写入操作在每个路径集上保持单一负责人且顺序执行。向每个子Agent说明目标、完成条件、约束、禁止事项和返回格式；在合并前验证每个子Agent的结果。仅当确实需要跨多个子Agent编排时才使用 Claude Code 的
```
Workflow
```
工具；该工具成本较高。
为每个子Agent选择模型层级；遵循路由配置。 如果运行框架或用户配置已经为子Agent配置了路由（Claude Code 的
```
CLAUDE_CODE_SUBAGENT_MODEL
```
或 CLAUDE.md 规则；Codex 的
```
agents.default_subagent_model
```
或角色的
```
agents.<name>.config_file
```
；Cursor 自定义子Agent的
```
model:
```
前置元数据），则遵循该配置，不要传递模型参数。否则：机械搜索或盘点 → 快速/低成本（Claude Code
```
haiku
```
）；实现和证据收集 → 中等（
```
sonnet
```
）；规划、评审、对抗性验证 → 顶级（
```
opus
```
或
```
fable
```
）。在 Claude Code 中，通过
```
Agent
```
工具的
```
model
```
参数或 Agent 前置元数据的
```
model:
```
设置；在 Codex 中，传递生成模型或在角色配置文件中设置
```
model
```
；在 Cursor 中，在
```
.cursor/agents/*.md
```
中设置
```
model:
```
（默认
```
inherit
```
）。如果运行框架无法选择，子Agent将继承父模型或由运行框架选择（Cursor 内置的 Explore/Bash/Browser 子Agent会根据子任务选择）；在状态说明中说明使用的模型。
长时间运行时保留检查清单。 对于超过约五个步骤或跨技能的工作，在仓库根目录保留
```
TASKS.md
```
，并在完成时勾选项目。除非仓库已经跟踪该文件，否则不要提交它。
每次运行结束时包含三个标题。
```
Blocked on me
```
（一个真正的问题或阻塞，否则为“none”）；
```
Changed
```
（文件、提交、GitHub 对象、部署，否则为“nothing”）；
```
Found
```
（证据、结论，以及
```
Next: <exact invoke>
```
）。

Commands

命令

Command	What it does
(none) / `status` / `audit`	Survey current repo(s): visibility, default branch, protection, workflows, secrets posture, topics
`create`	Plan/create a new GitHub repo (template, visibility, init files, team access)
`settings` / `protect`	Branch protection, rulesets, merge policy, required checks, autodelete heads
`split`	Carve a package/path/history into a new repo (filter-repo / subtree plan)
`combine` / `merge-repos`	Join multiple repos into one (history strategy, path prefixes, CI unification)
`monorepo`	Design or migrate to/from monorepo (tooling, packages, CI graph, ownership)
`architecture` / `arch`	Repo-as-system architecture: boundaries, apps/packages, deploy units, coupling
`ci`	CI/CD workflows — see CI subcommands
`secrets`	Secrets & config — Pulumi ESC default; see references/secrets-esc.md
`access`	Collaborators, teams, outside collaborators, deploy keys posture
`topics` / `rename` / `transfer` / `visibility`	Metadata and identity operations
`archive` / `unarchive`	Archive or restore a repo
`template`	Template repo flags / generate from template
`sync`	Mirror or keep a fork/upstream sync plan (no silent force)
`help` / `library`	List commands

Aliases:

carve

→

split

;

join

→

combine

;

esc

→

secrets

;

workflows

→

ci

Target:

owner/repo

, URL, local path, or “current repo.”

命令	功能
(none) / `status` / `audit`	调研当前仓库：可见性、默认分支、保护规则、工作流、密钥状态、主题
`create`	规划/创建新的 GitHub 仓库（模板、可见性、初始化文件、团队访问权限）
`settings` / `protect`	分支保护、规则集、合并策略、必需检查、自动删除头部分支
`split`	将包/路径/历史拆分为新仓库（filter-repo / subtree 方案）
`combine` / `merge-repos`	将多个仓库合并为一个（历史策略、路径前缀、CI 统一）
`monorepo`	设计或迁移到/迁出 monorepo（工具链、包、CI 图谱、所有权）
`architecture` / `arch`	仓库作为系统的架构：边界、应用/包、部署单元、耦合度
`ci`	CI/CD 工作流 —— 参见 CI 子命令
`secrets`	密钥与配置 —— 默认使用 Pulumi ESC；参见 references/secrets-esc.md
`access`	协作者、团队、外部协作者、部署密钥状态
`topics` / `rename` / `transfer` / `visibility`	元数据与身份操作
`archive` / `unarchive`	归档或恢复仓库
`template`	模板仓库标记 / 从模板生成
`sync`	镜像或保持 Fork/上游同步的方案（无静默强制推送）
`help` / `library`	列出命令

别名：

carve

→

split

；

join

→

combine

；

esc

→

secrets

；

workflows

→

ci

。

目标：

owner/repo

、URL、本地路径或“当前仓库”。

Routing

路由规则

No argument:
```
status
```
for the current git remote.
First word is a command: run it; remainder is target/context.
ci harden
/
ci simplify
: CI subcommands (below).
Clear intent (“split packages/api into its own repo”, “move secrets to ESC”): map and proceed.

Mutating GitHub (create, settings, transfer, archive, secret writes), Pulumi ESC, or history rewrites requires explicit approval. Prefer plans + DAG before execution. For complexity judgment on CI/architecture, pair with

kiss

无参数：对当前 git 远程仓库执行
```
status
```
。
第一个词是命令：执行该命令；其余部分为目标/上下文。
ci harden
/
ci simplify
：CI 子命令（见下文）。
意图明确（“将 packages/api 拆分为独立仓库”、“将密钥迁移到 ESC”）：映射到对应命令并执行。

修改 GitHub（创建、设置、转移、归档、写入密钥）、Pulumi ESC 或重写历史需要明确批准。执行前优先制定计划和 DAG。对于 CI/架构的复杂度判断，配合

kiss

技能使用。

CI subcommands

CI 子命令

Subcommand	What it does
`ci` / `ci status`	Inventory workflows, required checks, flaky/slow jobs, secrets usage
`ci harden`	Least privilege permissions, pin actions SHAs or trustworthy versions, OIDC, no plaintext secrets, branch protections aligned to checks, fail-closed on supply chain basics
`ci simplify`	Remove redundant jobs/matrices, cache sanely, consolidate reusable workflows — only if complexity is unwarranted (use `kiss` lens; keep earned gates)
`ci add`	Add a workflow (test/lint/release/deploy) fitting repo stack
`ci reuse`	Extract composite/reusable workflows across monorepo or org

Details: references/ci.md.

子命令	功能
`ci` / `ci status`	盘点工作流、必需检查、不稳定/慢速任务、密钥使用情况
`ci harden`	最小权限配置、固定 Action 的 SHA 或可信版本、OIDC、无明文密钥、分支保护与检查对齐、供应链基础场景采用故障关闭策略
`ci simplify`	移除冗余任务/矩阵、合理配置缓存、合并可复用工作流——仅当复杂度不合理时（使用 `kiss` 视角；保留已验证的门禁）
`ci add`	添加适合仓库技术栈的工作流（测试/代码检查/发布/部署）
`ci reuse`	在 monorepo 或组织内提取复合/可复用工作流

详情：references/ci.md。

secrets

(Pulumi ESC default)

secrets

（默认使用 Pulumi ESC）

Default method: Pulumi ESC + GitHub OIDC (

id-token: write

pulumi/auth-actions

pulumi/esc-action

) so CI does not store long-lived cloud keys in GitHub Secrets.

Subcommand	What it does
`secrets` / `secrets status`	Where secrets live today (GitHub / ESC / both); drift risk
`secrets setup`	Bootstrap ESC env + OIDC trust + workflow injection (default path)
`secrets migrate`	Move classic GitHub Actions secrets → ESC; remove static secrets when safe
`secrets github`	Classic repo/org/environment secrets only if user insists
`secrets rotate`	Rotation plan for ESC providers / remaining GitHub secrets

Follow references/secrets-esc.md. Never print secret values.

默认方案：Pulumi ESC + GitHub OIDC（

id-token: write

、

pulumi/auth-actions

、

pulumi/esc-action

），这样 CI 不需要在 GitHub Secrets 中存储长期有效的云密钥。

子命令	功能
`secrets` / `secrets status`	当前密钥的存储位置（GitHub / ESC / 两者都有）；漂移风险
`secrets setup`	初始化 ESC 环境 + OIDC 信任 + 工作流注入（默认路径）
`secrets migrate`	将传统 GitHub Actions 密钥迁移到 ESC；安全时移除静态密钥
`secrets github`	仅当用户坚持时使用传统的仓库/组织/环境密钥
`secrets rotate`	ESC 提供商 / 剩余 GitHub 密钥的轮换计划

遵循 references/secrets-esc.md。永远不要打印密钥值。

split

combine

monorepo

split

combine

monorepo

split: map boundaries → history strategy (
```
git filter-repo
```
preferred) → new remote → CI/secrets/access → update consumers. See references/split.md.
combine: path prefix plan → history import strategy → unified CI → CODEOWNERS → redirect/archive sources. See references/combine.md.
monorepo: package layout (apps/packages), task runner, affected CI, ownership, release units. See references/monorepo.md.

Always produce a DAG of migration steps with right-sized tasks (Goldilocks — see

kiss

Done when: the DAG is fully executed, consumer repos and import paths are updated, and CI is green on the new layout. Fan out per-repo inventories to parallel read-only subagents (fast tier) during the survey phase; keep

TASKS.md

across the migration for any chain longer than five steps.

split：划定边界 → 历史策略（优先使用
```
git filter-repo
```
）→ 新远程仓库 → CI/密钥/访问权限 → 更新依赖方。参见 references/split.md。
combine：路径前缀规划 → 历史导入策略 → 统一 CI → CODEOWNERS → 重定向/归档源仓库。参见 references/combine.md。
monorepo：包布局（apps/packages）、任务运行器、受影响的 CI、所有权、发布单元。参见 references/monorepo.md。

始终生成包含合适大小任务的迁移步骤 DAG（Goldilocks 原则——参见

kiss

）。

完成条件：DAG 完全执行，依赖方仓库和导入路径已更新，新布局下 CI 全部通过。在调研阶段，将各仓库的盘点任务分发给并行的只读子Agent（快速层级）；对于任何超过五步的迁移链条，保留

TASKS.md

。

architecture

architecture

Repo-level architecture review (not app feature design):

Deployable units vs packages vs shared libs
Boundary rules (who may import whom)
CI/CD and env topology (dev/staging/prod)
Recommendation: keep / reshape / split / combine — with risks/benefits

Hand off product/UI feeling to ProductFeeling / Impeccable; docs tree to DocSlime; code structure inside a package to

refactor-it

仓库级架构评审（非应用功能设计）：

可部署单元 vs 包 vs 共享库
边界规则（谁可以导入谁）
CI/CD 和环境拓扑（开发/预发/生产）
建议：保留 / 调整 / 拆分 / 合并——附带风险和收益

产品/UI 体验相关的工作移交给 ProductFeeling / Impeccable；文档结构相关移交给 DocSlime；包内的代码结构相关移交给

refactor-it

。

Standard hygiene (

status

checklist)

标准检查项（

status

检查清单）

Default branch, visibility, homepage/topics
Branch protection / rulesets vs actual required checks
Workflows present, permissions blocks, action pinning posture
Secrets: GitHub vs ESC; long-lived credentials remaining
Dependabot/Renovate, CODEOWNERS, SECURITY.md, license
Autodelete head branches, squash/rebase policy
Forks, templates, archive state

For large orgs (many repos), split the audit by repo across parallel read-only subagents (fast tier); verify each before consolidating.

默认分支、可见性、主页/主题
分支保护 / 规则集与实际必需检查的对比
现有工作流、权限块、Action 固定状态
密钥：GitHub vs ESC；剩余的长期凭证
Dependabot/Renovate、CODEOWNERS、SECURITY.md、许可证
自动删除头部分支、压缩/变基策略
Fork、模板、归档状态

对于大型组织（大量仓库），将审计任务按仓库拆分给并行的只读子Agent（快速层级）；在合并前验证每个子Agent的结果。

Output

输出

Blocked on me

none

Changed

nothing

Found

<exact skill>

(from the recommend above)

<exact skill>

（来自上述推荐）

Related skills

Grounding

基础依据

This skill’s TTPs are grounded in current engineering baselines (DORA, GitHub Docs, Fowler/Beck, Google SRE & SWE book, OpenTelemetry, OWASP LLM / NIST AI RMF, Diátaxis — see handbook

sources.md

DORA CI + loosely coupled topology; GitHub OIDC / pinned Actions / least privilege for supply-chain baseline; Pulumi ESC is this house’s default over long-lived cloud keys.

Handbook card:

handbook/practices/repos.md

本技能的 TTP 基于当前的工程基准（DORA、GitHub 文档、Fowler/Beck、Google SRE 与 SWE 书籍、OpenTelemetry、OWASP LLM / NIST AI RMF、Diátaxis——参见手册

sources.md

）。

DORA CI + 松耦合拓扑；GitHub OIDC / 固定 Action 版本 / 最小权限作为供应链基线；Pulumi ESC 是本团队默认的方案，替代长期有效的云密钥。

手册卡片：

handbook/practices/repos.md

。

repos

Original

Translation

Repos

仓库（Repos）

Operating contract

操作契约

Commands

命令

Routing

路由规则

CI subcommands

CI 子命令

`secrets`
(Pulumi ESC default)

`secrets`
（默认使用 Pulumi ESC）

`split`
/
`combine`
/
`monorepo`

`split`
/
`combine`
/
`monorepo`

`architecture`

`architecture`

Standard hygiene (
`status`
checklist)

标准检查项（
`status`
检查清单）

Output

输出

Blocked on me

Blocked on me

Changed

Changed

Found

Found

Related skills

相关技能

Grounding

基础依据

repos

Original

Translation

Repos

仓库（Repos）

Operating contract

操作契约

Commands

命令

Routing

路由规则

CI subcommands

CI 子命令

secrets (Pulumi ESC default)

secrets（默认使用 Pulumi ESC）

split / combine / monorepo

split / combine / monorepo

architecture

architecture

Standard hygiene (status checklist)

标准检查项（status 检查清单）

Output

输出

Blocked on me

Blocked on me

Changed

Changed

Found

Found

Related skills

相关技能

Grounding

基础依据

`secrets`
(Pulumi ESC default)

`secrets`
（默认使用 Pulumi ESC）

`split`
/
`combine`
/
`monorepo`

`split`
/
`combine`
/
`monorepo`

`architecture`

`architecture`

Standard hygiene (
`status`
checklist)

标准检查项（
`status`
检查清单）