refactor: optimize workflow templates and prompt structures

- Streamlined analysis templates (architecture, pattern, performance, quality, security)
- Simplified development templates (component, debugging, feature, refactor, testing)
- Optimized documentation templates (api, folder-navigation, module-readme, project-architecture, project-examples, project-readme)
- Enhanced planning templates (concept-eval, migration, task-breakdown)
- Improved verification templates (codex-technical, cross-validation, gemini-strategic)
- Updated claude-module-unified memory template
- Refined workflow-architecture documentation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

.claude/workflows/cli-templates/prompts/analysis/architecture.txt

@@ -1,16 +1,29 @@
-Analyze system architecture and design decisions:
+Analyze system architecture and design decisions.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Analyze system-wide structure, not just isolated components
+□ Provide file:line references for key architectural elements
+□ Distinguish between intended design and actual implementation
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
 1. Identify main architectural patterns and design principles
 2. Map module dependencies and component relationships
 3. Assess integration points and data flow patterns
 4. Evaluate scalability and maintainability aspects
 5. Document architectural trade-offs and design decisions
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Architectural diagrams or textual descriptions
 - Dependency mapping with specific file references
 - Integration point documentation with examples
 - Scalability assessment and bottleneck identification
+- Prioritized recommendations for architectural improvement
 
-Focus on high-level design patterns and system-wide architectural concerns.
+## VERIFICATION CHECKLIST ✓
+□ All major components and their relationships analyzed
+□ Key architectural decisions and trade-offs are documented
+□ Data flow and integration points are clearly mapped
+□ Scalability and maintainability findings are supported by evidence
+
+Focus: High-level design patterns and system-wide architectural concerns.

.claude/workflows/cli-templates/prompts/analysis/pattern.txt

@@ -1,16 +1,28 @@
-Analyze implementation patterns and code structure:
+Analyze implementation patterns and code structure.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Analyze ALL files in CONTEXT (not just samples)
+□ Provide file:line references for every pattern identified
+□ Distinguish between good patterns and anti-patterns
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
 1. Identify common code patterns and architectural decisions
 2. Extract reusable utilities and shared components
 3. Document existing conventions and coding standards
 4. Assess pattern consistency and identify anti-patterns
 5. Suggest improvements and optimization opportunities
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Specific file:line references for all findings
 - Code snippets demonstrating identified patterns
 - Clear recommendations for pattern improvements
-- Standards compliance assessment
+- Standards compliance assessment with priority levels
 
-Focus on actionable insights and concrete implementation guidance.
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed (not partial coverage)
+□ Every pattern backed by code reference (file:line)
+□ Anti-patterns clearly distinguished from good patterns
+□ Recommendations prioritized by impact
+
+Focus: Actionable insights with concrete implementation guidance.

.claude/workflows/cli-templates/prompts/analysis/performance.txt

@@ -1,16 +1,29 @@
-Analyze performance characteristics and optimization opportunities:
+Analyze performance characteristics and optimization opportunities.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Focus on measurable metrics (e.g., latency, memory, CPU usage)
+□ Provide file:line references for all identified bottlenecks
+□ Distinguish between algorithmic and resource-based issues
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
 1. Identify performance bottlenecks and resource usage patterns
 2. Assess algorithm efficiency and data structure choices
 3. Evaluate caching strategies and optimization techniques
 4. Review memory management and resource cleanup
 5. Document performance metrics and improvement opportunities
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Performance bottleneck identification with specific locations
+- Performance bottleneck identification with specific file:line locations
 - Algorithm complexity analysis and optimization suggestions
 - Caching pattern documentation and recommendations
 - Memory usage patterns and optimization opportunities
+- Prioritized list of performance improvements
 
-Focus on measurable performance improvements and concrete optimization strategies.
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed for performance characteristics
+□ Every bottleneck is backed by a code reference (file:line)
+□ Both algorithmic and resource-related issues are covered
+□ Recommendations are prioritized by potential impact
+
+Focus: Measurable performance improvements and concrete optimization strategies.

.claude/workflows/cli-templates/prompts/analysis/quality.txt

@@ -1,16 +1,29 @@
-Analyze code quality and maintainability aspects:
+Analyze code quality and maintainability aspects.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Analyze against the project's established coding standards
+□ Provide file:line references for all quality issues
+□ Assess both implementation code and test coverage
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
 1. Assess code organization and structural quality
 2. Evaluate naming conventions and readability standards
 3. Review error handling and logging practices
 4. Analyze test coverage and testing strategies
 5. Document technical debt and improvement priorities
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Code quality metrics and specific improvement areas
 - Naming convention consistency analysis
-- Error handling pattern documentation
+- Error handling and logging pattern documentation
 - Test coverage assessment with gap identification
+- Prioritized list of technical debt to address
 
-Focus on maintainability improvements and long-term code health.
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed for code quality
+□ Every finding is backed by a code reference (file:line)
+□ Both code and test quality have been evaluated
+□ Recommendations are prioritized by impact on maintainability
+
+Focus: Maintainability improvements and long-term code health.

.claude/workflows/cli-templates/prompts/analysis/security.txt

@@ -1,16 +1,29 @@
-Analyze security implementation and potential vulnerabilities:
+Analyze security implementation and potential vulnerabilities.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Identify all data entry points and external system interfaces
+□ Provide file:line references for all potential vulnerabilities
+□ Classify risks by severity and type (e.g., OWASP Top 10)
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
 1. Identify authentication and authorization mechanisms
 2. Assess input validation and sanitization practices
 3. Review data encryption and secure storage methods
 4. Evaluate API security and access control patterns
 5. Document security risks and compliance considerations
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Security vulnerability findings with file:line references
 - Authentication/authorization pattern documentation
-- Input validation examples and gaps
+- Input validation examples and identified gaps
 - Encryption usage patterns and recommendations
+- Prioritized remediation plan based on risk level
 
-Focus on identifying security gaps and providing actionable remediation steps.
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed for security vulnerabilities
+□ Every finding is backed by a code reference (file:line)
+□ Both authentication and data handling are covered
+□ Recommendations include clear, actionable remediation steps
+
+Focus: Identifying security gaps and providing actionable remediation steps.

.claude/workflows/cli-templates/prompts/development/component.txt

@@ -1,37 +1,55 @@
-You are tasked with creating a reusable component in this codebase. Follow these guidelines:
+Create a reusable component following project conventions and best practices.
 
-## Design Phase:
+## CORE CHECKLIST ⚡
+□ Analyze existing component patterns BEFORE implementing
+□ Follow established naming conventions and prop patterns
+□ Include comprehensive tests (unit + visual + accessibility)
+□ Provide complete TypeScript types and documentation
+
+## IMPLEMENTATION PHASES
+
+### Design Phase
 1. Analyze existing component patterns and structures
 2. Identify reusable design principles and styling approaches
 3. Review component hierarchy and prop patterns
 4. Study existing component documentation and usage
 
-## Development Phase:
+### Development Phase
 1. Create component with proper TypeScript interfaces
 2. Implement following established naming conventions
 3. Add appropriate default props and validation
 4. Include comprehensive prop documentation
 
-## Styling Phase:
+### Styling Phase
 1. Follow existing styling methodology (CSS modules, styled-components, etc.)
 2. Ensure responsive design principles
 3. Add proper theming support if applicable
 4. Include accessibility considerations (ARIA, keyboard navigation)
 
-## Testing Phase:
+### Testing Phase
 1. Write component tests covering all props and states
 2. Test accessibility compliance
 3. Add visual regression tests if applicable
 4. Test component in different contexts and layouts
 
-## Documentation Phase:
+### Documentation Phase
 1. Create usage examples and code snippets
 2. Document all props and their purposes
 3. Include accessibility guidelines
 4. Add integration examples with other components
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Provide complete component implementation
+- Complete component implementation with TypeScript types
-- Include comprehensive TypeScript types
+- Usage examples and integration patterns
-- Show usage examples and integration patterns
+- Component API documentation and best practices
-- Document component API and best practices
+- Test suite with accessibility validation
+- File:line references for pattern sources
+
+## VERIFICATION CHECKLIST ✓
+□ Implementation follows existing component patterns
+□ Complete TypeScript types and prop documentation
+□ Comprehensive tests (unit + visual + accessibility)
+□ Accessibility compliance (ARIA, keyboard navigation)
+□ Usage examples and integration documented
+
+Focus: Production-ready reusable component with comprehensive documentation and testing.

.claude/workflows/cli-templates/prompts/development/debugging.txt

@@ -1,37 +1,55 @@
-You are tasked with debugging and resolving issues in this codebase. Follow these systematic guidelines:
+Debug and resolve issues systematically in the codebase.
 
-## Issue Analysis Phase:
+## CORE CHECKLIST ⚡
+□ Identify and reproduce the issue completely before fixing
+□ Perform root cause analysis (not just symptom treatment)
+□ Provide file:line references for all changes
+□ Add tests to prevent regression of this specific issue
+
+## IMPLEMENTATION PHASES
+
+### Issue Analysis Phase
 1. Identify and reproduce the reported issue
 2. Analyze error logs and stack traces
 3. Study code flow and identify potential failure points
 4. Review recent changes that might have introduced the issue
 
-## Investigation Phase:
+### Investigation Phase
 1. Add strategic logging and debugging statements
 2. Use debugging tools and profilers as appropriate
 3. Test with different input conditions and edge cases
 4. Isolate the root cause through systematic elimination
 
-## Root Cause Analysis:
+### Root Cause Analysis
 1. Document the exact cause of the issue
 2. Identify contributing factors and conditions
 3. Assess impact scope and affected functionality
 4. Determine if similar issues exist elsewhere
 
-## Resolution Phase:
+### Resolution Phase
 1. Implement minimal, targeted fix for the root cause
 2. Ensure fix doesn't introduce new issues or regressions
 3. Add proper error handling and validation
 4. Include defensive programming measures
 
-## Prevention Phase:
+### Prevention Phase
 1. Add tests to prevent regression of this issue
 2. Improve error messages and logging
 3. Add monitoring or alerts for early detection
 4. Document lessons learned and prevention strategies
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Provide detailed root cause analysis
+- Detailed root cause analysis with file:line references
-- Show exact code changes made to resolve the issue
+- Exact code changes made to resolve the issue
-- Include new tests added to prevent regression
+- New tests added to prevent regression
-- Document debugging process and lessons learned
+- Debugging process documentation and lessons learned
+- Impact assessment and affected functionality
+
+## VERIFICATION CHECKLIST ✓
+□ Root cause identified and documented (not just symptoms)
+□ Minimal fix applied without introducing new issues
+□ Tests added to prevent this specific regression
+□ Similar issues checked and addressed if found
+□ Prevention measures documented
+
+Focus: Systematic root cause resolution with regression prevention.

.claude/workflows/cli-templates/prompts/development/feature.txt

@@ -1,31 +1,49 @@
-You are tasked with implementing a new feature in this codebase. Follow these guidelines:
+Implement a new feature following project conventions and best practices.
 
-## Analysis Phase:
+## CORE CHECKLIST ⚡
+□ Study existing code patterns BEFORE implementing
+□ Follow established project conventions and architecture
+□ Include comprehensive tests (unit + integration)
+□ Provide file:line references for all changes
+
+## IMPLEMENTATION PHASES
+
+### Analysis Phase
 1. Study existing code patterns and conventions
 2. Identify similar features and their implementation approaches
 3. Review project architecture and design principles
 4. Understand dependencies and integration points
 
-## Implementation Phase:
+### Implementation Phase
 1. Create feature following established patterns
 2. Implement with proper error handling and validation
 3. Add comprehensive logging for debugging
 4. Follow security best practices
 
-## Integration Phase:
+### Integration Phase
 1. Ensure seamless integration with existing systems
 2. Update configuration files as needed
 3. Add proper TypeScript types and interfaces
 4. Update documentation and comments
 
