核心用法
Backstage 是一个元工作流技能，设计用于任何软件项目的开发生命周期管理。它通过标准化的触发词（"backstage start"/"backstage end"）激活两种工作模式：
- Start 模式：工作会话开始时运行，执行分支检测、变更分析、健康检查、文档自动更新和开发者上下文生成
- End 模式：工作会话结束时运行，执行软失败健康检查、成就总结、身体状态检查，并安全关闭 VS Code
关键机制是README 的 🤖 导航区块作为唯一真相源——技能首先读取此区块以定位 ROADMAP、CHANGELOG、HEALTH、POLICY 四个状态文件，而非依赖硬编码路径。这种设计实现了真正的去中心化治理（polycentric governance）：全局规则与项目规则并存，冲突时项目规则优先。
显著优点
1. 零配置迁移：新项目的唯一要求是在 README 中添加 区块，无需修改技能代码
2. 强制文档同步：健康检查不通过则阻断提交，从根本上防止"代码领先文档"的技术债务
3. 多语言友好：触发词包含葡萄牙语（"vamos trabalhar""boa noite"），体现国际化设计
4. 开发者福祉设计：End 模式的身体检查（Hungry? Thirsty? Tired?）将心理健康纳入工作流
5. 状态机清晰：五种明确状态（Failed/Mismatch/Grooming/Progress/Complete）消除歧义
潜在缺点与局限性
- 草稿状态：当前为 v1.0.0 draft，Mermaid 流程图过于复杂，存在简化空间
- 脚本依赖：设计假定存在
backstage-start.sh/backstage-end.sh，但实际部署状态不明 - IDE 锁定：VS Code 关闭逻辑使用 macOS 专属的
osascript，跨平台兼容性存疑 - 沉默协议风险：End 模式要求"STAY SILENT"以防止未保存提示，但用户可能误以为是系统故障
适合人群
- 独立开发者管理多个项目，需要标准化的项目切换仪式
- 小型团队寻求轻量级项目管理替代 Jira/Linear
- 开源项目维护者希望强制 CHANGELOG 规范
- 注意力易分散的开发者，需要结构化的开始/结束边界
常规风险
- 硬失败阻断：Start 模式下健康检查硬失败可能打断心流，建议配置合理的检查粒度
- 文档膨胀：自动更新可能导致 ROADMAP/CHANGELOG 体积增长，需定期归档
- 分支检测误判：依赖分支命名规范（如
v0.4.0识别为 epic 分支），非标准命名会触发 groom 模式