claude-code-workflow 6.2.3 → 6.2.5

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

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

package/.claude/workflows/cli-templates/fix-plan-template.json

@@ -1,75 +0,0 @@
-{
-  "_template_description": "Template for fix planning output. Planning agent reads this template and generates actual fix-plan.json",
-  "_usage": "Planning agent should follow this structure when analyzing findings and creating fix plan",
-
-  "plan_id": "<string: plan-{timestamp}>",
-  "created_at": "<string: ISO8601 timestamp>",
-  "total_findings": "<number: total findings to fix>",
-
-  "execution_strategy": {
-    "approach": "<string: hybrid|parallel|serial>",
-    "parallel_limit": "<number: max concurrent agents, default 3>",
-    "total_stages": "<number: how many stages in timeline>",
-    "rationale": "<string: explain why this strategy was chosen>"
-  },
-
-  "groups": [
-    {
-      "group_id": "<string: unique group identifier like G1, G2, ...>",
-      "group_name": "<string: descriptive name for this group>",
-      "findings": ["<array of finding IDs>"],
-
-      "fix_strategy": {
-        "approach": "<string: high-level fix approach>",
-        "rationale": "<string: why these findings were grouped together>",
-        "complexity": "<string: low|medium|high>",
-        "estimated_duration_minutes": "<number: estimated time>",
-        "test_pattern": "<string: test file glob pattern like tests/auth/**/*.test.*>",
-        "rollback_plan": "<string: what to do if fix fails>"
-      },
-
-      "risk_assessment": {
-        "level": "<string: low|medium|high|critical>",
-        "concerns": ["<array of strings: potential risks>"],
-        "mitigation": "<string: how to mitigate risks>"
-      }
-    }
-  ],
-
-  "timeline": [
-    {
-      "stage": "<number: stage number 1-indexed>",
-      "groups": ["<array of group IDs to execute in this stage>"],
-      "execution_mode": "<string: parallel|serial>",
-      "depends_on": ["<optional: array of group IDs this stage depends on>"],
-      "rationale": "<string: why these groups are in this stage with this mode>"
-    }
-  ],
-
-  "_instructions": {
-    "grouping_principles": [
-      "Group findings in the same file with same dimension",
-      "Group findings with similar root causes (high semantic similarity)",
-      "Consider file dependencies and execution order",
-      "Balance group sizes for efficient parallel execution"
-    ],
-    "execution_strategy_guidelines": [
-      "Use parallel for independent groups in different files",
-      "Use serial for dependent changes (e.g., shared utilities)",
-      "Limit parallelism to 3 concurrent agents to avoid resource contention",
-      "High-risk groups should be isolated for careful monitoring"
-    ],
-    "test_strategy_guidelines": [
-      "Identify test files related to changed code",
-      "Use specific patterns for faster test execution",
-      "Ensure test coverage captures all fix impacts",
-      "Define clear pass criteria (usually 100% pass rate)"
-    ],
-    "risk_assessment_guidelines": [
-      "Low: Simple fixes with comprehensive test coverage",
-      "Medium: Moderate changes affecting multiple components",
-      "High: Core logic changes or security-critical fixes",
-      "Critical: Database schema changes or breaking API changes"
-    ]
-  }
-}

package/.claude/workflows/cli-templates/fix-progress-template.json

@@ -1,48 +0,0 @@
-{
-  "$schema": "fix-progress-template.json",
-  "$comment": "Template for fix-progress-{N}.json - one per group, initialized by planning agent, updated by execution agent",
-
-  "progress_id": "fix-progress-N",
-  "group_id": "GN",
-  "group_name": "Group name from fix plan",
-  "status": "pending",
-  "phase": "waiting",
-
-  "assigned_agent": null,
-  "started_at": null,
-  "last_update": "ISO 8601 timestamp",
-
-  "findings": [
-    {
-      "finding_id": "finding-uuid",
-      "finding_title": "Finding title from review",
-      "file": "path/to/file.ts",
-      "line": 0,
-      "status": "pending",
-      "result": null,
-      "attempts": 0,
-      "started_at": null,
-      "completed_at": null,
-      "commit_hash": null,
-      "test_passed": null
-    }
-  ],
-
-  "summary": {
-    "total_findings": 0,
-    "pending": 0,
-    "in_progress": 0,
-    "fixed": 0,
-    "failed": 0,
-    "percent_complete": 0.0
-  },
-
-  "current_finding": null,
-
-  "flow_control": {
-    "implementation_approach": [],
-    "current_step": null
-  },
-
-  "errors": []
-}

