@pzy560117/codex-harness 0.1.0 → 0.1.2

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

@@ -0,0 +1,144 @@
+---
+name: speckit-analyze
+description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 输出给用户的分析报告必须使用简体中文。
+- 报告中的表格标题、问题描述、修复建议、后续命令建议全部使用简体中文。
+- 保留需求编号、任务 ID、路径、命令、协议名等技术标识原样不变。
+
+## Goal
+
+Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit.tasks` has successfully produced a complete `tasks.md`.
+
+## Operating Constraints
+
+**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
+
+**Constitution Authority**: The project constitution (`.agents/.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle.
+
+## Execution Steps
+
+### 1. Initialize Analysis Context
+
+Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
+
+- SPEC = FEATURE_DIR/spec.md
+- PLAN = FEATURE_DIR/plan.md
+- TASKS = FEATURE_DIR/tasks.md
+
+Abort with an error message if any required file is missing.
+
+### 2. Load Artifacts (Progressive Disclosure)
+
+Load only the minimal necessary context from each artifact:
+
+**From spec.md:**
+- Overview/Context
+- Functional Requirements
+- Non-Functional Requirements
+- User Stories
+- Edge Cases (if present)
+
+**From plan.md:**
+- Architecture/stack choices
+- Data Model references
+- Phases
+- Technical constraints
+
+**From tasks.md:**
+- Task IDs
+- Descriptions
+- Phase grouping
+- Parallel markers [P]
+- Referenced file paths
+
+**From constitution:**
+- Load `.agents/.specify/memory/constitution.md` for principle validation
+
+### 3. Build Semantic Models
+
+Create internal representations (do not include raw artifacts in output):
+- **Requirements inventory**: Each functional + non-functional requirement with a stable key
+- **User story/action inventory**: Discrete user actions with acceptance criteria
+- **Task coverage mapping**: Map each task to one or more requirements or stories
+- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements
+
+### 4. Detection Passes (Token-Efficient Analysis)
+
+Focus on high-signal findings. Limit to 50 findings total.
+
+- **A. Duplication Detection**: Identify near-duplicate requirements
+- **B. Ambiguity Detection**: Flag vague adjectives lacking measurable criteria
+- **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
+- **LOW**: Style/wording improvements, minor redundancy
+
+### 6. Produce Compact Analysis Report
+
+Output a Markdown report in Simplified Chinese (no file writes) with:
+
+| ID | Category | Severity | Location(s) | Summary | Recommendation |
+|----|----------|----------|-------------|---------|----------------|
+
+**Coverage Summary Table:**
+
+| Requirement Key | Has Task? | Task IDs | Notes |
+|-----------------|-----------|----------|-------|
+
+**Constitution Alignment Issues:** (if any)
+
+**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
+
+### 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
+
+### 8. Offer Remediation
+
+Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
+
+## Operating Principles
+
+- **NEVER modify files** (this is read-only analysis)
+- **NEVER hallucinate missing sections** (if absent, report them accurately)
+- **Prioritize constitution violations** (these are always CRITICAL)
+- **Report zero issues gracefully** (emit success report with coverage statistics)

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

