@pzy560117/codex-harness 0.1.3 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/requirements-design-template/SKILL.md

@@ -67,10 +67,10 @@ description: 需求与设计文档模板
 | [指标2] | [目标值] | [如何衡量] |
 ```
 
-### 3. 用户与场景 (Users & Scenarios)
-
-```markdown
-## 用户与场景
+### 3. 用户与场景 (Users & Scenarios)
+
+```markdown
+## 用户与场景
 
 ### 目标用户
 | 用户角色 | 描述 | 核心诉求 | 优先级 |
@@ -95,40 +95,40 @@ journey
 ```
 
 ### 关键页面与原型
-| 页面/流程 | 原型链接 | 说明 |
-|-----------|----------|------|
-| [页面/流程] | [链接] | [说明] |
-```
-
-### 3.1 前端设计输入 (Frontend Design Inputs) ⚠️ UI 项目必填
-
-```markdown
-## 前端设计输入
-
-### 视觉与品牌参照
-| 项 | 内容 | 说明 |
-|----|------|------|
-| 产品类型 | [SaaS/CRM/电商/工具/内容/游戏等] | 决定信息密度与视觉调性 |
-| 目标气质 | [专业/高级/活泼/极简/工业/编辑感等] | 交给 `design-taste-frontend` 校准 |
-| 品牌参照 | [Apple/Stripe/Notion/Linear/Claude/无] | 有品牌参照时使用 `brand-design-md` 获取 DESIGN.md |
-| 反参照 | [明确不要像什么] | 避免默认 AI UI 或竞品误导 |
-
-### Skill 路由
-| 场景 | 必用 Skill | 输出 |
-|------|------------|------|
-| 需要完整 UI 设计 | `impeccable` + `design-taste-frontend` | 设计方向、布局原则、token 候选 |
-| 需要大厂风格 | `brand-design-md` | 项目根或临时上下文中的 DESIGN.md |
-| 需要 UI 工程规范 | `baseline-ui` | 组件、状态、响应式、Tailwind 约束 |
-| 需要图标 | `better-icons` | 可追溯 SVG/icon id |
-| 需要动效 | `motion-ai-kit`（如已安装）或 `fixing-motion-performance` | 动效方案与性能约束 |
-| 需要无障碍 | `fixing-accessibility` | 键盘、焦点、ARIA、语义要求 |
-| 需要页面元信息 | `fixing-metadata` | title/meta/OG/favicon 要求 |
-```
-
-### 4. 术语表 (Glossary)
-
-```markdown
-## 术语表
+| 页面/流程 | 原型链接 | 说明 |
+|-----------|----------|------|
+| [页面/流程] | [链接] | [说明] |
+```
+
+### 3.1 前端设计输入 (Frontend Design Inputs) ⚠️ UI 项目必填
+
+```markdown
+## 前端设计输入
+
+### 视觉与品牌参照
+| 项 | 内容 | 说明 |
+|----|------|------|
+| 产品类型 | [SaaS/CRM/电商/工具/内容/游戏等] | 决定信息密度与视觉调性 |
+| 目标气质 | [专业/高级/活泼/极简/工业/编辑感等] | 交给 `design-taste-frontend` 校准 |
+| 品牌参照 | [Apple/Stripe/Notion/Linear/Claude/无] | 有品牌参照时使用 `brand-design-md` 获取 DESIGN.md |
+| 反参照 | [明确不要像什么] | 避免默认 AI UI 或竞品误导 |
+
+### Skill 路由
+| 场景 | 必用 Skill | 输出 |
+|------|------------|------|
+| 需要完整 UI 设计 | `impeccable` + `design-taste-frontend` | 设计方向、布局原则、token 候选 |
+| 需要大厂风格 | `brand-design-md` | 项目根或临时上下文中的 DESIGN.md |
+| 需要 UI 工程规范 | `baseline-ui` | 组件、状态、响应式、Tailwind 约束 |
+| 需要图标 | `better-icons` | 可追溯 SVG/icon id |
+| 需要动效 | `motion-ai-kit`（如已安装）或 `fixing-motion-performance` | 动效方案与性能约束 |
+| 需要无障碍 | `fixing-accessibility` | 键盘、焦点、ARIA、语义要求 |
+| 需要页面元信息 | `fixing-metadata` | title/meta/OG/favicon 要求 |
+```
+
+### 4. 术语表 (Glossary)
+
+```markdown
+## 术语表
 
 | 术语 | 定义 | 备注 |
 |------|------|------|