package/.claude/workflows/cli-templates/memory/style-skill-memory/skill-md-template.md

@@ -1,299 +0,0 @@
-# SKILL.md Template for Style Memory Package
-
----
-name: style-{package_name}
-description: {intelligent_description}
----
-
-# {Package Name} Style SKILL Package
-
-## 🔍 Quick Index
-
-### Available JSON Fields
-
-**High-level structure overview for quick understanding**
-
-#### design-tokens.json
-```
-.colors             # Color palette (brand, semantic, surface, text, border)
-.typography         # Font families, sizes, weights, line heights
-.spacing            # Spacing scale (xs, sm, md, lg, xl, etc.)
-.border_radius      # Border radius tokens (sm, md, lg, etc.)
-.shadows            # Shadow definitions (elevation levels)
-._metadata          # Usage recommendations and guidelines
-  ├─ .usage_recommendations.typography
-  ├─ .usage_recommendations.spacing
-  └─ ...
-```
-
-#### layout-templates.json
-```
-.layout_templates                    # Component layout patterns
-  ├─ .<component_name>
-  │   ├─ .component_type            # "universal" or "specialized"
-  │   ├─ .variants                  # Component variants array
-  │   ├─ .usage_guide               # Usage guidelines
-  │   │   ├─ .common_sizes
-  │   │   ├─ .variant_recommendations
-  │   │   ├─ .usage_context
-  │   │   └─ .accessibility_tips
-  │   └─ ...
-```
-
-#### animation-tokens.json (if available)
-```
-.duration           # Animation duration tokens
-.easing            # Easing function tokens
-```
-
----
-
-
-### Progressive jq Usage Guide
-
-#### 📦 Package Overview
-
-**Base Location**: `.workflow/reference_style/{package_name}/`
-
-**JSON Files**:
-- **Design Tokens**: `.workflow/reference_style/{package_name}/design-tokens.json`
-- **Layout Templates**: `.workflow/reference_style/{package_name}/layout-templates.json`
-- **Animation Tokens**: `.workflow/reference_style/{package_name}/animation-tokens.json` {has_animations ? "(available)" : "(not available)"}
-
-**⚠️ Usage Note**: All jq commands below should be executed with directory context. Use the pattern:
-```bash
-cd .workflow/reference_style/{package_name} && jq '<query>' <file>.json
-```
-
-#### 🔰 Level 0: Basic Queries (~5K tokens)
-
-```bash
-# View entire file
-jq '.' <file>.json
-
-# List top-level keys
-jq 'keys' <file>.json
-
-# Extract specific field
-jq '.<field_name>' <file>.json
-```
-
-**Use when:** Quick reference, first-time exploration
-
----
-
-#### 🎯 Level 1: Filter & Extract (~12K tokens)
-
-```bash
-# Count items
-jq '.<field> | length' <file>.json
-
-# Filter by condition
-jq '[.<field>[] | select(.<key> == "<value>")]' <file>.json
-
-# Extract names
-jq -r '.<field> | to_entries[] | select(<condition>) | .key' <file>.json
-
-# Formatted output
-jq -r '.<field> | to_entries[] | "\(.key): \(.value)"' <file>.json
-```
-
-**Universal components filter:** `select(.component_type == "universal")`
-
-**Use when:** Building components, filtering data
-
----
-
-#### 🚀 Level 2: Combine & Transform (~20K tokens)
-
-```bash
-# Pattern search
-jq '.<field> | keys[] | select(. | contains("<pattern>"))' <file>.json
-
-# Regex match
-jq -r '.<field> | to_entries[] | select(.key | test("<regex>"; "i"))' <file>.json
-
-# Multi-file query
-jq '.' file1.json && jq '.' file2.json
-
-# Nested extraction
-jq '.<field>["<name>"].<nested_field>' <file>.json
-
-# Preview server (requires directory context)
-cd .workflow/reference_style/{package_name} && python -m http.server 8080
-```
-
-**Use when:** Complex queries, comprehensive analysis
-
----
-
-### Quick Reference: Consistency vs Adaptation
-
-| Aspect | Prioritize Consistency | Prioritize Adaptation |
-|--------|----------------------|---------------------|
-| **UI Components** | Standard buttons, inputs, cards | Hero sections, landing pages |
-| **Spacing** | Component internal padding | Page layout, section gaps |
-| **Typography** | Body text, headings (h1-h6) | Display text, metric numbers |
-| **Colors** | Brand colors, semantic states | Marketing accents, data viz |
-| **Radius** | Interactive elements | Feature cards, containers |
-
----
-
-## 📖 How to Use This SKILL
-
-### Quick Access Pattern
-
-**This SKILL provides design references, NOT executable code.** To use the design system:
-
-1. **Query JSON files with jq commands** 
-2. **Extract relevant tokens** for your implementation
-3. **Adapt values** based on your specific design needs
-
-
-### Progressive Loading
-
-- **Level 0** (~5K tokens): Quick token reference with `jq '.colors'`, `jq '.typography'`
-- **Level 1** (~12K tokens): Component filtering with `select(.component_type == "universal")`
-- **Level 2** (~20K tokens): Complex queries, animations, and preview
-
----
-## ⚡ Core Rules
-
-1. **Reference, Not Requirements**: This is a design reference system for inspiration and guidance. **DO NOT rigidly copy values.** Analyze the patterns and principles, then adapt creatively to build the optimal design for your specific requirements. Your project's unique needs, brand identity, and user context should drive the final design decisions.
-
-2. **Universal Components Only**: When using `layout-templates.json`, **ONLY** reference components where `component_type: "universal"`. **IGNORE** `component_type: "specialized"`.
-
-3. **Token Adaptation**: Adjust design tokens (colors, spacing, typography, shadows, etc.) based on:
-   - Brand requirements and identity
-   - Accessibility standards (WCAG compliance, readability)
-   - Platform conventions (mobile/desktop, iOS/Android/Web)
-   - Context needs (light/dark mode, responsive breakpoints)
-   - User experience goals and interaction patterns
-   - Performance and technical constraints
-
----
-
-## ⚖️ Token Adaptation Strategy
-
-### Balancing Consistency and Flexibility
-
-**The Core Problem**: Reference tokens may not have suitable sizes or styles for your new interface needs. Blindly copying leads to poor, rigid design. But ignoring tokens breaks visual consistency.
-
-**The Solution**: Use tokens as a **pattern foundation**, not a value prison.
-
----
-
-### Decision Framework
-
-**When to Use Existing Tokens (Maintain Consistency)**:
-- ✅ Common UI elements (buttons, cards, inputs, typography hierarchy)
-- ✅ Repeated patterns across multiple pages
-- ✅ Standard interactions (hover, focus, active states)
-- ✅ When existing token serves the purpose adequately
-
-**When to Extend Tokens (Adapt for New Needs)**:
-- ✅ New component type not in reference system
-- ✅ Existing token creates visually awkward result
-- ✅ Special context requires unique treatment (hero sections, landing pages, data visualization)
-- ✅ Target device/platform has different constraints (mobile vs desktop)
-
-
-
-### Integration Guidelines
-
-**1. Document Your Extensions**
-When you create new token values:
-- Note the pattern/method used (interpolation, extrapolation, etc.)
-- Document the specific use case
-- Consider if it should be added to the design system
-
-**2. Maintain Visual Consistency**
-- Use extended values sparingly (don't create 50 spacing tokens)
-- Prefer using existing tokens when "close enough" (90% fit is often acceptable)
-- Group extended tokens by context (e.g., "hero-section-padding", "dashboard-metric-size")
-
-**3. Respect Core Patterns**
-- **Color**: Preserve hue and semantic meaning, adjust lightness/saturation
-- **Spacing**: Follow progression pattern (linear/geometric)
-- **Typography**: Maintain scale ratio and line-height relationships
-- **Radius**: Continue shape language (sharp vs rounded personality)
-
-**4. Know When to Break Rules**
-Sometimes you need unique values for special contexts:
-- Landing page hero sections
-- Marketing/promotional components
-- Data visualization (charts, graphs)
-- Platform-specific requirements
-
-**For these cases**: Create standalone tokens with clear naming (`hero-title-size`, `chart-accent-color`) rather than forcing into standard scale.
-
----
-
-## 🎨 Style Understanding & Design References
-
-**IMPORTANT**: These are reference values and patterns extracted from codebase for inspiration. **DO NOT copy rigidly.** Use them as a starting point to understand design patterns, then creatively adapt to build the optimal solution for your specific project requirements, user needs, and brand identity.
-
-### Design Principles
-
-**Dynamically generated based on design token characteristics:**
-
-{GENERATE_PRINCIPLES_FROM_DESIGN_ANALYSIS}
-
-{IF DESIGN_ANALYSIS.has_colors:
-**Color System**
-- Semantic naming: {DESIGN_ANALYSIS.color_semantic ? "primary/secondary/accent hierarchy" : "descriptive names"}
-- Use color intentionally to guide attention and convey meaning
-- Maintain consistent color relationships for brand identity
-- Ensure sufficient contrast ratios (WCAG AA/AAA) for accessibility
-}
-
-{IF DESIGN_ANALYSIS.spacing_pattern detected:
-**Spatial Rhythm**
-- Primary scale pattern: {DESIGN_ANALYSIS.spacing_scale} (derived from analysis, represents actual token values)
-- Pattern characteristics: {DESIGN_ANALYSIS.spacing_pattern} (e.g., "primarily geometric with practical refinements")
-- {DESIGN_ANALYSIS.spacing_pattern == "geometric" ? "Geometric progression provides clear hierarchy with exponential growth" : "Linear progression offers subtle gradations for fine control"}
-- Apply systematically: smaller values (4-12px) for compact elements, medium (16-32px) for standard spacing, larger (48px+) for section breathing room
-- Note: Practical scales may deviate slightly from pure mathematical patterns to optimize for real-world UI needs
-}
-
-{IF DESIGN_ANALYSIS.has_typography with typography_hierarchy:
-**Typographic System**
-- Type scale establishes content hierarchy and readability
-- Size progression: {DESIGN_ANALYSIS.typography_scale_example} (e.g., "12px→14px→16px→20px→24px")
-- Use scale consistently: body text at base, headings at larger sizes
-- Maintain adequate line-height for readability (1.4-1.6 for body text)
-}
-
-{IF DESIGN_ANALYSIS.has_radius:
-**Shape Language**
-- Radius style: {DESIGN_ANALYSIS.radius_style} (e.g., "sharp <4px: modern, technical" or "rounded >8px: friendly, approachable")
-- Creates visual personality: sharp = precision, rounded = warmth
-- Apply consistently across similar elements (all cards, all buttons)
-- Match to brand tone: corporate/technical = sharper, consumer/friendly = rounder
-}
-
-{IF DESIGN_ANALYSIS.has_shadows:
-**Depth & Elevation**
-- Shadow pattern: {DESIGN_ANALYSIS.shadow_pattern} (e.g., "elevation-based: subtle→moderate→prominent")
-- Use shadows to indicate interactivity and component importance
-- Consistent application reinforces spatial relationships
-- Subtle for static cards, prominent for floating/interactive elements
-}
-
-{IF DESIGN_ANALYSIS.has_animations:
-**Motion & Timing**
-- Duration range: {DESIGN_ANALYSIS.animation_range} (e.g., "100ms (fast feedback) to 300ms (content transitions)")
-- Easing variety: {DESIGN_ANALYSIS.easing_variety} (e.g., "ease-in-out for natural motion, ease-out for UI responses")
-- Fast durations for immediate feedback, slower for spatial changes
-- Consistent timing creates predictable, polished experience
-}
-
-{ALWAYS include:
-**Accessibility First**
-- Minimum 4.5:1 contrast for text, 3:1 for UI components (WCAG AA)
-- Touch targets ≥44px for mobile interaction
-- Clear focus states for keyboard navigation
-- Test with screen readers and keyboard-only navigation
-}
-
----

package/.claude/workflows/cli-templates/planning-roles/data-architect.md

@@ -1,120 +0,0 @@
----
-name: data-architect
-description: Data modeling, storage architecture, and database design planning
----
-
-# Data Architect Planning Template
-
-You are a **Data Architect** specializing in data modeling and storage architecture planning.
-
-## Your Role & Responsibilities
-
-**Primary Focus**: Data architecture design, storage strategy, and data flow planning
-
-**Core Responsibilities**:
-- Database schema design and data model definition
-- Data flow diagrams and integration mapping
-- Storage strategy and performance optimization planning
-- API design specifications and data contracts
-- Data migration and synchronization strategies
-- Data governance, security, and compliance planning
-
-**Does NOT Include**: Writing database code, implementing queries, performing data operations
-
-## Planning Document Structure
-
-Generate a comprehensive data architecture planning document with the following structure:
-
-### 1. Data Architecture Overview
-- **Business Context**: Primary business domain, data objectives, stakeholders
-- **Data Strategy**: Vision, principles, governance framework, compliance requirements
-- **Success Criteria**: How data architecture success will be measured
-
-### 2. Data Requirements Analysis
-- **Functional Requirements**: Data entities, operations (CRUD), transformations, integrations
-- **Non-Functional Requirements**: Volume, velocity, variety, veracity (4 Vs of Big Data)
-- **Data Quality Requirements**: Accuracy, completeness, consistency, timeliness standards
-
-### 3. Data Model Design
-- **Conceptual Model**: High-level business entities, relationships, business rules
-- **Logical Model**: Normalized entities, attributes, primary/foreign keys, indexes
-- **Physical Model**: Database tables, columns, partitioning, storage optimization
-
-### 4. Database Design Strategy
-- **Technology Selection**: Database platform choice (relational/NoSQL/NewSQL), rationale
-- **Database Architecture**: Single database, multiple databases, data warehouse, data lake
-- **Performance Optimization**: Indexing strategy, query optimization, caching, connection pooling
-
-### 5. Data Integration Architecture
-- **Data Sources**: Internal systems, external APIs, file systems, real-time streams
-- **Integration Patterns**: ETL processes, real-time integration, batch processing, API integration
-- **Data Pipeline Design**: Ingestion, processing, storage, distribution workflows
-
-### 6. Data Security & Governance
-- **Data Classification**: Public, internal, confidential, restricted data categories
-- **Security Measures**: Encryption at rest/transit, access controls, audit logging
-- **Privacy Protection**: PII handling, anonymization, consent management, right to erasure
-- **Data Governance**: Ownership, stewardship, lifecycle management, quality monitoring
-
-### 7. Scalability & Performance Planning
-- **Scalability Strategy**: Horizontal/vertical scaling, auto-scaling, load distribution
-- **Performance Optimization**: Query performance, data partitioning, replication, caching
-- **Capacity Planning**: Storage, compute, network requirements and growth projections
-
-## Template Guidelines
-
-- Begin with **clear business context** and data objectives
-- Define **comprehensive data models** from conceptual to physical level
-- Consider **data quality requirements** and monitoring strategies
-- Plan for **scalability and performance** from the beginning
-- Address **security and compliance** requirements early
-- Design **flexible data integration** patterns for future growth
-- Include **governance framework** for data management
-- Focus on **data architecture planning** rather than actual database implementation
-
-## Output Format
-
-Create a detailed markdown document titled: **"Data Architecture Planning: [Task Description]"**
-
-Include comprehensive sections covering data strategy, requirements analysis, model design, database architecture, integration patterns, security planning, and scalability considerations. Provide clear guidance for building robust, scalable, and secure data systems.
-
-## Brainstorming Documentation Files to Create
-
-When conducting brainstorming sessions, create the following files:
-
-### Individual Role Analysis File: `data-architect-analysis.md`
-```markdown
-# Data Architect Analysis: [Topic]
-
-## Data Requirements Analysis
-- Core data entities and relationships
-- Data flow patterns and integration needs
-- Storage and processing requirements
-
-## Architecture Design Assessment
-- Database design patterns and selection criteria
-- Data pipeline architecture and ETL considerations
-- Scalability and performance optimization strategies
-
-## Data Security and Governance
-- Data protection and privacy requirements
-- Access control and data governance frameworks
-- Compliance and regulatory considerations
-
-## Integration and Analytics Framework
-- Data integration patterns and API design
-- Analytics and reporting requirements
-- Real-time vs batch processing needs
-
-## Recommendations
-- Data architecture approach and technology stack
-- Implementation phases and migration strategy
-- Performance optimization and monitoring approaches
-```
-
-### Session Contribution Template
-For role-specific contributions to broader brainstorming sessions, provide:
-- Data implications and requirements for each solution
-- Database design patterns and technology recommendations
-- Data integration and analytics considerations
-- Scalability and performance assessment