@@ -0,0 +1,126 @@
+---
+name: speckit-checklist
+description: Generate a custom checklist for the current feature based on user requirements.
+---
+
+## Checklist Purpose: "Unit Tests for English"
+
+**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain.
+
+**NOT for verification/testing**:
+- ❌ NOT "Verify the button clicks correctly"
+- ❌ NOT "Test error handling works"
+- ❌ NOT "Confirm the API returns 200"
+
+**FOR requirements quality validation**:
+- ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
+- ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
+- ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
+- ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的说明、完成汇报全部使用简体中文。
+- 实际写入仓库的 checklist 文档必须使用简体中文。
+- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
+- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
+
+## Execution Steps
+
+1. **Setup**: Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+   - All file paths must be absolute.
+
+2. **Clarify intent (dynamic)**: Derive up to THREE initial contextual clarifying questions. They MUST:
+   - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
+   - Only ask about information that materially changes checklist content
+   - Be skipped individually if already unambiguous in `$ARGUMENTS`
+
+3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
+   - Derive checklist theme (e.g., security, review, deploy, ux)
+   - Consolidate explicit must-have items mentioned by user
+   - Map focus selections to category scaffolding
+
+4. **Load feature context**: Read from FEATURE_DIR:
+   - spec.md: Feature requirements and scope
+   - plan.md (if exists): Technical details, dependencies
+   - tasks.md (if exists): Implementation tasks
+
+5. **Generate checklist** - Create "Unit Tests for Requirements":
+   - Create `FEATURE_DIR/checklists/` directory if it doesn't exist
+   - Generate unique checklist filename (e.g., `ux.md`, `api.md`, `security.md`)
+   - Number items sequentially starting from CHK001
+
+   **Category Structure** - Group items by requirement quality dimensions:
+   - **Requirement Completeness** (Are all necessary requirements documented?)
+   - **Requirement Clarity** (Are requirements specific and unambiguous?)
+   - **Requirement Consistency** (Do requirements align without conflicts?)
+   - **Acceptance Criteria Quality** (Are success criteria measurable?)
+   - **Scenario Coverage** (Are all flows/cases addressed?)
+   - **Edge Case Coverage** (Are boundary conditions defined?)
+   - **Non-Functional Requirements** (Performance, Security, Accessibility specified?)
+   - **Dependencies & Assumptions** (Are they documented and validated?)
+   - **Ambiguities & Conflicts** (What needs clarification?)
+
+   **HOW TO WRITE CHECKLIST ITEMS**:
+
+   ❌ **WRONG** (Testing implementation):
+   - "Verify landing page displays 3 episode cards"
+   - "Test hover states work on desktop"
+
+   ✅ **CORRECT** (Testing requirements quality):
+   - "Are the exact number and layout of featured episodes specified?" [Completeness]
+   - "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity]
+   - "Are hover state requirements consistent across all interactive elements?" [Consistency]
+   - "Are keyboard navigation requirements defined for all interactive UI?" [Coverage]
+
+   **ITEM STRUCTURE**:
+   - Question format asking about requirement quality
+   - Focus on what's WRITTEN (or not written) in the spec/plan
+   - Include quality dimension in brackets [Completeness/Clarity/Consistency/etc.]
+   - Reference spec section `[Spec §X.Y]` when checking existing requirements
+   - Use `[Gap]` marker when checking for missing requirements
+
+   **Traceability Requirements**:
+   - MINIMUM: ≥80% of items MUST include at least one traceability reference
+
+   **🚫 ABSOLUTELY PROHIBITED**:
+   - ❌ Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior
+   - ❌ References to code execution, user actions, system behavior
+   - ❌ "Displays correctly", "works properly", "functions as expected"
+   - ❌ "Click", "navigate", "render", "load", "execute"
+
+   **✅ REQUIRED PATTERNS**:
+   - ✅ "Are [requirement type] defined/specified/documented for [scenario]?"
+   - ✅ "Is [vague term] quantified/clarified with specific criteria?"
+   - ✅ "Are requirements consistent between [section A] and [section B]?"
+   - ✅ "Can [requirement] be objectively measured/verified?"
+   - ✅ "Does the spec define [missing aspect]?"
+
+6. **Structure Reference**: Generate the checklist following the canonical template in `.agents/.specify/templates/checklist-template.md`
+
+7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file.
+
+## Example Checklist Types & Sample Items
+
+**UX Requirements Quality:** `ux.md`
+- "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]"
+- "Is the number and positioning of UI elements explicitly specified? [Completeness, Spec §FR-1]"
+- "Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]"
+
+**API Requirements Quality:** `api.md`
+- "Are error response formats specified for all failure scenarios? [Completeness]"
+- "Are rate limiting requirements quantified with specific thresholds? [Clarity]"
+- "Are authentication requirements consistent across all endpoints? [Consistency]"
+
+**Security Requirements Quality:** `security.md`
+- "Are authentication requirements specified for all protected resources? [Coverage]"
+- "Are data protection requirements defined for sensitive information? [Completeness]"
+- "Is the threat model documented and requirements aligned to it? [Traceability]"

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

@@ -0,0 +1,108 @@
+---
+name: speckit-clarify
+description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
+- 回写到 `spec.md` 的澄清内容必须使用简体中文。
+- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
+
+## Outline
+
+Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
+
+Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/speckit.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
+
+## Execution Steps
+
+1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
+   - `FEATURE_DIR`
+   - `FEATURE_SPEC`
+   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
+   - If JSON parsing fails, abort and instruct user to re-run `/speckit.specify` or verify feature branch environment.
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
+
+   **Taxonomy Categories:**
+   - Functional Scope & Behavior
+   - Domain & Data Model
+   - Interaction & UX Flow
+   - Page Inventory & State Coverage
+   - Requirement-to-Interface Traceability
+   - Upfront Difficulty Research
+   - 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
+
+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
+
+4. Sequential questioning loop (interactive):
+    - Present EXACTLY ONE question at a time.
+    - For multiple-choice questions: Present your **recommended option prominently** at the top with clear reasoning.
+    - Format as: `**Recommended:** Option [X] - <reasoning>`
+    - Then render all options as a Markdown table
+    - After the user answers: validate and record in working memory
+
+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
+
+6. Validation (performed after EACH write plus final pass):
+   - Clarifications session contains exactly one bullet per accepted answer
+   - Total asked (accepted) questions ≤ 5
+   - Markdown structure valid
+
+7. Write the updated spec back to `FEATURE_SPEC`.
+
+8. Report completion:
+   - Number of questions asked & answered
+   - Path to updated spec
+   - Sections touched
+   - Coverage summary table
+   - Suggested next command
+
+## Behavior Rules
+
+- If no meaningful ambiguities found, respond: "No critical ambiguities detected worth formal clarification."
+- If spec file missing, instruct user to run `/speckit.specify` first
+- Never exceed 5 total asked questions
+- Respect user early termination signals ("stop", "done", "proceed")
+
+## Next Steps
+
+- `/speckit.plan` - Create a plan for the spec

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

