Osc2026 Guide

OSC 2026 Guide

Guide contestants through MoonBit国产开源生态大赛 OSC 2026. Default output language is Chinese unless the user explicitly requests another language.

Default Entry

When the user asks a broad question, asks for help, or invokes the skill without a specific task, start with a concise help message in Chinese:

你可以咨询关于 MoonBit国产开源生态大赛的任何事情，例如：
1. 比赛如何报名？
2. 比赛时间安排是什么？
3. 我应该怎么开始准备项目？
4. 申报书应该写什么？
5. GitHub / Gitlink 仓库应该如何准备？
6. 如何自查项目是否适合提交？

Then answer the user's actual question directly with contestant-facing guidance.

Rule Source

• Use the bundled charter as the primary rule source: references/2026 MoonBit 国产基础软件开源大赛章程.md.
• For operational FAQs and non-charter knowledge, also read references/supplemental-knowledge.md.
• Use the bundled charter instead of querying online charter pages.
• If the charter does not answer a question, say what is known, what is uncertain, and where the contestant can ask for confirmation.

Common Guidance Topics

• Registration: explain that contestants submit information and project proposal materials through the official competition entry described in the charter.
• Schedule: summarize the application, development, acceptance, and final presentation phases from the charter when asked.
• Project choice: guide contestants toward reusable MoonBit ecosystem libraries, ports, tools, examples, bindings, data structures, runtime utilities, or application ecosystem projects.
• Getting started: recommend choosing a clear project scope, creating a public repository, setting up MoonBit tooling, writing a README, adding a root license, adding runnable examples, and committing meaningful work regularly.
• Proposal: help contestants prepare a concise Markdown or PDF proposal that includes the project's GitHub repository link, project name, summary, direction, use case, core features, implementation plan, expected deliverables, and whether it is original, a port, or based on another project.
• GitHub / Gitlink: treat repository links as submission materials. Identify which links the contestant should submit, and remind them to verify the remote repository's default branch, not only a branch named main or master.
• Open source compliance: remind contestants to document upstream projects, licenses, generated code, copied code, fixtures, test data, and redistribution rights.
• Final acceptance preparation: mention README reproducibility, CI for check/build/test, runnable examples, tests for core paths, and readiness for publishing to mooncakes.io.

Environment Suggestions

• When the user asks about environment readiness or requests project review, use moon version --all to check the local MoonBit toolchain. If the version is older than MoonBit 1.0, suggest upgrading.
• When environment context is relevant, check whether moonbitlang/skills is installed, using the current tool's exposed skill list or local skill directories when available.
• If moonbitlang/skills is missing and the current agent supports skill installation, recommend installing it as the next step and offer to do it immediately. If installation is not available, provide the install command.
• When the toolchain is missing/outdated or moonbitlang/skills is missing, end the response with a concise offer tailored to the missing items, such as: 如果你愿意，我可以顺手帮你把 MoonBit 工具链更新到最新版，并装好 moonbitlang/skills。

Review Mode

Run the full local self-review only when the user explicitly asks for review, self-check, pre-submission check, or asks whether the current repository is ready to submit.

Review Scope

• Review the current local repository, or a local path explicitly provided by the user.
• Treat the proposal document as optional input. If it is missing, remind the contestant to prepare it for official submission; do not treat that as a repository defect.
• If a proposal document is provided, it should be Markdown or PDF. Markdown proposals should stay within 30 lines, and PDF proposals should stay within 1 page.
• Inspect the repository directly and return a Markdown report.
• Treat GitHub and Gitlink information as submission-material checks: identify the links the contestant should submit, but keep the report focused on the local repository.
• Run moon version --all and report toolchain issues separately from project issues.

Review Checks

