catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-02-05 01:50:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

refactor: optimize workflow templates and prompt structures

Browse Source 
- 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>
This commit is contained in:
catlog22
2025-10-16 13:48:35 +08:00
parent e95be40c2b
commit 39a35c24b1
26 changed files with 693 additions and 1402 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.claude/workflows/cli-templates/prompts/analysis/architecture.txt
View File

@@ -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.

22
.claude/workflows/cli-templates/prompts/analysis/pattern.txt
View File

@@ -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.

23
.claude/workflows/cli-templates/prompts/analysis/performance.txt
View File

@@ -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:
- Performance bottleneck identification with specific locations
## OUTPUT REQUIREMENTS
- 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.

23
.claude/workflows/cli-templates/prompts/analysis/quality.txt
View File

@@ -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.

23
.claude/workflows/cli-templates/prompts/analysis/security.txt
View File

@@ -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.

40
.claude/workflows/cli-templates/prompts/development/component.txt
View File

@@ -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:
- Provide complete component implementation
- Include comprehensive TypeScript types
- Show usage examples and integration patterns
- Document component API and best practices
## OUTPUT REQUIREMENTS
- Complete component implementation with TypeScript types
- Usage examples and integration patterns
- Component API documentation 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.

40
.claude/workflows/cli-templates/prompts/development/debugging.txt
View File

@@ -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:
- Provide detailed root cause analysis
- Show exact code changes made to resolve the issue
- Include new tests added to prevent regression
- Document debugging process and lessons learned
## OUTPUT REQUIREMENTS
- Detailed root cause analysis with file:line references
- Exact code changes made to resolve the issue
- New tests added to prevent regression
- 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.

38
.claude/workflows/cli-templates/prompts/development/feature.txt
View File

@@ -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:
- Provide file:line references for all changes
- Include code examples demonstrating key patterns
- Explain architectural decisions made
- Document any new dependencies or configurations
## OUTPUT REQUIREMENTS
- File:line references for all changes
- Code examples demonstrating key patterns
- Explanation of architectural decisions made
- 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.

40
.claude/workflows/cli-templates/prompts/development/refactor.txt
View File

@@ -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:
- Provide before/after code comparisons
- Document performance improvements achieved
- Include migration instructions for breaking changes
- Show updated test coverage and quality metrics
## OUTPUT REQUIREMENTS
- Before/after code comparisons with file:line references
- Performance improvements documented with benchmarks
- Migration instructions for breaking changes
- 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.

42
.claude/workflows/cli-templates/prompts/development/testing.txt
View File

@@ -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:
- Provide comprehensive test suite with high coverage
- Include performance benchmarks where relevant
- Document testing strategy and conventions used
- Show test coverage metrics and quality improvements
## OUTPUT REQUIREMENTS
- Comprehensive test suite with high coverage
- Performance benchmarks where relevant
- Testing strategy and conventions documentation
- 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.

342
.claude/workflows/cli-templates/prompts/documentation/api.txt
View File

@@ -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.
### 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]
...(content truncated)...

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

@@ -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.
### 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]
Focus: Creating a clear and concise navigation hub for parent directories.

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

@@ -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
**Why**: Explain why this module exists and what problems it solves
**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.
- **What**: Clearly state what this module is responsible for.
- **Why**: Explain the problem it solves.
- **Boundaries**: Define what is in and out of scope.
### 2. Core Concepts
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"]
- Explain key concepts, patterns, or abstractions.
### 3. Usage Scenarios
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
```
- Provide 2-4 common use cases with code examples.
### 4. Dependencies
#### 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]
- List internal and external dependencies with explanations.
### 5. Configuration
#### 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
};
```
- Document environment variables and configuration options.
### 6. Testing
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]
- Explain how to run tests for the module.
### 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]
**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]
Focus: Explaining the module's purpose and usage, not just its API.

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

