claude-code-workflow 6.1.4 → 6.2.2

package/.claude/skills/command-guide/reference/commands/workflow/tools/task-generate-tdd.md

@@ -113,7 +113,7 @@ Phase 2: Agent Execution (Document Generation)
     // Existing test patterns and coverage analysis
   },
   "mcp_capabilities": {
-    "code_index": true,
+    "codex_lens": true,
     "exa_code": true,
     "exa_web": true
   }
@@ -152,9 +152,14 @@ Phase 2: Agent Execution (Document Generation)
    roleAnalysisPaths.forEach(path => Read(path));
    ```
 
-5. **Load Conflict Resolution** (from context-package.json, if exists)
+5. **Load Conflict Resolution** (from conflict-resolution.json, if exists)
    ```javascript
-   if (contextPackage.brainstorm_artifacts.conflict_resolution?.exists) {
+   // Check for new conflict-resolution.json format
+   if (contextPackage.conflict_detection?.resolution_file) {
+     Read(contextPackage.conflict_detection.resolution_file)  // .process/conflict-resolution.json
+   }
+   // Fallback: legacy brainstorm_artifacts path
+   else if (contextPackage.brainstorm_artifacts?.conflict_resolution?.exists) {
      Read(contextPackage.brainstorm_artifacts.conflict_resolution.path)
    }
    ```
@@ -223,7 +228,7 @@ If conflict_risk was medium/high, modifications have been applied to:
 - **guidance-specification.md**: Design decisions updated to resolve conflicts
 - **Role analyses (*.md)**: Recommendations adjusted for compatibility
 - **context-package.json**: Marked as "resolved" with conflict IDs
-- NO separate CONFLICT_RESOLUTION.md file (conflicts resolved in-place)
+- Conflict resolution results stored in conflict-resolution.json
 
 ### MCP Analysis Results (Optional)
 **Code Structure**: {mcp_code_index_results}
@@ -333,7 +338,7 @@ Generate all three documents and report completion status:
 - TDD cycles configured: N cycles with quantified test cases
 - Artifacts integrated: synthesis-spec, guidance-specification, N role analyses
 - Test context integrated: existing patterns and coverage
-- MCP enhancements: code-index, exa-research
+- MCP enhancements: CodexLens, exa-research
 - Session ready for TDD execution: /workflow:execute
 `
 )