• Judge MoonBit project configuration using files recognized by the current toolchain, such as moon.mod and moon.pkg, together with moon check / moon test results.
• Inspect the package namespace in moon.mod, for example the username in username/package. The template default username should be replaced with the contestant's GitHub account name, otherwise publishing to mooncakes.io may fail.
• Do not require the repository URL owner/path in moon.mod to match the package namespace. A package namespace such as Milky2018/... may validly point to a repository hosted under an organization such as moonbit-community/....
• Treat a current local branch with 10 or fewer commits as high risk. When commit count is low, suggest meaningful development commits; do not suggest empty commits, duplicate commits, or meaningless splitting.
• When git history is available, distinguish work before and after 2026-04-29. Older projects may participate, but the contest values development work added from 2026-04-29 onward.
• Check whether the local repository appears to have the GitHub/Gitlink submission links the contestant will need. If a remote is missing, present it as a submission-material reminder.
• When checking a remote repository, identify its default branch first, for example with git remote show <remote> or the hosting site's default-branch setting. Do not assume main or master, and call out cases where important work exists only on a non-default branch.
• If a proposal document is provided, check that it is concise, uses Markdown or PDF format, includes the project's GitHub repository link, and explains the project name, summary, direction, target use case, core features, implementation plan, expected deliverables, and whether the project is original, a port, or based on another project. If it contains multiple GitHub links, distinguish the contestant's project repository from reference/upstream repositories.
• Check whether the project duplicates a mature MoonBit ecosystem project without clear new value. If it extends existing work, the README or proposal should explain the independent contribution.
• Estimate MoonBit source scale when practical. Very small, template-only, or empty-shell repositories should be called out; the charter gives 4~10k effective MoonBit lines as a project-scale reference, not a strict local line-count verdict.
• Use root-level LICENSE* files as the primary evidence for the project license.
• For ports or projects based on another open source project, the README or a dedicated document should identify the original project name, link, license, and scope of reference.
• Focus on evidence that affects submission risk: MoonBit as the main implementation language, README usability, runnable examples, tests, moon check / moon test, and source/license notes for third-party code or test data.
• Include later-stage readiness suggestions when relevant: CI for check/build/test, at least one runnable example, tests for core paths, and readiness for publishing to mooncakes.io.
• Call out compliance risks for copied code, generated code, fixtures, sample files, private/commercial code, undisclosed upstream sources, or materials whose redistribution rights are unclear.
• If personal sensitive information is found, mention only the risk and file location; do not repeat the sensitive content.

Review Report

Use these sections when appropriate:

• 总体判断
• 提交前需要处理的问题
• 需要进一步确认的问题
• 建议改进
• 已检查的证据
• 可选环境建议

Separate facts, inferences, and uncertain rule interpretations. Cite local commands or files for evidence-backed conclusions. Present items that cannot be verified locally as points to clarify, not final rulings.

osc2026-guide

面向 MoonBit国产开源生态大赛 OSC 2026 选手的全流程 Agent skill。

安装

推荐使用 skills CLI 安装：

npx skills@latest add Milky2018/osc2026-guide -g --skill osc2026-guide --agent universal

也可以手动克隆到本地 Agent skill 目录：

mkdir -p ~/.agent/skills
git clone https://github.com/Milky2018/osc2026-guide.git ~/.agent/skills/osc2026-guide

如果 skill 列表没有自动刷新，请重启对应工具。

使用

在需要了解比赛信息或检查项目时调用：

使用 $osc2026-guide 介绍一下 MoonBit国产开源生态大赛，我可以咨询哪些问题？

需要自查当前项目时可以说：

使用 $osc2026-guide 检查当前仓库是否适合提交到 MoonBit国产开源生态大赛。

2026 MoonBit 国产基础软件开源大赛章程

章程更新时间：2026.05.11

一、赛事定位

本赛事以 MoonBit 编程语言及其工具链为基础，面向所有开发者群体（不限学生或社会人士），鼓励参赛者利用 AI 工具与 MoonBit 完成各类开源库、生态包、开发工具和示例工程的设计、移植、实现与完善，共同推动国产开源基础软件生态建设。

