helloagents 3.0.10-beta.1 → 3.0.10

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "helloagents",
-  "version": "3.0.10-beta.1",
+  "version": "3.0.10",
   "description": "Quality-driven orchestration kernel for AI CLIs",
   "contextFileName": "bootstrap.md",
   "author": "HelloWind",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "helloagents",
-  "version": "3.0.10-beta.1",
+  "version": "3.0.10",
   "type": "module",
   "description": "HelloAGENTS — The orchestration kernel that makes any AI CLI smarter. Adds intelligent routing, quality verification (Ralph Loop), safety guards, and notifications.",
   "author": "HelloWind",
@@ -36,17 +36,7 @@
     ".claude-plugin/",
     ".codex-plugin/"
   ],
-  "keywords": [
-    "ai",
-    "agent",
-    "claude",
-    "codex",
-    "cli",
-    "orchestration",
-    "subagent",
-    "hooks",
-    "skills"
-  ],
+  "keywords": ["ai", "agent", "claude", "codex", "cli", "orchestration", "subagent", "hooks", "skills"],
   "engines": {
     "node": ">=18"
   }

package/skills/commands/build/SKILL.md

@@ -46,7 +46,7 @@ Trigger: ~build [description]
 ### 3. 执行实现
 
 - 根据任务拆解逐步修改
-- 读取 PLAN 阶段所需的 hello-* 技能并遵循其规范
+- 按当前实现需要读取对应的 hello-* 技能，并遵循其规范
 - 编码任务遵循：
   - 先补测试或最小验证手段，再写实现
   - 每次编辑后主动跑确定性检查

package/skills/commands/help/SKILL.md

@@ -32,7 +32,7 @@ Trigger: ~help
 
 ### 自动激活技能
 以下技能仅在全局模式或已激活项目中自动激活（例如执行过 `~wiki`、`~init`，或已处于项目级连续流程）。
-纯标准模式未激活项目不会自动触发这些深层技能；但涉及 UI 的任务仍受 UI 质量基线约束。
+纯标准模式未激活项目不会自动触发这些技能；但涉及 UI 的任务仍受 UI 质量基线约束。
 
 编码时：hello-ui, hello-api, hello-data, hello-security, hello-errors, hello-perf, hello-arch, hello-test
 特定场景：hello-debug, hello-subagent, hello-write, hello-review

package/skills/commands/loop/SKILL.md

@@ -35,51 +35,51 @@ iteration	commit	metric	delta	guard	status	description
 
 ## 八阶段循环
 
-`~loop` 的八阶段循环是统一执行流程（ROUTE/TIER→SPEC→PLAN→BUILD→VERIFY→CONSOLIDATE）在迭代优化场景下的特化形式。每轮迭代的 Modify 阶段遵循已标记的 hello-* 质量技能规范，Verify 阶段遵循 hello-verify 的验证规范。
+`~loop` 的八阶段循环是统一执行流程（ROUTE/TIER→SPEC→PLAN→BUILD→VERIFY→CONSOLIDATE）在迭代优化场景下的特化形式。每轮迭代的“修改”阶段遵循已标记的 hello-* 质量技能规范，“验证”阶段遵循 hello-verify 的验证规范。
 执行 `~loop` 时，涉及公共阶段边界、阻塞判定与收尾要求的部分，仍按当前已加载 bootstrap 执行；本 skill 负责补充 loop 场景的迭代顺序与回滚规则。
 
-不要停止。不要询问是否继续。
+除非达到迭代上限或命中阻塞判定，否则继续执行，不额外询问是否继续。
 每轮迭代必须完整走完以下八个阶段：
 
-### Phase 1: Review
+### 第 1 阶段：回顾
 - 读取 results log 最近 10-20 条记录
 - 运行 `git log --oneline -20` 查看最近变更
 - 运行 `git diff HEAD~1` 查看上一次变更
 - 如果 git log 有 results log 中未记录的 experiment commit → 上轮可能中断，先运行指标命令补录结果
 - 识别：什么有效、什么无效、什么还没试过
 
-### Phase 2: Ideate
+### 第 2 阶段：构思
 - 基于 review 结果，选择下一个改进方向
 - 优先尝试未探索的方向
 - 避免重复已失败的方向（git history 是记忆）
 - 连续 5 次 discard → 升级策略：组合近似成功的尝试、尝试相反方向、考虑架构级变更
 
