od-contribute

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

od-contribute — first-contribution flow for Open Design

od-contribute — Open Design 首次贡献流程

Locked to

nexu-io/open-design

. Branches by contribution type, not by issue. Replaces the dev-loop with type-specific no-code validators. Designed so a product user with zero coding background can ship a real PR.

锁定至

nexu-io/open-design

仓库。按贡献类型而非Issue创建分支。用特定类型的无代码验证器替代开发循环。旨在让完全没有编程背景的产品用户也能提交有效的PR。

Language

语言设置

Mirror the user's language in every user-facing message —

AskUserQuestion

labels and descriptions, status updates, error explanations. Detect from their first message; when uncertain, default to English.

Generated artifacts (PR titles, commit messages, PR/issue body files, branch names) MUST be English regardless of the user's chat language. GitHub conventions, maintainer review, and search all assume English. The templates under

templates/

are already English — keep them that way when rendering.

Scripts live under

scripts/

. Source the shared helpers from any script:

bash

source "$(dirname "$0")/config.sh"

SKILL_DIR

below = the directory that contains this

SKILL.md

在所有面向用户的消息中镜像用户的语言——包括

AskUserQuestion

的标签和描述、状态更新、错误说明。从用户的第一条消息检测语言；不确定时默认使用英语。

生成的产物（PR标题、提交信息、PR/Issue正文文件、分支名称）必须使用英语，无论用户的聊天语言是什么。GitHub的惯例、维护者审核和搜索都默认使用英语。

templates/

下的模板已为英语——渲染时保持原样。

脚本存放在

scripts/

目录下。从任意脚本中引入共享助手：

bash

source "$(dirname "$0")/config.sh"

下方的

SKILL_DIR

= 包含此

SKILL.md

文件的目录。

Step 1 — Prereq check (always first)

步骤1 — 前置条件检查（始终优先执行）

bash

bash "$SKILL_DIR/scripts/check-prereqs.sh"

Exit 0: capture

GH_USER=<login>

from stdout. Default

TARGET_FORK="${GH_USER}/open-design"

Exit 2: surface the printed install / auth hint verbatim and stop. Do not attempt token workarounds.

gh repo view "$TARGET_FORK"

fails, ask the user (one

AskUserQuestion

) whether to fork now via

gh repo fork nexu-io/open-design --clone=false

. Default to yes.

bash

bash "$SKILL_DIR/scripts/check-prereqs.sh"

退出码0：从标准输出捕获

GH_USER=<login>

。默认

TARGET_FORK="${GH_USER}/open-design"

。

退出码2：直接显示打印的安装/认证提示并停止流程。不要尝试令牌替代方案。

如果

gh repo view "$TARGET_FORK"

执行失败，向用户询问（通过一次

AskUserQuestion

）是否立即通过

gh repo fork nexu-io/open-design --clone=false

进行Fork。默认选择“是”。

Step 2 — Pick contribution type

步骤2 — 选择贡献类型

Single

AskUserQuestion

(header: "Contribution", multiSelect: false), four options. Translate option labels/descriptions into the user's chat language; the branch routing is unchanged.

🎨 Ship something I made with OD — a Skill, Design System, HyperFrame, or template I want to contribute upstream → branch
```
3a
```
🌍 Translate OD docs — README / QUICKSTART / CONTRIBUTING into a new language → branch
```
3b
```
📝 Fix docs / write a blog / fix a typo — typo fix, dead link, use-case writeup → branch
```
3c
```
🐛 Report a bug — something broke; I'll help turn it into a high-quality issue → branch
```
3d
```
(issue path, no PR)

Each branch below is self-contained. Steps 7–8 (preview + push) are shared across branches

3a

3b

3c

. Branch

3d

skips them entirely.

单次

AskUserQuestion

（标题：“贡献类型”，不可多选），提供四个选项。将选项标签/描述翻译成用户的聊天语言；分支路由保持不变。