---

二、赛事宗旨

MoonBit 作为面向 AI 时代的新一代编程语言和开发者工具链，具备现代类型系统、统一工具链、多后端支持以及面向工程化开发的设计基础。为了进一步降低开发者参与 MoonBit 生态建设的门槛，本赛事将重点聚焦“开源生态库建设”，鼓励参赛者参与生态共建。

本赛事强调项目真实可用、边界清晰、文档完整、测试可运行、后续可维护。参赛者可以从其他成熟语言生态中选择合适的开源库进行 MoonBit 移植，也可以围绕 MoonBit 生态中的实际需求设计原创库或示例项目。赛事鼓励合理使用 AI 工具完成代码生成、接口设计、测试补全和文档撰写，但最终成果应体现参赛者对项目目标、技术路径、质量边界和开源合规的理解与把控。

本赛事希望通过广参与、可验收、可展示的方式，形成一批真正能够被 MoonBit 开发者使用、学习和继续演进的生态项目，为国产开源生态积累更多基础组件和实践经验。

---

三、参赛对象与参赛形式

3.1 参赛对象

本赛事面向所有对 MoonBit、AI 编程、开源生态、基础软件和软件工程实践感兴趣的开发者群体（不限学生或社会人士）。

3.2 参赛形式

本赛事支持个人参赛，每位参赛者可提交一个参赛项目。已于 4 月 29 日前创建或存在的项目，可在原有基础上继续维护并参与本赛事；但参赛有效工作量仅统计自 4 月 29 日起新增提交的代码、文档及相关开发成果。

---

四、项目方向

本赛事重点围绕 MoonBit 开源生态建设。参赛项目应具备明确功能、真实使用场景和可复用价值。具体推荐方向可以查看附录一：推荐项目清单

参赛项目可以是原创实现，也可以是对其他成熟语言生态中优秀开源库的 MoonBit 移植或重写。鼓励参赛者参考 Rust、Go、TypeScript、Python、OCaml、Scala、Java 等语言生态中已有的成熟库，选择适合 MoonBit 生态现阶段需求的方向进行移植和实现。

参赛项目不得直接移植或重复 MoonBit 生态中已经存在且功能高度重合的成熟项目；如在已有项目基础上进行扩展，应明确说明新增价值和独立贡献。

项目规模参考范围为 4~10k 有效 MoonBit 代码行数。

---

五、比赛流程

阶段一：项目申报（即日起-7月10日）

参赛者需通过官方报名入口（CCF：https://www.gitlink.org.cn/competitions/track1_2026MoonBit），CCF官网注册后进赛事群提交参赛信息和项目申报材料。报名入口、申报模板及提交截止时间以赛事群为主。

问卷提交后，赛方会通过邮件通知选手是否通过申报审核。若通过，会同时发放第一阶段奖金；若不通过，邮件会说明拒绝原因，选手可以调整项目内容后继续申报。

项目申报材料建议控制在一页 PDF，不要求撰写复杂商业计划书。材料应重点说明项目要做什么、为什么值得做、计划如何实现、最终交付什么。

申报内容包括：

1. 项目名称； 2. 项目简介； 3. 项目方向与适用场景； 4. 拟实现的核心功能； 5. 是否为原创项目、移植项目或参考已有开源项目； 6. 如为移植项目，需说明参考项目名称、来源链接和许可证； 7. GitHub 仓库链接，含有10-20个有效commits，不得通过无意义拆分、空提交或重复提交满足次数要求。 8. Gitlink仓库链接，需要跟Github同步。

申报样本可参考附录二：项目申报书样本。

符合条件的项目可获得 150 元 / 项目 的启动支持。

启动支持用于鼓励参赛者尽快完成项目初始化、工程搭建、AI 工具使用、基础样例和早期代码探索。启动支持不代表项目已通过最终验收。

阶段二：项目开发与社区活动（即日起-7月10日）

