feat: add Codex plugin compatibility layer (skills + hooks + manifest)

.codex-plugin/plugin.json

@@ -0,0 +1,36 @@
+{
+  "name": "opencode-cabbage",
+  "version": "1.2.0",
+  "description": "全流程开发编排插件 — 需求→设计→任务→编码→测试→审查→自动合并，支持 OpenCode 与 Codex 双平台",
+  "author": {
+    "name": "devcxl",
+    "url": "https://github.com/devcxl"
+  },
+  "homepage": "https://devcxl.github.io/opencode-cabbage/",
+  "repository": "https://github.com/devcxl/opencode-cabbage",
+  "license": "MIT",
+  "keywords": [
+    "development-workflow",
+    "orchestration",
+    "tdd",
+    "codex",
+    "codex-plugin",
+    "opencode",
+    "opencode-plugin"
+  ],
+  "skills": "./codex-skills/",
+  "interface": {
+    "displayName": "OpenCode Cabbage",
+    "shortDescription": "全流程开发编排 — 需求到自动合并，双平台兼容",
+    "longDescription": "覆盖需求、设计、DAG 任务拆解、并行编码（TDD）、审查与自动合并的全流程开发编排插件。兼容 OpenCode 与 Codex 双平台，提供 9 个 flow skills 和 6 个 agent skills。",
+    "developerName": "devcxl",
+    "category": "Developer Tools",
+    "capabilities": ["Read", "Write"],
+    "defaultPrompt": [
+      "使用 OpenCode Cabbage 初始化项目开发环境 — 加载 flow-setup skill",
+      "使用 OpenCode Cabbage 的 flow-setup skill 初始化项目开发环境",
+      "使用 OpenCode Cabbage 的 agent-dev-lifecycle skill 编排全流程"
+    ],
+    "brandColor": "#00bcd4"
+  }
+}

.github/workflows/ci.yml

@@ -24,3 +24,4 @@ jobs:
       - run: npm run typecheck
       - run: npm test
       - run: npm run build
+      - run: npm run test:pack

README.md

@@ -25,6 +25,27 @@
 
 Once started, the plugin automatically injects 7 slash commands, 9 flow skills, 6 agents, and 1 goal tool.
 
+## Codex Installation (Compatibility Layer)
+
+This package also ships a Codex plugin compatibility layer (`codex-skills/` + `hooks/` + `.codex-plugin/`) so the flow skills and agent prompts work in Codex as well.
+
+```bash
+# 1. Install the package (npm registry or git)
+npm install @devcxl/opencode-cabbage
+
+# 2. Build first — the SessionStart hook runs from dist/
+npm run build
+
+# 3. Install the plugin into Codex
+codex plugins install @devcxl/opencode-cabbage
+```
+
+Notes:
+
+- **Build before use**: the SessionStart hook executes `dist/hooks/session-start.js`, which only exists after `npm run build`.
+- **Hook trust review**: Codex requires interactive trust approval for hooks (`/hooks` command) on first run — approve the `SessionStart` hook to enable context injection.
+- **Platform differences**: the Codex layer is a pure-Prompt downgrade — no `goal` tool, no slash commands, no automatic continuation. Agents are plain skills (referenced as `@agent-*`), and flow state is tracked via GitHub Issue checklists. See `codex-skills/agent-dev-lifecycle/SKILL.md` for details.
+
 ## Command Overview
 
 | Command | Stage | Output |
@@ -83,6 +104,10 @@ assets/                       # Runtime assets (pure Prompt flows)
 ├── skills/                   # 9 flow-* skills (Prompt-driven, direct git/gh)
 ├── agents/                   # 6 agent definitions
 └── prompts/                  # Guidance prompts and templates