@@ -0,0 +1,83 @@
+---
+name: speckit-constitution
+description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are updating the project constitution at `.agents/.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+Follow this execution flow:
+
+1. Load the existing constitution template at `.agents/.specify/memory/constitution.md`.
+   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2. Collect/derive values for placeholders:
+   - If user input (conversation) supplies a value, use it.
+   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+     - MAJOR: Backward incompatible governance/principle removals or redefinitions.
+     - MINOR: New principle/section added or materially expanded guidance.
+     - PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+   - If version bump type ambiguous, propose reasoning before finalizing.
+
+3. Draft the updated constitution content:
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non-negotiable rules, explicit rationale if not obvious.
+   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4. Consistency propagation checklist (convert prior checklist into active validations):
+   - Read `.agents/.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `.agents/.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `.agents/.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `.agents/.specify/templates/commands/*.md` (including this one) to verify no outdated references remain.
+   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
+
+5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
+   - Version change: old → new
+   - List of modified principles (old title → new title if renamed)
+   - Added sections
+   - Removed sections
+   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
+   - Follow-up TODOs if any placeholders intentionally deferred.
+
+6. Validation before final output:
+   - No remaining unexplained bracket tokens.
+   - Version line matches report.
+   - Dates ISO format YYYY-MM-DD.
+   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7. Write the completed constitution back to `.agents/.specify/memory/constitution.md` (overwrite).
+
+8. Output a final summary to the user with:
+   - New version and bump rationale.
+   - Any files flagged for manual follow-up.
+   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+## Formatting & Style Requirements
+
+- Use Markdown headings exactly as in the template (do not demote/promote levels).
+- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
+- Keep a single blank line between sections.
+- Avoid trailing whitespace.
+
+If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
+
+If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
+
+Do not create a new template; always operate on the existing `.agents/.specify/memory/constitution.md` file.
+
+## Next Steps
+
+- `/speckit.specify` - Implement the feature specification based on the updated constitution

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

@@ -0,0 +1,54 @@
+---
+name: speckit-e2e-tasks
+description: 生成严谨且具有强约束的 E2E 测试大纲 (e2e-plan.md) 并在 tasks.md 中精准追加格式一致的验证任务层。绝对禁绝 Mock。
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Context & Objectives
+
+此 Skill 专精于 OpenSpec 的前端测试落地 (Test-Left 策略)。在正式交付前端进入整体实施环节前，本工作流将分析已有前端切页，以绝对严苛的模板和任务规范为当前项目生成端到端测试大纲 (e2e-plan.md)。保证格式可控且任务格式 (`tasks.md`) 完全无缝对齐 OpenSpec 标准。
+
+## 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] 维度进行绑定映射。
+   - 将最终结构化分析的结果保存至对应的特性目录 (例如 `specs/xxx/e2e-plan.md`)。
+
+3. **Append Tasks using Strict `Speckit Tasks` Format (CRITICAL)**:
+   - 必须向原有的 `tasks.md` 末尾追加全新的 Phase。
+   - 所有的 Task **必须逐一严格遵循以下格式结构**，禁止遗漏 `<!-- id: XX -->` 和 Emoji 符号 `📋` `✅` `📁` `📝`：
+
+```markdown
+## Phase X: E2E 极致验收与 Mock 清理 <!-- id: [获取当前最高Phase的十位+10] -->
+
+**Goal**: 扫除所有的 Mock 数据拦截器保证生产流量贯通，并使用自动化代理执行 10 维度验收。
+
+- [ ] **T0XX [US-ALL] 前置检查: 扫除本模块界面中的 Mock 数据引用** <!-- id: X1 -->
+  - 📋 **规格参考**: e2e-plan.md → 第1节排雷清单
+  - ✅ **验收标准**: 前端代码完全剥离 Mock，所有前端页面的请求对接真实的 API 端点且不产生 404/跨域。
+  - 📁 **修改文件**: [填写步骤1扫出来的具体页面]
+  - 📝 **执行内容**: 清除硬编码、恢复 Axios 的网络层拦截调用，或者关闭 `MockStateWrapper`。
+
+- [ ] **T0XY [US-ALL] 执行全面元素级与 CRUD 闭环 E2E 测试** <!-- id: X2 -->
+  - 📋 **规格参考**: e2e-plan.md
+  - ✅ **验收标准**: 执行 `/browser-e2e-testing` 并全流程 Pass（通过每一个页面交互元素的点击、非法输入验证，及完整的 增、删、改、查 生命周期流转验证，过程中禁绝一切 Fake Data）。
+  - 📝 **执行内容**: 根据大纲跑通全功能。
+```
+
+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

