Back to Details

workbench-repo-brand-uplift

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workbench Repo Brand Uplift

Workbench 仓库品牌升级

Upgrade public GitHub repos into credible, proof-first artifacts. The target is not prettier prose; it is a first screen that makes the repo's value, proof, install path, and maturity obvious to a fresh outsider.
将公开GitHub仓库升级为可信、以证据为先的成果。目标并非更优美的文案，而是打造一个首屏界面，让初次接触的外部人员能清晰了解仓库的价值、证据、安装路径和成熟度。

Source Standard

参考标准

Use the Zonic/Evensong public surface as the design DNA:
  • tactical telemetry over marketing copy;
  • strong project name, short claim, visible proof, then navigation;
  • industrial grid language: sparse sections, tight labels, mono metadata, restrained badges, sharp boundaries;
  • public/private boundary stated clearly;
  • evidence links before long narrative;
  • no mascots, lore, fake momentum, private screenshots, raw logs, or internal run IDs in public docs.
以Zonic/Evensong的公开界面为设计基准：
  • 优先实用数据而非营销文案；
  • 清晰的项目名称、简短定位、可见证据，再导航入口；
  • 规整的网格布局风格：简洁区块、紧凑标签、统一元数据、克制使用徽章、明确边界；
  • 清晰区分公开/私有边界；
  • 先展示证据链接，再呈现长篇叙述；
  • 公开文档中不得包含吉祥物、故事设定、虚假热度、私有截图、原始日志或内部运行ID。

When To Use

使用场景

Use this for:
  • README or repo-front-page polish;
  • public repo metadata, topics, social-preview, examples, screenshots, or demo link updates;
  • turning an internal workbench-quality repo into a public adoption surface;
  • matching Evensong/Zonic visual and trust quality across multiple repos;
  • "senior dev README uplift", "brand design", "make this repo public-ready", "adopt zonicdesign.art", or similar requests.
Do not use this to fake traction, invent benchmarks, rewrite unrelated code, or spray the same template across repos without repo-specific proof.
适用于以下场景：
  • README或仓库首页优化；
  • 公开仓库元数据、主题、社交预览、示例、截图或演示链接更新；
  • 将内部工作台级别的仓库改造为面向公众的推广界面；
  • 在多个仓库中统一Evensong/Zonic的视觉风格与可信度标准；
  • 「资深开发者README升级」「品牌设计」「让仓库具备公开条件」「采用zonicdesign.art规范」等类似需求。
请勿用于伪造用户活跃度、编造基准测试、重写无关代码，或在未结合仓库专属证据的情况下盲目套用同一模板。

Brand Gates

品牌审核标准

Every uplift should pass these gates:
GateRequirement
First-screen clarityProject name, one-line claim, audience, and status visible before scrolling.
Proof before proseDemo, screenshot, CLI output, benchmark, live URL, or PR evidence appears early.
Fresh-clone pathInstall/run/test commands are current and scoped to this repo.
Architecture mapHuman and agent can locate main modules, docs, examples, and ownership boundaries.
Maturity labelsStable, experimental, research, internal, or archived surfaces are not mixed.
Public safetyNo secrets, private IDs, raw transcripts, screenshots, or unreviewed claims.
Community pathIssues, contribution route, license, examples, and support boundary are clear.
每一次升级都需通过以下审核项：
审核项要求
首屏清晰度无需滚动即可看到项目名称、一句话定位、受众群体和状态。
先证后文尽早展示演示、截图、CLI输出、基准测试、在线链接或PR证据。
克隆即用路径安装/运行/测试命令为当前有效版本，且仅针对本仓库。
架构地图人工和Agent均可快速定位主模块、文档、示例和所有权边界。
成熟度标签稳定版、实验版、研究版、内部版或归档版的标识不得混淆。
公开安全性不得包含机密信息、私有ID、原始对话记录、截图或未经审核的声明。
社区路径问题反馈、贡献流程、许可证、示例和支持边界清晰明确。

Workflow

