conejo

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Conejo — the coding philosophy

Conejo — 编码理念

Conejo is how we build. It is small on purpose: it states the non-negotiables and routes you to the focused skill for the task at hand.
Conejo是我们的开发准则。它刻意保持简洁:明确了不可妥协的原则,并引导你根据手头任务选择对应的专项指南。

Non-negotiables

不可妥协的原则

  1. Red-green TDD, always — backend and frontend alike. Write the failing test, watch it fail for the right reason, write the minimum to pass, refactor under green. No implementation before a failing test. See [[test-driven-development]].
  2. Test always. No exceptions. If you cannot write a test, you do not yet understand the problem.
  3. Stacked PRs. Branch over branch; PR often; each PR over its predecessor.
  4. Brainstorm before building anything non-trivial. See [[brainstorming]].
  5. Debug systematically, never by guessing. See [[systematic-debugging]].
  6. Evidence before claims. Never say "done/fixed/passing" without running the verification and showing output. See [[verification-before-completion]].
  1. 始终采用红绿TDD,前后端均适用。 编写失败的测试,确认其因正确原因失败,编写最少代码使其通过,在测试通过的前提下重构。未编写失败测试前,不得进行实现。详见[[test-driven-development]]。
  2. 始终测试,无一例外。 如果你无法编写测试,说明你尚未理解问题。
  3. 堆叠式PR(Stacked PRs)。 基于分支创建分支;频繁提交PR;每个PR基于其前置PR。
  4. 构建任何非琐碎功能前先进行头脑风暴。 详见[[brainstorming]]。
  5. 系统化调试,绝不凭猜测。 详见[[systematic-debugging]]。
  6. 先证后述。 未运行验证并展示输出前,绝不说“完成/修复/通过”。详见[[verification-before-completion]]。

Dispatch

任务调度

You are…Use
Writing/changing code (logic, services, APIs, libraries, CLIs)[[conejo-code]]
Building or changing any web UI[[conejo-frontend]] (strict; it includes the conejo-code base)
Reviewing, interrogating, implementing, or merging PRs[[conejo-merge]]
The testing doctrine is authored once in
conejo-code/references/testing-doctrine.md
; conejo-frontend adds the UI superset. Read the doctrine before writing any test.
你正在…使用
编写/修改代码(逻辑、服务、API、库、CLI)[[conejo-code]]
构建或修改任何Web UI[[conejo-frontend]](严格规范;包含conejo-code的基础要求)
评审、研讨、实施或合并PR[[conejo-merge]]
测试准则统一编写在
conejo-code/references/testing-doctrine.md
中;conejo-frontend在此基础上添加了UI相关的扩展内容。编写任何测试前,请先阅读该准则。

Example

示例

  • Brainstorm (Specs) → run "opencode run $PROMPT --model zai-coding-plan/glm-5.1 --dangerously-skip-permissions --dir path/to/this/dir" to review your specs → Plan "opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/this/dir" to review your plan (glm-5.1 is smarter but slow, deepseek is a bit faster) → Interface → "opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/a/clone/of/this/dir" to create tests failing tests → "opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/a/clone/of/this/dir" to Implement → Improve tests → Code review → (loop).
  • Full stage notes:
    references/feature-stages.md
    . UI stages (design/UIUX-review) and any visual work are owned by [[conejo-frontend]].
  • Attention! Don't be afraid of sending several agents: split the tasks as much as possible.
  • PR over PR ALWAYS. Push. After it is at Github, clean their mess.
  • PRESERVE your context no matter what! Send these other agents first, so we can have different perspectives, but if you need to do the work, send your agents. Don't pollute your context.
  • 头脑风暴(规格)→ 运行“opencode run $PROMPT --model zai-coding-plan/glm-5.1 --dangerously-skip-permissions --dir path/to/this/dir”来评审你的规格 → 规划阶段运行“opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/this/dir”来评审你的计划(glm-5.1更智能但速度慢,deepseek速度稍快)→ 界面设计 → 运行“opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/a/clone/of/this/dir”创建测试失败的测试→ 运行“opencode run $PROMPT --model deepseek/deepseek-v4-pro --dangerously-skip-permissions --dir path/to/a/clone/of/this/dir”进行实现 → 优化测试 → 代码评审 → (循环)。
  • 完整阶段说明:
    references/feature-stages.md
    。UI阶段(设计/UIUX评审)及所有视觉相关工作由[[conejo-frontend]]负责。
  • 注意!不要害怕调用多个Agent:尽可能拆分任务。
  • 始终采用PR堆叠。推送代码。代码上传至Github后,清理冗余内容。
  • 无论如何都要保留你的上下文!先调用这些其他Agent,以便获取不同视角,但如果你需要亲自处理工作,再调用你的专属Agent。不要混淆你的上下文。