@@ -215,12 +215,12 @@ flowchart TD
 ```mermaid
 stateDiagram-v2
     [*] --> 状态1: 创建
-    状态1 --> 状态2: 事件1
-    状态2 --> 状态3: 事件2
-    状态3 --> [*]: 完成
-
-    note right of 状态2: 状态说明
-```
+    状态1 --> 状态2: 事件1
+    状态2 --> 状态3: 事件2
+    状态3 --> [*]: 完成
+
+    note right of 状态2: 状态说明
+```
 
 ### 权限矩阵 ⚠️ 必填
 | 操作 | 角色1 | 角色2 | 角色3 | 备注 |
@@ -368,30 +368,30 @@ stateDiagram-v2
 
 ## 二、设计文档模板
 
-### 1. 概述 (Overview)
-
-```markdown
-## 概述
-
-### 设计目标
-1. [目标1]
-2. [目标2]
-
-### 前端设计上下文
-| 项 | 内容 |
-|----|------|
-| 触发的设计 Skill | `impeccable` / `design-taste-frontend` / `brand-design-md` / `baseline-ui` / `better-icons` / `fixing-accessibility` / `fixing-motion-performance` / `fixing-metadata` |
-| DESIGN.md 来源 | [项目已有 / brand-design-md 拉取 / 无] |
-| 设计方差 | [1-10] |
-| 动效强度 | [1-10] |
-| 信息密度 | [1-10] |
-| 图标来源 | [better-icons icon id / 项目现有图标库] |
-
-### 技术栈选择
-| 层级 | 技术 | 版本 | 选型理由 |
-|------|------|------|----------|
-| [层级] | [技术] | [版本] | [理由] |
-```
+### 1. 概述 (Overview)
+
+```markdown
+## 概述
+
+### 设计目标
+1. [目标1]
+2. [目标2]
+
+### 前端设计上下文
+| 项 | 内容 |
+|----|------|
+| 触发的设计 Skill | `impeccable` / `design-taste-frontend` / `brand-design-md` / `baseline-ui` / `better-icons` / `fixing-accessibility` / `fixing-motion-performance` / `fixing-metadata` |
+| DESIGN.md 来源 | [项目已有 / brand-design-md 拉取 / 无] |
+| 设计方差 | [1-10] |
+| 动效强度 | [1-10] |
+| 信息密度 | [1-10] |
+| 图标来源 | [better-icons icon id / 项目现有图标库] |
+
+### 技术栈选择
+| 层级 | 技术 | 版本 | 选型理由 |
+|------|------|------|----------|
+| [层级] | [技术] | [版本] | [理由] |
+```
 
 ### 2. 架构与模块 (Architecture)
 
@@ -526,12 +526,12 @@ stateDiagram-v2
 ### 时序图
 ```mermaid
 sequenceDiagram
-    participant U as 用户
-    participant A as 服务A
-    participant B as 服务B
-    participant DB as 数据库
-
-    U->>A: 请求
+    participant U as 用户
+    participant A as 服务A
+    participant B as 服务B
+    participant DB as 数据库
+
+    U->>A: 请求
     A->>B: 调用
     B->>DB: 查询
     DB-->>B: 返回
@@ -696,19 +696,19 @@ sequenceDiagram
 - [ ] 风险清单至少 3 项，每项有缓解措施
 - [ ] 待确认点已列出并指定负责人
 