参赛者可在开发周期内持续推进项目。赛事组将根据实际情况提供以下支持：

• MoonBit 快速开始指南；
• 项目模板仓库；
• 推荐项目方向清单；
• 常见问题答疑；
• 线上宣讲或高校专场分享；
• 社区答疑渠道；
• 优秀项目阶段性展示；
• MoonBit 工程最佳实践说明。

赛事鼓励参赛者在开发过程中保持公开、连续、可追踪的工程记录，包括工单及合并请求、提交记录和更新日志等。

阶段三：项目验收和优秀项目评选（7月11日-7月17日）

赛事组将根据项目完成度、工程质量、文档质量和开源规范进行审核。7月11日起，项目组开始评选入围线下参与展示的项目名单。

申请完成支持的项目应满足以下要求，上传到Github&Gitlink

1. 项目以 MoonBit 为主要实现语言； 2. GitHub 和 Gitlink 仓库公开可访问，提交记录清晰； 3. 源代码结构清晰，能够完成声明的核心功能； 4. 提供 README，说明项目目标、安装方式、使用方法和示例，并可复现； 5. 使用持续集成工具并且覆盖检查、构建、测试流程； 6. 提供至少一个可运行示例或最小使用样例； 7. 提供完整测试，覆盖核心功能路径； 8. 发布到 mooncakes.io； 9. 采用 OSI 认可的开源许可证；如参考或移植其他开源项目，应符合原项目许可证要求。

通过验收的项目可获得 350 元 / 项目 的完成支持。

启动支持与完成支持合计为 500 元 / 项目。该基础激励旨在鼓励更多开发者完成可用的 MoonBit 生态项目，与最终优秀作品奖励不冲突。

阶段四：线下展示（8月16日）

在基础验收之后，赛事组将根据项目完成度、对 MoonBit 开源生态的贡献、工程质量等维度综合评估，从通过验收的项目中遴选一批具有代表性的优秀项目，进入最终评选和展示环节：

入选项目需要参加决赛答辩（暂定8月16日），具体形式以赛事官方公告为准。

赛事组将综合专家评审、项目验收结果、生态价值和展示表现，评选最终优秀作品。

---

六、激励机制

本赛事激励分为两类：基础共建激励和优秀作品奖励。

6.1 基础共建激励

基础共建激励面向通过立项和验收的 MoonBit 生态项目，重点鼓励更多开发者完成可用的开源库和生态包。

基础共建激励按项目发放。每个项目仅可领取一次启动支持和一次完成支持。参赛者重复提交相似项目、空壳项目、低质量复制项目或无实质贡献项目的，赛事组有权不予发放或取消资格。

6.2 优秀项目奖励

本赛事设立优秀作品奖励，用于鼓励在工程质量、生态价值、文档体验、MoonBit 特性使用和长期维护潜力方面表现突出的项目。

优秀作品奖励总奖金池暂定为 15 万元人民币，具体奖项设置如下：

以上奖项数量和金额可根据实际参赛规模、项目质量和赛事预算进行合理调整。若某一奖项无符合质量要求的项目，赛事组可空缺该奖项或调整奖项分布。

基础共建激励不计入优秀作品奖金。获得基础共建激励的项目，仍可参与优秀作品评选。

6.3 转推荐奖励

为鼓励开发者邀请更多开发者参与 MoonBit 生态建设，赛事设立转推荐奖励：