🎨 提交我用OD制作的内容 — 我想向上游贡献的Skill、设计系统、HyperFrame或模板 → 分支
```
3a
```
🌍 翻译OD文档 — 将README / QUICKSTART / CONTRIBUTING翻译成新语言 → 分支
```
3b
```
📝 修复文档/撰写博客/修正拼写错误 — 拼写错误修复、失效链接修复、用例撰写 → 分支
```
3c
```
🐛 报告Bug — 出现了问题；我会协助将其转化为高质量Issue → 分支
```
3d
```
（仅创建Issue，不生成PR）

以下每个分支都是独立的。步骤7–8（预览 + 推送）在分支

3a

3b

3c

之间共享。分支

3d

完全跳过这些步骤。

Step 3a — OD product submission (Skill / Design System)

步骤3a — OD产品提交（Skill / 设计系统）

3a.1 Ask user: "What's the local path to the artifact you want to ship?" (single free-text, translated into the user's chat language). Common: a folder path (Skill) or a single

DESIGN.md

file (Design System).

3a.2 Sniff type:

bash

undefined

3a.1 询问用户：“你要提交的产物的本地路径是什么？”（单行自由文本，翻译成用户的聊天语言）。常见路径：文件夹路径（Skill）或单个

DESIGN.md

文件（设计系统）。

3a.2 检测类型：

bash

undefined

Skill: folder containing SKILL.md with frontmatter.

Skill：包含带前置元数据的SKILL.md的文件夹。

Design System: file matching DESIGN.md anatomy.

Design System：符合DESIGN.md结构的文件。


If ambiguous, ask the user to confirm.

**3a.3** Run setup:

```bash
bash "$SKILL_DIR/scripts/setup-workspace.sh" skill <slug>


如果类型不明确，请用户确认。

**3a.3** 运行设置：

```bash
bash "$SKILL_DIR/scripts/setup-workspace.sh" skill <slug>

or

或

bash "$SKILL_DIR/scripts/setup-workspace.sh" design-system <slug>


`<slug>` is `od::slugify` of the Skill `name` frontmatter field or of the brand name. Capture `WORKDIR` from stdout.

**3a.4** Copy artifact into workspace at the right target dir:
- Skill → `$WORKDIR/skills/<slug>/`
- Design System → `$WORKDIR/design-systems/<brand-slug>/DESIGN.md` (+ any sibling assets in the same folder)

**3a.5** Validate:

```bash
bash "$SKILL_DIR/scripts/validate-skill-submission.sh" "$WORKDIR/skills/<slug>"

bash "$SKILL_DIR/scripts/setup-workspace.sh" design-system <slug>


`<slug>`是Skill前置元数据字段`name`或品牌名称经过`od::slugify`处理后的结果。从标准输出捕获`WORKDIR`。

**3a.4** 将产物复制到工作区的目标目录：
- Skill → `$WORKDIR/skills/<slug>/`
- 设计系统 → `$WORKDIR/design-systems/<brand-slug>/DESIGN.md`（+ 同一文件夹中的所有同级资源）

**3a.5** 验证：

```bash
bash "$SKILL_DIR/scripts/validate-skill-submission.sh" "$WORKDIR/skills/<slug>"

or, with 1-2 reference DESIGN.md files passed in:

或，传入1-2个参考DESIGN.md文件：

bash "$SKILL_DIR/scripts/validate-design-system.sh"
"$WORKDIR/design-systems/<slug>/DESIGN.md"
--reference "$WORKDIR/design-systems/airbnb/DESIGN.md"
--reference "$WORKDIR/design-systems/apple/DESIGN.md"


If validation fails, surface the FAIL lines verbatim, ask the user to fix, retry. **Never push a failing artifact.**

**3a.6** Ask 3 short questions via `AskUserQuestion` (translate the labels into the user's chat language):
- "What name should we credit you under in the PR?" — free-text
- "One-line pitch for this Skill / Design System?" — free-text
- "Path to a screenshot (optional)?" — free-text

**3a.7** Render `templates/PR-BODY-skill.md` (or `PR-BODY-design-system.md`) with substitutions:
- `{{SKILL_NAME}}`, `{{SKILL_SLUG}}` (or `{{BRAND_NAME}}`, `{{BRAND_SLUG}}`)
- `{{PITCH}}` (the one-line)
- `{{MOTIVATION}}` (free-text — agent can offer to draft this from the skill body, but user confirms)
- `{{TRY_PROMPT}}` (a prompt they recommend trying — agent suggests a default, user confirms)
- `{{SCREENSHOT_BLOCK}}` (Markdown image block if a screenshot path was given, else empty)
- `{{DISCORD_INVITE}}` from `$OD_DISCORD_INVITE`

Write to `$WORKDIR/.od-contrib/PR-BODY.md`.

→ Jump to **Step 7**.

---


如果验证失败，直接显示失败行内容，要求用户修复后重试。**绝不推送验证失败的产物。**

**3a.6** 通过`AskUserQuestion`询问3个简短问题（将标签翻译成用户的聊天语言）：
- “PR中应使用什么名称署名？” — 自由文本
- “这个Skill / 设计系统的一句话介绍？” — 自由文本
- “截图路径（可选）？” — 自由文本

**3a.7** 渲染`templates/PR-BODY-skill.md`（或`PR-BODY-design-system.md`）并替换变量：
- `{{SKILL_NAME}}`、`{{SKILL_SLUG}}`（或`{{BRAND_NAME}}`、`{{BRAND_SLUG}}`）
- `{{PITCH}}`（一句话介绍）
- `{{MOTIVATION}}`（自由文本——Agent可根据Skill内容草拟，需用户确认）
- `{{TRY_PROMPT}}`（推荐尝试的提示词——Agent提供默认值，需用户确认）
- `{{SCREENSHOT_BLOCK}}`（如果提供了截图路径则为Markdown图片块，否则为空）
- `{{DISCORD_INVITE}}`来自`$OD_DISCORD_INVITE`

将结果写入`$WORKDIR/.od-contrib/PR-BODY.md`。

→ 跳转至**步骤7**。

---

Step 3b — i18n translation

步骤3b — 国际化翻译

3b.1 Setup workspace (slug =

translate-<doc>-<lang>

if known, else

translate

bash

bash "$SKILL_DIR/scripts/setup-workspace.sh" i18n translate

3b.1 设置工作区（如果已知，slug =

translate-<doc>-<lang>

，否则为

translate

）：

bash

bash "$SKILL_DIR/scripts/setup-workspace.sh" i18n translate

capture WORKDIR

捕获WORKDIR


**3b.2** Discover gaps:

```bash
bash "$SKILL_DIR/scripts/discover-i18n-gaps.sh" "$WORKDIR" > /tmp/od-i18n-gaps.json

Each line is JSON. Rank by:

```
status: "missing"
```
first (missing language is highest leverage)

then

status: "stale"

ordered by

english_commits_since_translation

desc

README family before QUICKSTART before CONTRIBUTING

3b.3 Take the top 3–4 gaps and present via

AskUserQuestion

(header: "Translation target"). Each option label like:

README → 한국어 (Korean)

QUICKSTART (zh-CN) refresh — 12 commits behind

. Translate the header text into the user's chat language but keep the option labels descriptive (the language names belong in their native script).

3b.4 Once user picks, rename branch to be specific:

bash

git -C "$WORKDIR" branch -m "od-contrib/i18n/<doc>-<lang>-<date>"

(or pre-set the slug in step 3b.1 if the user confirmed earlier.)

3b.5 Translate. Read the English source. Translate structure-preserving:

Code blocks: leave untranslated
Brand / product names: leave untranslated
Filenames in inline code: leave untranslated
Image / link targets: leave untranslated; if a localized version of a linked doc exists, swap the link to the localized file
Headings: translate, keep the heading depth identical
Tables: translate cell text only, keep alignment / pipes

Write the result to

$WORKDIR/<TRANSLATED_PATH>

(e.g.

QUICKSTART.es.md

). Show user a unified diff vs. the English source for visual sanity-check (line-count delta within ±15% is a healthy signal).

3b.6 Validate the translated file against the English source. The

--reference

flag tells the validator to ignore relative refs that were already broken in the source — OD docs frequently link to website route slugs (e.g.

skills/blog-post/

) that aren't files on disk; we don't want a structure-preserving translation to fail because of pre-existing dead refs.

bash

bash "$SKILL_DIR/scripts/validate-markdown.sh" \
  "$WORKDIR/<TRANSLATED_PATH>" \
  --reference "$WORKDIR/<ENGLISH_PATH>"

If FAIL → surface verbatim, fix, retry.

3b.7 Render

templates/PR-BODY-i18n.md

with

{{DOC_NAME}}

{{LANG_DISPLAY_NAME}}

{{LANG_CODE}}

{{TRANSLATED_PATH}}

{{ENGLISH_PATH}}

{{STATUS}}

{{TRANSLATION_NOTES}}

(one paragraph from the agent: anything tricky, untranslated terms it kept, etc.),

{{DISCORD_INVITE}}

→ Step 7.


**3b.2** 发现翻译缺口：

```bash
bash "$SKILL_DIR/scripts/discover-i18n-gaps.sh" "$WORKDIR" > /tmp/od-i18n-gaps.json

每行都是JSON。按以下优先级排序：

首先是
```
status: "missing"
```
（缺失的语言优先级最高）

然后是

status: "stale"

，按

english_commits_since_translation

降序排列

README系列优先于QUICKSTART，再优先于CONTRIBUTING

3b.3 选取前3–4个缺口，通过

AskUserQuestion

展示（标题：“翻译目标”）。每个选项标签示例：

README → 한국어 (Korean)

QUICKSTART (zh-CN) 刷新 — 落后12次提交

。将标题文本翻译成用户的聊天语言，但保持选项标签的描述性（语言名称使用其原生脚本）。

3b.4 用户选择后，重命名分支以明确用途：

bash

git -C "$WORKDIR" branch -m "od-contrib/i18n/<doc>-<lang>-<date>"

（如果用户之前已确认，可在步骤3b.1中预先设置slug。）

3b.5 翻译。读取英文源文件，保留结构进行翻译：

代码块：保持不翻译
品牌/产品名称：保持不翻译
行内代码中的文件名：保持不翻译
图片/链接目标：保持不翻译；如果链接文档存在本地化版本，将链接替换为本地化文件
标题：翻译，保持标题层级一致
表格：仅翻译单元格文本，保持对齐方式/竖线格式

将结果写入

$WORKDIR/<TRANSLATED_PATH>

（例如

QUICKSTART.es.md

）。向用户展示与英文源文件的统一差异，进行视觉合理性检查（行数差异在±15%以内为正常信号）。

3b.6 对照英文源文件验证翻译后的文件。

--reference

标志告知验证器忽略源文件中已存在的失效相对引用——OD文档经常链接到网站路由slug（如

skills/blog-post/

），这些并非磁盘上的文件；我们不希望因预存的失效引用导致结构保留的翻译验证失败。

bash

bash "$SKILL_DIR/scripts/validate-markdown.sh" \
  "$WORKDIR/<TRANSLATED_PATH>" \
  --reference "$WORKDIR/<ENGLISH_PATH>"

如果失败→直接显示内容，修复后重试。

3b.7 渲染

templates/PR-BODY-i18n.md

，替换变量：

{{DOC_NAME}}

、

{{LANG_DISPLAY_NAME}}

、

{{LANG_CODE}}

、

{{TRANSLATED_PATH}}

、

{{ENGLISH_PATH}}

、

{{STATUS}}

、

{{TRANSLATION_NOTES}}

（Agent撰写的一段说明：翻译中的难点、保留未翻译的术语等）、

{{DISCORD_INVITE}}

。

→ 步骤7。

Step 3c — Docs / blog / typo

步骤3c — 文档/博客/拼写错误修复

3c.1 Setup workspace (slug

docs

bash

bash "$SKILL_DIR/scripts/setup-workspace.sh" docs <slug>

3c.2 Ask user (one

AskUserQuestion

Auto-discover small fixes (run discover-doc-gaps, pick something)
I have a specific fix in mind (free-text)
I want to write a blog / case study (free-text — what's the use case?)

3c.3 (Auto-discover branch) Run:

bash

bash "$SKILL_DIR/scripts/discover-doc-gaps.sh" "$WORKDIR" > /tmp/od-doc-gaps.json

Group by

kind

(typo / deadlink / todo). Show the user up to 6 candidates via

AskUserQuestion

. Once picked, apply the fix in code (typo: replace word; deadlink: ask user for the new URL; todo: that's a proper task, ask user to write the missing prose).

3c.4 (Specific-fix branch) Read the file, apply user's described change. Confirm via diff.

3c.5 (Blog branch) First check whether OD has a blog directory:

bash

ls "$WORKDIR/docs" 2>/dev/null

If a

docs/blog/

or similar exists, place the new post there. If not, ask the user where it should live, defaulting to

docs/<slug>.md

. Generate an outline → user fills in user-specific bits (their use case, screenshots, the prompt they used, the rendered output) → agent stitches into a final Markdown.

3c.6 Validate every changed/added file. For files that already exist in the repo (typo fix, dead-link fix, doc edit), pass

--reference

pointing at HEAD's version so we only fail on relative refs the user introduced, not on pre-existing route slugs:

bash

undefined

3c.1 设置工作区（slug为

docs

）：

bash

bash "$SKILL_DIR/scripts/setup-workspace.sh" docs <slug>

3c.2 询问用户（一次

AskUserQuestion

）：

自动发现小修复（运行discover-doc-gaps，选择一个任务）
我有特定的修复方案（自由文本）
我想撰写博客/案例研究（自由文本——具体用例是什么？）

3c.3（自动发现分支） 运行：

bash

bash "$SKILL_DIR/scripts/discover-doc-gaps.sh" "$WORKDIR" > /tmp/od-doc-gaps.json

按

kind

（拼写错误/失效链接/待办事项）分组。通过

AskUserQuestion

向用户展示最多6个候选任务。用户选择后，在代码中应用修复（拼写错误：替换单词；失效链接：询问用户新URL；待办事项：需用户撰写缺失的内容）。

3c.4（特定修复分支） 读取文件，应用用户描述的更改。通过差异确认。

3c.5（博客分支） 首先检查OD是否有博客目录：

bash

ls "$WORKDIR/docs" 2>/dev/null

如果存在

docs/blog/

或类似目录，将新博客文章放在此处。如果不存在，询问用户存放位置，默认

docs/<slug>.md

。生成大纲→用户填写特定内容（他们的用例、截图、使用的提示词、渲染输出）→Agent拼接成最终Markdown。

3c.6 验证所有修改/新增的文件。对于仓库中已存在的文件（拼写错误修复、失效链接修复、文档编辑），传入

--reference

指向HEAD版本，以便仅针对用户引入的失效相对引用报错，而非预存的路由slug：

bash

undefined

For modifications to existing files:

针对现有文件的修改：

git -C "$WORKDIR" show "HEAD:<path>" > "/tmp/od-contrib-orig-<basename>" 2>/dev/null bash "$SKILL_DIR/scripts/validate-markdown.sh"
"$WORKDIR/<changed-path>"
--reference "/tmp/od-contrib-orig-<basename>"

For brand-new files (e.g. a blog post the user is creating from scratch),

针对全新文件（例如用户从头创建的博客文章），

omit --reference. The validator will skip the relative-ref check entirely

省略--reference。验证器将完全跳过相对引用检查

(since it can't tell route slugs from real paths in isolation).

（因为无法单独区分路由slug和真实路径）。


**3c.7** Render `templates/PR-BODY-docs.md` with `{{ONE_LINE_SUMMARY}}`, `{{DETAILS}}`, `{{FILES_LIST}}`, `{{DISCORD_INVITE}}`.

→ **Step 7**.

---


**3c.7** 渲染`templates/PR-BODY-docs.md`，替换变量：`{{ONE_LINE_SUMMARY}}`、`{{DETAILS}}`、`{{FILES_LIST}}`、`{{DISCORD_INVITE}}`。

→ **步骤7**。

---

Step 3d — Bug report (issue path, no PR)

步骤3d — Bug报告（仅创建Issue，不生成PR）

3d.1 Read OD's actual schema at runtime to make sure we mirror it:

bash

gh api "repos/${TARGET_REPO}/contents/.github/ISSUE_TEMPLATE/bug-report.yml" --jq .content | base64 -d > /tmp/od-bug-report.yml

If the schema has drifted from the template (

templates/ISSUE-BODY-bug.md

), regenerate the body to match.

3d.2 Ask the user via

AskUserQuestion

, one structured prompt per critical field. Use plain language, not the YAML field names:

Bug-report field	Prompt to user
`description`	"What went wrong? One sentence is fine."
`steps`	"How can I reproduce it? Walk me through step by step."
`expected`	"What did you expect to happen?"
`version`	"Which OD version are you running? (About menu, or `od --version` )"
`platform`	dropdown: macOS (Apple Silicon) / macOS (Intel) / Windows / Linux / Other
`logs`	"Any error logs you can paste? Skip if you don't have them."
`screenshots`	"Path to a screenshot? Skip if you don't have one."

Translate every prompt above into the user's chat language at runtime.

3d.3 Auto-collect what we can (these don't need to ask the user):

OS family from
```
uname
```
Node version from
```
node -v
```
if relevant

3d.4 Dedupe: extract 3–5 keywords from the description, run:

bash

gh search issues "<keywords>" --repo "$TARGET_REPO" --state open --limit 5 --json number,title,url

If matches exist, present them to the user via

AskUserQuestion

(translate to user's language): "These existing issues look related. Do you want to: (a) comment on an existing one, (b) open a new issue anyway, (c) cancel?"

3d.5 If proceeding with new issue, render

templates/ISSUE-BODY-bug.md

and submit:

bash

bash "$SKILL_DIR/scripts/create-issue.sh" \
  --title "$TITLE" \
  --body-file "$WORKDIR_OR_TMP/.od-contrib/ISSUE-BODY.md" \
  --dedupe-keywords "<keywords>"

3d.6 Print the issue URL on its own line. Do not push branches or open PRs from this branch.

3d.1 运行时读取OD的实际Issue模板，确保与之匹配：

bash

gh api "repos/${TARGET_REPO}/contents/.github/ISSUE_TEMPLATE/bug-report.yml" --jq .content | base64 -d > /tmp/od-bug-report.yml

如果模板与

templates/ISSUE-BODY-bug.md

不一致，重新生成正文以匹配最新模板。

3d.2 通过

AskUserQuestion

询问用户，每个关键字段对应一个结构化提示。使用通俗易懂的语言，而非YAML字段名：

Bug报告字段	用户提示
`description`	“出了什么问题？一句话描述即可。”
`steps`	“如何复现问题？请逐步说明。”
`expected`	“你预期会发生什么？”
`version`	“你正在运行哪个OD版本？（关于菜单，或执行 `od --version` ）”
`platform`	下拉选项：macOS（Apple Silicon）/ macOS（Intel）/ Windows / Linux / 其他
`logs`	“是否可以粘贴错误日志？没有的话可以跳过。”
`screenshots`	“截图路径？没有的话可以跳过。”

运行时将上述所有提示翻译成用户的聊天语言。

3d.3 自动收集可获取的信息（无需询问用户）：

从
```
uname
```
获取操作系统类型
相关时从
```
node -v
```
获取Node版本

3d.4 去重：从描述中提取3–5个关键词，运行：

bash

gh search issues "<keywords>" --repo "$TARGET_REPO" --state open --limit 5 --json number,title,url

如果存在匹配项，通过

AskUserQuestion

向用户展示（翻译成用户语言）：“这些现有Issue看起来相关。你想：(a) 在现有Issue下评论，(b) 仍要创建新Issue，(c) 取消？”

3d.5 如果继续创建新Issue，渲染

templates/ISSUE-BODY-bug.md

并提交：

bash

bash "$SKILL_DIR/scripts/create-issue.sh" \
  --title "$TITLE" \
  --body-file "$WORKDIR_OR_TMP/.od-contrib/ISSUE-BODY.md" \
  --dedupe-keywords "<keywords>"

3d.6 单独一行打印Issue URL。不要从此分支推送代码或创建PR。

Step 7 — Preview + confirm (shared, PR branches only)

步骤7 — 预览 + 确认（PR分支共享步骤）

Show the user a clean summary:

text

About to commit:
  Branch:  od-contrib/<type>/<slug>-<date>
  Files:
    + skills/foo/SKILL.md            (1.2 KB)
    + skills/foo/preview.png         (54 KB)
  Push to:  <fork or upstream>
  Open PR:  nexu-io/open-design:main ← <fork>:<branch>

Then

git -C "$WORKDIR" diff --stat

and a

head -40

of the rendered PR body for visual sanity.

Required

AskUserQuestion

confirmation (translate to user's language): "Push this PR?" with three options:

Ship it — proceed to Step 8
Let me revise — return to the relevant Step 3 sub-step
Cancel — leave the workspace on disk, tell the user the path so they can return later, exit

Never push without an explicit "Ship it".

向用户展示清晰的摘要：

text

即将提交：
  分支：  od-contrib/<type>/<slug>-<date>
  文件：
    + skills/foo/SKILL.md            (1.2 KB)
    + skills/foo/preview.png         (54 KB)
  推送至：  <Fork或上游仓库>
  创建PR：  nexu-io/open-design:main ← <Fork>:<branch>

然后展示

git -C "$WORKDIR" diff --stat

的结果，以及渲染后的PR正文前40行，进行视觉合理性检查。

必须通过

AskUserQuestion

获取确认（翻译成用户语言）：“推送此PR？”，提供三个选项：

提交 — 进入步骤8
我要修改 — 返回对应的步骤3子步骤
取消 — 保留磁盘上的工作区，告知用户路径以便后续返回，退出流程

未获得明确的“提交”确认绝不推送。

Step 8 — Push & open PR

步骤8 — 推送并创建PR

bash

bash "$SKILL_DIR/scripts/create-pr.sh" \
  --workdir "$WORKDIR" \
  --type "<skill|design-system|i18n|docs>" \
  --title "<PR title from references/newcomer-tone.md>" \
  --body-file "$WORKDIR/.od-contrib/PR-BODY.md"

Print the PR URL on its own line. Done.

bash

bash "$SKILL_DIR/scripts/create-pr.sh" \
  --workdir "$WORKDIR" \
  --type "<skill|design-system|i18n|docs>" \
  --title "<来自references/newcomer-tone.md的PR标题>" \
  --body-file "$WORKDIR/.od-contrib/PR-BODY.md"

单独一行打印PR URL。流程完成。

Safety rails (mandatory)

安全防护（强制要求）

Never push to
```
main
```
/
```
master
```
/
```
develop
```
. The push scripts refuse.
Never
```
--force
```
push. Just don't.
All workspace activity stays under
```
$OD_WORK_ROOT
```
(default
```
$HOME/od-contrib-work
```
).
```
od::assert_in_workroot
```
enforces this.
Bug-report path always runs the dedupe search before
```
gh issue create
```
.
Honor user memory: skip GitHub user
```
xxiaoxiong
```
from any contributor lookup ([[feedback_no_outreach_xxiaoxiong]]).

绝不推送到
```
main
```
/
```
master
```
/
```
develop
```
分支。推送脚本会拒绝此类操作。
绝不使用
```
--force
```
推送。绝对禁止。
所有工作区操作都在
```
$OD_WORK_ROOT
```
下进行（默认
```
$HOME/od-contrib-work
```
）。
```
od::assert_in_workroot
```
会强制执行此规则。
Bug报告流程必须在执行
```
gh issue create
```
前运行去重搜索。
尊重用户意愿：在任何贡献者查找中跳过GitHub用户
```
xxiaoxiong
```
（[[feedback_no_outreach_xxiaoxiong]]）。

When NOT to use this skill

何时不应使用此Skill

The user wants to fix a daemon / web bug or add a feature with code changes → use
```
auto-github-contributor
```
instead (it has the TDD loop). This skill deliberately doesn't run lint/typecheck/tests because content paths don't need them.
The user wants to generate a Skill / Design System from scratch → that's Open Design itself. Run OD first, get an artifact, then come back here to ship it.

用户想要修复守护进程/网页Bug或添加带代码变更的功能→改用
```
auto-github-contributor
```
（它包含TDD循环）。本Skill特意不运行lint/类型检查/测试，因为内容类贡献不需要这些。
用户想要从头生成Skill/设计系统→这是Open Design本身的功能。先运行OD生成产物，再返回此处提交。