需要搭建仓库、工具链、CI、发布或项目模板时…

用户请求仓库设置、工具基础设施或完整项目模板时，推断范围并配置格式化、lint、类型检查、CI、分发和贡献者文件。

适用场景

解决思路

1. 将 Jess 的默认配置应用到用户请求的仓库设置；仅当用户明确请求完整模板或相应门禁时，才使用完整模板。
2. 把应用或小原型请求视为不自动等于请求完整模板，除非用户明确请求完整模板。
3. 除非迁移是请求的一部分，否则保留已建立的工具链。
4. 从任务推断语言、产物类型和请求的设置；区分最小可运行项目与面向分发的仓库。
5. 在实现前说明关键基础设施选择。
6. 仅当缺失信息会改变用户自己拥有的决策时才提问。
7. 最小设置：提供源码布局、依赖清单，以及运行和验证项目所需命令。
8. 仓库工具：提供格式化器、linter、类型/构建检查和 CI。
9. 分发：提供发布自动化，以及与产品相称的面向贡献者的文件。
10. 完整 Jess 模板：包括仓库工具、适用的分发文件，以及 agent-rule 和 review 基础设施；仅在请求完整模板或这些门禁时使用。
11. Rust：格式化用 rustfmt，lint 用 clippy，类型/构建检查用 cargo build / cargo test。
12. Go：格式化用 gofmt / goimports，lint 用 staticcheck + go vet，类型/构建检查用 go build / go test。
13. TypeScript：格式化用 oxfmt，lint 用 oxlint，类型检查用 tsc --noEmit。
14. Python：格式化用 ruff format，lint 用 ruff check，类型检查用 mypy 或 pyright。
15. 每种语言只使用一个格式化器和一个 lint 配置。
16. 在支持的地方从严格类型检查开始。
17. 保持边界解析可行：不要全局禁止未知输入类型、运行时收窄或合法的 React effects。
18. 需要时使用 code-craft 获取语言特定指导。
19. 在 CI 和本地开发共享的同一个 recipe 中定义检查套件。
20. 如果请求 hooks，使用同一个 recipe 或范围化的快速子集。
21. 不要为了重复 CI 而在每次提交时运行慢速全量检查。
22. 当请求 agent-rule 强制或 AI review 时，把每条规则放在能忠实表达它的最低层。
23. 优先使用编译器和 linter 检查，而不是新建 agent-rule 系统。
24. 不要在多个层重复同一个门禁。
25. 对于需要强制执行的 agent 特定规则，尽可能使用结构化匹配，并提供独立于 agent 编辑的 CI 检查。
26. 对于 AI review 门禁，保持 reviewer 定义可审查，并通过仓库的 ownership 规则保护它们。
27. 必需门禁在评估失败时不得静默通过。
28. 对于面向二进制分发的 CLI，优先使用 tag 触发的发布，并为支持的平台提供带校验和的归档。
29. 从 tag 派生版本。
30. 仅在请求或分发计划需要时包含安装器；安装器安装前必须校验校验和。
31. 让支持的平台和包注册表与目标用户绑定。
32. 不要为未发布原型构建平台矩阵。
33. 对于面向公开分发的仓库，包含 license、贡献说明和私密安全报告路径。
34. 当请求完整模板或其特定目的时，添加行为准则、issue 模板、依赖更新和发布工作流。
35. Jess 的新许可证选择是 AGPL-3.0-or-later 或 Apache-2.0；为新项目授权时除非用户已选择，否则询问使用哪一个。
36. 使用 AGPL 时，Jess 的文档默认是 CC-BY-SA-4.0，记录在 NOTICE 中。
37. 保留现有许可证和第三方声明。
38. 运行生成的设置和必需检查。
39. 确认 CI 调用维护的检查 recipe。
40. 报告配置了什么，以及任何未验证的平台或外部服务。
41. 未经授权，不要发布、创建远程仓库或配置付费服务。

适用边界 · 注意事项

• 用户只要求写代码、做原型或加固，而不包含仓库设置时，不使用。
• 用户未请求完整 Jess 模板或相应门禁时，不要套用完整模板、agent 规则或 AI 审查基础设施。
• 除非迁移是请求的一部分，否则不要替换已有工具链。