-### 设计文档评审检查
-- [ ] 架构图包含所有外部依赖
-- [ ] 数据模型包含索引设计
-- [ ] 接口定义包含错误码和幂等性说明
-- [ ] 关键决策记录了"为什么不用其他方案"
-- [ ] 异常处理包含重试、超时、兜底策略
-- [ ] 监控指标和告警规则已定义
-- [ ] 测试策略包含 Mock 依赖清单
-- [ ] 追溯矩阵已建立（需求→设计→测试）
-- [ ] UI 项目已记录触发的前端设计 skill 和 DESIGN.md 来源
-- [ ] 图标、动效、无障碍、元数据已分别映射到 `better-icons`、`motion-ai-kit`/`fixing-motion-performance`、`fixing-accessibility`、`fixing-metadata`
-
----
+### 设计文档评审检查
+- [ ] 架构图包含所有外部依赖
+- [ ] 数据模型包含索引设计
+- [ ] 接口定义包含错误码和幂等性说明
+- [ ] 关键决策记录了"为什么不用其他方案"
+- [ ] 异常处理包含重试、超时、兜底策略
+- [ ] 监控指标和告警规则已定义
+- [ ] 测试策略包含 Mock 依赖清单
+- [ ] 追溯矩阵已建立（需求→设计→测试）
+- [ ] UI 项目已记录触发的前端设计 skill 和 DESIGN.md 来源
+- [ ] 图标、动效、无障碍、元数据已分别映射到 `better-icons`、`motion-ai-kit`/`fixing-motion-performance`、`fixing-accessibility`、`fixing-metadata`
+
+---
 
 ## 五、降低返工的关键动作
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/skills-index.md

@@ -45,18 +45,18 @@ description: Index of active skills under .agents/skills
 
 | Skill | 目录 | 描述 |
 |-------|------|------|
-| **build-error-resolver** | `build-error-resolver/` | 构建/TypeScript 错误修复专家，最小 diff 快速变绿 |
-| **refactor-cleaner** | `refactor-cleaner/` | 死代码清理与重构专家 - knip/depcheck/ts-prune 分析（Opus 模型） |
-| **doc-updater** | `doc-updater/` | 文档与 Codemap 更新专家 |
-| **harness-surface-sync** | `harness-surface-sync/` | 一次性审计并同步 harness runtime、docs/testing、templates、workflows、config、skills 与 package-assets 镜像 |
-
-## Git 与自动化
-
-| Skill | 目录 | 描述 |
-|-------|------|------|
-| **Auto Review and Commit** | `auto-commit/` | 检查当前工作区、补齐必要同步、生成提交并推送；缺少远程仓库时可用 GitHub CLI 自动建仓 |
-| **ai-config-git-sync** | `ai-config-git-sync/` | 审计、更新并 fan-out 共享 AI workflow/config 到多个 Git 项目，支持 drift 检查、同步分支、push 和 PR |
-| **git-xianyu-analyzer** | `git-xianyu-analyzer/` | 克隆 Git 仓库→清理→分析→生成咸鱼销售文案 |
+| **build-error-resolver** | `build-error-resolver/` | 构建/TypeScript 错误修复专家，最小 diff 快速变绿 |
+| **refactor-cleaner** | `refactor-cleaner/` | 死代码清理与重构专家 - knip/depcheck/ts-prune 分析（Opus 模型） |
+| **doc-updater** | `doc-updater/` | 文档与 Codemap 更新专家 |
+| **harness-surface-sync** | `harness-surface-sync/` | 一次性审计并同步 harness runtime、docs/testing、templates、workflows、config、skills 与 package-assets 镜像 |
+
+## Git 与自动化
+
+| Skill | 目录 | 描述 |
+|-------|------|------|
+| **Auto Review and Commit** | `auto-commit/` | 检查当前工作区、补齐必要同步、生成提交并推送；缺少远程仓库时可用 GitHub CLI 自动建仓 |
+| **ai-config-git-sync** | `ai-config-git-sync/` | 审计、更新并 fan-out 共享 AI workflow/config 到多个 Git 项目，支持 drift 检查、同步分支、push 和 PR |
+| **git-xianyu-analyzer** | `git-xianyu-analyzer/` | 克隆 Git 仓库→清理→分析→生成咸鱼销售文案 |
 
 ## 设计与 UI/UX
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-analyze/SKILL.md

@@ -9,13 +9,13 @@ description: Perform a non-destructive cross-artifact consistency and quality an
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 输出给用户的分析报告必须使用简体中文。
-- 报告中的表格标题、问题描述、修复建议、后续命令建议全部使用简体中文。
-- 保留需求编号、任务 ID、路径、命令、协议名等技术标识原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 输出给用户的分析报告必须使用简体中文。
+- 报告中的表格标题、问题描述、修复建议、后续命令建议全部使用简体中文。
+- 保留需求编号、任务 ID、路径、命令、协议名等技术标识原样不变。
 
 ## Goal
 
@@ -83,24 +83,24 @@ Focus on high-signal findings. Limit to 50 findings total.
 - **C. Underspecification**: Requirements with verbs but missing object or measurable outcome
 - **D. Constitution Alignment**: Any requirement or plan element conflicting with a MUST principle
 - **E. Coverage Gaps**: Requirements with zero associated tasks
