super-engineer-workflow 0.1.0

package/docs//351/241/271/347/233/256/346/236/266/346/236/204/344/270/216/350/256/276/350/256/241/350/257/264/346/230/216.md

@@ -0,0 +1,657 @@
+# super-engineer 项目架构与设计说明
+
+本文面向首次接触 `super-engineer` 的开发者，说明项目当前阶段、核心思想、架构分层和后续演进方向。
+
+## 1. 项目当前阶段
+
+`super-engineer` 当前处于“可用工作流内核 + Skill 分发”的阶段。
+
+它已经具备：
+
+- 可安装为 Codex / Claude skill 的工作流本体
+- 基于 `workspace.yml` 的工作空间配置
+- `todo` 与 `openspec` 两种输入模式
+- `manual` 与 `auto` 两种执行模式
+- `/se:*` 专属命令协议
+- 会话级运行状态与产物归档
+- 代码定位、计划生成、自查、审查、验证报告
+- OpenSpec change 创建前置准备、`tasks.md -> todo.md` 桥接、执行摘要回写、归档检查、安全归档
+- Java、Node.js / Vue / React、Go、Python、Rust、.NET、PHP、Ruby、Make / CMake 等主流项目识别与验证命令推断
+- `workspace.yml.verify_commands` 自定义验证命令覆盖
+- PushPlus / 飞书通知
+
+它暂时不是完整的平台产品，也不是一个独立的 Web 应用。当前的定位更接近“AI 工程交付操作系统的本地内核”：用户通过 AI 输入 `/se:*` 阶段命令，AI 按 skill 规则调用本项目脚本，脚本负责稳定地产出状态、报告和门禁证据。
+
+当前边界也需要明确：
+
+- 代码实现动作仍由 AI 根据 `plan.json` 和代码上下文完成，不是由 Python 脚本自动改业务代码。
+- OpenSpec 已接入到 change 生命周期，但还不是完全替代 OpenSpec 官方 CLI 的产品。
+- `/se:*` 是发给 AI 的协议，不是 shell 命令，也不是 OpenSpec 官方命令。
+- 脚本主要负责流程编排、状态管理、报告生成、验证执行和 OpenSpec 桥接。
+- 当前已提供 `/se:*` 的脚本路由入口，AI 收到命令后应优先通过统一入口解析并推进，不应自行组合状态文件。
+
+## 2. 项目要解决的问题
+
+普通 AI 编码容易出现几个问题：
+
+- 需求、计划、实现、验证都停留在聊天上下文里，后续无法追踪。
+- AI 直接写代码，缺少计划基线、审查门禁和验证闭环。
+- 存量系统、多服务、多仓库场景下，AI 容易改错服务或扩大修改范围。
+- 需求迭代完成后，缺少长期规格归档，下一次迭代不能复用前面的知识。
+
+`super-engineer` 的核心目标是把一次需求迭代拆成稳定阶段，并把关键事实落到文件系统：
+
+```text
+需求输入
+-> 规格阶段
+-> 交付计划
+-> 代码实现
+-> 实现自查
+-> 代码审查
+-> 自动化验证
+-> 规格回写与归档
+```
+
+这样做的结果是：
+
+- AI 可以持续推进，而不是每一步重新理解。
+- 人可以审核关键门禁，而不是只看最终代码。
+- 团队可以复盘每次交付的计划、风险、验证结果。
+- OpenSpec 模式下，需求迭代可以沉淀到长期规格。
+
+## 3. 核心设计思想
+
+### 3.1 Skill 是交互层，脚本是执行层
+
+`SKILL.md` 和 `references/` 定义 AI 应该如何理解用户意图，尤其是 `/se:*` 命令。
+
+`scripts/` 提供可重复调用的本地执行能力，例如初始化、生成计划、生成审查报告、执行验证、回写 OpenSpec。
+
+这种分层的好处是：
+
+- 用户只需要和 AI 对话，不需要直接执行底层脚本。
+- AI 的行为有明确协议，不完全依赖临场发挥。
+- 脚本产物稳定，方便调试、复盘和团队共享。
+- 状态机、通知、OpenSpec 回写、归档检查等关键证据由脚本生成，降低 AI 手工越过流程的概率。
+
+### 3.2 工作空间是唯一上下文入口
+
+每个实际需求迭代都从一个工作空间开始。工作空间根目录必须有：
+
+```text
+workspace.yml
+```
+
+`workspace.yml` 负责声明：
+
+- 当前模式：`todo` 或 `openspec`
+- 执行方式：`manual` 或 `auto`
+- 需求文件：`demand_file`
+- 执行入口：`todo_file`
+- 参考资料：`reference_files`
+- 代码根目录：`code_path`
+- 输出目录：`output_dir`
+- OpenSpec change 目录：`openspec.change_dir`
+
+路径支持相对路径和绝对路径。相对路径以当前工作空间根目录为基准。
+
+### 3.3 todo 是交付入口，OpenSpec 是规格入口
+
+项目支持两种输入来源：
+
+- `workflow_source=todo`：用户直接维护 `todo.md`，AI 基于 todo 进入交付。
+- `workflow_source=openspec`：先生成或完善 OpenSpec change，再把 `tasks.md` 桥接为 `todo.md`，审核通过后进入交付。
+
+两者的关键区别：
+
+- `todo.md` 面向“本轮要做什么”，是交付入口。
+- OpenSpec change 面向“需求为什么变、规格怎么变”，是长期规格入口。
+
+在 OpenSpec 模式下，`todo.md` 是桥接产物，不是规格源头。
+
+### 3.4 每次运行都是一次可追踪会话
+
+每次生成计划都会创建新的 `session_id`。运行产物分为两类。
+
+机器可读产物：
+
+```text
+<workspace>/.super-engineer/current-session.json
+<workspace>/.super-engineer/sessions/<session_id>/discovery.json
+<workspace>/.super-engineer/sessions/<session_id>/plan.json
+<workspace>/.super-engineer/sessions/<session_id>/self-check.json
+<workspace>/.super-engineer/sessions/<session_id>/review.json
+<workspace>/.super-engineer/sessions/<session_id>/verify.json
+<workspace>/.super-engineer/sessions/<session_id>/status.json
+```
+
+人可读报告：
+
+```text
+<output_dir>/<session_id>/discovery.md
+<output_dir>/<session_id>/plan.md
+<output_dir>/<session_id>/self-check.md
+<output_dir>/<session_id>/review.md
+<output_dir>/<session_id>/verify.md
+```
+
+这个设计保证聊天上下文丢失后，AI 仍然能通过文件恢复当前阶段。
+
+## 4. 目录结构
+
+```text
+super-engineer/
+├── README.md
+├── LICENSE
+├── docs/
+│   ├── 中文使用手册.md
+│   ├── se命令协议.md
+│   └── 项目架构与设计说明.md
+└── super-engineer-workflow/
+    ├── SKILL.md
+    ├── agents/
+    ├── adapters/
+    ├── assets/
+    ├── references/
+    └── scripts/
+```
+
+### 4.1 `super-engineer-workflow/SKILL.md`
+
+Skill 入口文件，定义：
+
+- skill 的适用场景
+- `/se:*` 命令处理规则
+- 工作流强约束
+- 输入模式和执行模式
+- 必走阶段
+- 资源导航
+
+AI 使用这个 skill 时，首先读取 `SKILL.md`，再按需读取 `references/` 和调用 `scripts/`。
+
+### 4.2 `references/`
+
+`references/` 是 AI 行为协议和工程规则库：
+
+- `se-commands.md`：`/se:*` 专属命令协议
+- `workflow.md`：工作空间配置、运行目录、会话规则、阻塞规则
+- `contracts.md`：关键产物、可靠性边界、归档前置条件
+- `execution-modes.md`：`manual` 与 `auto` 行为差异
+- `planning.md`：计划质量要求
+- `project-docs.md`：参考资料使用规则
+- `java.md`：Java 项目识别和验证建议
+- `review-checklist.md`：审查规则
+- `verify-checklist.md`：验证规则
+- `platform-openclaw.md`：后续平台化接入约束
+
+### 4.3 `adapters/`
+
+`adapters/` 是多语言项目识别与默认验证命令的适配层。
+
+当前内置：
+
+- `java-maven.yml`
+- `java-gradle.yml`
+- `node-react.yml`
+- `node-vue.yml`
+- `go.yml`
+- `python.yml`
+
+每个 adapter 描述：
+
+- 识别文件
+- 语言
+- 构建工具
+- 默认测试命令
+- 默认启动命令
+- 默认验证命令
+- review profile
+
+`workspace.yml.verify_commands` 仍然拥有最高优先级，可覆盖 adapter 或内置识别结果。
+
+这些文件不是给终端直接执行的，而是给 AI 读取后约束行为的。
+
+### 4.4 `assets/`
+
+`assets/` 存放配置示例和结构化 schema：
+
+- `workspace.example.yml`
+- `config.example.yml`
+- `config-schema.json`
+- `plan-schema.json`
+- `status-schema.json`
+
+这些文件的作用是稳定输入输出结构，降低不同 AI 模型理解差异。
+
+### 4.5 `scripts/`
+
+`scripts/` 是本项目的本地 runtime。统一入口是：
+
+```text
+scripts/run-workflow.py
+```
+
+主要脚本职责：
+
+- `init-workspace.py`：校验工作空间，创建运行目录，必要时创建 todo 模板和 skill 配置。
+- `propose-openspec.py`：为 OpenSpec propose 阶段准备输入，优先调用 OpenSpec CLI。
+- `bootstrap-openspec.py`：把 OpenSpec `tasks.md` 桥接成 `todo_file`。
+- `generate-discovery.py`：根据 todo 关键词定位代码证据。
+- `generate-smart-plan.py`：生成结构化计划和计划报告。
+- `update-status.py`：更新当前会话状态。
+- `generate-self-check.py`：生成实现自查。
+- `generate-review-report.py`：基于 Git diff 和计划生成审查报告。
+- `run-verify-and-report.py`：执行验证命令并生成验证报告。
+- `writeback-openspec.py`：把计划、审查、验证摘要回写到 OpenSpec change。
+- `prepare-archive-openspec.py`：检查归档条件和 spec 冲突。
+- `archive-openspec.py`：安全归档 OpenSpec change，并合并 delta specs。
+- `common.py`：共享工具层，包括配置解析、路径解析、会话管理、todo 解析、项目识别、通知等。
+
+## 5. 工作流架构
+
+### 5.1 todo 模式
+
+```text
+workspace.yml
+-> todo.md
+-> init
+-> discover
+-> plan
+-> implement
+-> self-check
+-> review
+-> verify
+```
+
+适合：
+
+- 需求较小
+- 不需要长期规格沉淀
+- 团队先希望用 AI 规范交付流程
+
+### 5.2 OpenSpec 模式
+
+```text
+demand_file
+-> /se:propose <change-name>
+-> OpenSpec change
+-> tasks.md
+-> /se:bridge
+-> todo.md
+-> plan / apply
+-> review
+-> verify
+-> writeback
+-> archive-check
+-> archive
+```
+
+适合：
+
+- 存量系统长期迭代
+- 多服务、多仓库协作
+- 需求变更需要团队共享和追踪
+- 希望把验收结果沉淀回规格体系
+
+### 5.3 manual 与 auto
+
+`manual` 模式：
+
+- 计划后停
+- 实现后停
+- 审查后停
+- 更适合早期引入、风险较高或需要人工强审核的需求
+
+`auto` 模式：
+
+- 除硬阻塞外连续推进
+- 自动进入自查、审查和验证
+- 更适合规则已经稳定、测试命令明确的仓库
+
+硬阻塞包括：
+
+- 配置缺失或不合法
+- 无法定位目标仓库
+- 多服务目标不明确
+- 验证失败到必须人工介入
+- review 出现阻塞级问题
+- 需求和代码现实严重冲突
+
+## 6. OpenSpec 集成方式
+
+当前项目采用“轻量桥接 + 局部 native”的方式接入 OpenSpec。
+
+已经做到：
+
+- `/se:propose <change-name>` 阶段优先调用 OpenSpec CLI 创建指定 change。
+- 读取 OpenSpec CLI status 和 artifact instructions。
+- 从 `demand_file` 准备 propose 输入。
+- 从 OpenSpec `tasks.md` 桥接生成 `todo.md`。
+- review / verify 后生成 `execution-summary.json` 和 `execution-summary.md`。
+- archive-check 阶段检查验收、review、verify、spec 冲突。
+- archive 阶段只允许在 `safe_merge` 条件下归档。
+
+OpenSpec change 名称必须显式指定，例如：
+
+```text
+/se:propose demand-addition-rate
+```
+
+工作流不会从 `vars.demand_name`、需求文件名或需求标题推导 change 名称。这样能避免 AI 把“需求目录名”“业务标题”和“OpenSpec change 名称”混在一起。
+
+## 7. 数据流
+
+### 7.1 配置加载
+
+```text
+workspace.yml
+-> common.load_workspace_config
+-> 变量展开
+-> 相对路径解析
+-> 读取当前 active OpenSpec change
+-> 合并 ~/.super-engineer/skill-config.yml
+```
+
+### 7.2 计划生成
+
+```text
+todo.md
++ reference_files
++ code_path
++ discovery.json
+-> plan.json
+-> plan.md
+-> status.json
+```
+
+### 7.3 审查与验证
+
+```text
+plan.json
++ Git diff
+-> review.json
+-> review.md
+
+plan.json
++ 项目识别出的验证命令
+-> verify.json
+-> verify.md
+-> status.json
+-> notification
+```
+
+验证命令会优先使用 `workspace.yml.verify_commands` 的显式配置。未配置时，工作流根据项目文件自动推断主流技术栈的验证命令，例如 Maven、Gradle、npm、pnpm、yarn、Go、pytest、Cargo、dotnet、Composer、Bundler、Make 等。无法识别可靠命令时，verify 阶段应进入 blocked。
+
+### 7.4 OpenSpec 回写与归档
+
+```text
+plan.json
++ review.json
++ verify.json
++ bridge context
+-> execution-summary.json
+-> archive-input.json
+-> archive-result.json
+```
+
+## 8. 关键设计取舍
+
+### 8.1 为什么不让用户直接跑脚本
+
+脚本是执行层，不是用户界面。用户直接跑脚本会暴露过多内部细节，也容易绕过阶段门禁。
+
+项目推荐用户通过 `/se:*` 与 AI 交互，由 AI 根据 skill 协议调用脚本。这样可以保留自然语言协作体验，同时让底层执行稳定可追踪。
+
+### 8.2 为什么保留 todo 模式
+
+OpenSpec 适合长期规格治理，但不是所有需求都值得先建 change。
+
+`todo` 模式提供低成本入口：
+
+- 配置简单
+- 学习成本低
+- 适合小需求或早期试点
+
+OpenSpec 模式则用于更正式、更长期、更需要协作追踪的需求。
+
+### 8.3 为什么 OpenSpec 前面还有桥接 todo
+
+OpenSpec 的 `tasks.md` 面向规格交付任务，不一定直接适合作为 AI 实现输入。
+
+桥接 `todo.md` 的作用是：
+
+- 把规格任务转换成交付任务
+- 汇总实现约束
+- 给人工审核一个明确入口
+- 复用原有 todo 驱动的计划、审查、验证能力
+
+这是一种低侵入集成方式，避免一次性把整个 workflow 改成强 OpenSpec-native。
+
+### 8.4 为什么要有 JSON 和 Markdown 双产物
+
+JSON 给 AI 和脚本读取，Markdown 给人看。
+
+这能同时满足：
+
+- 自动推进
+- 人工审核
+- 团队复盘
+- 后续平台化展示
+
+## 9. 开发者如何理解一次完整运行
+
+以 OpenSpec + auto 为例：
+
+1. 用户把原始需求写入 `demand_file`。
+2. 用户发 `/se:propose <change-name>`。
+3. AI 通过 `run-workflow.py route-se --command-text "/se:propose <change-name>"` 准备 OpenSpec 输入，并生成或完善 `proposal.md`、`design.md`、`tasks.md`。
+4. 用户发 `/se:bridge`。
+5. AI 通过 `run-workflow.py route-se --command-text "/se:bridge"` 把 `tasks.md` 转成 `todo.md`。
+6. 用户审核 `todo.md` 后发 `/se:apply`。
+7. AI 调用 `run-workflow.py plan`，生成 session、discovery、plan。
+8. AI 根据 `plan.json` 修改业务代码。
+9. AI 调用 `finish-implement` 生成 self-check。
+10. AI 调用 `review` 生成 review 门禁。
+11. AI 调用 `verify` 执行验证命令。
+12. OpenSpec 模式下自动回写 execution summary。
+14. 用户或 AI 执行 archive-check，满足 safe_merge 后 archive。
+
+## 10. 当前适用性判断
+
+当前项目适合：
+
+- 已经存在多年、结构复杂的业务中台系统
+- 多服务、多仓库交付
+- 需要规范 AI 编码行为的团队
+- 希望从“AI 帮忙写代码”升级到“AI 按工程流程交付”
+- 希望逐步引入 OpenSpec，而不是一次性重构研发流程
+
+当前不适合：
+
+- 追求完全无人值守的大规模自动改代码
+- 没有测试命令、没有基本工程结构的项目
+- 需求本身极度模糊且没有人工审核环节的场景
+- 期望它直接替代项目管理系统或完整 DevOps 平台
+
+## 11. 相比单一 OpenSpec 的优缺点
+
+这里的“单一 OpenSpec”指团队主要围绕 OpenSpec change、spec、tasks、archive 来管理需求变更，但不额外引入 `super-engineer` 的计划、审查、验证和会话产物。
+
+### 11.1 优点
+
+相比只使用 OpenSpec，`super-engineer + OpenSpec` 混合工作流的优势主要在交付阶段。
+
+第一，交付过程更可控。OpenSpec 更擅长描述“规格如何变化”，但不会天然约束 AI 在代码实现阶段如何做计划、自查、审查和验证。`super-engineer` 在 `tasks.md` 后增加 `todo.md` 桥接、`plan.json`、`review.json`、`verify.json`，让交付阶段有明确门禁。
+
+第二，更适合复杂存量系统。供应链中台、多服务、多仓库项目里，需求往往不只是改一个 spec，还要定位服务、确认调用链、识别测试入口、判断计划外改动。`super-engineer` 的 `discover -> plan -> review -> verify` 对这类场景更直接。
+
+第三，更适合 AI 编码协作。OpenSpec 主要管理需求和规格，`super-engineer` 进一步约束 AI 怎么读配置、怎么找代码、怎么记录状态、什么时候停止、什么时候自动推进。
+
+第四，有更完整的本地交付记录。每次运行都会产生 session 目录，包含计划、审查、验证和状态。即使聊天上下文丢失，也能从文件恢复。
+
+第五，支持渐进落地。团队可以先用 `todo` 模式规范 AI 交付，再逐步切到 `openspec` 模式，不需要一开始就把所有需求治理都迁移到 OpenSpec。
+
+### 11.2 缺点
+
+混合工作流也会带来额外成本。
+
+第一，流程更长。OpenSpec change 之后还要 bridge 成 `todo.md`，并审核 todo 后再进入实现。对很小的需求来说，这可能偏重。
+
+第二，概念更多。开发者需要理解 `workspace.yml`、`demand_file`、`todo_file`、session、OpenSpec change、archive-check 等概念。
+
+第三，维护面更大。除了 OpenSpec 文件，还要维护 skill、脚本、配置、运行产物和团队约定。
+
+第四，AI 仍然是执行主体。当前项目不是全自动代码生成引擎，业务代码实现仍依赖 AI 按计划修改。因此团队仍需要 review、verify 和人工判断。
+
+第五，OpenSpec-native 程度还在演进。当前是“轻量桥接 + 局部 native”，不是完全替代 OpenSpec 官方流程。
+
+### 11.3 怎么选择
+
+如果团队只是想管理规格变更，并且代码实现主要由人完成，单一 OpenSpec 更轻。
+
+如果团队希望 AI 参与真实编码交付，并且项目是存量系统、多服务、多仓库、需要审查和验证门禁，那么混合工作流更适合。
+
+可以按这个判断：
+
+```text
+只管规格治理：OpenSpec
+规格治理 + AI 交付闭环：super-engineer + OpenSpec
+只想快速让 AI 按 todo 写代码：super-engineer todo 模式
+```
+
+## 12. 新手快速入门
+
+新手不要一开始理解所有脚本。先按“一个工作空间、一份配置、一组 `/se:*` 提示词”来用。
+
+### 12.1 先理解三个文件
+
+最少只需要理解：
+
+```text
+workspace.yml
+需求.md
+todo.md
+```
+
+它们的关系是：
+
+```text
+需求.md      原始需求，给 OpenSpec propose 用
+todo.md      本轮交付任务，给 AI 实现用
+workspace.yml 告诉 AI 上面两个文件在哪里、代码在哪里、结果写哪里
+```
+
+### 12.2 如果先用 todo 模式
+
+适合第一次试用，流程最短。
+
+准备 `workspace.yml`：
+
+```yaml
+version: 1
+mode: auto
+workflow_source: todo
+todo_file: todo.md
+reference_files: []
+code_path: ../code
+output_dir: output
+```
+
+准备 `todo.md`：
+
+```md
+# 限制条件
+- 修改的服务是 user-service
+
+# 待办事项
+
+## 用户查询
+- [ ] 用户列表接口增加手机号精确筛选
+1. 兼容旧查询行为
+2. 补齐 controller 和 service 层测试
+```
+
+然后给 AI 发：
+
+```text
+/se:apply
+使用当前工作空间。
+当前模式是 todo + auto。
+如果没有硬阻塞，自动推进到计划、实现、自查、审查和验证。
+```
+
+### 12.3 如果使用 OpenSpec 模式
+
+适合正式需求迭代。
+
+准备 `workspace.yml`：
+
+```yaml
+version: 1
+mode: auto
+workflow_source: openspec
+vars:
+  demand_name: 7-add-phone-filter
+demand_file: superengineer/${demand_name}/需求.md
+todo_file: superengineer/${demand_name}/todo.md
+reference_files: []
+code_path: ../code
+output_dir: superengineer/${demand_name}/output
+openspec:
+  changes_dir: openspec/changes
+```
+
+准备需求文件：
+
+```text
+superengineer/7-add-phone-filter/需求.md
+```
+
+然后按顺序给 AI 发：
+
+```text
+/se:propose add-phone-filter
+请根据当前 workspace 的 demand_file 生成或完善 OpenSpec change。
+先不要改代码。
+```
+
+```text
+/se:bridge
+针对当前 OpenSpec change 生成交付阶段的桥接 todo，并总结待审核项。
+```
+
+人工审核 `todo.md` 后发：
+
+```text
+/se:apply
+我已审核当前桥接 todo，可以进入交付阶段。
+使用当前工作空间，当前模式是 openspec + auto。
+如果没有硬阻塞，自动推进到 verify；verify 通过后继续检查归档条件。
+```
+
+### 12.4 新手应该先看哪些文档
+
+建议阅读顺序：
+
+1. [README.md](/Users/muke/Documents/personal/codex/super-engineer/README.md)
+2. [docs/中文使用手册.md](/Users/muke/Documents/personal/codex/super-engineer/docs/中文使用手册.md)
+3. [docs/se命令协议.md](/Users/muke/Documents/personal/codex/super-engineer/docs/se命令协议.md)
+4. [super-engineer-workflow/references/workflow.md](/Users/muke/Documents/personal/codex/super-engineer/super-engineer-workflow/references/workflow.md)
+
+不建议新手一开始直接研究 `scripts/`。先跑通一次完整需求，再看脚本实现会更清楚。
+
+## 13. 后续演进方向
+
+建议后续按以下方向推进：
+
+1. 增强 OpenSpec-native 能力：让 propose、apply、archive 的状态和 OpenSpec artifact 更深度绑定。
+2. 增强桥接 todo 审核追踪：记录审核人、todo hash 和审核时间，但不新增用户命令。
+3. 增强多仓库支持：更明确地记录每个服务的计划、diff、review、verify。
+4. 增强验证策略：支持项目级 verify profile，避免只靠自动识别。
+5. 增强 schema 校验：对 `workspace.yml`、`plan.json`、`status.json`、OpenSpec 回写产物执行更严格校验。
+6. 增强平台化接入：把 JSON 产物作为后端数据源，提供可视化运行状态、报告和归档记录。
+7. 增强模型兼容性：把命令协议、阶段门禁和脚本输出进一步结构化，降低不同 AI 模型理解差异。
+
+## 14. 一句话总结
+
+`super-engineer` 的核心不是“再写一个 AI 编码提示词”，而是把 AI 编码变成一个可配置、可追踪、可审查、可验证、可归档的工程工作流。

