@liangjie559567/ultrapower 5.0.4

package/skills/ax-suspend/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: ax-suspend
+description: "/ax-suspend — Axiom 暂停保存工作流：保存当前状态快照，安全退出会话"
+triggers: ["ax-suspend", "suspend", "暂停任务", "保存退出", "save and exit"]
+---
+
+# Axiom 暂停保存工作流
+
+本工作流在退出会话前保存完整的工作状态，确保下次会话可以无缝恢复。
+
+**开始时宣告：** "I'm using the ax-suspend skill to save session state before exiting."
+
+## 执行步骤
+
+### Step 1: 收集当前状态
+
+读取所有状态文件：
+- `.omc/axiom/active_context.md` — 任务进度
+- `.omc/state/axiom-context.json` — 状态机状态
+- `.omc/axiom/evolution/learning_queue.md` — 待处理队列
+
+### Step 2: 创建检查点
+
+调用 axiom-context-manager：
+```
+Task(subagent_type="ultrapower:axiom-context-manager", model="sonnet", prompt="create_checkpoint")
+```
+
+### Step 3: 更新 active_context
+
+将当前进行中的任务标记为 PENDING（而非 BLOCKED），记录暂停原因。
+
+更新 `active_context.md` 的 `suspension_note` 字段：
+```markdown
+## 暂停记录
+- 暂停时间: YYYY-MM-DD HH:MM
+- 暂停原因: [用户主动暂停]
+- 当前任务: T-xxx
+- 下次恢复提示: [恢复时需要注意的事项]
+```
+
+### Step 4: 处理学习队列（可选）
+
+若学习队列有 P0/P1 优先级素材，询问用户：
+"检测到 X 条高优先级学习素材。是否在退出前处理？(Yes/No)"
+
+### Step 5: 确认保存
+
+输出保存摘要：
+```
+✓ 状态已保存
+✓ 检查点已创建: checkpoint-xxx
+✓ 当前任务: T-xxx (PENDING)
+✓ 下次会话将自动恢复
+
+下次启动时运行 /ax-status 查看状态。
+```

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: brainstorming
+description: "在任何创意工作之前必须使用此 skill —— 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。"
+---
+
+# 将想法转化为设计
+
+## 概述
+
+通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。
+
+首先了解当前项目上下文，然后逐一提问以细化想法。一旦理解了要构建的内容，呈现设计并获得用户批准。
+
+<HARD-GATE>
+在呈现设计并获得用户批准之前，不得调用任何实现 skill、编写任何代码、搭建任何项目或采取任何实现行动。这适用于每个项目，无论其表面上多么简单。
+</HARD-GATE>
+
+## 反模式："这太简单了，不需要设计"
+
+每个项目都要经历这个过程。待办事项列表、单函数工具、配置变更 —— 全部如此。"简单"项目恰恰是未经审视的假设造成最多浪费工作的地方。设计可以很短（对于真正简单的项目只需几句话），但必须呈现并获得批准。
+
+## 强制前置：代码库探索
+
+<HARD-GATE>
+在开始任何设计对话之前，必须先完成代码库探索。不允许跳过此步骤。
+</HARD-GATE>
+
+### 触发时立即执行
+
+1. 调用 `notepad_read` 检查是否已有 `codebase_summary`
+   - 若已有：直接使用，不重复调用 explore
+   - 若无：调用 `explore` agent（model: haiku）扫描代码库
+
+2. explore 扫描内容：项目结构、相关文件、近期5个 commit、现有约定
+
+3. 将探索结果写入 notepad（`notepad_write_working`，key: codebase_summary）
+
+4. 探索完成后，才进入"理解想法"阶段
+
+### 探索完成标准
+- [ ] 已识别与任务相关的主要文件（≥3个）
+- [ ] 已了解现有架构模式
+- [ ] 已检查近期相关提交
+
+## 检查清单
+
+必须为以下每个项目创建任务并按顺序完成：
+
+1. **探索项目上下文** —— 检查文件、文档、最近的提交
+2. **提出澄清问题** —— 每次一个，了解目的/约束/成功标准
+3. **提出 2-3 种方案** —— 附带权衡分析和推荐意见
+4. **呈现设计** —— 按复杂度分节呈现，每节后获得用户批准
+5. **编写设计文档** —— 保存到 `docs/plans/YYYY-MM-DD-<topic>-design.md` 并提交
+6. **过渡到实现** —— 调用 writing-plans skill 创建实现计划
+
+## 流程图
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Invoke writing-plans skill";
+}
+```
+
+**终止状态是调用 writing-plans。** 不得调用 frontend-design、mcp-builder 或任何其他实现 skill。头脑风暴后唯一调用的 skill 是 writing-plans。
+
+## 流程
+
+**理解想法：**
+- 首先了解当前项目状态（文件、文档、最近提交）
+- 逐一提问以细化想法
+- 尽可能使用多选题，开放式问题也可以
+- 每条消息只问一个问题 —— 若某个话题需要更多探索，拆分为多个问题
+- 专注于理解：目的、约束、成功标准
+
+**探索方案：**
+- 提出 2-3 种不同方案及其权衡分析
+- 以对话方式呈现选项，附上推荐意见和理由
+- 以推荐选项开头并解释原因
+
+**呈现设计：**
+- 一旦理解了要构建的内容，呈现设计
+- 根据复杂度调整每节篇幅：简单的几句话，复杂的最多 200-300 字
+- 每节后询问是否看起来正确
+- 涵盖：架构、组件、数据流、错误处理、测试
+- 准备好在某些内容不清晰时回头澄清
+
+## 设计完成后
+
+**文档：**
+- 将验证后的设计写入 `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- 如果可用，使用 elements-of-style:writing-clearly-and-concisely skill
+- 将设计文档提交到 git
+
+**实现：**
+- 调用 writing-plans skill 创建详细实现计划
+- 不得调用任何其他 skill。writing-plans 是下一步。
+
+## 核心原则
+
+- **每次一个问题** —— 不要用多个问题压倒用户
+- **优先多选题** —— 比开放式问题更容易回答
+- **彻底 YAGNI** —— 从所有设计中删除不必要的功能
+- **探索替代方案** —— 在确定方案前始终提出 2-3 种方法
+- **增量验证** —— 呈现设计，在继续前获得批准
+- **保持灵活** —— 当某些内容不清晰时回头澄清
+
+## 路由触发（设计批准后）
+
+设计文档提交到 git 后，调用 `next-step-router`：
+- current_skill: "brainstorming"
+- stage: "design_approved"
+- output_summary: 设计涉及的文件数、模块数、是否有架构/安全/性能变更
+- full_context: { doc_paths: [设计文档路径], key_decisions: [...], codebase_summary: [...] }
+
+## Axiom PRD 起草流程（增强）
+
+当需要生成结构化 PRD 时，执行以下步骤：
+
+1. **需求澄清循环**
+   - 对用户输入运行需求分析
+   - 若置信度 < 90%：向用户询问澄清问题，等待回复后重复
+   - 若置信度 > 90%：进入下一步
+
+2. **生成 PRD 初稿**
+   - 使用通过验证的需求上下文生成 PRD
+   - 输出到 `docs/prd/[name]-draft.md`
+
+3. **用户评审门禁**
+   - 向用户展示 PRD 初稿路径
+   - 询问："PRD 初稿已就绪。是否进入专家评审阶段？"
+   - 是 → 触发 5 专家并行评审（ux_director、product_director、domain_expert、tech_lead、critic）
+   - 否 → 停止