-- **F. Inconsistency**: Terminology drift, conflicting requirements
-- **G. Delivery Mode Drift**: Prototype/spike deliverables masquerading as completed formal `FR-*`
-- **H. Integration Downgrade**: Requirements tied to predefined OSS/external systems but implemented only as local mock/sample without explicit downgrade note
-- **I. Reuse Matrix Gap**: Missing or incomplete OSS reuse matrix rows for predefined stack / external systems
-- **J. Blocker Gate Failure**: Related `TBD-*` still open while tasks try to close the linked requirement
-- **K. Ordering Risk**: UI/BFF tasks are planned ahead of environment evidence, real connector, or integration-prep tasks they depend on
-- **L. Task Compression Risk**: A story or feature is represented by a single oversized task that spans blockers/evidence, connector work, bridge logic, API/BFF, UI, and final verification, hiding progress and making stop-hook continuation ineffective
-
-### 5. Severity Assignment
-
-- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or open integration blocker falsely treated as complete
-- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, or a single oversized integration task that hides multiple execution layers
-- **MEDIUM**: Terminology drift, missing non-functional task coverage, or missing explicit downgrade record
+- **F. Inconsistency**: Terminology drift, conflicting requirements
+- **G. Delivery Mode Drift**: Prototype/spike deliverables masquerading as completed formal `FR-*`
+- **H. Integration Downgrade**: Requirements tied to predefined OSS/external systems but implemented only as local mock/sample without explicit downgrade note
+- **I. Reuse Matrix Gap**: Missing or incomplete OSS reuse matrix rows for predefined stack / external systems
+- **J. Blocker Gate Failure**: Related `TBD-*` still open while tasks try to close the linked requirement
+- **K. Ordering Risk**: UI/BFF tasks are planned ahead of environment evidence, real connector, or integration-prep tasks they depend on
+- **L. Task Compression Risk**: A story or feature is represented by a single oversized task that spans blockers/evidence, connector work, bridge logic, API/BFF, UI, and final verification, hiding progress and making stop-hook continuation ineffective
+
+### 5. Severity Assignment
+
+- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or open integration blocker falsely treated as complete
+- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, or a single oversized integration task that hides multiple execution layers
+- **MEDIUM**: Terminology drift, missing non-functional task coverage, or missing explicit downgrade record
 - **LOW**: Style/wording improvements, minor redundancy
 
 ### 6. Produce Compact Analysis Report
 
-Output a Markdown report in Simplified Chinese (no file writes) with:
+Output a Markdown report in Simplified Chinese (no file writes) with:
 
 | ID | Category | Severity | Location(s) | Summary | Recommendation |
 |----|----------|----------|-------------|---------|----------------|
@@ -115,22 +115,22 @@ Output a Markdown report in Simplified Chinese (no file writes) with:
 **Unmapped Tasks:** (if any)
 
 **Metrics:**
-- Total Requirements
-- Total Tasks
-- Coverage % (requirements with >=1 task)
-- Integration Requirements Count
-- Open `TBD-*` Count
-- Compressed Story Count
-- Ambiguity Count
-- Duplication Count
-- Critical Issues Count
+- Total Requirements
+- Total Tasks
+- Coverage % (requirements with >=1 task)
+- Integration Requirements Count
+- Open `TBD-*` Count
+- Compressed Story Count
+- Ambiguity Count
+- Duplication Count
+- Critical Issues Count
 
 ### 7. Provide Next Actions
 
-- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
-- If Task Compression Risk exists: Recommend splitting the affected task into 4-6 acceptance-sized tasks before `/speckit.implement`
-- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions
+- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
+- If Task Compression Risk exists: Recommend splitting the affected task into 4-6 acceptance-sized tasks before `/speckit.implement`
+- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
+- Provide explicit command suggestions
 
 ### 8. Offer Remediation
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-checklist/SKILL.md

@@ -24,14 +24,14 @@ description: Generate a custom checklist for the current feature based on user r
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的说明、完成汇报全部使用简体中文。
-- 实际写入仓库的 checklist 文档必须使用简体中文。
-- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
-- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的说明、完成汇报全部使用简体中文。
+- 实际写入仓库的 checklist 文档必须使用简体中文。
+- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
+- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
 
 ## Execution Steps
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-clarify/SKILL.md