@@ -0,0 +1,143 @@
+---
+name: speckit-implement
+description: Execute tasks from tasks.md with per-task planning, validation, and task-boundary completion control
+---
+
+## User Input
+
+```text
+$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
+
+## Outline
+
+1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
+   - Scan all checklist files in the checklists/ directory
+   - For each checklist, count:
+     - Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
+     - Completed items: Lines matching `- [X]` or `- [x]`
+     - Incomplete items: Lines matching `- [ ]`
+   - Create a status table:
+
+     | Checklist | Total | Completed | Incomplete | Status |
+     |-----------|-------|-----------|------------|--------|
+     | ux.md     | 12    | 12        | 0          | ✓ PASS |
+     | test.md   | 8     | 5         | 3          | ✗ FAIL |
+     | security.md | 6   | 6         | 0          | ✓ PASS |
+
+   - **If any checklist is incomplete**:
+     - Display the table with incomplete item counts
+     - **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
+     - Wait for user response before continuing
+
+   - **If all checklists are complete**:
+     - Display the table showing all checklists passed
+     - Automatically proceed to step 3
+
+3. Load and analyze the implementation context:
+   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
+   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
+   - **IF EXISTS**: Read research.md for technical decisions and constraints
+   - **IF EXISTS**: Read quickstart.md for integration scenarios
+
+4. **Project Setup Verification**:
+   - **REQUIRED**: Create/verify ignore files based on actual project setup:
+
+   **Detection & Creation Logic**:
+   - Check if git repo exists → create/verify .gitignore
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* exists → create/verify .eslintignore
+   - Check if eslint.config.* exists → ensure the config's `ignores` entries cover required patterns
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+
+   **Common Patterns by Technology** (from plan.md tech stack):
+   - **Node.js/JavaScript/TypeScript**: `node_modules/`, `dist/`, `build/`, `*.log`, `.env*`
+   - **Python**: `__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/`
+   - **Java**: `target/`, `*.class`, `*.jar`, `.gradle/`, `build/`
+   - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/`
+
+5. Parse tasks.md structure and extract:
+   - **Task phases**: Setup, Tests, Core, Integration, Polish
+   - **Task dependencies**: Sequential vs parallel execution rules
+   - **Task details**: ID, description, file paths, parallel markers [P]
+   - **Execution flow**: Order and dependency requirements
+
+6. **子任务执行循环** (对每个子任务重复执行):
+
+   **6.1 子任务分析阶段** (进入新子任务前必须执行):
+   - 从 tasks.md 读取当前要执行的子任务
+   - 分析子任务的具体要求、输入输出、依赖关系
+   - 识别需要修改/创建的文件列表
+   - 确认技术方案和实现思路
+   - 先进入内置 Plan mode，只围绕当前子任务拆成 3-7 个扁平子步骤
+   - **输出**: 简洁的子任务分析摘要（2-3行）
+
+   **6.2 子任务实现阶段**:
+   - 按分析结果执行具体实现
+   - 遵循 TDD：先写测试再写实现（如适用）
+   - 确保代码符合项目规范和设计文档
+
+   **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
+
+8. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **Integration work**: Database connections, middleware, logging, external services
+   - **Polish and validation**: Unit tests, performance optimization, documentation
+
+9. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **CRITICAL**: 每个子任务完成后必须立即更新 tasks.md，不要批量更新
+
+10. Completion validation:
+    - Verify all required tasks are completed
+    - Check that implemented features match the original specification
+    - Validate that tests pass and coverage meets requirements
+    - Confirm the implementation follows the technical plan
+    - Report final status with summary of completed work
+
+Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/speckit.tasks` first to regenerate the task list.