@@ -373,10 +378,12 @@ const agentContext = {
     .flatMap(role => role.files)
     .map(file => Read(file.path)),
 
-  // Load conflict resolution if exists (from context package)
-  conflict_resolution: brainstorm_artifacts.conflict_resolution?.exists
-    ? Read(brainstorm_artifacts.conflict_resolution.path)
-    : null,
+  // Load conflict resolution if exists (prefer new JSON format)
+  conflict_resolution: context_package.conflict_detection?.resolution_file
+    ? Read(context_package.conflict_detection.resolution_file)  // .process/conflict-resolution.json
+    : (brainstorm_artifacts?.conflict_resolution?.exists
+        ? Read(brainstorm_artifacts.conflict_resolution.path)
+        : null),
 
   // Optional MCP enhancements
   mcp_analysis: executeMcpDiscovery()
@@ -408,7 +415,7 @@ This section provides quick reference for TDD task JSON structure. For complete
 │   ├── IMPL-3.2.json                # Complex feature subtask (if needed)
 │   └── ...
 └── .process/
-    ├── CONFLICT_RESOLUTION.md       # Conflict resolution strategies (if conflict_risk ≥ medium)
+    ├── conflict-resolution.json     # Conflict resolution results (if conflict_risk ≥ medium)
     ├── test-context-package.json    # Test coverage analysis
     ├── context-package.json         # Input from context-gather
     ├── context_package_path         # Path to smart context package

package/.claude/skills/command-guide/reference/commands/workflow/tools/test-concept-enhanced.md

@@ -89,7 +89,7 @@ Template: ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.t
 
 ## EXECUTION STEPS
 1. Execute Gemini analysis:
-   cd .workflow/active/{test_session_id}/.process && gemini -p "$(cat ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.txt)" --approval-mode yolo
+   ccw cli -p "$(cat ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.txt)" --tool gemini --mode write --cd .workflow/active/{test_session_id}/.process
 
 2. Generate TEST_ANALYSIS_RESULTS.md:
    Synthesize gemini-test-analysis.md into standardized format for task generation

package/.claude/skills/command-guide/reference/commands/workflow/ui-design/import-from-code.md

@@ -180,14 +180,14 @@ Task(subagent_type="ui-design-agent",
   - Pattern: rg → Extract values → Compare → If different → Read full context with comments → Record conflict
   - Alternative (if many files): Execute CLI analysis for comprehensive report:
     \`\`\`bash
-    cd ${source} && gemini -p \"
+    ccw cli -p \"
     PURPOSE: Detect color token conflicts across all CSS/SCSS/JS files
     TASK: • Scan all files for color definitions • Identify conflicting values • Extract semantic comments
     MODE: analysis
     CONTEXT: @**/*.css @**/*.scss @**/*.js @**/*.ts
     EXPECTED: JSON report listing conflicts with file:line, values, semantic context
     RULES: Focus on core tokens | Report ALL variants | analysis=READ-ONLY
-    \"
+    \" --tool gemini --mode analysis --cd ${source}
     \`\`\`
 
   **Step 1: Load file list**
@@ -295,14 +295,14 @@ Task(subagent_type="ui-design-agent",
   - Pattern: rg → Identify animation types → Map framework usage → Prioritize extraction targets
   - Alternative (if complex framework mix): Execute CLI analysis for comprehensive report:
     \`\`\`bash
-    cd ${source} && gemini -p \"
+    ccw cli -p \"
     PURPOSE: Detect animation frameworks and patterns
     TASK: • Identify frameworks • Map animation patterns • Categorize by complexity
     MODE: analysis
     CONTEXT: @**/*.css @**/*.scss @**/*.js @**/*.ts
     EXPECTED: JSON report listing frameworks, animation types, file locations
     RULES: Focus on framework consistency | Map all animations | analysis=READ-ONLY
-    \"
+    \" --tool gemini --mode analysis --cd ${source}
     \`\`\`
 
   **Step 1: Load file list**
@@ -374,14 +374,14 @@ Task(subagent_type="ui-design-agent",
   - Pattern: rg → Count occurrences → Classify by frequency → Prioritize universal components
   - Alternative (if large codebase): Execute CLI analysis for comprehensive categorization:
     \`\`\`bash
-    cd ${source} && gemini -p \"
+    ccw cli -p \"
     PURPOSE: Classify components as universal vs specialized
     TASK: • Identify UI components • Classify reusability • Map layout systems
     MODE: analysis
     CONTEXT: @**/*.css @**/*.scss @**/*.js @**/*.ts @**/*.html
     EXPECTED: JSON report categorizing components, layout patterns, naming conventions
     RULES: Focus on component reusability | Identify layout systems | analysis=READ-ONLY
-    \"
+    \" --tool gemini --mode analysis --cd ${source}
     \`\`\`
 
   **Step 1: Load file list**

package/.claude/workflows/chinese-response.md

@@ -0,0 +1,38 @@
+# 中文回复准则
+
+## 核心原则
+
+- **语言一致性**：所有回复必须使用中文（简体）
+- **专业术语**：技术术语可保留英文原文，但需添加中文解释
+- **代码注释**：代码注释使用英文（保持代码的国际化兼容性）
+
+## 回复格式
+
+### 一般对话
+- 使用简洁、清晰的中文表达
+- 避免过度使用网络用语或口语化表达
+- 保持专业、礼貌的语气
+
+### 技术讨论
+- 技术概念首次出现时可用「中文（English）」格式
+- 示例：依赖注入（Dependency Injection）
+- 后续可直接使用中文或英文缩写
+
+### 代码相关
+- 代码块内容保持英文（变量名、注释等）
+- 代码解释使用中文
+- 文件路径、命令等保持原样
+
+## 格式规范
+
+- 中英文之间添加空格：`使用 TypeScript 开发`
+- 数字与中文之间添加空格：`共有 3 个文件`
+- 标点符号使用中文全角标点：`，。！？：；`
+- 引用代码或命令时使用反引号：`npm install`
+
+## 注意事项
+
+- 不要在代码文件中写入中文（保持代码的国际化）
+- 错误信息和日志保持英文
+- Git commit 信息保持英文
+- 文档文件可根据需要使用中文

package/.claude/workflows/cli-templates/prompts/rules/rule-api.txt

@@ -0,0 +1,122 @@
+# Rule Template: API Rules (Backend/Fullstack Only)
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {FILE_EXT}: File extension pattern
+- {API_FRAMEWORK}: API framework (Express, FastAPI, etc)
+
+## Output Format
+
+```markdown
+---
+paths:
+  - "**/api/**/*.{FILE_EXT}"
+  - "**/routes/**/*.{FILE_EXT}"
+  - "**/endpoints/**/*.{FILE_EXT}"
+  - "**/controllers/**/*.{FILE_EXT}"
+  - "**/handlers/**/*.{FILE_EXT}"
+---
+
+# {TECH_STACK_NAME} API Rules
+
+## Endpoint Design
+
+[REST/GraphQL conventions from Exa research]
+
+### URL Structure
+- Resource naming (plural nouns)
+- Nesting depth limits
+- Query parameter conventions
+- Version prefixing
+
+### HTTP Methods
+- GET: Read operations
+- POST: Create operations
+- PUT/PATCH: Update operations
+- DELETE: Remove operations
+
+### Status Codes
+- 2xx: Success responses
+- 4xx: Client errors
+- 5xx: Server errors
+
+## Request Validation
+
+[Input validation patterns]
+
+### Schema Validation
+```{lang}
+// Example validation schema
+```
+
+### Required Fields
+- Validation approach
+- Error messages format
+- Sanitization rules
+
+## Response Format
+
+[Standard response structures]
+
+### Success Response
+```json
+{
+  "data": {},
+  "meta": {}
+}
+```
+
+### Pagination
+```json
+{
+  "data": [],
+  "pagination": {
+    "page": 1,
+    "limit": 20,
+    "total": 100
+  }
+}
+```
+
+## Error Responses
+
+[Error handling for APIs]
+
+### Error Format
+```json
+{
+  "error": {
+    "code": "ERROR_CODE",
+    "message": "Human readable message",
+    "details": {}
+  }
+}
+```
+
+### Common Error Codes
+- VALIDATION_ERROR
+- NOT_FOUND
+- UNAUTHORIZED
+- FORBIDDEN
+
+## Authentication & Authorization
+
+[Auth patterns]
+- Token handling
+- Permission checks
+- Rate limiting
+
+## Documentation
+
+[API documentation standards]
+- OpenAPI/Swagger
+- Inline documentation
+- Example requests/responses
+```
+
+## Content Guidelines
+
+- Focus on API-specific patterns
+- Include request/response examples
+- Cover security considerations
+- Reference framework conventions

package/.claude/workflows/cli-templates/prompts/rules/rule-components.txt

@@ -0,0 +1,122 @@
+# Rule Template: Component Rules (Frontend/Fullstack Only)
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {FILE_EXT}: File extension pattern
+- {UI_FRAMEWORK}: UI framework (React, Vue, etc)
+
+## Output Format
+
+```markdown
+---
+paths:
+  - "**/components/**/*.{FILE_EXT}"
+  - "**/ui/**/*.{FILE_EXT}"
+  - "**/views/**/*.{FILE_EXT}"
+  - "**/pages/**/*.{FILE_EXT}"
+---
+
+# {TECH_STACK_NAME} Component Rules
+
+## Component Structure
+
+[Organization patterns from Exa research]
+
+### File Organization
+```
+components/
+├── common/          # Shared components
+├── features/        # Feature-specific
+├── layout/          # Layout components
+└── ui/              # Base UI elements
+```
+
+### Component Template
+```{lang}
+// Standard component structure
+```
+
+### Naming Conventions
+- PascalCase for components
+- Descriptive names
+- Prefix conventions (if any)
+
+## Props & State
+
+[State management guidelines]
+
+### Props Definition
+```{lang}
+// Props type/interface example
+```
+
+### Props Best Practices
+- Required vs optional
+- Default values
+- Prop validation
+- Prop naming
+
+### Local State
+- When to use local state
+- State initialization
+- State updates
+
+### Shared State
+- State management approach
+- Context usage
+- Store patterns
+
+## Styling
+
+[CSS/styling conventions]
+
+### Approach
+- [CSS Modules/Styled Components/Tailwind/etc]
+
+### Style Organization
+```{lang}
+// Style example
+```
+
+### Naming Conventions
+- Class naming (BEM, etc)
+- CSS variable usage
+- Theme integration
+
+## Accessibility
+
+[A11y requirements]
+
+### Essential Requirements
+- Semantic HTML
+- ARIA labels
+- Keyboard navigation
+- Focus management
+
+### Testing A11y
+- Automated checks
+- Manual testing
+- Screen reader testing
+
+## Performance
+
+[Performance guidelines]
+
+### Optimization Patterns
+- Memoization
+- Lazy loading
+- Code splitting
+- Virtual lists
+
+### Avoiding Re-renders
+- When to memoize
+- Callback optimization
+- State structure
+```
+
+## Content Guidelines
+
+- Focus on component-specific patterns
+- Include framework-specific examples
+- Cover accessibility requirements
+- Address performance considerations

package/.claude/workflows/cli-templates/prompts/rules/rule-config.txt

@@ -0,0 +1,89 @@
+# Rule Template: Configuration Rules
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {CONFIG_FILES}: List of config file patterns
+
+## Output Format
+
+```markdown
+---
+paths:
+  - "*.config.*"
+  - ".*rc"
+  - ".*rc.{js,json,yaml,yml}"
+  - "package.json"
+  - "tsconfig*.json"
+  - "pyproject.toml"
+  - "Cargo.toml"
+  - "go.mod"
+  - ".env*"
+---
+
+# {TECH_STACK_NAME} Configuration Rules
+
+## Project Setup
+
+[Configuration guidelines from Exa research]
+
+### Essential Config Files
+- [List primary config files]
+- [Purpose of each]
+
+### Recommended Structure
+```
+project/
+├── [config files]
+├── src/
+└── tests/
+```
+
+## Tooling
+
+[Linters, formatters, bundlers]
+
+### Linting
+- Tool: [ESLint/Pylint/etc]
+- Config file: [.eslintrc/pyproject.toml/etc]
+- Key rules to enable
+
+### Formatting
+- Tool: [Prettier/Black/etc]
+- Integration with editor
+- Pre-commit hooks
+
+### Build Tools
+- Bundler: [Webpack/Vite/etc]
+- Build configuration
+- Optimization settings
+
+## Environment
+
+[Environment management]
+
+### Environment Variables
+- Naming conventions
+- Required vs optional
+- Secret handling
+- .env file structure
+
+### Development vs Production
+- Environment-specific configs
+- Feature flags
+- Debug settings
+
+## Dependencies
+
+[Dependency management]
+- Lock file usage
+- Version pinning strategy
+- Security updates
+- Peer dependencies
+```
+
+## Content Guidelines
+
+- Focus on config file best practices
+- Include security considerations
+- Cover development workflow setup
+- Mention CI/CD integration where relevant

package/.claude/workflows/cli-templates/prompts/rules/rule-core.txt

@@ -0,0 +1,60 @@
+# Rule Template: Core Principles
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {FILE_EXT}: File extension pattern
+
+## Output Format
+
+```markdown
+---
+paths: **/*.{FILE_EXT}
+---
+
+# {TECH_STACK_NAME} Core Principles
+
+## Philosophy
+
+[Synthesize core philosophy from Exa research]
+- Key paradigms and mental models
+- Design philosophy
+- Community conventions
+
+## Naming Conventions
+
+[Language-specific naming rules]
+- Variables and functions
+- Classes and types
+- Files and directories
+- Constants and enums
+
+## Code Organization
+
+[Structure and module guidelines]
+- File structure patterns
+- Module boundaries
+- Import organization
+- Dependency management
+
+## Type Safety
+
+[Type system best practices - if applicable]
+- Type annotation guidelines
+- Generic usage patterns
+- Type inference vs explicit types
+- Null/undefined handling
+
+## Documentation
+
+[Documentation standards]
+- Comment style
+- JSDoc/docstring format
+- README conventions
+```
+
+## Content Guidelines
+
+- Focus on universal principles that apply to ALL files
+- Keep rules actionable and specific
+- Include rationale for each rule
+- Reference official style guides where applicable

package/.claude/workflows/cli-templates/prompts/rules/rule-patterns.txt

@@ -0,0 +1,70 @@
+# Rule Template: Implementation Patterns
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {FILE_EXT}: File extension pattern
+
+## Output Format
+
+```markdown
+---
+paths: src/**/*.{FILE_EXT}
+---
+
+# {TECH_STACK_NAME} Implementation Patterns
+
+## Common Patterns
+
+[With code examples from Exa research]
+
+### Pattern 1: [Name]
+```{lang}
+// Example code
+```
+**When to use**: [Context]
+**Benefits**: [Why this pattern]
+
+### Pattern 2: [Name]
+...
+
+## Anti-Patterns to Avoid
+
+[Common mistakes with examples]
+
+### Anti-Pattern 1: [Name]
+```{lang}
+// Bad example
+```
+**Problem**: [Why it's bad]
+**Solution**: [Better approach]
+
+## Error Handling
+
+[Error handling conventions]
+- Error types and hierarchy
+- Try-catch patterns
+- Error propagation
+- Logging practices
+
+## Async Patterns
+
+[Asynchronous code conventions - if applicable]
+- Promise handling
+- Async/await usage
+- Concurrency patterns
+- Error handling in async code
+
+## State Management
+
+[State handling patterns]
+- Local state patterns
+- Shared state approaches
+- Immutability practices
+```
+
+## Content Guidelines
+
+- Focus on source code implementation
+- Provide concrete code examples
+- Show both good and bad patterns
+- Include context for when to apply each pattern