@@ -9,13 +9,13 @@ description: Identify underspecified areas in the current feature spec by asking
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
-- 回写到 `spec.md` 的澄清内容必须使用简体中文。
-- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
+- 回写到 `spec.md` 的澄清内容必须使用简体中文。
+- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
 
 ## Outline
 
@@ -44,27 +44,27 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i
    - Roles & Permissions
    - Non-Functional Quality Attributes
    - Integration & External Dependencies
-   - Edge Cases & Failure Handling
-   - Acceptance Criteria & Success Metrics
-   - Testability & Acceptance Evidence
-   - Required Test Data
-   - Evidence Paths & Observable Oracles
-   - Baseline / Affected Test Expectations
-   - Constraints & Tradeoffs
-   - Terminology & Consistency
-   - Completion Signals
-   - Misc / Placeholders
+   - Edge Cases & Failure Handling
+   - Acceptance Criteria & Success Metrics
+   - Testability & Acceptance Evidence
+   - Required Test Data
+   - Evidence Paths & Observable Oracles
+   - Baseline / Affected Test Expectations
+   - Constraints & Tradeoffs
+   - Terminology & Consistency
+   - Completion Signals
+   - Misc / Placeholders
 
 3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
     - Maximum of 10 total questions across the whole session.
     - Each question must be answerable with EITHER:
        - A short multiple-choice selection (2–5 distinct, mutually exclusive options), OR
        - A one-word / short-phrase answer (explicitly constrain: "Answer in <=5 words").
-    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
-    - Prioritize questions that unblock verification: missing environment, endpoint, RBAC, dashboard/panel ID, webhook target, fixture, credential, acceptance oracle, evidence path, or delivery-mode downgrade.
-    - If a P0/P1 requirement cannot be objectively verified, ask about verification before asking lower-impact UX or implementation-preference questions.
-    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first
-    - Never exceed 5 total asked questions
+    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
+    - Prioritize questions that unblock verification: missing environment, endpoint, RBAC, dashboard/panel ID, webhook target, fixture, credential, acceptance oracle, evidence path, or delivery-mode downgrade.
+    - If a P0/P1 requirement cannot be objectively verified, ask about verification before asking lower-impact UX or implementation-preference questions.
+    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first
+    - Never exceed 5 total asked questions
 
 4. Sequential questioning loop (interactive):
     - Present EXACTLY ONE question at a time.
@@ -75,12 +75,12 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i
 
 5. Integration after EACH accepted answer (incremental update approach):
     - Maintain in-memory representation of the spec
-    - Ensure a `## 澄清记录` section exists
-    - Append a bullet line in Chinese: `- 问：<问题> → 答：<最终答案>`
-    - Apply the clarification to the most appropriate section(s)
-    - If the answer changes testability, update `Testability & Acceptance Evidence`, `External Dependency Preconditions`, or the relevant acceptance scenario in the spec
-    - If the answer confirms a blocker, add or update a linked `TBD-*` / `TBD-TEST-*` item instead of silently treating the requirement as implementation-ready
-    - Save the spec file AFTER each integration
+    - Ensure a `## 澄清记录` section exists
+    - Append a bullet line in Chinese: `- 问：<问题> → 答：<最终答案>`
+    - Apply the clarification to the most appropriate section(s)
+    - If the answer changes testability, update `Testability & Acceptance Evidence`, `External Dependency Preconditions`, or the relevant acceptance scenario in the spec
+    - If the answer confirms a blocker, add or update a linked `TBD-*` / `TBD-TEST-*` item instead of silently treating the requirement as implementation-ready
+    - Save the spec file AFTER each integration
 
 6. Validation (performed after EACH write plus final pass):
    - Clarifications session contains exactly one bullet per accepted answer

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-e2e-tasks/SKILL.md

@@ -17,16 +17,16 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Outline
 