工作流程

  1. Inspect live repo state: 
    pwd
    , 
    git status --short --branch
    , 
    git remote -v
    .
  2. Read current 
    README.md
    , package metadata, docs map, examples, and public assets only as needed.
  3. Identify the strongest available proof. If proof is missing, add a clear "needs proof" residual risk instead of inventing one.
  4. Draft the README around proof, not vibes:
    • name and claim;
    • status badges only if accurate;
    • public screenshot/demo/CLI evidence;
    • quickstart;
    • architecture map;
    • examples;
    • maturity and safety boundary;
    • contribution path.
  5. Update adjacent public surfaces when relevant: package description, topics recommendation, docs links, examples, and public image references.
  6. Run touched-path checks. At minimum: 
    git diff --check
    , link/file existence checks for local docs, and repo-specific build/test commands if README quickstart changed.
  7. If this is part of Workbench public docs or skill sync, route the patch through 
    workbench-hermes-docs-sync
    .
  1. 检查仓库当前状态：执行
    pwd
    、
    git status --short --branch
    、
    git remote -v
    命令。
  2. 按需阅读当前
    README.md
    、包元数据、文档地图、示例和公开资源。
  3. 确定现有最有力的证据。若缺少证据，需明确标注「需补充证据」的潜在风险，而非编造证据。
  4. 围绕证据而非主观感受撰写README：
    • 名称与定位；
    • 仅添加准确的状态徽章；
    • 公开截图/演示/CLI证据；
    • 快速入门指南；
    • 架构地图；
    • 示例；
    • 成熟度与安全边界；
    • 贡献路径。
  5. 相关联的公开界面同步更新：包描述、主题推荐、文档链接、示例和公开图片引用。
  6. 执行变更路径检查：至少需执行
    git diff --check
    、本地文档的链接/文件存在性检查；若README中的快速入门内容有变更，需执行仓库专属的构建/测试命令。
  7. 若本次升级属于Workbench公开文档或技能同步范畴，需通过
    workbench-hermes-docs-sync
    提交补丁。

Zonic GitHub Pattern

Zonic GitHub 模板

Use this shape unless the repo has a stronger native convention:
markdown
undefined
除非仓库有更合适的原生规范，否则使用以下模板：
markdown
undefined

PROJECT NAME

PROJECT NAME

One sentence: what it is, who uses it, and why it matters.
[status badges]
一句话描述：是什么、面向谁、核心价值。
[状态徽章]

Public Proof

公开证据

  • Live demo:
  • Screenshot / CLI output:
  • Latest verified command:
  • 在线演示：
  • 截图 / CLI输出：
  • 最新验证命令：

Quickstart

快速入门

bash
...
bash
...

System Map

系统地图

SurfacePathPurpose
界面路径用途

Maturity

成熟度

SurfaceStateNotes
界面状态说明

Contributing / License

贡献指南 / 许可证


Keep the top compact. A README that needs a tour guide has already failed the
landing-page job.

保持顶部内容紧凑。需要额外指引的README，已经失去了作为 landing page 的作用。

Verdict Contract

结论模板

Return:
text
REPO_BRAND_UPLIFT
repo:
brand_dna_source:
target_audience:
public_surfaces_checked:
proof_used:
changed:
metadata_recommendations:
verification:
residual_risk:
next_repo_or_next_action:
VERDICT: PASS | FLAG | BLOCK
Use 
PASS
only when the repo is materially clearer to a fresh outsider and all new public claims have evidence. Use 
FLAG
when the README is improved but needs screenshot, live demo, CI, metadata, or maintainer action. Use 
BLOCK
when public claims would mislead users or leak private/internal material.
返回：
text
REPO_BRAND_UPLIFT
repo:
brand_dna_source:
target_audience:
public_surfaces_checked:
proof_used:
changed:
metadata_recommendations:
verification:
residual_risk:
next_repo_or_next_action:
VERDICT: PASS | FLAG | BLOCK
仅当仓库对初次接触的外部人员而言清晰度显著提升，且所有新增公开声明均有证据支撑时，使用
PASS
；当README已有改进但仍需补充截图、在线演示、CI、元数据或需维护者进一步操作时，使用
FLAG
；当公开声明可能误导用户或泄露私有/内部信息时，使用
BLOCK
。