-### Phase 3: Modify
+### 第 3 阶段：修改
 - 做一个原子修改（单一关注点）
 - 只修改作用范围内的文件
 - 不修改测试文件和守卫命令涉及的文件
 
-### Phase 4: Commit
+### 第 4 阶段：提交
 - 在验证之前提交（便于干净回滚）
 - commit message 格式：`experiment(<scope>): <description>`
 
-### Phase 5: Verify
+### 第 5 阶段：验证
 - 运行指标命令，获取新值
 - 计算 delta（新值 - 基线或上一次保留值）
 - 如有守卫命令，运行守卫检查
 
-### Phase 6: Decide
+### 第 6 阶段：决策
 - IMPROVED（指标改善 + 守卫通过）→ keep
 - SAME/WORSE（指标未改善）→ `git revert HEAD`（保留历史）
 - GUARD FAILED（指标改善但守卫失败）→ 尝试修复（最多 2 次），仍失败则 revert
 - CRASHED（命令执行失败）→ revert + 记录
 
-### Phase 7: Log
+### 第 7 阶段：记录
 - 追加一行到 results log
 - status: baseline / keep / discard / crash / no-op
 - 重写 `state_path`：保持主线目标=当前优化目标，并记录当前迭代轮次、最近一次决策（keep / discard / crash）、当前最佳指标、下一步动作
 
-### Phase 8: Repeat
+### 第 8 阶段：继续
 - 如果 iterations > 0 且 current_iteration >= max_iterations → 输出总结并停止
 - 否则 → 回到 Phase 1
 

package/skills/hello-ui/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: hello-ui
-description: 已进入显式 UI 工作流、已激活项目的视觉变更、设计系统改造或需要视觉验收时使用；在通用 UI 基线之上补充项目契约消费、设计系统映射与视觉验证。
+description: 已进入显式 UI 工作流、已激活项目的视觉变更、设计系统改造或需要视觉验收时使用；在通用 UI 基线之上补充项目契约执行、设计系统映射与视觉验证。
 ---
 