• 已成功报名的参赛者（推荐人），可邀请新参赛者（被推荐人）报名参赛；
• 被推荐人在提交项目申报问卷时，需在“推荐人”字段准确填写推荐人的手机号码；
• 推荐关系认定规则：
• 一位被推荐人只能绑定一位推荐人。若被推荐人由多人先后邀请，以报名问卷中首次有效提交的推荐人信息为准。
• 推荐关系一经赛事组审核确认，不予变更。推荐人与被推荐人不得相互推荐、重复推荐或通过虚假账号套取奖励，一经发现，取消比赛双方比赛资格。
• 异常账号与刷奖判定：
• 同一推荐人所邀请的被推荐人中，若存在 GitHub 账号注册时间过新，或仓库内容、结构、提交历史高度相似的情况，赛事组可判定为风险账号。
• 经复核确认存在批量注册新账号、复制仓库套取推荐奖励行为的，将取消推荐人及涉事被推荐人的比赛资格和已发放的全部激励。
• 赛事组审核确认被推荐人报名成功后，推荐人可获得 50 元 / 人 的现金奖励，上限 30 人；
• 推荐奖励可与基础共建激励、优秀作品奖励叠加获取，不受项目数量限制。

---

七、开源与成果提交要求

参赛项目须以开源方式提交，并满足以下基本要求：

1. 项目须在 GitHub 或赛事组认可的平台公开发布； 2. 仓库须包含完整源代码； 3. 仓库须保留合理开发历史记录； 4. 仓库须包含 README 文档； 5. 项目须选择 OSI 认证许可证； 6. 如项目移植或参考其他开源项目，应在 README 或专门文档中注明原项目名称、链接、许可证和参考范围； 7. 项目须遵守第三方依赖及参考项目的许可证要求； 8. 项目不得侵犯他人知识产权，不得提交未经授权的私有代码、闭源代码或商业代码； 9. 如项目包含生成代码、测试数据或样例文件，应保证其来源合法合规； 10. 项目通过验收并参与展示的，参赛者同意主办方在保留作者署名的前提下，用于赛事宣传、官网展示、社区文章、技术分享和生态推广。

参赛者保留项目的著作权及开源项目署名权。赛事支持与奖励不构成主办方对项目著作权、商业权利或独占使用权的购买。

---

八、赛事时间安排

赛事组可能根据参赛规模和实际执行情况调整赛程，并通过官方渠道提前通知。

---

九、违规处理

参赛者应遵守开源规范、学术诚信和基本工程伦理。出现以下情况的，赛事组有权取消项目立项、验收资格、激励发放资格或获奖资格：

1. 提交虚假个人信息或项目信息； 2. 抄袭、冒用、盗用他人项目成果； 3. 未经授权使用闭源代码、私有代码或商业代码； 4. 隐瞒项目移植来源或违反第三方许可证限制； 5. 通过无意义提交、重复项目、空壳仓库等方式刷取基础激励； 6. 项目内容违反法律法规、公序良俗或平台规则； 7. 项目存在恶意代码、后门、攻击性功能或明显安全风险； 8. 在赛事沟通、评审或展示中存在严重不诚信行为； 9. 其他经赛事组认定严重影响赛事公平性和生态建设目标的行为。

如存在争议，赛事组可要求参赛者补充说明、提交代码来源证明、补充许可证说明。

---

十、附则

1. 本赛事所有支持与奖励均为赛事激励性质，不构成任何形式的劳务报酬、委托开发、成果购买或雇佣关系。 2. 启动支持、完成支持及优秀作品奖励的具体发放方式、时间和税务处理，将按主办方及相关规定执行。 3. 参赛者须保证提交信息真实有效，并配合完成必要的奖励发放信息确认。 4. 主办方在尊重作者署名权和开源许可证的前提下，可对参赛项目进行展示、宣传和生态推广。 5. 主办方不因赛事激励获得参赛项目的独占权利、商业权利或著作权转让。 6. 主办方保留在不改变赛事总体原则的前提下，对赛程、奖励设置、评审方式和章程细则进行合理调整的权利，并通过官方渠道公告。 7. 参赛者提交报名即视为已阅读并同意本章程全部内容。

---

十一、宣传与推广

展示机制

为鼓励参赛者持续参与开源建设，赛事组将建立项目展示机制。

通过验收或表现突出的项目，有机会获得以下展示支持：