@@ -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
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]
- Architectural Style, Core Principles, and Technology Stack.
### 2. System Structure
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) │
└─────────────────────────────────────┘
```
- Visual representation of the system's layers or components.
### 3. Module Map
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 | - |
- A table listing all modules, their layers, responsibilities, and dependencies.
### 4. Module Interactions
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 ───┤ ↑
└──────────────┘
```
- Describe key data flows and show a dependency graph.
### 5. Design Patterns
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]
- Document key architectural patterns used across the project.
### 6. Aggregated API Overview
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*
- A high-level summary of all public APIs, grouped by category.
### 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**:
1. HTTP request enters through API layer
2. Request validation and authentication (auth module)
3. Business logic processing (domain modules)
4. Data persistence (database module)
5. Response formatting and return
## VERIFICATION CHECKLIST ✓
□ The documentation provides a cohesive, system-level view
□ Module interactions and dependencies are clearly illustrated
□ The rationale behind major design patterns and decisions is explained
□ The document synthesizes, rather than duplicates, module-level details
**Event Flow** (if applicable):
- [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
Focus: Providing a holistic, system-level understanding of the project architecture.

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

@@ -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
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"]
- Overview of the examples and any prerequisites.
### 2. Quick Start Example
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]
- The simplest possible working example to verify setup.
### 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**:
```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
Focus: Helping users accomplish common tasks through complete, practical examples.

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

@@ -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
- **Purpose**: [High-level mission and goals of the project]
- **Target Audience**: [Primary users, developers, stakeholders]
- **Key Features**: [List of major functionalities and capabilities]
## README STRUCTURE
## 2. System Architecture
- **Architectural Style**: [e.g., Monolith, Microservices, Layered, Event-Driven]
- **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]
### 1. Overview
- Purpose, Target Audience, and Key Features.
## 3. Getting Started
- **Prerequisites**: [Required software, tools, versions]
- **Installation**:
```bash
# Installation commands
```
- **Configuration**: [Environment setup, config files]
- **Running the Project**:
```bash
# Startup commands
```
### 2. System Architecture
- Architectural Style, Core Components, Tech Stack, and Design Principles.
## 4. Development Workflow
- **Branching Strategy**: [e.g., GitFlow, trunk-based]
- **Coding Standards**: [Style guide, linting rules]
- **Testing**:
```bash
# Test commands
```
- **Build & Deployment**: [CI/CD pipeline overview]
### 3. Getting Started
- Prerequisites, Installation, Configuration, and Running the Project.
## 5. Project Structure
```
project-root/
├── src/ # [Description]
├── tests/ # [Description]
├── docs/ # [Description]
└── config/ # [Description]
```
### 4. Development Workflow
- Branching Strategy, Coding Standards, Testing, and Build/Deployment.
## 6. Navigation
- [Module Documentation](./modules/)
- [API Reference](./api/)
- [Architecture Details](./architecture/)
- [Contributing Guidelines](./CONTRIBUTING.md)
### 5. Project Structure
- A high-level tree view of the main directories.
---
**Last Updated**: [Auto-generated timestamp]
**Documentation Version**: [Project version]
### 6. Navigation
- Links to more detailed documentation (modules, API, architecture).
## 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.

20
.claude/workflows/cli-templates/prompts/implementation/component.txt
View File

@@ -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.

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

@@ -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
- **For Code Files**: Analyze classes, functions, interfaces, and implementation details
- **Folders/Modules**: Analyze directory structure, sub-modules, and architectural patterns
- **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**:
- Directory organization and file structure
- Sub-module categorization
- Architectural layout
**For Code Files**:
- File organization (imports, exports, structure)
- Core classes and their hierarchy
- Main functions and their grouping
**For Folders**: Directory organization, sub-module categorization, architectural layout
**For Code Files**: File organization (imports, exports), class hierarchy, function grouping
#### 3. Key Components
**For Folders/Modules**:
- Sub-modules and their responsibilities
- Major components and their interactions
- Entry points and public interfaces
**For Folders**: Sub-modules, major components, entry points, public interfaces
**For Code Files**:
- Core classes with brief descriptions
- Key methods/functions with complete signatures and parameter details
- Method name and purpose
- **Parameters**: name, type, description, default values (if any)
- **Return value**: type and description
- **Throws**: exceptions or errors (if applicable)
- Core classes with descriptions and responsibilities
- Key methods with complete signatures:
```
methodName(param1: Type1, param2: Type2): ReturnType
- Purpose: [what it does]
- 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
- What it imports/requires
- Dependency relationships and flow
- **External Dependencies**: Third-party libraries and frameworks
- Critical dependencies and their purposes
- Version constraints if important
**Internal Dependencies**: Other modules/files within project (with purpose)
**External Dependencies**: Third-party libraries and frameworks (with purpose, version constraints if critical)
#### 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:
- 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
## OUTPUT REQUIREMENTS
### 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`
- **Purpose**: [What this method does]
- **Parameters**:
- `param1` (Type1): [Description of param1] [default: value]
- `param2` (Type2): [Description of param2] [optional]
- **Returns**: (ReturnType) [Description of return value]
- **Throws**: [Exception types and conditions]
- **Example**:
```
const result = instance.methodName(value1, value2);
```
### [Component/Class Name 2]
...
#### `methodName(param1: Type1, param2?: Type2): ReturnType`
- Purpose: [what this method does]
- Parameters:
• param1 (Type1): [description]
• param2 (Type2): [description] [optional] [default: value]
- Returns: (ReturnType) [description]
- Throws: [exceptions if applicable]
## 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]
- Security: [Any security considerations]
- Limitations: [Known limitations]
- Performance: [notes]
- Security: [notes]
- Limitations: [notes]
```
### Content Restrictions (STRICTLY AVOID):
- Don't duplicate content from other CLAUDE.md files - reference them instead
- Avoid overly detailed code explanations (code should be self-documenting)
- Don't include complete code listings (use signatures and descriptions)
- Avoid version-specific implementation details unless critical
- Don't document every single function - focus on key components
- **BUT DO document**: All public/exported APIs with complete parameter details
- **Internal/private methods**: Only document if they are complex or critical to understanding
### Documentation Style
- **Concise but complete** - Focus on "what" and "why", not detailed "how"
- **Code signatures** for key APIs - Include all parameter details
- **Parameters**: Name, type, description, optional/default indicators, constraints
- **Return values**: Type, description, special conditions (null, undefined, empty)
- **Evidence-based** - Reference related documentation when appropriate
- **Examples** for complex methods - Show usage patterns
### Special Instructions:
- If analyzing a folder with existing CLAUDE.md files in subdirectories, reference them rather than duplicating their content
- For code files, prioritize exported/public APIs over internal implementation details
- **For method documentation**:
- MUST document all parameters for public/exported methods
- Include parameter types, descriptions, and constraints
- 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
### Content Restrictions (STRICTLY AVOID)
- ❌ Duplicating content from other CLAUDE.md files (reference instead)
- ❌ Overly detailed code explanations (code should be self-documenting)
- ❌ Complete code listings (use signatures and descriptions)
- ❌ Version-specific details unless critical
- ❌ Documenting every single function (focus on public/exported APIs)
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.

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

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

26
.claude/workflows/cli-templates/prompts/planning/migration.txt
View File

@@ -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
- Risk analysis and rollback procedures
- Compatibility assessment with file:line references
- 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.

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

@@ -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
- Risk assessment and mitigation plans
- Effort estimation with confidence levels
- 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.

20
.claude/workflows/cli-templates/prompts/review/code-review.txt
View File

@@ -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.

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

@@ -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:
1. **Implementation Complexity Assessment**
- Evaluate code complexity and technical difficulty
- Assess required technical skills and expertise levels
- Validate implementation approach feasibility
- Identify technical challenges and solutions
## CORE CHECKLIST ⚡
□ Evaluate implementation complexity and required skills
□ Validate all technical dependencies and prerequisites
□ Assess the proposed code structure and integration patterns
□ Verify the completeness of the testing strategy
2. **Technical Dependencies Validation**
- Review external library and framework dependencies
- Assess version compatibility and dependency conflicts
- Evaluate build system and deployment requirements
- Identify missing technical prerequisites
## REQUIRED TECHNICAL ANALYSIS
1. **Implementation Complexity**: Evaluate code difficulty and required skills.
2. **Technical Dependencies**: Review libraries, versions, and build systems.
3. **Code Structure**: Assess file organization, naming, and modularity.
4. **Testing Completeness**: Evaluate test coverage, types, and gaps.
5. **Execution Readiness**: Validate control flow, context, and file targets.
3. **Code Structure Assessment**
- Evaluate proposed file organization and structure
- Assess naming conventions and code organization
- Validate integration with existing codebase patterns
- Review modularity and separation of concerns
## OUTPUT REQUIREMENTS
- **Technical Assessment Report**: Grades for implementation, complexity, and quality.
- **Detailed Technical Findings**: Blocking issues, performance concerns, and improvements.
- **Implementation Recommendations**: Prerequisites, best practices, and refactoring.
- **Risk Mitigation**: Technical, dependency, integration, and quality risks.
4. **Testing Completeness Evaluation**
- Assess test coverage and testing strategy completeness
- Evaluate test types and testing approach adequacy
- Review integration testing and end-to-end coverage
- Identify testing gaps and quality assurance needs
## VERIFICATION CHECKLIST ✓
□ Implementation complexity and feasibility have been thoroughly evaluated
□ All technical dependencies and prerequisites are validated
□ The proposed code structure aligns with project standards
□ The testing plan is complete and adequate for the proposed changes
5. **Execution Readiness Verification**
- 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.
Focus: Technical execution details, code quality concerns, and implementation feasibility.

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

@@ -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:
1. **Consensus Identification**
- Identify areas where both analyses agree on issues or strengths
- Document shared concerns and aligned recommendations
- Highlight consistent risk assessments and mitigation strategies
- Establish priority consensus for implementation focus
## CORE CHECKLIST ⚡
□ Identify both consensus and conflict between the two analyses
□ Synthesize a unified risk profile and recommendation set
□ Resolve conflicting suggestions with a balanced approach
□ Frame final decisions as clear choices for the user
2. **Conflict Resolution Analysis**
- Identify discrepancies between strategic and technical perspectives
- Analyze root causes of conflicting assessments
- Evaluate trade-offs between strategic goals and technical constraints
- Provide balanced recommendations for resolution
## REQUIRED CROSS-VALIDATION ANALYSIS
1. **Consensus Identification**: Find where both analyses agree.
2. **Conflict Resolution**: Analyze and resolve discrepancies.
3. **Risk Level Synthesis**: Combine risk assessments into a single profile.
4. **Recommendation Integration**: Synthesize recommendations into a unified plan.
5. **Quality Assurance Framework**: Establish combined quality metrics.
3. **Risk Level Synthesis**
- Combine strategic and technical risk assessments
- Establish overall implementation risk profile
- Prioritize risks by impact and probability
- Recommend risk mitigation strategies
## OUTPUT REQUIREMENTS
- **Cross-Validation Summary**: Overall grade, confidence score, and risk profile.
- **Synthesis Report**: Consensus areas, conflict areas, and integrated recommendations.
- **User Approval Framework**: A clear breakdown of changes for user approval.
- **Modification Categories**: Classify changes by type (e.g., Task Structure, Technical).
4. **Recommendation Integration**
- Synthesize strategic and technical recommendations
- Resolve conflicting suggestions with balanced approach
- Prioritize recommendations by impact and effort
- Establish implementation sequence and dependencies
## VERIFICATION CHECKLIST ✓
□ Both consensus and conflict between analyses are identified and documented
□ Risks and recommendations are synthesized into a single, coherent plan
□ Conflicting points are resolved with balanced, well-reasoned proposals
□ Final output is structured to facilitate clear user decisions
5. **Quality Assurance Framework**
- 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.
Focus: A balanced integration of strategic and technical perspectives to produce a single, actionable plan.

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

@@ -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:
1. **Architectural Soundness Assessment**
- Evaluate overall system design coherence
- Assess component interaction patterns
- Validate architectural decision consistency
- Identify potential design conflicts or gaps
## CORE CHECKLIST ⚡
□ Evaluate the plan against high-level system architecture
□ Assess the logic of the task breakdown and dependencies
□ Verify alignment with stated business objectives and success criteria
□ Identify strategic risks, not just low-level technical ones
2. **Task Decomposition Logic Evaluation**
- Review task breakdown methodology and rationale
- Assess functional completeness of each task
- Evaluate task granularity and scope appropriateness
- Identify missing or redundant decomposition elements
## REQUIRED STRATEGIC ANALYSIS
1. **Architectural Soundness**: Assess design coherence and pattern consistency.
2. **Task Decomposition Logic**: Review task breakdown, granularity, and completeness.
3. **Dependency Coherence**: Analyze task interdependencies and logical flow.
4. **Business Alignment**: Validate against business objectives and requirements.
5. **Strategic Risk Identification**: Identify architectural, resource, and timeline risks.
3. **Dependency Coherence Analysis**
- Map task interdependencies and logical flow
- Validate dependency ordering and scheduling
- Assess circular dependency risks
- Evaluate parallel execution opportunities
## OUTPUT REQUIREMENTS
- **Strategic Assessment Report**: Grades for architecture, decomposition, and business alignment.
- **Detailed Recommendations**: Critical issues, improvements, and alternative approaches.
- **Action Items**: A prioritized list of changes (Immediate, Short-term, Long-term).
4. **Business Alignment Verification**
- Validate alignment with stated business objectives
- Assess stakeholder requirement coverage
- Evaluate success criteria completeness and measurability
- Identify business risk and mitigation adequacy
## VERIFICATION CHECKLIST ✓
□ The plan's architectural soundness has been thoroughly assessed
□ Task decomposition and dependencies are logical and coherent
□ The plan is confirmed to be in alignment with business goals
□ Strategic risks are identified with clear recommendations
5. **Strategic Risk Identification**
- 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.
Focus: High-level strategic concerns, business alignment, and long-term architectural implications.

37
.claude/workflows/workflow-architecture.md
View File

@@ -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
│ ├── style-consolidation/ # Design system tokens (per-style)
│ ├── .intermediates/ # Intermediate analysis files
│ │ ├── 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
│ ├── style-consolidation/ # Design system tokens (per-style)
│ ├── .intermediates/ # Intermediate analysis files
│ │ ├── 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