Ren bootstrap

Skill HubertBiyo/ren-flow/plugins/ren-flow/skills/ren-bootstrap

ren = 人 (human). Human-in-the-loop Vibe Coding workflow for Claude Code — 16 skills orchestrating the software lifecycle: intent → spec → code → verify → knowledge.

Install

npx -y skills add HubertBiyo/ren-flow --skill ren-bootstrap

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

新应用 / 新服务冷启动 —— 从 .ren-flow/templates/ 拉脚手架、建可编译可部署的仓库骨架(src + CI + 部署配置),并接上已沉淀的踩坑清单。触发：用户说「新建一个服务 / 应用」「搭个新 repo 骨架」「初始化 xxx 服务」「立项新应用」「从零起一个仓库」。

SKILL.md

4.7 KB, as published. Nobody here has run it

ren-bootstrap

启动必读

先 Read .ren-flow/attention.md。工作区模式：确认本次新应用归哪个业务域（或要不要新立域），新代码落点 repo 路径要先和用户对齐。

这个技能干什么

把一个全新仓库 / 服务从零带到「可编译、能起、能部署」的骨架状态。它管的是实际应用代码骨架（src/、CI、部署配置 —— Dockerfile / K8s / Serverless 等，按团队部署形态），不是 ren-flow 元数据目录。

与 ren-init 的边界（别混）：

	ren-bootstrap	ren-init
产出	新 repo 的应用代码骨架 + CI / 部署配置	`.ren-flow/` 工作流元数据目录
何时	立项一个新服务 / 新前端	给已有代码接入 ren-flow 流程
关系	先 bootstrap 搭骨架 → 再 init 接工作流 → 再 spec 开第一个功能	—

核心纪律：先查沉淀,再动手

新应用立项是高复用场景 —— 同类脚手架、同类踩坑大概率有人做过。开工前必须按序查：

Glob .ren-flow/templates/** —— 有没有现成脚手架（cicd/、app-skeleton/{lang}/、k8s/）。找到 → 复制改占位符;没有 → 从零搭,用完回填到 templates/ 供下次复用。
Glob .ren-flow/**/notes/ + Grep 关键词 —— 同类立项清单（如某份 new-service-checklist.md 记了新服务上线的容器平台 / 配置中心 / Ingress / 网关 / 权限菜单等步骤）。
查已有约定（memory / CLAUDE.md / 团队规范文档）—— 框架版本坑（如某框架升大版本后启动路由注册方式变了、默认端口变了、依赖注册写法变了）、命名 / 数据规范。

不查就照抄旧仓库是头号事故源 —— 旧版本模板抄到新版本仓库常直接崩。

流程

1. 对齐要建什么

确认：语言 / 框架、服务类型（API 服务 / 管理后台 / 消息消费者 / 定时任务 / 前端）、落点 repo 路径、配置中心标识 / 命名空间（若团队用配置中心）、归属业务域。拿不准的逐项问，别假设跟某个旧仓库一样。

2. 查沉淀（上面三步，强制）

把找到的模板、清单、踩坑列给用户，说明本次复用哪些、从零搭哪些。

3. 搭骨架

按项目惯例 + 召回的约定建最小可跑骨架：

目录分层（按你框架 / 团队的标准结构，见项目 attention.md）
入口项目能编译、健康检查端点能过（注意有些框架要显式注册路由 / 中间件才生效）
CI + Dockerfile + 部署配置（按团队部署形态），优先抄同框架版本的正确范本（别抄到跨大版本的旧范本）
配置占位（配置文件 / 配置中心），敏感值留占位符不写死
接入集中日志 / 可观测性时：按项目 notes 的新服务清单关联公共观测配置、并把 ServiceName 类字段覆盖成本应用标识（具体公共配置名 / 字段随环境，见项目层清单）

4. 自证可起

至少跑通构建（如 dotnet build / npm run build / go build，按栈）；能本地起则起一下确认健康检查端点。不留 TODO 空壳充数 —— 骨架要真能跑，不是摆样子。

5. 回填 + 交棒

本次从零搭的可复用部分（CI 配置 / 骨架）→ 回填 .ren-flow/templates/，下次直接复用
提示后续：ren-init 接工作流 → ren-spec 开第一个功能
立项中踩的新坑 / 定的新约定 → ren-note

退出条件

已查过 templates/ + notes 立项清单 + 已有约定（memory / CLAUDE.md），复用 / 从零的边界说清
骨架可编译（贴构建输出），关键探针 / 路由不是 404 空壳
CI / 部署配置抄的是同框架版本的正确范本
敏感配置留占位符，未写死凭证
可复用产物已回填 templates/；已提示接 ren-init / ren-spec

容易踩的坑

不查 templates / 清单 / memory 就照抄旧仓库 —— 版本差导致探针 404 / CrashLoop / 编译报错
骨架留一堆 TODO 空实现就说「搭好了」—— 必须真能编译能起
把 ren-bootstrap 和 ren-init 混为一谈 —— 一个搭应用代码，一个接工作流
敏感配置直接写死进 yaml / appsettings
从零搭完不回填 templates/ —— 下次又得重来一遍