-## Testing Phase:
+### Testing Phase
 1. Write unit tests covering edge cases
 2. Add integration tests for feature workflows
 3. Verify error scenarios are properly handled
 4. Test performance and security implications
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Provide file:line references for all changes
+- File:line references for all changes
-- Include code examples demonstrating key patterns
+- Code examples demonstrating key patterns
-- Explain architectural decisions made
+- Explanation of architectural decisions made
-- Document any new dependencies or configurations
+- Documentation of new dependencies or configurations
+- Test coverage summary
+
+## VERIFICATION CHECKLIST ✓
+□ Implementation follows existing patterns (no divergence)
+□ Complete test coverage (unit + integration)
+□ Documentation updated (code comments + external docs)
+□ Integration verified (no breaking changes)
+□ Security and performance validated
+
+Focus: Production-ready implementation with comprehensive testing and documentation.

.claude/workflows/cli-templates/prompts/development/refactor.txt

@@ -1,37 +1,55 @@
-You are tasked with refactoring existing code to improve quality, performance, or maintainability. Follow these guidelines:
+Refactor existing code to improve quality, performance, or maintainability.
 
-## Analysis Phase:
+## CORE CHECKLIST ⚡
+□ Preserve existing functionality (no behavioral changes unless specified)
+□ Ensure all existing tests continue to pass
+□ Plan incremental changes (avoid big-bang refactoring)
+□ Provide file:line references for all modifications
+
+## IMPLEMENTATION PHASES
+
+### Analysis Phase
 1. Identify code smells and technical debt
 2. Analyze performance bottlenecks and inefficiencies
 3. Review code complexity and maintainability metrics
 4. Study existing test coverage and identify gaps
 
-## Planning Phase:
+### Planning Phase
 1. Create refactoring strategy preserving existing functionality
 2. Identify breaking changes and migration paths
 3. Plan incremental refactoring steps
 4. Consider backward compatibility requirements
 
-## Refactoring Phase:
+### Refactoring Phase
 1. Apply SOLID principles and design patterns
 2. Improve code readability and documentation
 3. Optimize performance while maintaining functionality
 4. Reduce code duplication and improve reusability
 
-## Validation Phase:
+### Validation Phase
 1. Ensure all existing tests continue to pass
 2. Add new tests for improved code coverage
 3. Verify performance improvements with benchmarks
 4. Test edge cases and error scenarios
 
-## Migration Phase:
+### Migration Phase
 1. Update dependent code to use refactored interfaces
 2. Update documentation and usage examples
 3. Provide migration guides for breaking changes
 4. Add deprecation warnings for old interfaces
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Provide before/after code comparisons
+- Before/after code comparisons with file:line references
-- Document performance improvements achieved
+- Performance improvements documented with benchmarks
-- Include migration instructions for breaking changes
+- Migration instructions for breaking changes
-- Show updated test coverage and quality metrics
+- Updated test coverage and quality metrics
+- Technical debt reduction summary
+
+## VERIFICATION CHECKLIST ✓
+□ All existing tests pass (functionality preserved)
+□ New tests added for improved coverage
+□ Performance verified with benchmarks (if applicable)
+□ Backward compatibility maintained or migration provided
+□ Documentation updated with refactoring changes
+
+Focus: Incremental quality improvement while preserving functionality.

.claude/workflows/cli-templates/prompts/development/testing.txt

@@ -1,43 +1,61 @@
-You are tasked with creating comprehensive tests for this codebase. Follow these guidelines:
+Create comprehensive tests for the codebase.
 
-## Test Strategy Phase:
+## CORE CHECKLIST ⚡
+□ Analyze existing test coverage and identify gaps
+□ Follow project testing frameworks and conventions
+□ Include unit, integration, and end-to-end tests
+□ Ensure tests are reliable and deterministic
+
+## IMPLEMENTATION PHASES
+
+### Test Strategy Phase
 1. Analyze existing test coverage and identify gaps
 2. Study codebase architecture and critical paths
 3. Identify edge cases and error scenarios
 4. Review testing frameworks and conventions used
 
-## Unit Testing Phase:
+### Unit Testing Phase
 1. Write tests for individual functions and methods
 2. Test all branches and conditional logic
 3. Cover edge cases and boundary conditions
 4. Mock external dependencies appropriately
 
-## Integration Testing Phase:
+### Integration Testing Phase
 1. Test interactions between components and modules
 2. Verify API endpoints and data flow
 3. Test database operations and transactions
 4. Validate external service integrations
 
-## End-to-End Testing Phase:
+### End-to-End Testing Phase
 1. Test complete user workflows and scenarios
 2. Verify critical business logic and processes
 3. Test error handling and recovery mechanisms
 4. Validate performance under load
 
-## Quality Assurance:
+### Quality Assurance
 1. Ensure tests are reliable and deterministic
 2. Make tests readable and maintainable
 3. Add proper test documentation and comments
 4. Follow testing best practices and conventions
 
-## Test Data Management:
+### Test Data Management
 1. Create realistic test data and fixtures
 2. Ensure test isolation and cleanup
 3. Use factories or builders for complex objects
 4. Handle sensitive data appropriately in tests
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
-- Provide comprehensive test suite with high coverage
+- Comprehensive test suite with high coverage
-- Include performance benchmarks where relevant
+- Performance benchmarks where relevant
-- Document testing strategy and conventions used
+- Testing strategy and conventions documentation
-- Show test coverage metrics and quality improvements
+- Test coverage metrics and quality improvements
+- File:line references for tested code
+
+## VERIFICATION CHECKLIST ✓
+□ Test coverage gaps identified and filled
+□ All test types included (unit + integration + e2e)
+□ Tests are reliable and deterministic (no flaky tests)
+□ Test data properly managed (isolation + cleanup)
+□ Testing conventions followed consistently
+
+Focus: High-quality, reliable test suite with comprehensive coverage.

.claude/workflows/cli-templates/prompts/documentation/api.txt

@@ -1,337 +1,15 @@
-# Unified API Documentation Template
+Generate comprehensive API documentation for code or HTTP services.
 
-Generate comprehensive API documentation. This template supports both **Code API** (for libraries/modules) and **HTTP API** (for web services). Include only the sections relevant to your project type.
+## CORE CHECKLIST ⚡
+□ Include only sections relevant to the project type (Code API vs. HTTP API)
+□ Provide complete and runnable examples for HTTP APIs
+□ Use signatures-only for Code API documentation (no implementation)
+□ Document all public-facing APIs, not internal ones
 
----
+## UNIFIED API DOCUMENTATION TEMPLATE
 
-## Part A: Code API (For Libraries, Modules, SDKs)
+This template supports both **Code API** (for libraries/modules) and **HTTP API** (for web services). Include only the sections relevant to your project type.
 
-**Use this section when documenting**: Exported functions, classes, interfaces, and types from code modules.
+--- 
 