-本 skill 不是 UI 质量的唯一来源。当前已加载 bootstrap 中的 UI 质量基线负责所有 UI 任务的基础水准；本 skill 在显式 UI 工作流和深度 UI 任务中，补充更强的契约执行、实现映射与视觉验收。
+本 skill 不是 UI 质量的唯一来源。当前已加载 bootstrap 中的 UI 质量基线负责所有 UI 任务的基础水准；本 skill 在显式 UI 工作流和复杂 UI 任务中，补充更明确的契约执行、实现映射与视觉验收。
 `.helloagents/` 在本 skill 中统一按项目级存储路径理解：`.ralph-*.json` 等运行态证据保持项目本地；若 `project_store_mode=repo-shared`，`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
 
 ## 适用边界
@@ -17,24 +17,24 @@ description: 已进入显式 UI 工作流、已激活项目的视觉变更、设
 3. 本 skill 的通用规则
 缺少上层产物时，才直接依赖下层规则；不得用通用审美覆盖已确认的项目契约。
 
-## 深层职责
-- 消费上游契约：把 `plan.md` / PRD / `DESIGN.md` 中已确认的 UI 决策视为强约束，而不是建议
-- 消费可选 UI 契约：若 `contract.json` 启用 `ui.styleAdvisor`，复用 `.helloagents/.ralph-advisor.json` 留下设计方向复查证据；若启用 `ui.visualValidation`，用 `.helloagents/.ralph-visual.json` 留下视觉验收证据
+## 核心职责
+- 遵循上游契约：把 `plan.md` / PRD / `DESIGN.md` 中已确认的 UI 决策视为强约束，而不是建议
+- 处理可选 UI 契约：若 `contract.json` 启用 `ui.styleAdvisor`，复用 `.helloagents/.ralph-advisor.json` 记录设计方向复查证据；若启用 `ui.visualValidation`，用 `.helloagents/.ralph-visual.json` 记录视觉验收证据
 - 映射到代码结构：明确 token 放在哪里、组件边界如何划分、状态组件如何组织、动效与主题如何实现
 - 做视觉验收闭环：优先使用截图/浏览器工具做桌面与移动端检查；没有工具时也要完成结构化视觉自检
 - 回写稳定决策：只把跨 feature 稳定成立的设计系统规则同步回 `.helloagents/DESIGN.md`（按当前项目存储模式解析），不要把一次性页面细节全部写成项目级契约
 
-## 深层设计 brief（编码前必须落定）
+## 设计简报（编码前必须明确）
 
-理解上下文，做出大胆且有意图的设计决策：
+先理解上下文，再做出大胆且有意图的设计决策：
 
 1. 目的：这个界面解决什么问题？谁在用？什么场景？什么平台？
-2. 美学方向：选择一个鲜明的方向并坚持到底。不从固定列表中选，而是根据项目的受众、场景和情感目标，创造一个忠于上下文的独特风格。问自己：这个产品的用户期待什么情绪？什么视觉语言能传达这种情绪？
+2. 美学方向：选择一个鲜明的方向并坚持到底。不套用固定风格标签，而是根据项目的受众、场景和情感目标，创造一个忠于上下文的独特风格。先问清楚：这个产品的用户期待什么情绪？什么视觉语言能传达这种情绪？
 3. 记忆点：用户看到这个设计会记住的一个特征是什么？
 4. 差异化：当任务明确要求探索，或缺少现成设计约束时，主动避免滑入常见默认风格；差异化必须服务产品语义、品牌边界与可用性，不为变化而变化。
 5. 设计 token：尽早建立变量/token 体系——背景色/表面色/主色/弱化色/强调色 + 展示/标题/正文/说明文字的字体角色。Web 用 CSS 变量，桌面/移动端用平台对应的主题系统。
-6. 约束定义：为当前项目定义具体约束（如最多几个区块、几种字体、几个强调色、首屏的 CTA 数量），约束释放创意。
-7. 真实内容：使用真实文案、产品信息、项目上下文，不使用 Lorem ipsum 或泛化占位符。真实内容帮助做出更贴合上下文的设计决策。
+6. 约束定义：为当前项目定义具体约束（如最多几个区块、几种字体、几个强调色、首屏的 CTA 数量），用约束帮助释放创意。
+7. 真实内容：使用真实文案、产品信息、项目上下文，不使用 Lorem ipsum 或泛化占位符。真实内容更容易帮助做出更贴合上下文的设计决策。
 
 执行顺序要求：
 - 已激活项目且存在 `.helloagents/DESIGN.md`（按当前项目存储模式解析）时，进入真实 UI 任务先读取它，再展开方案或实现
@@ -56,7 +56,7 @@ description: 已进入显式 UI 工作流、已激活项目的视觉变更、设
 ### 展示型页面（着陆页、营销页、产品展示页）
 
 第一屏构图：
-- 第一屏必须是一个完整构图，品牌/产品名必须是英雄级信号
+- 第一屏必须是一个完整构图，品牌/产品名必须是最明显的识别点
 - 品牌测试：如果去掉导航栏后第一屏可以属于任何品牌，说明品牌感太弱
 
 Hero 区域：
@@ -182,7 +182,7 @@ Hero 区域：
 
 ## 复杂度匹配
 
-实现复杂度必须匹配美学愿景。大胆的设计需要丰富的代码，精致的设计需要克制和精确。优雅来自于执行愿景的质量，而非堆砌效果。根据上下文做出意外但合理的选择——展现真正的创造力。
+实现复杂度必须匹配设计目标。需要强表现力的界面，可以用更丰富的实现；需要克制的界面，就保持简洁和精确。不要为了效果堆效果，也不要为了求稳把设计做平，而是根据上下文做出意外但合理的选择——展现真正的创造力。
 
 ## 交付检查
 

package/skills/hello-verify/SKILL.md

@@ -11,7 +11,7 @@ description: 声称工作完成前、提交代码前、创建 PR 前、报告任
 没有运行验证命令 = 不能说"完成"、"通过"、"已修复"。
 没有看到验证输出 = 不能声称结果。
 
-## 验证循环（Ralph Loop）
+## 验证循环
 
 验证不是一次性操作，而是循环直到通过：
 
@@ -90,7 +90,7 @@ description: 声称工作完成前、提交代码前、创建 PR 前、报告任
 7. 若 `contract.json` 中 `ui.visualValidation.required=true`，额外确认 `.helloagents/.ralph-visual.json` 已存在、覆盖要求的关键 screens / states，且结论为 `PASS`；若没有视觉验收证据，不得把本轮视为 UI 可交付
 8. 发现遗漏 → 补充实现 → 重新验证
 
-## 反代理目标漂移 (APGD)
+## 目标偏移检查
 
 验证时必须区分真正目标和代理指标：
 - 真正目标：用户实际要解决的问题（功能正确、体验达标、需求满足）