claude-code-workflow 6.2.4 → 6.2.5

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

@@ -1,122 +0,0 @@
-# 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

@@ -1,89 +0,0 @@
-# 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

@@ -1,60 +0,0 @@
-# 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

@@ -1,70 +0,0 @@
-# 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

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

@@ -1,81 +0,0 @@
-# Rule Template: Testing Rules
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {FILE_EXT}: File extension pattern
-- {TEST_FRAMEWORK}: Primary testing framework
-
-## Output Format
-
-```markdown
----
-paths:
-  - "**/*.{test,spec}.{FILE_EXT}"
-  - "tests/**/*.{FILE_EXT}"
-  - "__tests__/**/*.{FILE_EXT}"
-  - "**/test_*.{FILE_EXT}"
-  - "**/*_test.{FILE_EXT}"
----
-
-# {TECH_STACK_NAME} Testing Rules
-
-## Testing Framework
-
-[Recommended frameworks from Exa research]
-- Primary: {TEST_FRAMEWORK}
-- Assertion library
-- Mocking library
-- Coverage tool
-
-## Test Structure
-
-[Organization patterns]
-
-### File Naming
-- Unit tests: `*.test.{ext}` or `*.spec.{ext}`
-- Integration tests: `*.integration.test.{ext}`
-- E2E tests: `*.e2e.test.{ext}`
-
-### Test Organization
-```{lang}
-describe('[Component/Module]', () => {
-  describe('[method/feature]', () => {
-    it('should [expected behavior]', () => {
-      // Arrange
-      // Act
-      // Assert
-    });
-  });
-});
-```
-
-## Mocking & Fixtures
-
-[Best practices]
-- Mock creation patterns
-- Fixture organization
-- Test data factories
-- Cleanup strategies
-
-## Assertions
-
-[Assertion patterns]
-- Common assertions
-- Custom matchers
-- Async assertions
-- Error assertions
-
-## Coverage Requirements
-
-[Coverage guidelines]
-- Minimum coverage thresholds
-- What to cover vs skip
-- Coverage report interpretation
-```
-
-## Content Guidelines
-
-- Include framework-specific patterns
-- Show test structure examples
-- Cover both unit and integration testing
-- Include async testing patterns

package/.claude/workflows/cli-templates/prompts/rules/tech-rules-agent-prompt.txt

@@ -1,89 +0,0 @@
-# Tech Stack Rules Generation Agent Prompt
-
-## Context Variables
-- {TECH_STACK_NAME}: Normalized tech stack name (e.g., "typescript-react")
-- {PRIMARY_LANG}: Primary language (e.g., "typescript")
-- {FILE_EXT}: File extension pattern (e.g., "{ts,tsx}")
-- {FRAMEWORK_TYPE}: frontend | backend | fullstack | library
-- {COMPONENTS}: Array of tech components
-- {OUTPUT_DIR}: .claude/rules/tech/{TECH_STACK_NAME}/
-
-## Agent Instructions
-
-Generate path-conditional rules for Claude Code automatic loading.
-
-### Step 1: Execute Exa Research
-
-Run 4-6 parallel queries based on tech stack:
-
-**Base Queries** (always execute):
-```
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} best practices principles 2025", tokensNum: 8000)
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} implementation patterns examples", tokensNum: 7000)
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} testing strategies conventions", tokensNum: 5000)
-mcp__exa__web_search_exa(query: "{PRIMARY_LANG} configuration setup 2025", numResults: 5)
-```
-
-**Component Queries** (for each framework in COMPONENTS):
-```
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} {component} integration patterns", tokensNum: 5000)
-```
-
-### Step 2: Read Rule Templates
-
-Read each template file before generating content:
-```
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-core.txt)
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-patterns.txt)
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-testing.txt)
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-config.txt)
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-api.txt)       # Only if backend/fullstack
-Read(~/.claude/workflows/cli-templates/prompts/rules/rule-components.txt) # Only if frontend/fullstack
-```
-
-### Step 3: Generate Rule Files
-
-Create directory and write files:
-```bash
-mkdir -p "{OUTPUT_DIR}"
-```
-
-**Always Generate**:
-- core.md (from rule-core.txt template)
-- patterns.md (from rule-patterns.txt template)
-- testing.md (from rule-testing.txt template)
-- config.md (from rule-config.txt template)
-
-**Conditional**:
-- api.md: Only if FRAMEWORK_TYPE == 'backend' or 'fullstack'
-- components.md: Only if FRAMEWORK_TYPE == 'frontend' or 'fullstack'
-
-### Step 4: Write Metadata
-
-```json
-{
-  "tech_stack": "{TECH_STACK_NAME}",
-  "primary_lang": "{PRIMARY_LANG}",
-  "file_ext": "{FILE_EXT}",
-  "framework_type": "{FRAMEWORK_TYPE}",
-  "components": ["{COMPONENTS}"],
-  "generated_at": "{ISO_TIMESTAMP}",
-  "source": "exa-research",
-  "files_generated": ["core.md", "patterns.md", "testing.md", "config.md", ...]
-}
-```
-
-### Step 5: Report Completion
-
-Provide summary:
-- Files created with their path patterns
-- Exa queries executed (count)
-- Sources consulted (count)
-
-## Critical Requirements
-
-1. Every .md file MUST start with `paths` YAML frontmatter
-2. Use {FILE_EXT} consistently across all rule files
-3. Synthesize Exa research into actionable rules
-4. Include code examples from Exa sources
-5. Keep each file focused on its specific domain