fix(codeagent-wrapper): correct default models for oracle and librarian agents (#120)

- oracle: claude-sonnet-4-20250514 → claude-opus-4-5-20251101
- librarian: claude-sonnet-4-5-20250514 → claude-sonnet-4-5-20250929

Fixes #120

Generated with SWE-Agent.ai

Co-Authored-By: SWE-Agent.ai <noreply@swe-agent.ai>

CHANGELOG.md

@@ -2,6 +2,66 @@
 
 All notable changes to this project will be documented in this file.
 
+## [5.6.4] - 2026-01-15
+
+### 🚀 Features
+
+- add reasoning effort config for codex backend
+- default to skip-permissions and bypass-sandbox
+- add multi-agent support with yolo mode
+- add omo module for multi-agent orchestration
+- add intelligent backend selection based on task complexity (#61)
+- v5.4.0 structured execution report (#94)
+- add millisecond-precision timestamps to all log entries (#91)
+- skill-install install script and security scan
+- add uninstall scripts with selective module removal
+
+### 🐛 Bug Fixes
+
+- filter codex stderr noise logs
+- use config override for codex reasoning effort
+- propagate SkipPermissions to parallel tasks (#113)
+- add timeout for Windows process termination
+- reject dash as workdir parameter (#118)
+- add sleep in fake script to prevent CI race condition
+- fix gemini env load
+- fix omo
+- fix codeagent skill TaskOutput
+- 修复 Gemini init 事件 session_id 未提取的问题 (#111)
+- Windows 后端退出：taskkill 结束进程树 + turn.completed 支持 (#108)
+- support model parameter for all backends, auto-inject from settings (#105)
+- replace setx with reg add to avoid 1024-char PATH truncation (#101)
+- 移除未知事件格式的日志噪声 (#96)
+- prevent duplicate PATH entries on reinstall (#95)
+- Minor issues #12 and #13 - ASCII mode and performance optimization
+- correct settings.json filename and bump version to v5.2.8
+- allow claude backend to read env from setting.json while preventing recursion (#92)
+- comprehensive security and quality improvements for PR #85 & #87 (#90)
+- Improve backend termination after message and extend timeout (#86)
+- Parser重复解析优化 + 严重bug修复 + PR #86兼容性 (#88)
+- filter noisy stderr output from gemini backend (#83)
+- 修復 wsl install.sh 格式問題 (#78)
+- 修复多 backend 并行日志 PID 混乱并移除包装格式 (#74) (#76)
+
+### 🚜 Refactor
+
+- remove sisyphus agent and unused code
+- streamline agent documentation and remove sisyphus
+
+### 📚 Documentation
+
+- add OmO workflow to README and fix plugin marketplace structure
+- update FAQ for default bypass/skip-permissions behavior
+- 添加 FAQ 常见问题章节
+- update troubleshooting with idempotent PATH commands (#95)
+
+### 💼 Other
+
+- add test-cases skill
+- add browser skill
+- BMADh和Requirements-Driven支持根据语义生成对应的文档 (#82)
+- update all readme
+
 ## [5.2.4] - 2025-12-16
 
 

codeagent-wrapper/agent_config.go

@@ -26,8 +26,8 @@ var defaultModelsConfig = ModelsConfig{
 	DefaultBackend: "opencode",
 	DefaultModel:   "opencode/grok-code",
 	Agents: map[string]AgentModelConfig{
-			"oracle":                  {Backend: "claude", Model: "claude-sonnet-4-20250514", PromptFile: "~/.claude/skills/omo/references/oracle.md", Description: "Technical advisor"},
-			"librarian":               {Backend: "claude", Model: "claude-sonnet-4-5-20250514", PromptFile: "~/.claude/skills/omo/references/librarian.md", Description: "Researcher"},
+			"oracle":                  {Backend: "claude", Model: "claude-opus-4-5-20251101", PromptFile: "~/.claude/skills/omo/references/oracle.md", Description: "Technical advisor"},
+			"librarian":               {Backend: "claude", Model: "claude-sonnet-4-5-20250929", PromptFile: "~/.claude/skills/omo/references/librarian.md", Description: "Researcher"},
 			"explore":                 {Backend: "opencode", Model: "opencode/grok-code", PromptFile: "~/.claude/skills/omo/references/explore.md", Description: "Code search"},
 			"develop":                 {Backend: "codex", Model: "", PromptFile: "~/.claude/skills/omo/references/develop.md", Description: "Code development"},
 			"frontend-ui-ux-engineer": {Backend: "gemini", Model: "", PromptFile: "~/.claude/skills/omo/references/frontend-ui-ux-engineer.md", Description: "Frontend engineer"},

codeagent-wrapper/agent_config_test.go

@@ -19,8 +19,8 @@ func TestResolveAgentConfig_Defaults(t *testing.T) {
 		wantModel      string
 		wantPromptFile string
 	}{
-			{"oracle", "claude", "claude-sonnet-4-20250514", "~/.claude/skills/omo/references/oracle.md"},
-			{"librarian", "claude", "claude-sonnet-4-5-20250514", "~/.claude/skills/omo/references/librarian.md"},
+			{"oracle", "claude", "claude-opus-4-5-20251101", "~/.claude/skills/omo/references/oracle.md"},
+			{"librarian", "claude", "claude-sonnet-4-5-20250929", "~/.claude/skills/omo/references/librarian.md"},
 			{"explore", "opencode", "opencode/grok-code", "~/.claude/skills/omo/references/explore.md"},
 			{"frontend-ui-ux-engineer", "gemini", "", "~/.claude/skills/omo/references/frontend-ui-ux-engineer.md"},
 			{"document-writer", "gemini", "", "~/.claude/skills/omo/references/document-writer.md"},

codeagent-wrapper/executor.go

@@ -766,7 +766,7 @@ func buildCodexArgs(cfg *Config, targetArg string) []string {
 	}
 
 	if reasoningEffort := strings.TrimSpace(cfg.ReasoningEffort); reasoningEffort != "" {
-		args = append(args, "--reasoning-effort", reasoningEffort)
+		args = append(args, "-c", "model_reasoning_effort="+reasoningEffort)
 	}
 
 	args = append(args, "--skip-git-repo-check")
@@ -983,6 +983,9 @@ func runCodexTaskWithContext(parentCtx context.Context, taskSpec TaskSpec, backe
 		if cfg.Backend == "gemini" {
 			stderrFilter = newFilteringWriter(os.Stderr, geminiNoisePatterns)
 			stderrOut = stderrFilter
+		} else if cfg.Backend == "codex" {
+			stderrFilter = newFilteringWriter(os.Stderr, codexNoisePatterns)
+			stderrOut = stderrFilter
 		}
 		stderrWriters = append([]io.Writer{stderrOut}, stderrWriters...)
 	}

codeagent-wrapper/filter.go

@@ -18,6 +18,12 @@ var geminiNoisePatterns = []string{
 	"YOLO mode is enabled",
 }
 
+// codexNoisePatterns contains stderr patterns to filter for codex backend
+var codexNoisePatterns = []string{
+	"ERROR codex_core::codex: needs_follow_up:",
+	"ERROR codex_core::skills::loader:",
+}
+
 // filteringWriter wraps an io.Writer and filters out lines matching patterns
 type filteringWriter struct {
 	w        io.Writer

codeagent-wrapper/main.go

@@ -14,7 +14,7 @@ import (
 )
 
 const (
-	version               = "5.5.0"
+	version               = "5.6.4"
 	defaultWorkdir        = "."
 	defaultTimeout        = 7200 // seconds (2 hours)
 	defaultCoverageTarget = 90.0

codeagent-wrapper/main_test.go

@@ -1970,7 +1970,7 @@ func TestRunBuildCodexArgs_NewMode_WithReasoningEffort(t *testing.T) {
 	args := buildCodexArgs(cfg, "my task")
 	expected := []string{
 		"e",
-		"--reasoning-effort", "high",
+		"-c", "model_reasoning_effort=high",
 		"--skip-git-repo-check",
 		"-C", "/test/dir",
 		"--json",
@@ -2010,13 +2010,13 @@ func TestRunCodexTaskWithContext_CodexReasoningEffort(t *testing.T) {
 
 	found := false
 	for i := 0; i+1 < len(gotArgs); i++ {
-		if gotArgs[i] == "--reasoning-effort" && gotArgs[i+1] == "high" {
+		if gotArgs[i] == "-c" && gotArgs[i+1] == "model_reasoning_effort=high" {
 			found = true
 			break
 		}
 	}
 	if !found {
-		t.Fatalf("expected --reasoning-effort high in args, got %v", gotArgs)
+		t.Fatalf("expected -c model_reasoning_effort=high in args, got %v", gotArgs)
 	}
 }
 
@@ -3736,7 +3736,7 @@ func TestVersionFlag(t *testing.T) {
 		}
 	})
 
-	want := "codeagent-wrapper version 5.5.0\n"
+	want := "codeagent-wrapper version 5.6.4\n"
 
 	if output != want {
 		t.Fatalf("output = %q, want %q", output, want)
@@ -3752,7 +3752,7 @@ func TestVersionShortFlag(t *testing.T) {
 		}
 	})
 
-	want := "codeagent-wrapper version 5.5.0\n"
+	want := "codeagent-wrapper version 5.6.4\n"
 
 	if output != want {
 		t.Fatalf("output = %q, want %q", output, want)
@@ -3768,7 +3768,7 @@ func TestVersionLegacyAlias(t *testing.T) {
 		}
 	})
 
-	want := "codex-wrapper version 5.5.0\n"
+	want := "codex-wrapper version 5.6.4\n"
 
 	if output != want {
 		t.Fatalf("output = %q, want %q", output, want)

skills/dev/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: dev
+description: Extreme lightweight end-to-end development workflow with requirements clarification, intelligent backend selection, parallel codeagent execution, and mandatory 90% test coverage
+---
+
+You are the /dev Workflow Orchestrator, an expert development workflow manager specializing in orchestrating minimal, efficient end-to-end development processes with parallel task execution and rigorous test coverage validation.
+
+---
+
+## CRITICAL CONSTRAINTS (NEVER VIOLATE)
+
+These rules have HIGHEST PRIORITY and override all other instructions:
+
+1. **NEVER use Edit, Write, or MultiEdit tools directly** - ALL code changes MUST go through codeagent-wrapper
+2. **MUST use AskUserQuestion in Step 0** - Backend selection MUST be the FIRST action (before requirement clarification)
+3. **MUST use AskUserQuestion in Step 1** - Do NOT skip requirement clarification
+4. **MUST use TodoWrite after Step 1** - Create task tracking list before any analysis
+5. **MUST use codeagent-wrapper for Step 2 analysis** - Do NOT use Read/Glob/Grep directly for deep analysis
+6. **MUST wait for user confirmation in Step 3** - Do NOT proceed to Step 4 without explicit approval
+7. **MUST invoke codeagent-wrapper --parallel for Step 4 execution** - Use Bash tool, NOT Edit/Write or Task tool
+
+**Violation of any constraint above invalidates the entire workflow. Stop and restart if violated.**
+
+---
+
+**Core Responsibilities**
+- Orchestrate a streamlined 7-step development workflow (Step 0 + Step 1–6):
+  0. Backend selection (user constrained)
+  1. Requirement clarification through targeted questioning
+  2. Technical analysis using codeagent-wrapper
+  3. Development documentation generation
+  4. Parallel development execution (backend routing per task type)
+  5. Coverage validation (≥90% requirement)
+  6. Completion summary
+
+**Workflow Execution**
+- **Step 0: Backend Selection [MANDATORY - FIRST ACTION]**
+  - MUST use AskUserQuestion tool as the FIRST action with multiSelect enabled
+  - Ask which backends are allowed for this /dev run
+  - Options (user can select multiple):
+    - `codex` - Stable, high quality, best cost-performance (default for most tasks)
+    - `claude` - Fast, lightweight (for quick fixes and config changes)
+    - `gemini` - UI/UX specialist (for frontend styling and components)
+  - Store the selected backends as `allowed_backends` set for routing in Step 4
+  - Special rule: if user selects ONLY `codex`, then ALL subsequent tasks (including UI/quick-fix) MUST use `codex` (no exceptions)
+
+- **Step 1: Requirement Clarification [MANDATORY - DO NOT SKIP]**
+  - MUST use AskUserQuestion tool
+  - Focus questions on functional boundaries, inputs/outputs, constraints, testing, and required unit-test coverage levels
+  - Iterate 2-3 rounds until clear; rely on judgment; keep questions concise
+  - After clarification complete: MUST use TodoWrite to create task tracking list with workflow steps
+
+- **Step 2: codeagent-wrapper Deep Analysis (Plan Mode Style) [USE CODEAGENT-WRAPPER ONLY]**
+
+  MUST use Bash tool to invoke `codeagent-wrapper` for deep analysis. Do NOT use Read/Glob/Grep tools directly - delegate all exploration to codeagent-wrapper.
+
+  **How to invoke for analysis**:
+  ```bash
+  # analysis_backend selection:
+  # - prefer codex if it is in allowed_backends
+  # - otherwise pick the first backend in allowed_backends
+  codeagent-wrapper --backend {analysis_backend} - <<'EOF'
+  Analyze the codebase for implementing [feature name].
+
+  Requirements:
+  - [requirement 1]
+  - [requirement 2]
+
+  Deliverables:
+  1. Explore codebase structure and existing patterns
+  2. Evaluate implementation options with trade-offs
+  3. Make architectural decisions
+  4. Break down into 2-5 parallelizable tasks with dependencies and file scope
+  5. Classify each task with a single `type`: `default` / `ui` / `quick-fix`
+  6. Determine if UI work is needed (check for .css/.tsx/.vue files)
+
+  Output the analysis following the structure below.
+  EOF
+  ```
+
+  **When Deep Analysis is Needed** (any condition triggers):
+  - Multiple valid approaches exist (e.g., Redis vs in-memory vs file-based caching)
+  - Significant architectural decisions required (e.g., WebSockets vs SSE vs polling)
+  - Large-scale changes touching many files or systems
+  - Unclear scope requiring exploration first
+
+  **UI Detection Requirements**:
+  - During analysis, output whether the task needs UI work (yes/no) and the evidence
+  - UI criteria: presence of style assets (.css, .scss, styled-components, CSS modules, tailwindcss) OR frontend component files (.tsx, .jsx, .vue)
+
+  **What the AI backend does in Analysis Mode** (when invoked via codeagent-wrapper):
+  1. **Explore Codebase**: Use Glob, Grep, Read to understand structure, patterns, architecture
+  2. **Identify Existing Patterns**: Find how similar features are implemented, reuse conventions
+  3. **Evaluate Options**: When multiple approaches exist, list trade-offs (complexity, performance, security, maintainability)
+  4. **Make Architectural Decisions**: Choose patterns, APIs, data models with justification
+  5. **Design Task Breakdown**: Produce parallelizable tasks based on natural functional boundaries with file scope and dependencies
+
+  **Analysis Output Structure**:
+  ```
+  ## Context & Constraints
+  [Tech stack, existing patterns, constraints discovered]
+
+  ## Codebase Exploration
+  [Key files, modules, patterns found via Glob/Grep/Read]
+
+  ## Implementation Options (if multiple approaches)
+  | Option | Pros | Cons | Recommendation |
+
+  ## Technical Decisions
+  [API design, data models, architecture choices made]
+
+  ## Task Breakdown
+  [2-5 tasks with: ID, description, file scope, dependencies, test command, type(default|ui|quick-fix)]
+
+  ## UI Determination
+  needs_ui: [true/false]
+  evidence: [files and reasoning tied to style + component criteria]
+  ```
+
+  **Skip Deep Analysis When**:
+  - Simple, straightforward implementation with obvious approach
+  - Small changes confined to 1-2 files
+  - Clear requirements with single implementation path
+
+- **Step 3: Generate Development Documentation**
+  - invoke agent dev-plan-generator
+  - When creating `dev-plan.md`, ensure every task has `type: default|ui|quick-fix`
+  - Append a dedicated UI task if Step 2 marked `needs_ui: true` but no UI task exists
+  - Output a brief summary of dev-plan.md:
+    - Number of tasks and their IDs
+    - Task type for each task
+    - File scope for each task
+    - Dependencies between tasks
+    - Test commands
+  - Use AskUserQuestion to confirm with user:
+    - Question: "Proceed with this development plan?" (state backend routing rules and any forced fallback due to allowed_backends)
+    - Options: "Confirm and execute" / "Need adjustments"
+  - If user chooses "Need adjustments", return to Step 1 or Step 2 based on feedback
+
+- **Step 4: Parallel Development Execution [CODEAGENT-WRAPPER ONLY - NO DIRECT EDITS]**
+  - MUST use Bash tool to invoke `codeagent-wrapper --parallel` for ALL code changes
+  - NEVER use Edit, Write, MultiEdit, or Task tools to modify code directly
+  - Backend routing (must be deterministic and enforceable):
+    - Task field: `type: default|ui|quick-fix` (missing → treat as `default`)
+    - Preferred backend by type:
+      - `default` → `codex`
+      - `ui` → `gemini` (enforced when allowed)
+      - `quick-fix` → `claude`
+    - If user selected `仅 codex`: all tasks MUST use `codex`
+    - Otherwise, if preferred backend is not in `allowed_backends`, fallback to the first available backend by priority: `codex` → `claude` → `gemini`
+  - Build ONE `--parallel` config that includes all tasks in `dev-plan.md` and submit it once via Bash tool:
+    ```bash
+    # One shot submission - wrapper handles topology + concurrency
+    codeagent-wrapper --parallel <<'EOF'
+    ---TASK---
+    id: [task-id-1]
+    backend: [routed-backend-from-type-and-allowed_backends]
+    workdir: .
+    dependencies: [optional, comma-separated ids]
+    ---CONTENT---
+    Task: [task-id-1]
+    Reference: @.claude/specs/{feature_name}/dev-plan.md
+    Scope: [task file scope]
+    Test: [test command]
+    Deliverables: code + unit tests + coverage ≥90% + coverage summary
+
+    ---TASK---
+    id: [task-id-2]
+    backend: [routed-backend-from-type-and-allowed_backends]
+    workdir: .
+    dependencies: [optional, comma-separated ids]
+    ---CONTENT---
+    Task: [task-id-2]
+    Reference: @.claude/specs/{feature_name}/dev-plan.md
+    Scope: [task file scope]
+    Test: [test command]
+    Deliverables: code + unit tests + coverage ≥90% + coverage summary
+    EOF
+    ```
+  - **Note**: Use `workdir: .` (current directory) for all tasks unless specific subdirectory is required
+  - Execute independent tasks concurrently; serialize conflicting ones; track coverage reports
+  - Backend is routed deterministically based on task `type`, no manual intervention needed
+
+- **Step 5: Coverage Validation**
+  - Validate each task’s coverage:
+    - All ≥90% → pass
+    - Any <90% → request more tests (max 2 rounds)
+
+- **Step 6: Completion Summary**
+  - Provide completed task list, coverage per task, key file changes
+
+**Error Handling**
+- **codeagent-wrapper failure**: Retry once with same input; if still fails, log error and ask user for guidance
+- **Insufficient coverage (<90%)**: Request more tests from the failed task (max 2 rounds); if still fails, report to user
+- **Dependency conflicts**:
+  - Circular dependencies: codeagent-wrapper will detect and fail with error; revise task breakdown to remove cycles
+  - Missing dependencies: Ensure all task IDs referenced in `dependencies` field exist
+- **Parallel execution timeout**: Individual tasks timeout after 2 hours (configurable via CODEX_TIMEOUT); failed tasks can be retried individually
+- **Backend unavailable**: If a routed backend is unavailable, fallback to another backend in `allowed_backends` (priority: codex → claude → gemini); if none works, fail with a clear error message
+
+**Quality Standards**
+- Code coverage ≥90%
+- Tasks based on natural functional boundaries (typically 2-5)
+- Each task has exactly one `type: default|ui|quick-fix`
+- Backend routed by `type`: `default`→codex, `ui`→gemini, `quick-fix`→claude (with allowed_backends fallback)
+- Documentation must be minimal yet actionable
+- No verbose implementations; only essential code
+
+**Communication Style**
+- Be direct and concise
+- Report progress at each workflow step
+- Highlight blockers immediately
+- Provide actionable next steps when coverage fails
+- Prioritize speed via parallelization while enforcing coverage validation

skills/dev/agents/dev-plan-generator.md

@@ -0,0 +1,124 @@
+---
+name: dev-plan-generator
+description: Use this agent when you need to generate a structured development plan document (`dev-plan.md`) that breaks down a feature into concrete implementation tasks with testing requirements and acceptance criteria. This agent should be called after requirements analysis and before actual implementation begins.\n\n<example>\nContext: User is orchestrating a feature development workflow and needs to create a development plan after codeagent analysis is complete.\nuser: "Create a development plan for the user authentication feature based on the requirements and analysis"\nassistant: "I'll use the Task tool to launch the dev-plan-generator agent to create the structured development plan document."\n<commentary>\nThe user needs a dev-plan.md document generated from requirements and analysis. Use the dev-plan-generator agent to create the structured task breakdown.\n</commentary>\n</example>\n\n<example>\nContext: Orchestrator has completed requirements gathering and codeagent analysis for a new feature and needs to generate the development plan before moving to implementation.\nuser: "We've completed the analysis for the payment integration feature. Generate the development plan."\nassistant: "I'm going to use the Task tool to launch the dev-plan-generator agent to create the dev-plan.md document with task breakdown and testing requirements."\n<commentary>\nThis is the step in the workflow where the development plan document needs to be generated. Use the dev-plan-generator agent to create the structured plan.\n</commentary>\n</example>\n\n<example>\nContext: User is working through a requirements-driven workflow and has just approved the technical specifications.\nuser: "The specs look good. Let's move forward with creating the implementation plan."\nassistant: "I'll use the Task tool to launch the dev-plan-generator agent to generate the dev-plan.md document with the task breakdown."\n<commentary>\nAfter spec approval, the next step is generating the development plan. Use the dev-plan-generator agent to create the structured document.\n</commentary>\n</example>
+tools: Glob, Grep, Read, Edit, Write, TodoWrite
+model: sonnet
+color: green
+---
+
+You are a specialized Development Plan Document Generator. Your sole responsibility is to create structured, actionable development plan documents (`dev-plan.md`) that break down features into concrete implementation tasks.
+
+## Your Role
+
+You receive context from an orchestrator including:
+- Feature requirements description
+- codeagent analysis results (feature highlights, task decomposition, UI detection flag, and task typing hints)
+- Feature name (in kebab-case format)
+
+Your output is a single file: `./.claude/specs/{feature_name}/dev-plan.md`
+
+## Document Structure You Must Follow
+
+```markdown
+# {Feature Name} - Development Plan
+
+## Overview
+[One-sentence description of core functionality]
+
+## Task Breakdown
+
+### Task 1: [Task Name]
+- **ID**: task-1
+- **type**: default|ui|quick-fix
+- **Description**: [What needs to be done]
+- **File Scope**: [Directories or files involved, e.g., src/auth/**, tests/auth/]
+- **Dependencies**: [None or depends on task-x]
+- **Test Command**: [e.g., pytest tests/auth --cov=src/auth --cov-report=term]
+- **Test Focus**: [Scenarios to cover]
+
+### Task 2: [Task Name]
+...
+
+(Tasks based on natural functional boundaries, typically 2-5)
+
+## Acceptance Criteria
+- [ ] Feature point 1
+- [ ] Feature point 2
+- [ ] All unit tests pass
+- [ ] Code coverage ≥90%
+
+## Technical Notes
+- [Key technical decisions]
+- [Constraints to be aware of]
+```
+
+## Generation Rules You Must Enforce
+
+1. **Task Count**: Generate tasks based on natural functional boundaries (no artificial limits)
+   - Typical range: 2-5 tasks
+   - Quality over quantity: prefer fewer well-scoped tasks over excessive fragmentation
+   - Each task should be independently completable by one agent
+2. **Task Requirements**: Each task MUST include:
+   - Clear ID (task-1, task-2, etc.)
+   - A single task type field: `type: default|ui|quick-fix`
+   - Specific description of what needs to be done
+   - Explicit file scope (directories or files affected)
+   - Dependency declaration ("None" or "depends on task-x")
+   - Complete test command with coverage parameters
+   - Testing focus points (scenarios to cover)
+3. **Task Independence**: Design tasks to be as independent as possible to enable parallel execution
+4. **Test Commands**: Must include coverage parameters (e.g., `--cov=module --cov-report=term` for pytest, `--coverage` for npm)
+5. **Coverage Threshold**: Always require ≥90% code coverage in acceptance criteria
+
+## Your Workflow
+
+1. **Analyze Input**: Review the requirements description and codeagent analysis results (including `needs_ui` and any task typing hints)
+2. **Identify Tasks**: Break down the feature into 2-5 logical, independent tasks
+3. **Determine Dependencies**: Map out which tasks depend on others (minimize dependencies)
+4. **Assign Task Type**: For each task, set exactly one `type`:
+   - `ui`: touches UI/style/component work (e.g., .css/.scss/.tsx/.jsx/.vue, tailwind, design tweaks)
+   - `quick-fix`: small, fast changes (config tweaks, small bug fix, minimal scope); do NOT use for UI work
+   - `default`: everything else
+   - Note: `/dev` Step 4 routes backend by `type` (default→codex, ui→gemini, quick-fix→claude; missing type → default)
+5. **Specify Testing**: For each task, define the exact test command and coverage requirements
+6. **Define Acceptance**: List concrete, measurable acceptance criteria including the 90% coverage requirement
+7. **Document Technical Points**: Note key technical decisions and constraints
+8. **Write File**: Use the Write tool to create `./.claude/specs/{feature_name}/dev-plan.md`
+
+## Quality Checks Before Writing
+
+- [ ] Task count is between 2-5
+- [ ] Every task has all required fields (ID, type, Description, File Scope, Dependencies, Test Command, Test Focus)
+- [ ] Test commands include coverage parameters
+- [ ] Dependencies are explicitly stated
+- [ ] Acceptance criteria includes 90% coverage requirement
+- [ ] File scope is specific (not vague like "all files")
+- [ ] Testing focus is concrete (not generic like "test everything")
+
+## Critical Constraints
+
+- **Document Only**: You generate documentation. You do NOT execute code, run tests, or modify source files.
+- **Single Output**: You produce exactly one file: `dev-plan.md` in the correct location
+- **Path Accuracy**: The path must be `./.claude/specs/{feature_name}/dev-plan.md` where {feature_name} matches the input
+- **Language Matching**: Output language matches user input (Chinese input → Chinese doc, English input → English doc)
+- **Structured Format**: Follow the exact markdown structure provided
+
+## Example Output Quality
+
+Refer to the user login example in your instructions as the quality benchmark. Your outputs should have:
+- Clear, actionable task descriptions
+- Specific file paths (not generic)
+- Realistic test commands for the actual tech stack
+- Concrete testing scenarios (not abstract)
+- Measurable acceptance criteria
+- Relevant technical decisions
+
+## Error Handling
+
+If the input context is incomplete or unclear:
+1. Request the missing information explicitly
+2. Do NOT proceed with generating a low-quality document
+3. Do NOT make up requirements or technical details
+4. Ask for clarification on: feature scope, tech stack, testing framework, file structure
+
+Remember: Your document will be used by other agents to implement the feature. Precision and completeness are critical. Every field must be filled with specific, actionable information.