Project Bootstrap 用于按 Jess 的默认规范，对用户请求的仓库进行初始化配置。它强调：请求一个应用或小型原型，本身并不等于请求完整模板；除非迁移是请求的一部分，否则应保留既有工具链。
用途
该技能适用于用户请求仓库搭建、工具链基础设施或 Jess 完整项目模板的场景。它会根据任务推断语言、产物类型和所需配置，并区分最小可运行项目与面向分发的仓库。对于影响较大的基础设施选择，应在实施前说明；只有当缺失信息会改变由用户拥有的决策时才提问。
范围选择
技能将配置范围分为几档：
- 最小配置：源码布局、依赖清单，以及运行和验证项目所需的命令。
- 仓库工具链：格式化器、Linter、类型/构建检查以及 CI。
- 分发：发布自动化，以及适合该产品的面向贡献者的文件。
- 完整 Jess 模板：仓库工具链、适用的分发文件，以及智能体规则和审查基础设施。仅在请求完整模板或这些门禁时使用。
工具链默认值
按语言提供默认工具：
- Rust：rustfmt、clippy、cargo build / cargo test。
- Go：gofmt / goimports、staticcheck + go vet、go build / go test。
- TypeScript：oxfmt、oxlint、tsc --noEmit。
- Python：ruff format、ruff check、mypy 或 pyright。
每种语言使用一个格式化器和一个 Lint 配置。在支持的情况下从严格类型检查开始。保持边界解析可行：不要全局禁止未知输入类型、运行时收窄或合法的 React effect。需要时使用 code-craft 获取语言特定指导。
对于新的 TypeScript 应用或完整模板，按 code-craft 的 proof ladder 设置项目将使用的技术栈：Effect 及其语言服务诊断纳入类型检查，边界使用 Effect Schema 或 Zod，命名工作流使用 xstate，gdp-ts 及其 lint 预设，Vitest 配合 @effect/vitest，Vercel Emulate 用于提供方测试，Postgres 遵循 database-craft。让 Linter 对 any、未检查的 as、非空断言 !、浮动 Promise 以及无理由的抑制报错。原型只获得其实际使用的内容。
对于新的 Rust 服务器，按 code-craft 的 Rust 参考设置服务器栈：tokio、axum、snafu、aerosol 和 sqlx，使用 [workspace.lints] deny 列表配合 disallowed_methods 和 disallowed_types，nextest 配合一个 tests/it 测试 crate，并在库和二进制目标上设置 test = false，CI 中运行 cargo sqlx prepare --check。
在一个配方中定义检查套件，由 CI 和本地开发共享。如果请求钩子，使用同一配方或一个范围更小的快速子集。不要仅仅为了重复 CI 而在每次提交时运行缓慢的全套检查。
智能体基础设施
当请求智能体规则强制执行或 AI 审查时，将每条规则放在能忠实表达它的最强层。优先使用编译器和 Linter 检查，而不是新建智能体规则系统。不要跨层重复同一门禁。
对于需要强制执行的智能体特定规则，尽可能使用结构化匹配，并提供独立于智能体编辑的 CI 检查。对于 AI 审查门禁，保持审查者定义可审查，并通过仓库自身的所有权规则保护它们。当评估失败时，必需门禁不得静默通过。
分发与项目文件
对于面向二进制分发的 CLI，优先使用标签触发的发布，并为支持的平台提供带校验和的归档。版本从标签派生。仅在请求或分发计划需要时包含安装器；安装器在安装前必须验证校验和。
将支持的平台和包注册表与目标用户绑定。不要为未发布的原型构建平台矩阵。
对于面向公开分发的仓库，包含许可证、贡献说明和私密安全报告路径。当请求完整模板或其特定目的时，添加行为准则、议题模板、依赖更新和发布工作流。
Jess 的新许可证选择为 AGPL-3.0-or-later 或 Apache-2.0。为新项目授权时，除非用户已选择，否则询问使用哪一个。使用 AGPL 时，Jess 的文档默认许可证为 CC-BY-SA-4.0，记录在 NOTICE 中。保留现有许可证和第三方声明。
验证与报告
运行生成的配置和所需检查。确认 CI 调用维护中的检查配方。报告配置了什么，以及任何未验证的平台或外部服务。未经授权，不要发布、创建远程仓库或配置付费服务。