-**Omit this section if**: This is a pure web service with only HTTP endpoints and no programmatic API.
+...(content truncated)...
-
-### 1. Exported Functions
-
-For each exported function, provide:
-```typescript
-/**
- * Brief one-line description of what the function does
- * @param paramName - Parameter type and description
- * @returns Return type and description
- * @throws ErrorType - When this error occurs
- */
-export function functionName(paramName: ParamType): ReturnType;
-```
-
-**Example**:
-```typescript
-/**
- * Authenticates a user with email and password
- * @param credentials - User email and password
- * @returns Authentication token and user info
- * @throws AuthenticationError - When credentials are invalid
- */
-export function authenticate(credentials: Credentials): Promise<AuthResult>;
-```
-
-### 2. Exported Classes
-
-For each exported class, provide:
-```typescript
-/**
- * Brief one-line description of the class purpose
- */
-export class ClassName {
-  constructor(param: Type);
-
-  // Public properties
-  propertyName: Type;
-
-  // Public methods
-  methodName(param: Type): ReturnType;
-}
-```
-
-**Example**:
-```typescript
-/**
- * Manages user session lifecycle and token refresh
- */
-export class SessionManager {
-  constructor(config: SessionConfig);
-
-  // Current session state
-  isActive: boolean;
-
-  // Refresh the session token
-  refresh(): Promise<void>;
-
-  // Terminate the session
-  destroy(): void;
-}
-```
-
-### 3. Exported Interfaces
-
-For each exported interface, provide:
-```typescript
-/**
- * Brief description of what this interface represents
- */
-export interface InterfaceName {
-  field1: Type;  // Field description
-  field2: Type;  // Field description
-  method?: (param: Type) => ReturnType;  // Optional method
-}
-```
-
-### 4. Type Definitions
-
-For each exported type, provide:
-```typescript
-/**
- * Brief description of what this type represents
- */
-export type TypeName = string | number | CustomType;
-```
-
----
-
-## Part B: HTTP API (For Web Services, REST APIs, GraphQL)
-
-**Use this section when documenting**: HTTP endpoints, REST APIs, GraphQL APIs, webhooks.
-
-**Omit this section if**: This is a library/SDK with no HTTP interface.
-
-### 1. Overview
-
-[Brief description of the API's purpose and capabilities]
-
-**Base URL**:
-```
-Production: https://api.example.com/v1
-Staging: https://staging.api.example.com/v1
-Development: http://localhost:3000/api/v1
-```
-
-### 2. Authentication
-
-#### Authentication Method
-[e.g., JWT Bearer Token, OAuth2, API Keys]
-
-#### Obtaining Credentials
-```bash
-# Example: Login to get token
-curl -X POST https://api.example.com/v1/auth/login \
-  -H "Content-Type: application/json" \
-  -d '{"email": "user@example.com", "password": "password"}'
-```
-
-#### Using Credentials
-```http
-GET /api/resource HTTP/1.1
-Authorization: Bearer <token>
-```
-
-### 3. Common Response Codes
-
-| Code | Description | Common Causes |
-|------|-------------|---------------|
-| 200  | Success | Request completed successfully |
-| 201  | Created | Resource created successfully |
-| 400  | Bad Request | Invalid request body or parameters |
-| 401  | Unauthorized | Missing or invalid authentication |
-| 403  | Forbidden | Authenticated but not authorized |
-| 404  | Not Found | Resource does not exist |
-| 429  | Too Many Requests | Rate limit exceeded |
-| 500  | Internal Server Error | Server-side error |
-
-### 4. Endpoints
-
-#### Resource: [Resource Name, e.g., Users]
-
-##### GET /resource
-**Description**: [What this endpoint does]
-
-**Query Parameters**:
-| Parameter | Type | Required | Description | Default |
-|-----------|------|----------|-------------|---------|
-| `limit` | number | No | Number of results | 20 |
-| `offset` | number | No | Pagination offset | 0 |
-
-**Example Request**:
-```http
-GET /users?limit=10&offset=0 HTTP/1.1
-Authorization: Bearer <token>
-```
-
-**Response (200 OK)**:
-```json
-{
-  "data": [
-    {
-      "id": 1,
-      "name": "John Doe",
-      "email": "john@example.com"
-    }
-  ],
-  "pagination": {
-    "total": 100,
-    "limit": 10,
-    "offset": 0
-  }
-}
-```
-
-**Error Response (401 Unauthorized)**:
-```json
-{
-  "error": {
-    "code": "UNAUTHORIZED",
-    "message": "Invalid or expired token"
-  }
-}
-```
-
----
-
-##### POST /resource
-**Description**: [What this endpoint does]
-
-**Request Body**:
-```json
-{
-  "field1": "value",
-  "field2": 123
-}
-```
-
-**Validation Rules**:
-- `field1`: Required, 2-100 characters
-- `field2`: Required, positive integer
-
-**Response (201 Created)**:
-```json
-{
-  "id": 124,
-  "field1": "value",
-  "field2": 123,
-  "created_at": "2024-01-20T12:00:00Z"
-}
-```
-
----
-
-##### PUT /resource/:id
-**Description**: [What this endpoint does]
-
-**Path Parameters**:
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `id` | number | Resource ID |
-
-**Request Body** (all fields optional):
-```json
-{
-  "field1": "new value"
-}
-```
-
-**Response (200 OK)**:
-```json
-{
-  "id": 124,
-  "field1": "new value",
-  "updated_at": "2024-01-21T09:15:00Z"
-}
-```
-
----
-
-##### DELETE /resource/:id
-**Description**: [What this endpoint does]
-
-**Path Parameters**:
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `id` | number | Resource ID |
-
-**Response (204 No Content)**:
-[Empty response body]
-
----
-
-### 5. Rate Limiting
-
-- **Limit**: 1000 requests per hour per API key
-- **Headers**:
-  - `X-RateLimit-Limit`: Total requests allowed
-  - `X-RateLimit-Remaining`: Requests remaining
-  - `X-RateLimit-Reset`: Unix timestamp when limit resets
-
-**Example Response Headers**:
-```http
-X-RateLimit-Limit: 1000
-X-RateLimit-Remaining: 847
-X-RateLimit-Reset: 1640000000
-```
-
-### 6. Webhooks (Optional)
-
-[Description of webhook system if applicable]
-
-**Webhook Events**:
-- `resource.created` - Triggered when a new resource is created
-- `resource.updated` - Triggered when a resource is updated
-- `resource.deleted` - Triggered when a resource is deleted
-
-**Webhook Payload Example**:
-```json
-{
-  "event": "resource.created",
-  "timestamp": "2024-01-20T12:00:00Z",
-  "data": {
-    "id": 124,
-    "field1": "value"
-  }
-}
-```
-
----
-
-## Rules
-
-1. **Include only relevant sections** - Skip Part A for pure web services, skip Part B for pure libraries
-2. **Signatures only in Part A** - No implementation code in Code API section
-3. **Complete examples in Part B** - All HTTP examples should be runnable
-4. **Consistent formatting** - Use language-specific code blocks (TypeScript, HTTP, JSON, bash)
-5. **Brief descriptions** - One line per item is sufficient for Code API
-6. **Detailed explanations for HTTP** - Include request/response examples, validation rules, error cases
-7. **Alphabetical order** - Sort items within each section for easy lookup
-8. **Public API only** - Do not document internal/private exports or endpoints
-
----
-
-## Template Usage Guidelines
-
-### For Module-Level API.md (Code API)
-**Use**: Part A only
-**Location**: `modules/[module-name]/API.md`
-**Focus**: Exported functions, classes, interfaces
-
-### For Project-Level HTTP API Documentation
-**Use**: Part B only
-**Location**: `.workflow/docs/api/README.md`
-**Focus**: REST/GraphQL endpoints, authentication
-
-### For Full-Stack Projects (Both Code and HTTP APIs)
-**Use**: Both Part A and Part B
-**Organization**:
-- Part A for SDK/client library APIs
-- Part B for HTTP endpoints
-
----
-
-**Last Updated**: [Auto-generated timestamp]
-**API Version**: [Version number]
-**Module/Service Path**: [Auto-fill with actual path]

.claude/workflows/cli-templates/prompts/documentation/folder-navigation.txt

@@ -1,68 +1,27 @@
-# Folder Navigation Documentation Template
+Generate a navigation README for directories that contain only subdirectories.
 
-Generate a navigation README for directories that contain only subdirectories (no code files). This serves as an index to help readers navigate to specific modules.
+## CORE CHECKLIST ⚡
+□ Keep the content brief and act as an index
+□ Use one-line descriptions for each module
+□ Ensure all mentioned modules link to their respective READMEs
+□ Use scannable formats like tables and lists
 
-## Structure
+## REQUIRED CONTENT
+1. **Overview**: Brief description of the directory's purpose.
+2. **Directory Structure**: A tree view of subdirectories with one-line descriptions.
+3. **Module Quick Reference**: A table with links, purposes, and key features.
+4. **How to Navigate**: Guidance on which module to explore for specific needs.
+5. **Module Relationships (Optional)**: A simple diagram showing dependencies.
 
-### 1. Overview
+## OUTPUT REQUIREMENTS
+- A scannable index for navigating subdirectories.
+- Links to each submodule's detailed documentation.
+- A clear, high-level overview of the directory's contents.
 
-Brief description of what this directory/category contains:
+## VERIFICATION CHECKLIST ✓
+□ The generated README is brief and serves as a scannable index
+□ All submodules are linked correctly
+□ Descriptions are concise and clear
+□ The structure follows the required content outline
 
-> The `modules/` directory contains the core business logic modules of the application. Each subdirectory represents a self-contained functional module with its own responsibilities.
+Focus: Creating a clear and concise navigation hub for parent directories.
-
-### 2. Directory Structure
-
-Provide a tree view of the subdirectories with brief descriptions:
-
-```
-modules/
-├── auth/              - User authentication and authorization
-├── api/               - API route handlers and middleware
-├── database/          - Database connections and ORM models
-└── utils/             - Shared utility functions
-```
-
-### 3. Module Quick Reference
-
-Table format for quick scanning:
-
-| Module | Purpose | Key Features |
-|--------|---------|--------------|
-| [auth](./auth/) | Authentication | JWT tokens, session management |
-| [api](./api/) | API routing | REST endpoints, validation |
-| [database](./database/) | Data layer | PostgreSQL, migrations |
-| [utils](./utils/) | Utilities | Logging, helpers |
-
-### 4. How to Navigate
-
-Guidance on which module to explore based on needs:
-
-- **For authentication logic** → [auth module](./auth/)
-- **For API endpoints** → [api module](./api/)
-- **For database queries** → [database module](./database/)
-- **For helper functions** → [utils module](./utils/)
-
-### 5. Module Relationships (Optional)
-
-If modules have significant dependencies, show them:
-
-```
-api → auth (uses for authentication)
-api → database (uses for data access)
-auth → database (uses for user storage)
-```
-
----
-
-## Rules
-
-1. **Keep it brief** - This is an index, not detailed documentation
-2. **One-line descriptions** - Each module gets a concise purpose statement
-3. **Scannable format** - Use tables and lists for quick navigation
-4. **Link to submodules** - Every module mentioned should link to its README
-5. **No code examples** - This is navigation only
-
----
-
-**Directory Path**: [Auto-fill with actual directory path]
-**Last Updated**: [Auto-generated timestamp]

.claude/workflows/cli-templates/prompts/documentation/module-readme.txt

@@ -1,98 +1,40 @@
-# Module README Documentation Template
+Generate comprehensive module documentation focused on understanding and usage.
 
-Generate comprehensive module documentation focused on understanding and usage. Explain WHAT the module does, WHY it exists, and HOW to use it. Do NOT duplicate API signatures (those belong in API.md).
+## CORE CHECKLIST ⚡
+□ Explain WHAT the module does, WHY it exists, and HOW to use it
+□ Do NOT duplicate API signatures from API.md; refer to it instead
+□ Provide practical, real-world usage examples
+□ Clearly define the module's boundaries and dependencies
 
-## Structure
+## DOCUMENTATION STRUCTURE
 
 ### 1. Purpose
-
+- **What**: Clearly state what this module is responsible for.
-**What**: Clearly state what this module is responsible for
+- **Why**: Explain the problem it solves.
-**Why**: Explain why this module exists and what problems it solves
+- **Boundaries**: Define what is in and out of scope.
-**Boundaries**: Define what is IN scope and OUT of scope
-
-Example:
-> The `auth` module handles user authentication and authorization. It exists to centralize security logic and provide a consistent authentication interface across the application. It does NOT handle user profile management or session storage.
 
 ### 2. Core Concepts
-
+- Explain key concepts, patterns, or abstractions.
-List and explain key concepts, patterns, or abstractions used by this module:
-
-- **Concept 1**: [Brief explanation of important concept]
-- **Concept 2**: [Another key concept users should understand]
-- **Pattern**: [Architectural pattern used, e.g., "Uses middleware pattern for request processing"]
 
 ### 3. Usage Scenarios
-
+- Provide 2-4 common use cases with code examples.
-Provide 2-4 common use cases with code examples:
-
-#### Scenario 1: [Common use case title]
-```typescript
-// Brief example showing how to use the module for this scenario
-import { functionName } from './module';
-
-const result = functionName(input);
-```
-
-#### Scenario 2: [Another common use case]
-```typescript
-// Another practical example
-```
 
 ### 4. Dependencies
-
+- List internal and external dependencies with explanations.
-#### Internal Dependencies
-List other project modules this module depends on and explain why:
-- **[Module Name]** - [Why this dependency exists and what it provides]
-
-#### External Dependencies
-List third-party libraries and their purpose:
-- **[Library Name]** (`version`) - [What functionality it provides to this module]
 
 ### 5. Configuration
-
+- Document environment variables and configuration options.
-#### Environment Variables
-List any environment variables the module uses:
-- `ENV_VAR_NAME` - [Description, type, default value]
-
-#### Configuration Options
-If the module accepts configuration objects:
-```typescript
-// Example configuration
-const config = {
-  option1: value,  // Description of option1
-  option2: value,  // Description of option2
-};
-```
 
 ### 6. Testing
-
+- Explain how to run tests for the module.
-Explain how to test code that uses this module:
-```bash
-# Command to run tests for this module
-npm test -- path/to/module
-```
-
-**Test Coverage**: [Brief note on what's tested]
 
 ### 7. Common Issues
+- List common problems and their solutions.
 
-List 2-3 common problems and their solutions:
+## VERIFICATION CHECKLIST ✓
+□ The module's purpose, scope, and boundaries are clearly defined
+□ Core concepts are explained for better understanding
+□ Usage examples are practical and demonstrate real-world scenarios
+□ All dependencies and configuration options are documented
 
-#### Issue: [Common problem description]
+Focus: Explaining the module's purpose and usage, not just its API.
-**Solution**: [How to resolve it]
-
----
-
-## Rules
-
-1. **No API duplication** - Refer to API.md for signatures
-2. **Focus on understanding** - Explain concepts, not just code
-3. **Practical examples** - Show real usage, not trivial cases
-4. **Clear dependencies** - Help readers understand module relationships
-5. **Concise** - Each section should be scannable and to-the-point
-
----
-
-**Module Path**: [Auto-fill with actual module path]
-**Last Updated**: [Auto-generated timestamp]
-**See also**: [Link to API.md for interface details]

.claude/workflows/cli-templates/prompts/documentation/project-architecture.txt

@@ -1,167 +1,41 @@
-# Project Architecture Documentation Template
+Generate comprehensive architecture documentation for the entire project.
 
-Generate comprehensive architecture documentation that synthesizes information from all module documents. Focus on system-level design, module relationships, and aggregated API overview. This document should be created AFTER all module documentation is complete.
+## CORE CHECKLIST ⚡
+□ Synthesize information from all modules; do not duplicate content
+□ Maintain a system-level perspective, focusing on module interactions
+□ Use visual aids (like ASCII diagrams) to clarify structure
+□ Explain the WHY behind architectural decisions
 
-## Structure
+## DOCUMENTATION STRUCTURE
 
 ### 1. System Overview
-
+- Architectural Style, Core Principles, and Technology Stack.
-High-level description of the system architecture:
-
-**Architectural Style**: [e.g., Layered, Microservices, Event-Driven, Hexagonal]
-
-**Core Principles**:
-- [Principle 1, e.g., "Separation of concerns"]
-- [Principle 2, e.g., "Dependency inversion"]
-- [Principle 3, e.g., "Single responsibility"]
-
-**Technology Stack**:
-- **Languages**: [Primary programming languages]
-- **Frameworks**: [Key frameworks]
-- **Databases**: [Data storage solutions]
-- **Infrastructure**: [Deployment, hosting, CI/CD]
 
 ### 2. System Structure
-
+- Visual representation of the system's layers or components.
-Visual representation of the system structure using text diagrams:
-
-```
-┌─────────────────────────────────────┐
-│         Application Layer           │
-│  (API Routes, Controllers)          │
-└────────────┬────────────────────────┘
-             │
-┌────────────▼────────────────────────┐
-│       Business Logic Layer          │
-│  (Modules: auth, orders, payments)  │
-└────────────┬────────────────────────┘
-             │
-┌────────────▼────────────────────────┐
-│        Data Access Layer            │
-│  (Database, ORM, Repositories)      │
-└─────────────────────────────────────┘
-```
 
 ### 3. Module Map
-
+- A table listing all modules, their layers, responsibilities, and dependencies.
-Comprehensive list of all modules with their responsibilities:
-
-| Module | Layer | Responsibility | Dependencies |
-|--------|-------|----------------|--------------|
-| `auth` | Business | Authentication & authorization | database, utils |
-| `api` | Application | HTTP routing & validation | auth, orders |
-| `database` | Data | Data persistence | - |
-| `utils` | Infrastructure | Shared utilities | - |
 
 ### 4. Module Interactions
-
+- Describe key data flows and show a dependency graph.
-Describe key interaction patterns between modules:
-
-#### Data Flow Example: User Authentication
-```
-1. Client → api/login endpoint
-2. api → auth.authenticateUser()
-3. auth → database.findUser()
-4. database → PostgreSQL
-5. auth → JWT token generation
-6. api → Response with token
-```
-
-#### Dependency Graph
-```
-api ──────┐
-          ├──→ auth ───→ database
-orders ───┤              ↑
-          └──────────────┘
-```
 
 ### 5. Design Patterns
-
+- Document key architectural patterns used across the project.
-Document key architectural patterns used:
-
-#### Pattern 1: [Pattern Name, e.g., "Repository Pattern"]
-- **Where**: [Which modules use this pattern]
-- **Why**: [Reason for using this pattern]
-- **How**: [Brief explanation of implementation]
-
-#### Pattern 2: [Another pattern]
-[Similar structure]
 
 ### 6. Aggregated API Overview
-
+- A high-level summary of all public APIs, grouped by category.
-High-level summary of all public APIs across modules. Group by category:
-
-#### Authentication APIs
-- `auth.authenticate(credentials)` - Validate user credentials
-- `auth.authorize(user, permission)` - Check user permissions
-- `auth.generateToken(userId)` - Create JWT token
-
-#### Data APIs
-- `database.findOne(query)` - Find single record
-- `database.findMany(query)` - Find multiple records
-- `database.insert(data)` - Insert new record
-
-#### Utility APIs
-- `utils.logger.log(message)` - Application logging
-- `utils.validator.validate(data, schema)` - Data validation
-
-*Note: For detailed API signatures, refer to individual module API.md files*
 
 ### 7. Data Flow
+- Describe the typical request lifecycle or event flow.
 
-Describe how data moves through the system:
+### 8. Security and Scalability
+- Overview of security measures and scalability considerations.
 
-**Request Lifecycle**:
+## VERIFICATION CHECKLIST ✓
-1. HTTP request enters through API layer
+□ The documentation provides a cohesive, system-level view
-2. Request validation and authentication (auth module)
+□ Module interactions and dependencies are clearly illustrated
-3. Business logic processing (domain modules)
+□ The rationale behind major design patterns and decisions is explained
-4. Data persistence (database module)
+□ The document synthesizes, rather than duplicates, module-level details
-5. Response formatting and return
 
-**Event Flow** (if applicable):
+Focus: Providing a holistic, system-level understanding of the project architecture.
-- [Describe event-driven flows if present]
-
-### 8. Security Architecture
-
-Overview of security measures:
-
-- **Authentication**: [JWT, OAuth2, etc.]
-- **Authorization**: [RBAC, ACL, etc.]
-- **Data Protection**: [Encryption, hashing]
-- **API Security**: [Rate limiting, CORS, etc.]
-
-### 9. Scalability Considerations
-
-Architectural decisions that support scalability:
-
-- [Horizontal scaling approach]
-- [Caching strategy]
-- [Database optimization]
-- [Load balancing]
-
----
-
-## Rules
-
-1. **Synthesize, don't duplicate** - Reference module docs, don't copy them
-2. **System-level perspective** - Focus on how modules work together
-3. **Visual aids** - Use diagrams for clarity (ASCII art is fine)
-4. **Aggregated APIs** - One-line summaries only, link to detailed docs
-5. **Design rationale** - Explain WHY decisions were made
-6. **Maintain consistency** - Ensure all module docs are considered
-
----
-
-## Required Inputs
-
-This document requires the following to be available:
-- All module README.md files (for understanding module purposes)
-- All module API.md files (for aggregating API overview)
-- Project README.md (for context and navigation)
-
----
-
-**Last Updated**: [Auto-generated timestamp]
-**See also**:
-- [Project README](./README.md) for project overview
-- [Module Documentation](./modules/) for detailed module docs

.claude/workflows/cli-templates/prompts/documentation/project-examples.txt

@@ -1,205 +1,35 @@
-# Project Examples Documentation Template
+Generate practical, end-to-end examples demonstrating core project usage.
 
-Generate practical, end-to-end examples demonstrating core usage patterns of the project. Focus on realistic scenarios that span multiple modules. These examples should help users understand how to accomplish common tasks.
+## CORE CHECKLIST ⚡
+□ Provide complete, runnable code for every example
+□ Focus on realistic, real-world scenarios, not trivial cases
+□ Explain the flow and how different modules interact
+□ Include expected output to verify correctness
 
-## Structure
+## EXAMPLES STRUCTURE
 
 ### 1. Introduction
-
+- Overview of the examples and any prerequisites.
-Brief overview of what these examples cover:
-
-> This document provides complete, working examples for common use cases. Each example demonstrates how multiple modules work together to accomplish a specific task.
-
-**Prerequisites**:
-- [List required setup, e.g., "Project installed and configured"]
-- [Environment requirements, e.g., "PostgreSQL running on localhost"]
 
 ### 2. Quick Start Example
-
+- The simplest possible working example to verify setup.
-The simplest possible working example to get started:
-
-```typescript
-// The minimal example to verify setup
-import { App } from './src';
-
-const app = new App();
-await app.start();
-console.log('Application running!');
-```
-
-**What this does**: [Brief explanation]
 
 ### 3. Core Use Cases
+- 3-5 complete examples for common scenarios with code, output, and explanations.
 
-Provide 3-5 complete examples for common scenarios:
+### 4. Advanced & Integration Examples
+- Showcase more complex scenarios or integrations with external systems.
 
-#### Example 1: [Scenario Name, e.g., "User Registration and Login"]
+### 5. Testing Examples
+- Show how to test code that uses the project.
 
-**Objective**: [What this example accomplishes]
+### 6. Best Practices & Troubleshooting
+- Demonstrate recommended patterns and provide solutions to common issues.
 
-**Modules involved**: `auth`, `database`, `api`
+## VERIFICATION CHECKLIST ✓
+□ All examples are complete, runnable, and tested
+□ Scenarios are realistic and demonstrate key project features
+□ Explanations clarify module interactions and data flow
+□ Best practices and error handling are demonstrated
 
-**Complete code**:
+Focus: Helping users accomplish common tasks through complete, practical examples.
-```typescript
-import { createUser, authenticateUser } from './modules/auth';
-import { startServer } from './modules/api';
-
-// Step 1: Initialize the application
-const app = await startServer({ port: 3000 });
-
-// Step 2: Register a new user
-const user = await createUser({
-  email: 'user@example.com',
-  password: 'securePassword123',
-  name: 'John Doe'
-});
-
-// Step 3: Authenticate the user
-const session = await authenticateUser({
-  email: 'user@example.com',
-  password: 'securePassword123'
-});
-
-// Step 4: Use the authentication token
-console.log('Login successful, token:', session.token);
-```
-
-**Expected output**:
-```
-Server started on port 3000
-User created: { id: 1, email: 'user@example.com', name: 'John Doe' }
-Login successful, token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
-```
-
-**Explanation**:
-1. [Step-by-step breakdown of what each part does]
-2. [How modules interact]
-3. [Common variations or customizations]
-
----
-
-#### Example 2: [Another Common Scenario]
-
-[Similar structure with complete code]
-
----
-
-#### Example 3: [Another Use Case]
-
-[Similar structure with complete code]
-
-### 4. Advanced Examples
-
-More complex scenarios for power users:
-
-#### Advanced Example 1: [Complex Scenario]
-
-**Objective**: [What this example accomplishes]
-
-**Modules involved**: [List]
-
-```typescript
-// Complete working code with detailed comments
-```
-
-**Key points**:
-- [Important concept or gotcha]
-- [Performance consideration]
-- [Security note]
-
-### 5. Integration Examples
-
-Examples showing how to integrate with external systems:
-
-#### Integration with [External System]
-
-```typescript
-// Example of integrating with a third-party service
-```
-
-### 6. Testing Examples
-
-Show how to test code that uses this project:
-
-```typescript
-// Example test case using the project
-import { describe, it, expect } from 'your-test-framework';
-
-describe('User authentication', () => {
-  it('should authenticate valid credentials', async () => {
-    const result = await authenticateUser({
-      email: 'test@example.com',
-      password: 'password123'
-    });
-
-    expect(result.success).toBe(true);
-    expect(result.token).toBeDefined();
-  });
-});
-```
-
-### 7. Best Practices
-
-Demonstrate recommended patterns:
-
-#### Pattern 1: [Best Practice Title]
-```typescript
-// Good: Recommended approach
-const result = await handleWithErrorRecovery(operation);
-
-// Bad: Anti-pattern to avoid
-const result = operation(); // No error handling
-```
-
-**Why**: [Explanation of why this is the best approach]
-
-#### Pattern 2: [Another Best Practice]
-[Similar structure]
-
-### 8. Troubleshooting Common Issues
-
-Example-based solutions to common problems:
-
-#### Issue: [Common Problem]
-
-**Symptom**: [What the user experiences]
-
-**Solution**:
-```typescript
-// Before: Code that causes the issue
-const broken = doSomethingWrong();
-
-// After: Corrected code
-const fixed = doSomethingRight();
-```
-
----
-
-## Rules
-
-1. **Complete, runnable code** - Every example should be copy-paste ready
-2. **Real-world scenarios** - Avoid trivial or contrived examples
-3. **Explain the flow** - Show how modules work together
-4. **Include output** - Show what users should expect to see
-5. **Error handling** - Demonstrate proper error handling patterns
-6. **Comment complex parts** - Help readers understand non-obvious code
-7. **Version compatibility** - Note if examples are version-specific
-
----
-
-## Code Quality Standards
-
-All example code should:
-- Follow project coding standards
-- Include proper error handling
-- Use async/await correctly
-- Show TypeScript types where applicable
-- Be tested and verified to work
-
----
-
-**Last Updated**: [Auto-generated timestamp]
-**See also**:
-- [Project README](./README.md) for getting started
-- [Architecture](./ARCHITECTURE.md) for understanding system design
-- [Module Documentation](./modules/) for API details

.claude/workflows/cli-templates/prompts/documentation/project-readme.txt

@@ -1,58 +1,35 @@
-# Project-Level Documentation Template
+Generate a comprehensive project-level README documentation.
 
-Generate comprehensive project documentation following this structure:
+## CORE CHECKLIST ⚡
+□ Clearly state the project's purpose and target audience
+□ Provide clear, runnable instructions for getting started
+□ Outline the development workflow and coding standards
+□ Offer a high-level overview of the project structure and architecture
 
-## 1. Overview
+## README STRUCTURE
-- **Purpose**: [High-level mission and goals of the project]
-- **Target Audience**: [Primary users, developers, stakeholders]
-- **Key Features**: [List of major functionalities and capabilities]
 
-## 2. System Architecture
+### 1. Overview
-- **Architectural Style**: [e.g., Monolith, Microservices, Layered, Event-Driven]
+- Purpose, Target Audience, and Key Features.
-- **Core Components**: [Diagram or list of major system parts and their interactions]
-- **Technology Stack**:
-  - Languages: [Programming languages used]
-  - Frameworks: [Key frameworks and libraries]
-  - Databases: [Data storage solutions]
-  - Infrastructure: [Deployment and hosting]
-- **Design Principles**: [Guiding principles like SOLID, DRY, separation of concerns]
 
-## 3. Getting Started
+### 2. System Architecture
-- **Prerequisites**: [Required software, tools, versions]
+- Architectural Style, Core Components, Tech Stack, and Design Principles.
-- **Installation**:
-  ```bash
-  # Installation commands
-  ```
-- **Configuration**: [Environment setup, config files]
-- **Running the Project**:
-  ```bash
-  # Startup commands
-  ```
 
-## 4. Development Workflow
+### 3. Getting Started
-- **Branching Strategy**: [e.g., GitFlow, trunk-based]
+- Prerequisites, Installation, Configuration, and Running the Project.
-- **Coding Standards**: [Style guide, linting rules]
-- **Testing**:
-  ```bash
-  # Test commands
-  ```
-- **Build & Deployment**: [CI/CD pipeline overview]
 
-## 5. Project Structure
+### 4. Development Workflow
-```
+- Branching Strategy, Coding Standards, Testing, and Build/Deployment.
-project-root/
-├── src/           # [Description]
-├── tests/         # [Description]
-├── docs/          # [Description]
-└── config/        # [Description]
-```
 
-## 6. Navigation
+### 5. Project Structure
-- [Module Documentation](./modules/)
+- A high-level tree view of the main directories.
-- [API Reference](./api/)
-- [Architecture Details](./architecture/)
-- [Contributing Guidelines](./CONTRIBUTING.md)
 
----
+### 6. Navigation
-**Last Updated**: [Auto-generated timestamp]
+- Links to more detailed documentation (modules, API, architecture).
-**Documentation Version**: [Project version]
+
+## VERIFICATION CHECKLIST ✓
+□ The project's purpose and value proposition are clear
+□ A new developer can successfully set up and run the project
+□ The development process and standards are well-defined
+□ The README provides clear navigation to other key documents
+
+Focus: Providing a central entry point for new users and developers to understand and run the project.

.claude/workflows/cli-templates/prompts/implementation/component.txt

@@ -1,16 +1,28 @@
-Guide component implementation and development patterns:
+Guide component implementation and development patterns.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Define component interface and API requirements clearly
+□ Identify reusable patterns and composition strategies
+□ Plan state management and data flow before implementation
+□ Design a comprehensive testing and validation approach
+
+## REQUIRED ANALYSIS
 1. Define component interface and API requirements
 2. Identify reusable patterns and composition strategies
 3. Plan state management and data flow implementation
 4. Design component testing and validation approach
 5. Document integration points and usage examples
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Component specification with clear interface definition
 - Implementation patterns and best practices
 - State management strategy and data flow design
 - Testing approach and validation criteria
 
-Focus on reusable, maintainable component design with clear usage patterns.
+## VERIFICATION CHECKLIST ✓
+□ Component specification includes a clear interface definition
+□ Reusable implementation patterns and best practices are documented
+□ State management and data flow design is clear and robust
+□ A thorough testing and validation approach is defined
+
+Focus: Reusable, maintainable component design with clear usage patterns.

.claude/workflows/cli-templates/prompts/memory/claude-module-unified.txt

@@ -1,12 +1,20 @@
-Create or update CLAUDE.md documentation with unified module/file template:
+Create or update CLAUDE.md documentation using unified module/file template.
 
-## Unified Module Documentation Requirements
+## CORE CHECKLIST ⚡
+□ MUST include all 6 sections: Purpose, Structure, Components, Dependencies, Integration, Implementation
+□ For code files: Document all public/exported APIs with complete parameter details
+□ For folders: Reference subdirectory CLAUDE.md files instead of duplicating
+□ Provide method signatures with parameter types, descriptions, defaults, and return values
+□ Distinguish internal dependencies from external libraries
+□ Apply RULES template requirements exactly as specified
+
+## DOCUMENTATION REQUIREMENTS
 
 ### Analysis Strategy
-- **For Folders/Modules**: Analyze directory structure, sub-modules, and architectural patterns
+- **Folders/Modules**: Analyze directory structure, sub-modules, and architectural patterns
-- **For Code Files**: Analyze classes, functions, interfaces, and implementation details
+- **Code Files**: Analyze classes, functions, interfaces, and implementation details
 
-### Content Focus (MUST INCLUDE):
+### Required Sections (ALL 6 MUST BE INCLUDED)
 
 #### 1. Purpose and Scope
 - Clear description of what this module/file does
@@ -14,42 +22,33 @@ Create or update CLAUDE.md documentation with unified module/file template:
 - Role within the larger system
 
 #### 2. Structure Overview
-**For Folders/Modules**:
+**For Folders**: Directory organization, sub-module categorization, architectural layout
-- Directory organization and file structure
+**For Code Files**: File organization (imports, exports), class hierarchy, function grouping
-- Sub-module categorization
-- Architectural layout
-
-**For Code Files**:
-- File organization (imports, exports, structure)
-- Core classes and their hierarchy
-- Main functions and their grouping
 
 #### 3. Key Components
-**For Folders/Modules**:
+**For Folders**: Sub-modules, major components, entry points, public interfaces
-- Sub-modules and their responsibilities
-- Major components and their interactions
-- Entry points and public interfaces
-
 **For Code Files**:
-- Core classes with brief descriptions
+- Core classes with descriptions and responsibilities
-- Key methods/functions with complete signatures and parameter details
+- Key methods with complete signatures:
-  - Method name and purpose
+  ```
-  - **Parameters**: name, type, description, default values (if any)
+  methodName(param1: Type1, param2: Type2): ReturnType
-  - **Return value**: type and description
+  - Purpose: [what it does]
-  - **Throws**: exceptions or errors (if applicable)
+  - Parameters:
+    • param1 (Type1): [description] [default: value]
+    • param2 (Type2): [description] [optional]
+  - Returns: (ReturnType) [description]
+  - Throws: [exception types and conditions]
+  - Example: [usage example for complex methods]
+  ```
 - Important interfaces/types
-- Exported APIs with usage examples
+- Exported APIs
 
 #### 4. Dependencies
-- **Internal Dependencies**: Other modules/files within the project
+**Internal Dependencies**: Other modules/files within project (with purpose)
-  - What it imports/requires
+**External Dependencies**: Third-party libraries and frameworks (with purpose, version constraints if critical)
-  - Dependency relationships and flow
-- **External Dependencies**: Third-party libraries and frameworks
-  - Critical dependencies and their purposes
-  - Version constraints if important
 
 #### 5. Integration Points
-- How this module/file connects to other parts
+- How this connects to other parts
 - Public APIs or interfaces exposed
 - Data flow patterns (input → processing → output)
 - Event handling or callbacks
@@ -63,25 +62,9 @@ Create or update CLAUDE.md documentation with unified module/file template:
 - Security considerations if applicable
 - Known limitations or caveats
 
-### Documentation Style Guidelines:
+## OUTPUT REQUIREMENTS
-- Be concise but complete
-- Use clear, descriptive language
-- Include code signatures for key APIs
-- **For method parameters**:
-  - Always document each parameter with name, type, and description
-  - Indicate optional parameters with `[optional]`
-  - Show default values with `[default: value]`
-  - Include parameter constraints if applicable (e.g., range, format)
-- **For return values**:
-  - Specify return type clearly
-  - Describe what the returned value represents
-  - Document special return conditions (null, undefined, empty, etc.)
-- Focus on "what" and "why", not detailed "how"
-- Reference related documentation when appropriate
-- Use bullet points for readability
-- Provide usage examples for complex methods
 
-### Template Structure:
+### Template Structure
 ```markdown
 # [Module/File Name]
 
@@ -92,46 +75,32 @@ Create or update CLAUDE.md documentation with unified module/file template:
 [Directory structure for modules OR File organization for code files]
 
 ## Key Components
-### [Component/Class Name 1]
+### [Component/Class Name]
 - Description: [Brief description]
 - Responsibilities: [What it does]
 - Key Methods:
-
+  #### `methodName(param1: Type1, param2?: Type2): ReturnType`
-  #### `methodName(param1: Type1, param2: Type2, ...): ReturnType`
+  - Purpose: [what this method does]
-  - **Purpose**: [What this method does]
+  - Parameters:
-  - **Parameters**:
+    • param1 (Type1): [description]
-    - `param1` (Type1): [Description of param1] [default: value]
+    • param2 (Type2): [description] [optional] [default: value]
-    - `param2` (Type2): [Description of param2] [optional]
+  - Returns: (ReturnType) [description]
-  - **Returns**: (ReturnType) [Description of return value]
+  - Throws: [exceptions if applicable]
-  - **Throws**: [Exception types and conditions]
-  - **Example**:
-    ```
-    const result = instance.methodName(value1, value2);
-    ```
-
-### [Component/Class Name 2]
-...
 
 ## Dependencies
 ### Internal Dependencies
 - `[module/file path]` - [purpose]
-- ...
 
 ### External Dependencies
 - `[library name]` - [purpose and usage]
-- ...
 
 ## Integration Points
 ### Public APIs
 - `[API/function signature]` - [description]
-- ...
 
 ### Data Flow
 [How data flows through this module/file]
 
-### Extension Points
-[How this can be extended or customized]
-
 ## Implementation Notes
 ### Design Patterns
 - [Pattern name]: [Usage and rationale]
@@ -139,34 +108,46 @@ Create or update CLAUDE.md documentation with unified module/file template:
 ### Technical Decisions
 - [Decision]: [Rationale]
 
-### Configuration
-- [Config item]: [Purpose and default]
-
 ### Considerations
-- Performance: [Any performance notes]
+- Performance: [notes]
-- Security: [Any security considerations]
+- Security: [notes]
-- Limitations: [Known limitations]
+- Limitations: [notes]
 ```
 
-### Content Restrictions (STRICTLY AVOID):
+### Documentation Style
-- Don't duplicate content from other CLAUDE.md files - reference them instead
+- **Concise but complete** - Focus on "what" and "why", not detailed "how"
-- Avoid overly detailed code explanations (code should be self-documenting)
+- **Code signatures** for key APIs - Include all parameter details
-- Don't include complete code listings (use signatures and descriptions)
+- **Parameters**: Name, type, description, optional/default indicators, constraints
-- Avoid version-specific implementation details unless critical
+- **Return values**: Type, description, special conditions (null, undefined, empty)
-- Don't document every single function - focus on key components
+- **Evidence-based** - Reference related documentation when appropriate
-- **BUT DO document**: All public/exported APIs with complete parameter details
+- **Examples** for complex methods - Show usage patterns
-- **Internal/private methods**: Only document if they are complex or critical to understanding
 
-### Special Instructions:
+### Content Restrictions (STRICTLY AVOID)
-- If analyzing a folder with existing CLAUDE.md files in subdirectories, reference them rather than duplicating their content
+- ❌ Duplicating content from other CLAUDE.md files (reference instead)
-- For code files, prioritize exported/public APIs over internal implementation details
+- ❌ Overly detailed code explanations (code should be self-documenting)
-- **For method documentation**:
+- ❌ Complete code listings (use signatures and descriptions)
-  - MUST document all parameters for public/exported methods
+- ❌ Version-specific details unless critical
-  - Include parameter types, descriptions, and constraints
+- ❌ Documenting every single function (focus on public/exported APIs)
-  - Document return values and exceptions
-  - Add usage examples for non-trivial methods
-  - Private/internal methods: document only if complex or critical
-- Keep dependency lists focused on direct dependencies, not transitive ones
-- Update existing CLAUDE.md files rather than creating new sections unnecessarily
 
-Remember: This template serves both folder-level module documentation and file-level implementation documentation. Adapt the sections based on what you're documenting.
+### Method Documentation Rules
+- **Public/Exported methods**: MUST document with full parameter details
+- **Private/Internal methods**: Only document if complex or critical
+- **Parameters**: MUST include type, description, constraints, defaults
+- **Return values**: MUST document type and description
+- **Exceptions**: Document all thrown errors
+
+### Special Instructions
+- If analyzing folder with existing subdirectory CLAUDE.md files → reference them
+- For code files → prioritize exported/public APIs
+- Keep dependency lists focused on direct dependencies (not transitive)
+- Update existing CLAUDE.md files rather than creating duplicate sections
+
+## VERIFICATION CHECKLIST ✓
+□ All 6 required sections included (Purpose, Structure, Components, Dependencies, Integration, Implementation)
+□ All public/exported APIs documented with complete signatures
+□ Parameters documented with types, descriptions, and defaults
+□ References used instead of duplicating subdirectory documentation
+□ Internal vs external dependencies clearly distinguished
+□ Examples provided for non-trivial methods
+
+Focus: Comprehensive yet concise documentation covering all essential aspects without redundancy.

.claude/workflows/cli-templates/prompts/planning/concept-eval.txt

@@ -1,77 +1,78 @@
-CONCEPT EVALUATION FRAMEWORK
+Conduct comprehensive concept evaluation to assess feasibility, identify risks, and provide optimization recommendations.
 
-## EVALUATION DIRECTIVE
+## CORE CHECKLIST ⚡
-You are conducting a comprehensive concept evaluation to assess feasibility, identify risks, and provide optimization recommendations before formal implementation planning begins.
+□ Evaluate all 6 dimensions: Conceptual, Architectural, Technical, Resource, Risk, Dependency
+□ Provide quantified assessment scores (1-5 scale)
+□ Classify risks by severity (LOW/MEDIUM/HIGH/CRITICAL)
+□ Include specific, actionable recommendations
+□ Integrate session context and existing patterns
 
-## CORE EVALUATION DIMENSIONS
+## EVALUATION DIMENSIONS
 
-### 1. CONCEPTUAL INTEGRITY
+### 1. Conceptual Integrity
-- **Design Coherence**: Are all components logically connected and consistent?
+- Design Coherence: Logical component connections
-- **Requirement Completeness**: Are all necessary requirements identified and defined?
+- Requirement Completeness: All requirements identified
-- **Scope Clarity**: Is the concept scope clearly defined and bounded?
+- Scope Clarity: Defined and bounded scope
-- **Success Criteria**: Are measurable success criteria clearly established?
+- Success Criteria: Measurable metrics established
 
-### 2. ARCHITECTURAL SOUNDNESS
+### 2. Architectural Soundness
-- **System Integration**: How well does the concept integrate with existing architecture?
+- System Integration: Fit with existing architecture
-- **Design Patterns**: Are appropriate and established design patterns utilized?
+- Design Patterns: Appropriate pattern usage
-- **Modularity**: Is the concept appropriately modular and maintainable?
+- Modularity: Maintainable structure
-- **Scalability**: Can the concept scale to meet future requirements?
+- Scalability: Future requirement capacity
 
-### 3. TECHNICAL FEASIBILITY
+### 3. Technical Feasibility
-- **Implementation Complexity**: What is the technical difficulty level?
+- Implementation Complexity: Difficulty level assessment
-- **Technology Maturity**: Are required technologies stable and well-supported?
+- Technology Maturity: Stable, supported technologies
-- **Skill Requirements**: Do we have the necessary technical expertise?
+- Skill Requirements: Team expertise availability
-- **Infrastructure Needs**: What infrastructure changes or additions are required?
+- Infrastructure Needs: Required changes/additions
 
-### 4. RESOURCE ASSESSMENT
+### 4. Resource Assessment
-- **Development Time**: Realistic time estimation for implementation
+- Development Time: Realistic estimation
-- **Team Resources**: Required team size and skill composition
+- Team Resources: Size and skill composition
-- **Budget Impact**: Financial implications and resource allocation
+- Budget Impact: Financial implications
-- **Opportunity Cost**: What other initiatives might be delayed or cancelled?
+- Opportunity Cost: Delayed initiatives
 
-### 5. RISK IDENTIFICATION
+### 5. Risk Identification
-- **Technical Risks**: Technology limitations, complexity, and unknowns
+- Technical Risks: Limitations, complexity, unknowns
-- **Business Risks**: Market timing, user adoption, and business impact
+- Business Risks: Market timing, adoption, impact
-- **Integration Risks**: Compatibility and system integration challenges
+- Integration Risks: Compatibility challenges
-- **Resource Risks**: Team availability, skill gaps, and timeline pressures
+- Resource Risks: Availability, skills, timeline
 
-### 6. DEPENDENCY ANALYSIS
+### 6. Dependency Analysis
-- **External Dependencies**: Third-party services, libraries, and tools
+- External Dependencies: Third-party services/tools
-- **Internal Dependencies**: Other systems, teams, and organizational resources
+- Internal Dependencies: Systems, teams, resources
-- **Temporal Dependencies**: Sequence requirements and timing constraints
+- Temporal Dependencies: Sequence and timing
-- **Critical Path**: Essential dependencies that could block progress
+- Critical Path: Essential blocking dependencies
 
-## EVALUATION METHODOLOGY
+## ASSESSMENT METHODOLOGY
 
-### ASSESSMENT CRITERIA
+**Scoring Scale** (1-5):
-Rate each dimension on a scale of 1-5:
+- 5 - Excellent: Minimal risk, well-defined, highly feasible
-- **5 - Excellent**: Minimal risk, well-defined, highly feasible
+- 4 - Good: Low risk, mostly clear, feasible
-- **4 - Good**: Low risk, mostly clear, feasible with minor adjustments
+- 3 - Average: Moderate risk, needs clarification
-- **3 - Average**: Moderate risk, some clarification needed, feasible with effort
+- 2 - Poor: High risk, major changes required
-- **2 - Poor**: High risk, significant issues, major changes required
+- 1 - Critical: Very high risk, fundamental problems
-- **1 - Critical**: Very high risk, fundamental problems, may not be feasible
 
-### RISK CLASSIFICATION
+**Risk Levels**:
-- **LOW**: Minor issues, easily addressable
+- LOW: Minor issues, easily addressable
-- **MEDIUM**: Manageable challenges requiring attention
+- MEDIUM: Manageable challenges
-- **HIGH**: Significant concerns requiring major mitigation
+- HIGH: Significant concerns, major mitigation needed
-- **CRITICAL**: Fundamental problems threatening concept viability
+- CRITICAL: Fundamental viability threats
 
-### OPTIMIZATION PRIORITIES
+**Optimization Priorities**:
-- **CRITICAL**: Must be addressed before planning
+- CRITICAL: Must address before planning
-- **IMPORTANT**: Should be addressed for optimal outcomes
+- IMPORTANT: Should address for optimal outcomes
-- **OPTIONAL**: Nice-to-have improvements
+- OPTIONAL: Nice-to-have improvements
 
 ## OUTPUT REQUIREMENTS
 
-### EVALUATION SUMMARY
+### Evaluation Summary
 ```markdown
-# Concept Evaluation Summary
-
 ## Overall Assessment
-- **Feasibility Score**: X/5
+- Feasibility Score: X/5
-- **Risk Level**: LOW/MEDIUM/HIGH/CRITICAL
+- Risk Level: LOW/MEDIUM/HIGH/CRITICAL
-- **Recommendation**: PROCEED/PROCEED_WITH_MODIFICATIONS/RECONSIDER/REJECT
+- Recommendation: PROCEED/PROCEED_WITH_MODIFICATIONS/RECONSIDER/REJECT
 
 ## Dimension Scores
 - Conceptual Integrity: X/5
@@ -82,120 +83,45 @@ Rate each dimension on a scale of 1-5:
 - Dependency Complexity: X/5
 ```
 
-### DETAILED ANALYSIS
+### Detailed Analysis
-For each dimension, provide:
+For each dimension:
-1. **Assessment**: Current state evaluation
+1. Assessment: Current state evaluation
-2. **Strengths**: What works well in the concept
+2. Strengths: What works well
-3. **Concerns**: Identified issues and risks
+3. Concerns: Issues and risks
-4. **Recommendations**: Specific improvement suggestions
+4. Recommendations: Specific improvements
 
-### RISK MATRIX
+### Risk Matrix
-```markdown
 | Risk Category | Level | Impact | Mitigation Strategy |
-|---------------|-------|--------|-------------------|
+|---------------|-------|--------|---------------------|
-| Technical     | HIGH  | Delays | Proof of concept  |
+| Technical     | HIGH  | Delays | Proof of concept    |
-| Resource      | MED   | Budget | Phase approach    |
+| Resource      | MED   | Budget | Phased approach     |
-```
 
-### OPTIMIZATION ROADMAP
+### Optimization Roadmap
-Prioritized list of improvements:
+1. CRITICAL: [Issue] - [Recommendation] - [Impact]
-1. **CRITICAL**: [Issue] - [Recommendation] - [Impact]
+2. IMPORTANT: [Issue] - [Recommendation] - [Impact]
-2. **IMPORTANT**: [Issue] - [Recommendation] - [Impact]
+3. OPTIONAL: [Issue] - [Recommendation] - [Impact]
-3. **OPTIONAL**: [Issue] - [Recommendation] - [Impact]
 
-## CONTEXT INTEGRATION RULES
+## CONTEXT INTEGRATION
 
-### CLAUDE CODE MEMORY INTEGRATION
+**Session Memory**: Reference current conversation, decisions, patterns from session history
-- **Session Context**: Reference current conversation history and decisions made
+**Existing Patterns**: Identify similar implementations, evaluate success/failure, leverage proven approaches
-- **Project Memory**: Leverage knowledge from previous implementations and lessons learned
+**Architectural Alignment**: Ensure consistency, consider evolution, apply standards
-- **Pattern Recognition**: Use identified successful approaches and anti-patterns from session memory
+**Business Context**: Strategic fit, user impact, competitive advantage, timeline alignment
-- **Evaluation History**: Consider previous concept evaluations and their outcomes
-- **Technical Evolution**: Build on previous technical decisions and architectural changes
-- **Context Continuity**: Maintain consistency with established project direction and decisions
 
-### EXISTING PATTERNS
+## PROJECT TYPE CONSIDERATIONS
-- **Identify**: Find similar implementations in the codebase
-- **Analyze**: Evaluate success/failure patterns
-- **Leverage**: Recommend reusing successful approaches
-- **Avoid**: Flag problematic patterns to avoid
 
-### ARCHITECTURAL ALIGNMENT
+**Innovation Projects**: Higher risk tolerance, learning focus, phased approach
-- **Consistency**: Ensure concept aligns with existing architecture
+**Critical Business**: Lower risk tolerance, reliability focus, comprehensive mitigation
-- **Evolution**: Consider architectural evolution and migration paths
+**Integration Projects**: Compatibility focus, minimal disruption, rollback strategies
-- **Standards**: Apply established coding and design standards
+**Greenfield Projects**: Architectural innovation, scalability, technology standardization
-- **Integration**: Evaluate integration touchpoints and complexity
 
-### BUSINESS CONTEXT
+## VERIFICATION CHECKLIST ✓
-- **Strategic Fit**: Alignment with business objectives and priorities
+□ All 6 evaluation dimensions thoroughly assessed with scores
-- **User Impact**: Effect on user experience and satisfaction
+□ Risk matrix completed with mitigation strategies
-- **Competitive Advantage**: Differentiation and market positioning
+□ Optimization recommendations prioritized (CRITICAL/IMPORTANT/OPTIONAL)
-- **Timeline**: Alignment with business timelines and milestones
+□ Integration with existing systems evaluated
+□ Resource requirements and timeline implications identified
+□ Success criteria and validation metrics defined
+□ Next steps and decision points outlined
 
-## QUALITY STANDARDS
+Focus: Actionable insights to improve concept quality and reduce implementation risks.
-
-### ANALYSIS DEPTH
-- Provide specific examples and evidence
-- Quantify assessments where possible
-- Consider multiple perspectives and scenarios
-- Base recommendations on concrete analysis
-
-### ACTIONABILITY
-- Make recommendations specific and implementable
-- Provide clear next steps and decision points
-- Identify responsible parties and timelines
-- Include success metrics and validation criteria
-
-### OBJECTIVITY
-- Balance optimism with realistic assessment
-- Acknowledge uncertainty and assumptions
-- Present multiple options where applicable
-- Focus on concept improvement rather than criticism
-
-## SPECIAL CONSIDERATIONS
-
-### INNOVATION PROJECTS
-- Higher tolerance for technical risk
-- Emphasis on learning and experimentation
-- Phased approach with validation milestones
-- Clear success/failure criteria
-
-### CRITICAL BUSINESS PROJECTS
-- Lower risk tolerance
-- Emphasis on reliability and predictability
-- Comprehensive risk mitigation strategies
-- Detailed contingency planning
-
-### INTEGRATION PROJECTS
-- Focus on compatibility and interoperability
-- Emphasis on minimizing system disruption
-- Careful change management planning
-- Rollback and recovery strategies
-
-### GREENFIELD PROJECTS
-- Opportunity for architectural innovation
-- Emphasis on future scalability and flexibility
-- Technology stack selection and standardization
-- Team skill development considerations
-
-## EVALUATION COMPLETION CHECKLIST
-
-- [ ] All six evaluation dimensions thoroughly assessed
-- [ ] Risk matrix completed with mitigation strategies
-- [ ] Optimization recommendations prioritized
-- [ ] Integration with existing systems evaluated
-- [ ] Resource requirements clearly identified
-- [ ] Timeline implications considered
-- [ ] Success criteria and validation metrics defined
-- [ ] Next steps and decision points outlined
-
-## OUTPUT FORMAT
-
-Provide a structured evaluation report that includes:
-1. Executive summary with overall recommendation
-2. Detailed dimension-by-dimension analysis
-3. Risk assessment and mitigation strategies
-4. Prioritized optimization recommendations
-5. Implementation roadmap and next steps
-6. Resource requirements and timeline implications
-
-Focus on providing actionable insights that will improve concept quality and reduce implementation risks during the formal planning phase.

.claude/workflows/cli-templates/prompts/planning/migration.txt

@@ -1,16 +1,30 @@
-Plan system migration and modernization strategies:
+Plan system migration and modernization strategies.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Assess current system completely before planning migration
+□ Plan incremental migration (avoid big-bang approach)
+□ Include rollback plan for every migration step
+□ Provide file:line references for all affected code
+
+## REQUIRED ANALYSIS
 1. Assess current system architecture and migration requirements
 2. Identify migration paths and transformation strategies
 3. Plan data migration and system cutover procedures
 4. Evaluate compatibility and integration challenges
 5. Document rollback plans and risk mitigation strategies
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Migration strategy with step-by-step execution plan
 - Data migration procedures and validation checkpoints
-- Compatibility assessment and integration requirements
+- Compatibility assessment with file:line references
-- Risk analysis and rollback procedures
+- Risk analysis and rollback procedures for each phase
+- Testing strategy for migration validation
 
-Focus on low-risk migration strategies with comprehensive fallback options.
+## VERIFICATION CHECKLIST ✓
+□ Migration planned in incremental phases (not big-bang)
+□ Every phase has rollback plan documented
+□ Data migration validated with checkpoints
+□ Compatibility issues identified and mitigated
+□ Testing strategy covers all migration phases
+
+Focus: Low-risk incremental migration with comprehensive fallback options.

.claude/workflows/cli-templates/prompts/planning/task-breakdown.txt

@@ -1,16 +1,30 @@
-Create detailed task breakdown and implementation planning:
+Create detailed task breakdown and implementation planning.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Break down tasks into manageable subtasks (3-8 hours each)
+□ Identify all dependencies and execution sequence
+□ Provide realistic effort estimates with buffer
+□ Document risks for each task
+
+## REQUIRED ANALYSIS
 1. Break down complex tasks into manageable subtasks
 2. Identify dependencies and execution sequence requirements
 3. Estimate effort and resource requirements for each task
 4. Map task relationships and critical path analysis
 5. Document risks and mitigation strategies
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Hierarchical task breakdown with specific deliverables
 - Dependency mapping and execution sequence
-- Effort estimation and resource allocation
+- Effort estimation with confidence levels
-- Risk assessment and mitigation plans
+- Resource allocation and skill requirements
+- Risk assessment and mitigation plans for each task
 
-Focus on actionable task planning with clear deliverables and timelines.
+## VERIFICATION CHECKLIST ✓
+□ All tasks broken down to manageable size (3-8 hours)
+□ Dependencies mapped and critical path identified
+□ Effort estimates realistic with buffer included
+□ Every task has clear deliverable defined
+□ Risks documented with mitigation strategies
+
+Focus: Actionable task planning with clear deliverables, dependencies, and realistic timelines.

.claude/workflows/cli-templates/prompts/review/code-review.txt

@@ -1,16 +1,28 @@
-Conduct comprehensive code review and quality assessment:
+Conduct comprehensive code review and quality assessment.
 
-## Required Analysis:
+## CORE CHECKLIST ⚡
+□ Review against established coding standards and conventions
+□ Assess logic correctness, including potential edge cases
+□ Evaluate security implications and vulnerability risks
+□ Check for performance bottlenecks and optimization opportunities
+
+## REQUIRED ANALYSIS
 1. Review code against established coding standards and conventions
 2. Assess logic correctness and potential edge cases
 3. Evaluate security implications and vulnerability risks
 4. Check performance characteristics and optimization opportunities
 5. Validate test coverage and documentation completeness
 
-## Output Requirements:
+## OUTPUT REQUIREMENTS
 - Standards compliance assessment with specific violations
 - Logic review findings with potential issue identification
 - Security assessment with vulnerability documentation
 - Performance review with optimization recommendations
 
-Focus on actionable feedback with clear improvement priorities and implementation guidance.
+## VERIFICATION CHECKLIST ✓
+□ Code is assessed against established standards
+□ Logic, including edge cases, is thoroughly reviewed
+□ Security and performance have been evaluated
+□ Test coverage and documentation are validated
+
+Focus: Actionable feedback with clear improvement priorities and implementation guidance.

.claude/workflows/cli-templates/prompts/verification/codex-technical.txt

@@ -1,59 +1,28 @@
-Technical feasibility assessment of workflow implementation plan from code quality and execution perspective:
+Assess the technical feasibility of a workflow implementation plan.
 
-## Required Technical Analysis:
+## CORE CHECKLIST ⚡
-1. **Implementation Complexity Assessment**
+□ Evaluate implementation complexity and required skills
-   - Evaluate code complexity and technical difficulty
+□ Validate all technical dependencies and prerequisites
-   - Assess required technical skills and expertise levels
+□ Assess the proposed code structure and integration patterns
-   - Validate implementation approach feasibility
+□ Verify the completeness of the testing strategy
-   - Identify technical challenges and solutions
 
-2. **Technical Dependencies Validation**
+## REQUIRED TECHNICAL ANALYSIS
-   - Review external library and framework dependencies
+1. **Implementation Complexity**: Evaluate code difficulty and required skills.
-   - Assess version compatibility and dependency conflicts
+2. **Technical Dependencies**: Review libraries, versions, and build systems.
-   - Evaluate build system and deployment requirements
+3. **Code Structure**: Assess file organization, naming, and modularity.
-   - Identify missing technical prerequisites
+4. **Testing Completeness**: Evaluate test coverage, types, and gaps.
+5. **Execution Readiness**: Validate control flow, context, and file targets.
 
-3. **Code Structure Assessment**
+## OUTPUT REQUIREMENTS
-   - Evaluate proposed file organization and structure
+- **Technical Assessment Report**: Grades for implementation, complexity, and quality.
-   - Assess naming conventions and code organization
+- **Detailed Technical Findings**: Blocking issues, performance concerns, and improvements.
-   - Validate integration with existing codebase patterns
+- **Implementation Recommendations**: Prerequisites, best practices, and refactoring.
-   - Review modularity and separation of concerns
+- **Risk Mitigation**: Technical, dependency, integration, and quality risks.
 
-4. **Testing Completeness Evaluation**
+## VERIFICATION CHECKLIST ✓
-   - Assess test coverage and testing strategy completeness
+□ Implementation complexity and feasibility have been thoroughly evaluated
-   - Evaluate test types and testing approach adequacy
+□ All technical dependencies and prerequisites are validated
-   - Review integration testing and end-to-end coverage
+□ The proposed code structure aligns with project standards
-   - Identify testing gaps and quality assurance needs
+□ The testing plan is complete and adequate for the proposed changes
 
-5. **Execution Readiness Verification**
+Focus: Technical execution details, code quality concerns, and implementation feasibility.
-   - Validate flow_control definitions and execution paths
-   - Assess task context completeness and adequacy
-   - Evaluate target_files specifications and accuracy
-   - Review implementation prerequisites and setup requirements
-
-## Output Requirements:
-### Technical Assessment Report:
-- **Implementation Grade** (A-F): Technical approach quality
-- **Complexity Score** (1-10): Implementation difficulty level
-- **Readiness Level** (1-5): Execution preparation completeness
-- **Quality Rating** (1-10): Code quality and maintainability projection
-
-### Detailed Technical Findings:
-- **Blocking Issues**: Technical problems that prevent implementation
-- **Performance Concerns**: Scalability and performance implications
-- **Quality Improvements**: Code quality and maintainability enhancements
-- **Testing Enhancements**: Testing strategy and coverage improvements
-
-### Implementation Recommendations:
-- **Prerequisites**: Required setup and configuration changes
-- **Best Practices**: Code patterns and conventions to follow
-- **Tool Requirements**: Additional tools or dependencies needed
-- **Refactoring Suggestions**: Code structure and organization improvements
-
-### Risk Mitigation:
-- **Technical Risks**: Implementation complexity and technical debt
-- **Dependency Risks**: External dependencies and compatibility issues
-- **Integration Risks**: Codebase integration and compatibility concerns
-- **Quality Risks**: Code quality and maintainability implications
-
-Focus on technical execution details, code quality concerns, and implementation feasibility. Provide specific, actionable recommendations with clear implementation guidance and priority levels.

.claude/workflows/cli-templates/prompts/verification/cross-validation.txt

@@ -1,65 +1,28 @@
-Cross-validation analysis of gemini strategic and codex technical assessments for workflow implementation plan:
+Cross-validate strategic (Gemini) and technical (Codex) assessments.
 
-## Required Cross-Validation Analysis:
+## CORE CHECKLIST ⚡
-1. **Consensus Identification**
+□ Identify both consensus and conflict between the two analyses
-   - Identify areas where both analyses agree on issues or strengths
+□ Synthesize a unified risk profile and recommendation set
-   - Document shared concerns and aligned recommendations
+□ Resolve conflicting suggestions with a balanced approach
-   - Highlight consistent risk assessments and mitigation strategies
+□ Frame final decisions as clear choices for the user
-   - Establish priority consensus for implementation focus
 
-2. **Conflict Resolution Analysis**
+## REQUIRED CROSS-VALIDATION ANALYSIS
-   - Identify discrepancies between strategic and technical perspectives
+1. **Consensus Identification**: Find where both analyses agree.
-   - Analyze root causes of conflicting assessments
+2. **Conflict Resolution**: Analyze and resolve discrepancies.
-   - Evaluate trade-offs between strategic goals and technical constraints
+3. **Risk Level Synthesis**: Combine risk assessments into a single profile.
-   - Provide balanced recommendations for resolution
+4. **Recommendation Integration**: Synthesize recommendations into a unified plan.
+5. **Quality Assurance Framework**: Establish combined quality metrics.
 
-3. **Risk Level Synthesis**
+## OUTPUT REQUIREMENTS
-   - Combine strategic and technical risk assessments
+- **Cross-Validation Summary**: Overall grade, confidence score, and risk profile.
-   - Establish overall implementation risk profile
+- **Synthesis Report**: Consensus areas, conflict areas, and integrated recommendations.
-   - Prioritize risks by impact and probability
+- **User Approval Framework**: A clear breakdown of changes for user approval.
-   - Recommend risk mitigation strategies
+- **Modification Categories**: Classify changes by type (e.g., Task Structure, Technical).
 
-4. **Recommendation Integration**
+## VERIFICATION CHECKLIST ✓
-   - Synthesize strategic and technical recommendations
+□ Both consensus and conflict between analyses are identified and documented
-   - Resolve conflicting suggestions with balanced approach
+□ Risks and recommendations are synthesized into a single, coherent plan
-   - Prioritize recommendations by impact and effort
+□ Conflicting points are resolved with balanced, well-reasoned proposals
-   - Establish implementation sequence and dependencies
+□ Final output is structured to facilitate clear user decisions
 
-5. **Quality Assurance Framework**
+Focus: A balanced integration of strategic and technical perspectives to produce a single, actionable plan.
-   - Establish combined quality metrics and success criteria
-   - Define validation checkpoints and review gates
-   - Recommend monitoring and feedback mechanisms
-   - Ensure both strategic and technical quality standards
-
-## Input Analysis Sources:
-- **Gemini Strategic Analysis**: Architecture, business alignment, strategic risks
-- **Codex Technical Analysis**: Implementation feasibility, code quality, technical risks
-- **Original Implementation Plan**: IMPL_PLAN.md, task definitions, context
-
-## Output Requirements:
-### Cross-Validation Summary:
-- **Overall Assessment Grade** (A-F): Combined strategic and technical evaluation
-- **Implementation Confidence** (1-10): Combined feasibility assessment
-- **Risk Profile**: High/Medium/Low with specific risk categories
-- **Recommendation Priority Matrix**: Urgent/Important classification
-
-### Synthesis Report:
-- **Consensus Areas**: Shared findings and aligned recommendations
-- **Conflict Areas**: Divergent perspectives requiring resolution
-- **Integrated Recommendations**: Balanced strategic and technical guidance
-- **Implementation Roadmap**: Phased approach balancing strategic and technical needs
-
-### User Approval Framework:
-- **Critical Changes**: Must-implement modifications (blocking issues)
-- **Important Improvements**: High-value enhancements (quality/efficiency)
-- **Optional Enhancements**: Nice-to-have improvements (future consideration)
-- **Trade-off Decisions**: User choice between competing approaches
-
-### Modification Categories:
-- **Task Structure**: Task merging, splitting, or reordering
-- **Dependencies**: Dependency additions, removals, or modifications
-- **Context Enhancement**: Requirements, acceptance criteria, or documentation
-- **Technical Adjustments**: Implementation approach or tool changes
-- **Strategic Alignment**: Business objective or success criteria refinement
-
-Focus on balanced integration of strategic and technical perspectives. Provide clear user decision points with impact analysis and implementation guidance. Prioritize recommendations by combined strategic and technical value.

.claude/workflows/cli-templates/prompts/verification/gemini-strategic.txt

@@ -1,52 +1,27 @@
-Strategic validation of workflow implementation plan from architectural and business perspective:
+Validate the strategic and architectural soundness of a workflow implementation plan.
 
-## Required Strategic Analysis:
+## CORE CHECKLIST ⚡
-1. **Architectural Soundness Assessment**
+□ Evaluate the plan against high-level system architecture
-   - Evaluate overall system design coherence
+□ Assess the logic of the task breakdown and dependencies
-   - Assess component interaction patterns
+□ Verify alignment with stated business objectives and success criteria
-   - Validate architectural decision consistency
+□ Identify strategic risks, not just low-level technical ones
-   - Identify potential design conflicts or gaps
 
-2. **Task Decomposition Logic Evaluation**
+## REQUIRED STRATEGIC ANALYSIS
-   - Review task breakdown methodology and rationale
+1. **Architectural Soundness**: Assess design coherence and pattern consistency.
-   - Assess functional completeness of each task
+2. **Task Decomposition Logic**: Review task breakdown, granularity, and completeness.
-   - Evaluate task granularity and scope appropriateness
+3. **Dependency Coherence**: Analyze task interdependencies and logical flow.
-   - Identify missing or redundant decomposition elements
+4. **Business Alignment**: Validate against business objectives and requirements.
+5. **Strategic Risk Identification**: Identify architectural, resource, and timeline risks.
 
-3. **Dependency Coherence Analysis**
+## OUTPUT REQUIREMENTS
-   - Map task interdependencies and logical flow
+- **Strategic Assessment Report**: Grades for architecture, decomposition, and business alignment.
-   - Validate dependency ordering and scheduling
+- **Detailed Recommendations**: Critical issues, improvements, and alternative approaches.
-   - Assess circular dependency risks
+- **Action Items**: A prioritized list of changes (Immediate, Short-term, Long-term).
-   - Evaluate parallel execution opportunities
 
-4. **Business Alignment Verification**
+## VERIFICATION CHECKLIST ✓
-   - Validate alignment with stated business objectives
+□ The plan's architectural soundness has been thoroughly assessed
-   - Assess stakeholder requirement coverage
+□ Task decomposition and dependencies are logical and coherent
-   - Evaluate success criteria completeness and measurability
+□ The plan is confirmed to be in alignment with business goals
-   - Identify business risk and mitigation adequacy
+□ Strategic risks are identified with clear recommendations
 
-5. **Strategic Risk Identification**
+Focus: High-level strategic concerns, business alignment, and long-term architectural implications.
-   - Identify architectural risks and technical debt implications
-   - Assess implementation complexity and resource requirements
-   - Evaluate timeline feasibility and milestone realism
-   - Document potential blockers and escalation scenarios
-
-## Output Requirements:
-### Strategic Assessment Report:
-- **Architecture Grade** (A-F): Overall design quality assessment
-- **Decomposition Grade** (A-F): Task breakdown effectiveness
-- **Risk Level** (Low/Medium/High): Combined implementation risk
-- **Business Alignment Score** (1-10): Requirement satisfaction level
-
-### Detailed Recommendations:
-- **Critical Issues**: Must-fix problems that could cause failure
-- **Improvement Opportunities**: Non-blocking enhancements
-- **Alternative Approaches**: Strategic alternatives worth considering
-- **Resource Implications**: Staffing and timeline considerations
-
-### Action Items:
-- **Immediate**: Changes needed before implementation starts
-- **Short-term**: Improvements for early phases
-- **Long-term**: Strategic enhancements for future iterations
-
-Focus on high-level strategic concerns, business alignment, and long-term architectural implications. Provide actionable recommendations with clear rationale and priority levels.

.claude/workflows/workflow-architecture.md

@@ -678,15 +678,20 @@ All workflows use the same file structure definition regardless of complexity. *
 │
 ├── [.design/]                  # Standalone UI design outputs (created when needed)
 │   └── run-[timestamp]/        # Timestamped design runs without session
-│       ├── style-extraction/   # Style analysis results
+│       ├── .intermediates/     # Intermediate analysis files
-│       ├── style-consolidation/ # Design system tokens (per-style)
+│       │   ├── style-analysis/ # Style analysis data
+│       │   │   ├── computed-styles.json        # Extracted CSS values
+│       │   │   └── design-space-analysis.json  # Design directions
+│       │   └── layout-analysis/ # Layout analysis data
+│       │       ├── dom-structure-{target}.json # DOM extraction
+│       │       └── inspirations/               # Layout research
+│       │           └── {target}-layout-ideas.txt
+│       ├── style-extraction/   # Final design systems
 │       │   ├── style-1/        # design-tokens.json, style-guide.md
 │       │   └── style-N/
+│       ├── layout-extraction/  # Layout templates
+│       │   └── layout-templates.json
 │       ├── prototypes/         # Generated HTML/CSS prototypes
-│       │   ├── _templates/     # Target-specific layout plans and templates
-│       │   │   ├── {target}-layout-{n}.json  # Layout plan (target-specific)
-│       │   │   ├── {target}-layout-{n}.html  # HTML template
-│       │   │   └── {target}-layout-{n}.css   # CSS template
 │       │   ├── {target}-style-{s}-layout-{l}.html  # Final prototypes
 │       │   ├── compare.html    # Interactive matrix view
 │       │   └── index.html      # Navigation page
@@ -706,15 +711,20 @@ All workflows use the same file structure definition regardless of complexity. *
     │   ├── IMPL-*-summary.md      # Main task summaries
     │   └── IMPL-*.*-summary.md    # Subtask summaries
     ├── [design-*/]                 # UI design outputs (created by ui-design workflows)
-    │   ├── style-extraction/       # Style analysis results
+    │   ├── .intermediates/         # Intermediate analysis files
-    │   ├── style-consolidation/    # Design system tokens (per-style)
+    │   │   ├── style-analysis/     # Style analysis data
+    │   │   │   ├── computed-styles.json        # Extracted CSS values
+    │   │   │   └── design-space-analysis.json  # Design directions
+    │   │   └── layout-analysis/    # Layout analysis data
+    │   │       ├── dom-structure-{target}.json # DOM extraction
+    │   │       └── inspirations/               # Layout research
+    │   │           └── {target}-layout-ideas.txt
+    │   ├── style-extraction/       # Final design systems
     │   │   ├── style-1/            # design-tokens.json, style-guide.md
     │   │   └── style-N/
+    │   ├── layout-extraction/      # Layout templates
+    │   │   └── layout-templates.json
     │   ├── prototypes/             # Generated HTML/CSS prototypes
-    │   │   ├── _templates/         # Target-specific layout plans and templates
-    │   │   │   ├── {target}-layout-{n}.json  # Layout plan (target-specific)
-    │   │   │   ├── {target}-layout-{n}.html  # HTML template
-    │   │   │   └── {target}-layout-{n}.css   # CSS template
     │   │   ├── {target}-style-{s}-layout-{l}.html  # Final prototypes
     │   │   ├── compare.html        # Interactive matrix view
     │   │   └── index.html          # Navigation page
@@ -730,7 +740,8 @@ All workflows use the same file structure definition regardless of complexity. *
 - **Dynamic Files**: Subtask JSON files created during task decomposition
 - **Scratchpad Usage**: `.scratchpad/` created when CLI commands run without active session
 - **Design Usage**: `design-{timestamp}/` created by UI design workflows, `.design/` for standalone design runs
-- **Layout Planning**: `prototypes/_templates/` contains target-specific layout plans (JSON) generated during UI generation phase
+- **Intermediate Files**: `.intermediates/` contains analysis data (style/layout) separate from final deliverables
+- **Layout Templates**: `layout-extraction/layout-templates.json` contains structural templates for UI assembly
 
 #### Scratchpad Directory (.scratchpad/)
 **Purpose**: Centralized location for non-session-specific CLI outputs