package/package.json

@@ -0,0 +1,55 @@
+{
+  "name": "super-engineer-workflow",
+  "version": "0.1.0",
+  "description": "Super Engineer workflow skill and CLI for legacy-system AI delivery with OpenSpec bridge support.",
+  "license": "MIT",
+  "author": "Gary-Coding",
+  "homepage": "https://github.com/Gary-Coding/super-engineer#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Gary-Coding/super-engineer.git"
+  },
+  "bugs": {
+    "url": "https://github.com/Gary-Coding/super-engineer/issues"
+  },
+  "engines": {
+    "node": ">=18",
+    "npm": ">=9"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "bin": {
+    "super-engineer": "bin/super-engineer.js",
+    "se": "bin/super-engineer.js"
+  },
+  "files": [
+    "bin/",
+    "scripts/",
+    "!scripts/__pycache__/",
+    "!scripts/**/*.pyc",
+    "super-engineer-workflow/",
+    "!super-engineer-workflow/scripts/__pycache__/",
+    "!super-engineer-workflow/scripts/**/*.pyc",
+    "docs/",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md",
+    "CONTRIBUTING.md",
+    "SECURITY.md"
+  ],
+  "scripts": {
+    "setup": "python3 scripts/se-setup.py",
+    "check": "python3 -m py_compile scripts/se-cli.py scripts/se-setup.py scripts/se-smoke-test.py super-engineer-workflow/scripts/*.py",
+    "smoke": "python3 scripts/se-smoke-test.py",
+    "pack:check": "npm pack --dry-run"
+  },
+  "keywords": [
+    "ai",
+    "workflow",
+    "openspec",
+    "codex",
+    "claude",
+    "skill"
+  ]
+}