-1. **Setup & Component Discovery**:
-   - 阅读目标特性目录的 `tasks.md`（或 `plan.md`），获取目前的 Task ID 增长规律（如 `<!-- id: X0 -->` 系列）以及涉及的页面。
-   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件锁定前端入口、页面目录、状态源和测试相关目录，禁止无边界全仓扫描。
-   - **强制遍历指令:** 必须使用 `find_by_name` 或 `list_dir` 锁定 `frontend/src/pages/`、`views/` 等目录下具体的 `.vue` 页面文件列表。
-   - 必须基于上述页面采用 `grep_search` 或深度读取源码，搜索 `mock` 关键字、组件属性写死数组等，精准生成无幻觉的 “Mock依赖排雷清单”。
-
-2. **Element Deep Extraction & Generate Standardized e2e-plan.md**:
-   - 调用并克隆参考模板 `.agents/.specify/templates/e2e-plan-template.md`。
-   - **强制源码解构:** 严禁自由联想。必须通过 `view_file` 彻底读取所有相关 `.vue` 文件的 `<template>` 结构。精准提取出所有的 `<button>`、`<input>`、`el-select/a-select` 等交互控件，以及 `v-if`/`v-show` 所定义的动态状态(加载屏、空态、报错视图)。
-   - 将这些确凿的交互元素清单对应填入模板的 **“代码入口与影响面”**、**“2.元素级扫描”** 和 **“3. CRUD 闭环”** 中，并强制与 [D1-D10] 维度进行绑定映射。
+1. **Setup & Component Discovery**:
+   - 阅读目标特性目录的 `tasks.md`（或 `plan.md`），获取目前的 Task ID 增长规律（如 `<!-- id: X0 -->` 系列）以及涉及的页面。
+   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件锁定前端入口、页面目录、状态源和测试相关目录，禁止无边界全仓扫描。
+   - **强制遍历指令:** 必须使用 `find_by_name` 或 `list_dir` 锁定 `frontend/src/pages/`、`views/` 等目录下具体的 `.vue` 页面文件列表。
+   - 必须基于上述页面采用 `grep_search` 或深度读取源码，搜索 `mock` 关键字、组件属性写死数组等，精准生成无幻觉的 “Mock依赖排雷清单”。
+
+2. **Element Deep Extraction & Generate Standardized e2e-plan.md**:
+   - 调用并克隆参考模板 `.agents/.specify/templates/e2e-plan-template.md`。
+   - **强制源码解构:** 严禁自由联想。必须通过 `view_file` 彻底读取所有相关 `.vue` 文件的 `<template>` 结构。精准提取出所有的 `<button>`、`<input>`、`el-select/a-select` 等交互控件，以及 `v-if`/`v-show` 所定义的动态状态(加载屏、空态、报错视图)。
+   - 将这些确凿的交互元素清单对应填入模板的 **“代码入口与影响面”**、**“2.元素级扫描”** 和 **“3. CRUD 闭环”** 中，并强制与 [D1-D10] 维度进行绑定映射。
    - 将最终结构化分析的结果保存至对应的特性目录 (例如 `specs/xxx/e2e-plan.md`)。
 
 3. **Append Tasks using Strict `Speckit Tasks` Format (CRITICAL)**:
@@ -50,5 +50,5 @@ You **MUST** consider the user input before proceeding (if not empty).
   - 📝 **执行内容**: 根据大纲跑通全功能。
 ```
 
-4. **Report to User**:
-   - 通知用户该特性的 E2E 大纲及其配套的 tasks 生成完毕。提醒使用者若计划无误即可使用 `/speckit.implement` 执行排雷，最后再调用 `/browser-e2e-testing` 运行测例；测试失败后先按 `TEST_CODE_ISSUE / PRODUCT_BUG / REQUIREMENT_CHANGE / ENV_OR_DATA_ISSUE / FLAKY` 做一级归因。
+4. **Report to User**:
+   - 通知用户该特性的 E2E 大纲及其配套的 tasks 生成完毕。提醒使用者若计划无误即可使用 `/speckit.implement` 执行排雷，最后再调用 `/browser-e2e-testing` 运行测例；测试失败后先按 `TEST_CODE_ISSUE / PRODUCT_BUG / REQUIREMENT_CHANGE / ENV_OR_DATA_ISSUE / FLAKY` 做一级归因。

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: speckit-implement
-description: Execute tasks from tasks.md with per-task planning, validation, and task-boundary completion control
+name: speckit-implement
+description: Execute tasks from tasks.md with per-task planning, validation, and task-boundary completion control
 ---
 
 ## User Input
@@ -9,22 +9,22 @@ description: Execute tasks from tasks.md with per-task planning, validation, and
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的执行进展、验证结果、阻塞说明、完成汇报全部使用简体中文。
-- 如需回写 `tasks.md`、补充说明或更新当前 feature 文档，实际落盘内容必须使用简体中文。
-- 保留 `_Requirements: ..._`、任务 ID、HTML `<!-- id: XX -->`、路径、命令等机器敏感标记原样不变。
-
-## Driver-First Rule
-
-- do not try to finish the entire feature in one uninterrupted pass
-- focus on the current task boundary first
-- before editing files, enter built-in Plan mode and break the current task into 3-7 flat implementation steps
-- prefer sub-agents for complex or cross-surface tasks, but do not block simple tasks on that formality
-- only mark task checklist items as done after their validation command passes
-- when the feature plan is ready for repository execution, convert the task boundary into `task.json` and let the full driver own execution, trace, and commit
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的执行进展、验证结果、阻塞说明、完成汇报全部使用简体中文。
+- 如需回写 `tasks.md`、补充说明或更新当前 feature 文档，实际落盘内容必须使用简体中文。
+- 保留 `_Requirements: ..._`、任务 ID、HTML `<!-- id: XX -->`、路径、命令等机器敏感标记原样不变。
+
+## Driver-First Rule
+
+- do not try to finish the entire feature in one uninterrupted pass
+- focus on the current task boundary first
+- before editing files, enter built-in Plan mode and break the current task into 3-7 flat implementation steps
+- prefer sub-agents for complex or cross-surface tasks, but do not block simple tasks on that formality
+- only mark task checklist items as done after their validation command passes
+- when the feature plan is ready for repository execution, convert the task boundary into `task.json` and let the full driver own execution, trace, and commit
 
 ## Outline
 
@@ -87,36 +87,36 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 6. **子任务执行循环** (对每个子任务重复执行):
 
-   **6.1 子任务分析阶段** (进入新子任务前必须执行):
-   - 从 tasks.md 读取当前要执行的子任务
-   - 分析子任务的具体要求、输入输出、依赖关系
-   - 识别需要修改/创建的文件列表
-   - 确认技术方案和实现思路
-   - 先进入内置 Plan mode，只围绕当前子任务拆成 3-7 个扁平子步骤
-   - **输出**: 简洁的子任务分析摘要（2-3行）
+   **6.1 子任务分析阶段** (进入新子任务前必须执行):
+   - 从 tasks.md 读取当前要执行的子任务
+   - 分析子任务的具体要求、输入输出、依赖关系
+   - 识别需要修改/创建的文件列表
+   - 确认技术方案和实现思路
+   - 先进入内置 Plan mode，只围绕当前子任务拆成 3-7 个扁平子步骤
+   - **输出**: 简洁的子任务分析摘要（2-3行）
 
    **6.2 子任务实现阶段**:
    - 按分析结果执行具体实现
    - 遵循 TDD：先写测试再写实现（如适用）
    - 确保代码符合项目规范和设计文档
 
-   **6.3 子任务完成更新** (完成后立即执行):
-   - 先运行当前子任务块里的 `🔍 自检命令`
-   - **立即**将 tasks.md 中对应任务标记为 `[X]`
-   - 记录完成时间和关键产出（如新增文件路径）
-   - 验证子任务产出符合预期
+   **6.3 子任务完成更新** (完成后立即执行):
+   - 先运行当前子任务块里的 `🔍 自检命令`
+   - **立即**将 tasks.md 中对应任务标记为 `[X]`
+   - 记录完成时间和关键产出（如新增文件路径）
+   - 验证子任务产出符合预期
 
    **6.4 进入下一个子任务**:
    - 返回步骤 6.1，分析下一个未完成的子任务
    - 直到当前 Phase 的所有子任务完成
 
-7. Execute implementation following the task plan:
-   - **Phase-by-phase execution**: Complete each phase before moving to the next
-   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
-   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
-   - **File-based coordination**: Tasks affecting the same files must run sequentially
-   - **Validation checkpoints**: Verify each phase completion before proceeding
-   - Prefer stopping at a single completed task boundary and hand full-driver execution back to `task.json` / `tools/harness/codex-loop.ps1` when repository automation should continue
+7. Execute implementation following the task plan:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+   - Prefer stopping at a single completed task boundary and hand full-driver execution back to `task.json` / `tools/harness/codex-loop.ps1` when repository automation should continue
 
 8. Implementation execution rules:
    - **Setup first**: Initialize project structure, dependencies, configuration