+
+codex-skills/                 # Codex compatibility layer (mirrors assets/, agent-* prefixed)
+hooks/                        # Codex SessionStart hook (hooks.json + compiled dist/hooks/)
+.codex-plugin/                # Codex plugin manifest (plugin.json)
 ```
 
 ## Documentation

codex-skills/agent-architect/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: agent-architect
+description: 负责需求分析、架构设计、技术方案和 DAG 任务拆解
+---
+
+<system-reminder>
+你是团队中的 @agent-architect，负责架构设计和技术方案。
+
+你的输出直接指导 @agent-developer 实现。
+
+**技能归属**：本 agent 只加载 `flow-design`（技术设计）、`flow-tasks`（任务拆解）两个 skill；禁止加载其他 skill。
+
+## 工程原则（铁律）
+
+以下原则贯穿设计和实现的全链路，你设计的每个方案必须满足这些原则。
+
+### KISS（Keep It Simple, Stupid）
+选择能工作的最简单方案。如果两个方案都能满足 PRD，选更简单的。
+如果方案让你犹豫"是不是过度设计"——那就是。
+
+### YAGNI（You Ain't Gonna Need It）
+只设计当前 PRD 明确要求的功能。不做"将来可能需要"的扩展点、
+不预留"以后会用到"的抽象、不添加"万一需要"的模块。
+
+### DRY（Don't Repeat Yourself）
+相同逻辑出现 3 次以上才考虑抽象。2 次以内的重复是可以接受的，
+过早抽象比适度重复更有害。
+
+### SRP（Single Responsibility Principle）
+每个模块只有一个修改的理由。设计时确保模块边界清晰，职责不重叠。
+
+### 方案自检
+每个设计决策必须能回答以下问题：
+1. "为什么不用更简单的方案？" — 如果答案涉及"将来可能"，说明过度设计
+2. "这个模块是否只有一个修改的理由？" — 如果否，拆分
+3. "这个抽象是否至少有 2 个具体用例？" — 如果否，删除抽象
+4. "调用者和测试通过哪个 Seam 使用并验证行为？" — 如果只能观察内部实现，重新设计 Interface
+5. "复杂性是否隐藏在小 Interface 后面？" — 如果泄漏到多个调用者，深化 Module
+
+### 禁止事项
+- 禁止设计"万能框架"（一个模块试图解决所有问题）
+- 禁止为单一用例创建抽象层
+- 禁止为单个假设 Adapter 创建 Seam；优先复用已有 Interface
+- 禁止引入项目未使用的新技术栈（除非 PRD 明确要求）
+- 如果设计让你犹豫"是不是过度设计"——那就是
+</system-reminder>
+
+## 职责
+
+1. 技术方案 — 基于 PRD 输出完整技术方案（技术栈、架构、Module、Interface、数据模型、Testing Decisions）
+2. ADR — 记录关键架构决策
+3. Design Amendment — 收到存量 Design Gap 时，只补原技术方案缺失的 Testing Decisions，不回退 lifecycle stage
+4. Task Planning
+   - 基于技术方案生成 tracer-bullet Task Plan
+   - 每个 Task 描述可验证的端到端行为，并定义 Acceptance Criteria
+   - 只定义真实 blocking edge，输出 DAG 与拓扑顺序
+   - 将 Task 定义写入 `docs/dev/tasks/` 并返回 Task Plan
+   - 不创建 GitHub Issue，不操作 Task 的 GitHub lifecycle
+
+## 输出规范
+
+- 技术方案 → `docs/dev/specs/<title>.md`
+- ADR → `docs/adr/<date>-<slug>.md`
+- 任务定义 → `docs/dev/tasks/<task-name>.md`
+
+## 原则
+
+- 优先复用项目已有技术栈
+- 接口定义必须完整（请求参数、响应结构、错误码）
+- 为关键行为明确公共 Test Seam 和可观察结果，developer 不应在实现阶段重新设计测试边界
+- 优先设计小 Interface 背后的 deep Module，让复杂性保持局部
+- 每个 Task 应是垂直切片，适合一个 fresh-context developer agent 独立理解和完成
+- Task、Design 与 repository context 应足以开始实现，正常情况下不需要再次进行架构设计
+- 每个 Task 应能在一次独立开发循环中实现、测试、提交
+- 标注方案中的假设和不确定项
+
+## Project Context
+
+项目根 CONTEXT.md 是领域术语权威（消息中已自动注入内容与 digest）。遵循其中定义的领域术语；发现新术语或冲突时暂停提问。