• 入选赛事官网项目墙；
• 入选 MoonBit 生态项目列表；
• 在 MoonBit 官方社区、公众号、X / Twitter、Discord、B 站、视频号等渠道展示；
• 获得项目作者访谈或技术文章发布机会；
• 参与线上分享或高校宣讲；
• 进入后续生态维护和协作计划；
• 推荐成为 MoonBit 示例工程或学习材料。

赛事鼓励参赛者在开发过程中同步撰写博客、开发日志或经验总结。优秀内容可被赛事组推荐传播。

高校合作与推广机制

本赛事鼓励高校、学生社团、实验室、课程团队和开源组织参与共建。

赛事组可与高校合作开展以下活动：

• 校园宣讲；
• 线上训练营；
• MoonBit 快速入门 workshop；
• AI 编程实践工作坊；
• 开源项目认领活动；
• 校内项目展示；
• 高校优秀作品专场；
• 高校组织荣誉展示。

高校合作方可组织学生围绕课程实践、暑期实践、开源训练营或社团活动参与本赛事。赛事组可根据实际情况提供项目清单、基础教程、评审标准、示例仓库和线上答疑支持。

高校合作请联系：MoonBit小助手：13923429458(微信同号）

欢迎参赛选手进入赛事群，群内会有对应工作人员解答赛事问题

---

附录一：推荐项目清单

以下方向仅作为参考，不构成限制性要求。参赛者可根据自身能力和兴趣选择合适方向。

基础数据结构与算法

• 常用数据结构，例如 indexmap、bitmask；
• Graph 相关算法库；
• Pathfinding 工具库；
• moon prove 验证的通用算法库。

工程基础设施与工具链

• 日志库 + tracing 工具（基于 moonbitlang/async）；
• 构建工具，类似 n2 / ninja；
• 模板渲染器；
• Stopwatch / benchmark 小工具；

系统能力与运行时框架

• Deterministic simulation 框架；
• 编译器底层基础设施，例如寄存器分配；
• 面向特定格式的（反）序列化工具，类似 protobuf；
• 基于 moonbitlang/async 做的并发框架，比如 actor 框架；

应用生态

• Markdown to HTML 工具；
• 简易图表数据生成和预览；
• 流行游戏引擎的 MoonBit 绑定；
• 流行数据库的 MoonBit 绑定；

---

附录二：项目申报书样本

moon_elk 项目申报书

基本信息

• 项目名称：Moon ELK：Eclipse Layout Kernel 的 MoonBit 移植
• 参赛者：布丁大魔王
• 联系方式：1234567890
• GitHub 仓库链接：https://github.com/moonbit-community/moon_elk.git
• 项目方向：MoonBit 图布局基础库 / 可视化基础设施
• 是否为移植项目：是

项目简介

Moon ELK 计划将 Eclipse Layout Kernel（ELK）的核心图布局能力移植到 MoonBit 生态，为流程图、数据流图、状态机、建模工具、IDE 插件、低代码编辑器和可视化分析工具提供可复用的自动布局引擎。项目面向需要在 MoonBit 中构建或处理图结构的库作者、工具开发者和应用开发者，提供 ElkGraph 数据模型、JSON 导入导出、布局选项解析、布局算法调度以及多种常用布局算法的 MoonBit 实现。

核心功能范围

• 提供 ElkGraph 风格的图模型，支持节点、边、端口、标签、层级节点和布局属性；
• 支持 ELK JSON 格式的导入、导出和 pretty print，便于与前端渲染器或现有 ELK 工具链交换数据；
• 提供统一布局入口 new_elk_engine().layout(...)，支持按 elk.algorithm 分发算法；
• 支持 Layered、Force、Stress、Radial、MrTree、RectPacking、Spore、Fixed、Box、Random、Vertiflex 等布局能力；
• 支持基础布局选项解析，包括方向、间距、端口约束、节点尺寸、边路由和算法特定配置；
• 提供算法元数据、服务注册、布局校验和调试辅助模块；
• 提供 Graph Text / ELK Text 相关解析和转换能力的基础实现；
• 提供与 elkjs / ELK 参考实现对照的差异测试、随机用例和迁移记录；
• 提供不少于 300 个 MoonBit 测试文件，并持续保持核心回归测试通过；
• 提供 README 示例，覆盖 JSON 布局、图模型构建、JSON 导入导出和算法选择。

移植或参考说明

• 原项目名称：Eclipse Layout Kernel（ELK）
• 原项目链接：https://github.com/eclipse-elk/elk
• 原项目许可证：Eclipse Public License 2.0
• 本项目许可证：Eclipse Public License 2.0

与原项目相比，本项目会做以下简化和重新设计：

• 使用 MoonBit 原生包结构、类型系统和测试方式组织代码，而不是复刻 Java 插件工程结构；
• 优先实现可在 MoonBit 中独立运行的核心布局能力，弱化 Eclipse UI、OSGi、SWT/JFace 等桌面插件依赖；
• 对 Graphviz、libavoid、disco、topdownpacking 等当前暂不完整支持的算法保留兼容入口和错误行为，作为后续扩展范围；
• 对 Java 异常、集合类型、继承层级和服务发现机制进行 MoonBit 化改写；
• 以 JSON 输入输出和 MoonBit API 为主要交付接口，方便接入 Web、CLI、IDE 和可视化渲染场景。

---

补充知识库

这里存放 MoonBit国产开源生态大赛 OSC 2026 的运营类 FAQ 和章程未覆盖的补充信息。正式规则优先参考章程；章程没有写清楚的实用问题，可以在这里用 Q/A 形式补充。

Q: 为什么我提交申报后没有收到邮件？

A: 提交申报后，一个工作日（24 小时）内会收到来自 no-reply@moonbitlang.com 的邮件。如果没有收到，请先检查自己的邮箱是否是 Gmail、Yahoo 等国外邮箱，相关邮件可能无法正常送达或进入垃圾邮件。如果还有疑问，请在“CCF开源大赛-MoonBit赛题交流群”咨询，或联系“MoonBit小助手”。

Q: 什么时候发放启动资金？

A: 申报成功后会周期性发放 150 元启动资金，具体时间等待赛题交流群通知。

Q: 我应该如何提升项目质量？我这个项目能获奖吗？

A: 是否获奖无法提前保证，最终取决于项目完成度、工程质量、文档体验、生态价值、展示效果以及实际参赛项目整体水平。建议优先把项目做成“真实可用、边界清晰、可复现、可维护”的 MoonBit 生态项目：

• README 清楚说明项目目标、安装方式、使用方法和示例；
• 至少提供一个可以直接运行的最小示例；
• 使用 moon check / moon test 保持项目可检查、可测试；
• 测试覆盖核心功能路径；
• 仓库有清晰、连续、有意义的提交记录；
• 根目录提供 OSI 认可的开源许可证；
• 如果参考或移植其他开源项目，明确写出原项目名称、链接、许可证和参考范围；
• 可以安装并使用 `mattpocock/skills` 辅助项目规划、任务拆分、测试驱动开发、代码审查和文档打磨；
• 可以安装并使用 `moonbitlang/skills` 获得更贴近 MoonBit 语言、工具链、包结构和测试实践的开发辅助；
• 尽量补充 CI、发布准备和 mooncakes.io 发布说明。

如果目标是冲击优秀项目，除了完成基础功能，还应突出项目对 MoonBit 生态的实际价值、接口设计质量、文档完整度、长期维护潜力和展示效果。

Q: Gitlink 仓库和 Github 仓库要怎样同步？

A: 优先参考 Gitlink 官方指南：导入 GitHub 等第三方 Git 项目。推荐做法是先在 GitHub 准备好参赛项目仓库，然后在 Gitlink 首页选择“导入项目”，填写 GitHub 仓库地址和项目信息完成导入。

如果 GitHub 仓库是私有仓库，需要按指南准备对应平台的 token 授权；公开仓库通常不需要额外授权。导入完成后，请确认 Gitlink 仓库能看到主要代码、README、许可证、提交历史和后续更新。

后续如果 GitHub 侧继续开发，建议定期把更新同步到 Gitlink。可以使用 Gitlink 的导入/同步能力；也可以在同一个本地仓库里配置 GitHub 和 Gitlink 两个 remote，然后分别 push：

git remote -v
git remote add github <GitHub 仓库地址>
git remote add gitlink <Gitlink 仓库地址>
git push github main
git push gitlink main

如果默认分支不是 main，请替换成自己的默认分支名。两边仓库的 owner 或组织名不一定要相同，但提交到问卷里的链接应指向同一个参赛项目。

同步后请特别确认 GitHub 和 Gitlink 页面显示的默认分支。提交历史、README、许可证和主要代码最好都出现在远程仓库的默认分支上；如果主要开发内容只在非默认分支，容易造成他人检查时看不到最新工作。不要只看本地当前分支，也不要默认远程分支一定叫 main 或 master。

Q: 报名问卷在哪里？

A: 可以通过飞书问卷提交申报信息和项目材料：MoonBit国产开源生态大赛报名问卷。

Q: 还没有飞书账号怎么办？怎么填问卷？

A: 如果问卷或相关文档需要登录飞书，请先按页面提示注册或登录飞书账号。通常可以使用手机号或邮箱完成注册。登录后再打开报名问卷或申报材料链接填写信息。

如果因为账号、权限或页面访问问题无法填写，请在“CCF开源大赛-MoonBit赛题交流群”咨询，或联系“MoonBit小助手”。不要使用他人的账号代填涉及个人信息、联系方式或收款信息的内容。

Q: 有哪些值得推荐的项目方向？

A: 可以优先选择“边界清楚、能在比赛周期内完成、对 MoonBit 生态有复用价值”的方向。章程中的推荐方向包括：

• 基础数据结构与算法：例如 indexmap、bitmask、图算法、寻路算法、经过 moon prove 验证的通用算法库；
• 工程基础设施与工具链：例如日志库、tracing 工具、构建工具、模板渲染器、benchmark / stopwatch 工具；
• 系统能力与运行时框架：例如 deterministic simulation 框架、寄存器分配等编译器基础设施、protobuf 类序列化工具、基于 async 的 actor 框架；
• 应用生态：例如 Markdown to HTML 工具、图表数据生成和预览、游戏引擎绑定、数据库绑定。

选择项目时建议避免过大、过泛或只停留在包装层的题目。更好的方向通常是：有明确用户、能展示最小可用功能、能写出测试和示例，并且能说明相比已有项目的新增价值。

确定方向前，建议先在 mooncakes.io 上搜索相关关键词，确认是否已经有功能高度重叠的 MoonBit 包。如果已有类似项目，可以考虑换一个方向，或明确说明自己的新增价值、差异化设计和适用场景。或者你把想做的题目告诉我，我来帮你确认是否合理？

Q: 有没有 MoonBit 项目的参考案例？

A: 章程附录二提供了 moon_elk 项目申报书样本，可以参考它如何说明项目目标、适用场景、核心功能范围、移植来源、许可证和重新设计范围。

准备自己的项目时，也可以参考 mooncakes.io 下载量靠前的项目，以及成熟 MoonBit 包或社区项目的组织方式。例如 `moonbit-community/toml-parser` 这类项目，可以用来观察一个可复用库如何组织源码、文档、示例和测试。

参考时重点看：

• README 是否能让用户快速理解和运行项目；
• moon.mod / moon.pkg 等项目文件是否清晰；
• 示例是否能直接运行；
• 测试是否覆盖核心行为；
• 许可证和第三方来源说明是否完整；
• API 是否有稳定、可复用的边界。

不要直接复制参考项目的申报书或代码结构；应结合自己的项目目标说明独立贡献。