package/skills/build-fix/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: build-fix
+description: Fix build and TypeScript errors with minimal changes
+---
+
+# 构建修复 Skill
+
+快速修复构建和编译错误，代码改动最小化。在不重构的情况下让构建变绿。
+
+## 使用时机
+
+此 skill 在以下情况激活：
+- 用户说 "fix the build"、"build is broken"
+- TypeScript 编译失败
+- 构建命令或类型检查器报告错误
+- 用户请求对错误进行 "minimal fixes"
+
+## 功能
+
+委托给 `build-fixer` agent（Sonnet 模型）执行：
+
+1. **收集错误**
+   - 运行项目的类型检查命令（如 `tsc --noEmit`、`mypy`、`cargo check`、`go vet`）
+   - 或运行项目构建命令获取构建失败信息
+   - 按类型和严重程度分类错误
+
+2. **策略性修复**
+   - 在缺失处添加类型注解
+   - 在需要处添加 null 检查
+   - 修复 import/export 语句
+   - 解决模块解析问题
+   - 修复阻塞构建的 linter 错误
+
+3. **最小差异策略**
+   - 不重构无关代码
+   - 不进行架构变更
+   - 不进行性能优化
+   - 仅做让构建通过所必需的修改
+
+4. **验证**
+   - 每次修复后运行项目类型检查命令
+   - 确保未引入新错误
+   - 构建通过后停止
+
+## Agent 委托
+
+```
+Task(
+  subagent_type="ultrapower:build-fixer",
+  model="sonnet",
+  prompt="BUILD FIX TASK
+
+Fix all build and TypeScript errors with minimal changes.
+
+Requirements:
+- Run tsc/build to collect errors
+- Fix errors one at a time
+- Verify each fix doesn't introduce new errors
+- NO refactoring, NO architectural changes
+- Stop when build passes
+
+Output: Build error resolution report with:
+- List of errors fixed
+- Lines changed per fix
+- Final build status"
+)
+```
+
+## 停止条件
+
+build-fixer agent 在以下情况停止：
+- 类型检查命令以退出码 0 退出
+- 构建命令成功完成
+- 未引入新错误
+
+## 输出格式
+
+```
+BUILD FIX REPORT
+================
+
+Errors Fixed: 12
+Files Modified: 8
+Lines Changed: 47
+
+Fixes Applied:
+1. src/utils/validation.ts:15 - Added return type annotation
+2. src/components/Header.tsx:42 - Added null check for props.user
+3. src/api/client.ts:89 - Fixed import path for axios
+...
+
+Final Build Status: ✓ PASSING
+Verification: [type check command] (exit code 0)
+```
+
+## 最佳实践
+
+- **每次一个修复** —— 更易于验证和调试
+- **最小改动** —— 修复时不重构
+- **记录原因** —— 对不明显的修复添加注释
+- **之后测试** —— 确保测试仍然通过
+
+## 与其他 Skill 配合使用
+
+与其他 skill 组合进行全面修复：
+
+**与 Ultrawork 配合：**
+```
+/ultrawork fix all build errors
+```
+为不同文件并行生成多个 build-fixer agent。
+
+**与 Ralph 配合：**
+```
+/ralph fix the build
+```
+持续尝试直到构建通过，即使需要多次迭代。
+
+**与 Pipeline 配合：**
+```
+/pipeline debug "build is failing"
+```
+使用：explore → architect → build-fixer 工作流。