mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-05 01:50:27 +08:00
Add comprehensive analysis and development templates for CLAUDE workflows
- Introduced new analysis templates for architecture, implementation patterns, performance, quality, and security. - Created detailed development templates for component creation, debugging, feature implementation, refactoring, testing, and migration planning. - Established structured documentation guidelines for root, domain, module, and sub-module levels to enhance clarity and organization. - Implemented a hierarchy analysis template to optimize project structure and documentation depth. - Updated codex-unified documentation to reflect new command structures, template usage, and best practices for autonomous development workflows.
This commit is contained in:
@@ -112,7 +112,7 @@ This section details how the system programmatically interacts with the Gemini C
|
|||||||
- **Central Guidelines**: All CLI usage patterns, syntax, and context detection rules are defined in the central guidelines document:
|
- **Central Guidelines**: All CLI usage patterns, syntax, and context detection rules are defined in the central guidelines document:
|
||||||
- **Template Selection**: For specific analysis types, the system references the template selection guide:
|
- **Template Selection**: For specific analysis types, the system references the template selection guide:
|
||||||
- **All Templates**: `gemini-template-rules.md` - provides guidance on selecting appropriate templates
|
- **All Templates**: `gemini-template-rules.md` - provides guidance on selecting appropriate templates
|
||||||
- **Template Library**: `gemini-templates/` - contains actual prompt and command templates
|
- **Template Library**: `cli-templates/` - contains actual prompt and command templates
|
||||||
|
|
||||||
### 📝 **Enhancement Examples**
|
### 📝 **Enhancement Examples**
|
||||||
|
|
||||||
|
|||||||
@@ -52,10 +52,10 @@ Quick analysis tool for codebase insights using intelligent pattern detection an
|
|||||||
## Templates Used
|
## Templates Used
|
||||||
|
|
||||||
Templates are automatically selected based on analysis type:
|
Templates are automatically selected based on analysis type:
|
||||||
- **Pattern Analysis**: `~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt`
|
- **Pattern Analysis**: `~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt`
|
||||||
- **Architecture Analysis**: `~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt`
|
- **Architecture Analysis**: `~/.claude/workflows/cli-templates/prompts/analysis/architecture.txt`
|
||||||
- **Security Analysis**: `~/.claude/workflows/gemini-templates/prompts/analysis/security.txt`
|
- **Security Analysis**: `~/.claude/workflows/cli-templates/prompts/analysis/security.txt`
|
||||||
- **Performance Analysis**: `~/.claude/workflows/gemini-templates/prompts/analysis/performance.txt`
|
- **Performance Analysis**: `~/.claude/workflows/cli-templates/prompts/analysis/performance.txt`
|
||||||
|
|
||||||
## Workflow Integration
|
## Workflow Integration
|
||||||
|
|
||||||
|
|||||||
@@ -40,22 +40,22 @@ update_module_claude() {
|
|||||||
if [ "$module_path" = "." ]; then
|
if [ "$module_path" = "." ]; then
|
||||||
# Root directory
|
# Root directory
|
||||||
layer="Layer 1 (Root)"
|
layer="Layer 1 (Root)"
|
||||||
template_path="~/.claude/workflows/gemini-templates/prompts/dms/claude-layer1-root.txt"
|
template_path="~/.claude/workflows/cli-templates/prompts/dms/claude-layer1-root.txt"
|
||||||
analysis_strategy="--all-files"
|
analysis_strategy="--all-files"
|
||||||
elif [[ "$clean_path" =~ ^[^/]+$ ]]; then
|
elif [[ "$clean_path" =~ ^[^/]+$ ]]; then
|
||||||
# Top-level directories (e.g., .claude, src, tests)
|
# Top-level directories (e.g., .claude, src, tests)
|
||||||
layer="Layer 2 (Domain)"
|
layer="Layer 2 (Domain)"
|
||||||
template_path="~/.claude/workflows/gemini-templates/prompts/dms/claude-layer2-domain.txt"
|
template_path="~/.claude/workflows/cli-templates/prompts/dms/claude-layer2-domain.txt"
|
||||||
analysis_strategy="@{*/CLAUDE.md}"
|
analysis_strategy="@{*/CLAUDE.md}"
|
||||||
elif [[ "$clean_path" =~ ^[^/]+/[^/]+$ ]]; then
|
elif [[ "$clean_path" =~ ^[^/]+/[^/]+$ ]]; then
|
||||||
# Second-level directories (e.g., .claude/scripts, src/components)
|
# Second-level directories (e.g., .claude/scripts, src/components)
|
||||||
layer="Layer 3 (Module)"
|
layer="Layer 3 (Module)"
|
||||||
template_path="~/.claude/workflows/gemini-templates/prompts/dms/claude-layer3-module.txt"
|
template_path="~/.claude/workflows/cli-templates/prompts/dms/claude-layer3-module.txt"
|
||||||
analysis_strategy="@{*/CLAUDE.md}"
|
analysis_strategy="@{*/CLAUDE.md}"
|
||||||
else
|
else
|
||||||
# Deeper directories (e.g., .claude/workflows/gemini-templates/prompts)
|
# Deeper directories (e.g., .claude/workflows/cli-templates/prompts)
|
||||||
layer="Layer 4 (Sub-Module)"
|
layer="Layer 4 (Sub-Module)"
|
||||||
template_path="~/.claude/workflows/gemini-templates/prompts/dms/claude-layer4-submodule.txt"
|
template_path="~/.claude/workflows/cli-templates/prompts/dms/claude-layer4-submodule.txt"
|
||||||
analysis_strategy="--all-files"
|
analysis_strategy="--all-files"
|
||||||
fi
|
fi
|
||||||
|
|
||||||
|
|||||||
@@ -108,14 +108,14 @@ Output: Data layer context with implementation patterns"
|
|||||||
### 使用提示词模板
|
### 使用提示词模板
|
||||||
```bash
|
```bash
|
||||||
# 基础模板引入
|
# 基础模板引入
|
||||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)"
|
||||||
|
|
||||||
# 组合多个模板
|
# 组合多个模板
|
||||||
gemini -p "@{src/**/*} $(cat <<'EOF'
|
gemini -p "@{src/**/*} $(cat <<'EOF'
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/architecture.txt)
|
||||||
|
|
||||||
Additional focus:
|
Additional focus:
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/quality.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/quality.txt)
|
||||||
EOF
|
EOF
|
||||||
)"
|
)"
|
||||||
```
|
```
|
||||||
@@ -124,11 +124,11 @@ EOF
|
|||||||
```bash
|
```bash
|
||||||
# 基于项目特征动态选择模板
|
# 基于项目特征动态选择模板
|
||||||
if [ -f "package.json" ] && grep -q "react" package.json; then
|
if [ -f "package.json" ] && grep -q "react" package.json; then
|
||||||
TEMPLATE="~/.claude/workflows/gemini-templates/prompts/tech/react-component.txt"
|
TEMPLATE="~/.claude/workflows/cli-templates/prompts/tech/react-component.txt"
|
||||||
elif [ -f "requirements.txt" ]; then
|
elif [ -f "requirements.txt" ]; then
|
||||||
TEMPLATE="~/.claude/workflows/gemini-templates/prompts/tech/python-api.txt"
|
TEMPLATE="~/.claude/workflows/cli-templates/prompts/tech/python-api.txt"
|
||||||
else
|
else
|
||||||
TEMPLATE="~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt"
|
TEMPLATE="~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt"
|
||||||
fi
|
fi
|
||||||
|
|
||||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat $TEMPLATE)"
|
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat $TEMPLATE)"
|
||||||
@@ -0,0 +1,37 @@
|
|||||||
|
You are tasked with creating a reusable component in this codebase. Follow these guidelines:
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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
|
||||||
@@ -0,0 +1,37 @@
|
|||||||
|
You are tasked with debugging and resolving issues in this codebase. Follow these systematic guidelines:
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
You are tasked with implementing a new feature in this codebase. Follow these guidelines:
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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
|
||||||
@@ -0,0 +1,37 @@
|
|||||||
|
You are tasked with refactoring existing code to improve quality, performance, or maintainability. Follow these guidelines:
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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
|
||||||
@@ -0,0 +1,43 @@
|
|||||||
|
You are tasked with creating comprehensive tests for this codebase. Follow these guidelines:
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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:
|
||||||
|
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
|
||||||
247
.claude/workflows/codex-unified.md
Normal file
247
.claude/workflows/codex-unified.md
Normal file
@@ -0,0 +1,247 @@
|
|||||||
|
---
|
||||||
|
name: codex-unified
|
||||||
|
description: Comprehensive Codex CLI guidelines - core rules, syntax, patterns, templates, and best practices with automation focus
|
||||||
|
type: technical-guideline
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🚀 Command Overview: `codex`
|
||||||
|
|
||||||
|
- **Purpose**: An AI-powered CLI tool for automated codebase analysis, intelligent code generation, and autonomous development workflows.
|
||||||
|
- **Key Characteristic**: **No `--all-files` flag** - requires explicit `@` pattern references for file inclusion.
|
||||||
|
- **Default Mode**: `--full-auto` automation mode for autonomous task execution.
|
||||||
|
- **Primary Triggers**:
|
||||||
|
- When user needs automated code generation or refactoring.
|
||||||
|
- When task requires intelligent analysis with autonomous execution.
|
||||||
|
- When building complex features or applications from scratch.
|
||||||
|
- **Core Use Cases**:
|
||||||
|
- Automated application development.
|
||||||
|
- Intelligent code refactoring and optimization.
|
||||||
|
- Context-aware feature implementation.
|
||||||
|
- Autonomous debugging and problem-solving.
|
||||||
|
|
||||||
|
### ⚙️ Command Syntax & Arguments
|
||||||
|
|
||||||
|
- **Basic Structure**:
|
||||||
|
```bash
|
||||||
|
codex exec "prompt with @{patterns}"
|
||||||
|
codex --full-auto "automated development task"
|
||||||
|
```
|
||||||
|
- **Key Commands**:
|
||||||
|
- `codex exec "..."` ≡ `gemini -p "..."` (non-interactive automation mode)
|
||||||
|
- `codex --full-auto "..."` (default autonomous development mode)
|
||||||
|
- `codex --cd /path "..."` (specify working directory)
|
||||||
|
|
||||||
|
- **Template Usage**:
|
||||||
|
```bash
|
||||||
|
# Direct execution (most common)
|
||||||
|
codex exec "@{src/**/*} @{CLAUDE.md} Refactor authentication system"
|
||||||
|
|
||||||
|
# With template injection
|
||||||
|
codex exec "@{src/**/*} @{CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/development/feature.txt)"
|
||||||
|
|
||||||
|
# Multi-template composition
|
||||||
|
codex exec "@{src/**/*} @{CLAUDE.md} $(cat <<'EOF'
|
||||||
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/architecture.txt)
|
||||||
|
|
||||||
|
Development Focus:
|
||||||
|
$(cat ~/.claude/workflows/cli-templates/prompts/development/component.txt)
|
||||||
|
EOF
|
||||||
|
)"
|
||||||
|
```
|
||||||
|
|
||||||
|
### 📂 File Pattern Rules - **CRITICAL FOR CODEX**
|
||||||
|
|
||||||
|
⚠️ **UNLIKE GEMINI**: Codex has **NO `--all-files` flag** - you MUST use `@` patterns to reference files.
|
||||||
|
|
||||||
|
- **Syntax**:
|
||||||
|
- `@{pattern}`: Single file or directory pattern.
|
||||||
|
- `@{pattern1,pattern2}`: Multiple patterns, comma-separated.
|
||||||
|
- **Essential Patterns**:
|
||||||
|
```bash
|
||||||
|
@{**/*} # All files recursively (equivalent to --all-files)
|
||||||
|
@{src/**/*} # All source files
|
||||||
|
@{*.ts,*.js} # Specific file types
|
||||||
|
@{CLAUDE.md,**/*CLAUDE.md} # Documentation hierarchy
|
||||||
|
@{package.json,*.config.*} # Configuration files
|
||||||
|
```
|
||||||
|
- **Cross-Platform Rules**:
|
||||||
|
- Always use forward slashes (`/`) for paths.
|
||||||
|
- Enclose paths with spaces in quotes: `@{"My Project/src/**/*"}`.
|
||||||
|
- Escape special characters like brackets: `@{src/**/*\[bracket\]*}`.
|
||||||
|
|
||||||
|
### 📁 Shared Template Directory Structure
|
||||||
|
|
||||||
|
Templates are shared between gemini and codex. This structure must be located at `~/.claude/workflows/cli-templates/`.
|
||||||
|
|
||||||
|
```
|
||||||
|
~/.claude/workflows/cli-templates/
|
||||||
|
├── prompts/
|
||||||
|
│ ├── development/ # Automated development templates
|
||||||
|
│ │ ├── feature.txt # 🔧 Feature implementation & integration
|
||||||
|
│ │ ├── component.txt # 🧩 Component design & development
|
||||||
|
│ │ ├── refactor.txt # 🔄 Code refactoring & optimization
|
||||||
|
│ │ ├── testing.txt # 🧪 Test generation & validation
|
||||||
|
│ │ └── debugging.txt # 🐛 Bug analysis & resolution
|
||||||
|
│ ├── automation/ # Autonomous workflow templates
|
||||||
|
│ │ ├── scaffold.txt # 🏗️ Project scaffolding & setup
|
||||||
|
│ │ ├── migration.txt # 🚀 Automated migration & upgrades
|
||||||
|
│ │ └── deployment.txt # 🚢 CI/CD & deployment automation
|
||||||
|
│ ├── analysis/ # Inherited from gemini templates
|
||||||
|
│ │ ├── pattern.txt # ✨ Implementation patterns & conventions
|
||||||
|
│ │ ├── architecture.txt # 🏗️ System architecture & dependencies
|
||||||
|
│ │ ├── security.txt # 🔒 Security vulnerabilities & protection
|
||||||
|
│ │ ├── performance.txt # ⚡ Performance bottlenecks & optimization
|
||||||
|
│ │ └── quality.txt # 📊 Code quality & maintainability
|
||||||
|
│ └── integration/ # Cross-system templates
|
||||||
|
│ ├── api-design.txt # 🌐 API design & implementation
|
||||||
|
│ └── database.txt # 🗄️ Database schema & operations
|
||||||
|
└── commands/ # Command examples and patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### 🧭 Template Selection Guide
|
||||||
|
|
||||||
|
| Task Type | Primary Template | Purpose | Codex Advantage |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Build New Feature | `feature.txt` | End-to-end feature development | Autonomous implementation |
|
||||||
|
| Create Component | `component.txt` | Reusable component development | Pattern-aware generation |
|
||||||
|
| Refactor Code | `refactor.txt` | Code improvement & optimization | Context-aware refactoring |
|
||||||
|
| Generate Tests | `testing.txt` | Comprehensive test coverage | Intelligent test generation |
|
||||||
|
| Debug Issues | `debugging.txt` | Problem analysis & resolution | Root cause identification |
|
||||||
|
| Scaffold Project | `scaffold.txt` | Project structure creation | Best practice templates |
|
||||||
|
| Migrate Systems | `migration.txt` | Technology upgrades | Automated migration paths |
|
||||||
|
| API Development | `api-design.txt` | API design & implementation | RESTful pattern adherence |
|
||||||
|
|
||||||
|
### 📦 Standard Command Structures
|
||||||
|
|
||||||
|
- **Basic Development Task**
|
||||||
|
```bash
|
||||||
|
codex exec "@{src/**/*,*.json,CLAUDE.md} Implement user authentication with JWT"
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Template-Enhanced Development**
|
||||||
|
```bash
|
||||||
|
codex exec "@{src/**/*,CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/development/feature.txt)
|
||||||
|
|
||||||
|
## Task: User Authentication System
|
||||||
|
- JWT token management
|
||||||
|
- Role-based access control
|
||||||
|
- Password reset functionality"
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Full Auto Mode (Default)**
|
||||||
|
```bash
|
||||||
|
codex --full-auto "@{**/*} Create a complete todo application with React and TypeScript"
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Debugging & Analysis**
|
||||||
|
```bash
|
||||||
|
codex exec "@{src/**/*,package.json,CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/development/debugging.txt)
|
||||||
|
|
||||||
|
## Issue: Performance degradation in user dashboard
|
||||||
|
- Identify bottlenecks
|
||||||
|
- Propose optimizations
|
||||||
|
- Implement solutions"
|
||||||
|
```
|
||||||
|
|
||||||
|
### ⭐ Best Practices & Rules
|
||||||
|
|
||||||
|
#### 🎯 Codex-Specific Guidelines
|
||||||
|
|
||||||
|
**Always Use @ Patterns:**
|
||||||
|
- **MANDATORY**: Codex requires explicit file references via `@` patterns
|
||||||
|
- **No automatic inclusion**: Unlike gemini's `--all-files`, you must specify what to analyze
|
||||||
|
- **Be comprehensive**: Use `@{**/*}` for full codebase context when needed
|
||||||
|
- **Be selective**: Use specific patterns like `@{src/**/*.ts}` for targeted analysis
|
||||||
|
|
||||||
|
**Default Automation Mode:**
|
||||||
|
- **`--full-auto` is preferred**: Maximizes autonomous capabilities
|
||||||
|
- **`codex exec` for specific tasks**: Use when you need precise control
|
||||||
|
- **Let codex decide**: Trust the AI's architectural decisions in auto mode
|
||||||
|
|
||||||
|
#### 📋 CLAUDE.md Loading Rules
|
||||||
|
|
||||||
|
**Critical Difference from Gemini:**
|
||||||
|
- **Always explicit**: Must use `@{CLAUDE.md}` or `@{**/*CLAUDE.md}`
|
||||||
|
- **No automatic loading**: Codex will not include documentation without explicit reference
|
||||||
|
- **Hierarchical loading**: Use `@{CLAUDE.md,**/*CLAUDE.md}` for complete context
|
||||||
|
|
||||||
|
#### ⚠️ Error Prevention
|
||||||
|
|
||||||
|
- **Always include @ patterns**: Commands without file references will fail
|
||||||
|
- **Test patterns first**: Validate @ patterns match existing files
|
||||||
|
- **Use comprehensive patterns**: `@{**/*}` when unsure of file structure
|
||||||
|
- **Include documentation**: Always add `@{CLAUDE.md,**/*CLAUDE.md}` for context
|
||||||
|
- **Quote complex paths**: Use proper shell quoting for paths with spaces
|
||||||
|
|
||||||
|
#### 🔄 Template Reuse
|
||||||
|
|
||||||
|
**Compatibility with Gemini Templates:**
|
||||||
|
- **`cat` command works identically**: Reuse gemini templates seamlessly
|
||||||
|
- **Cross-reference patterns**: Combine analysis and development templates
|
||||||
|
- **Template composition**: Build complex prompts from multiple template sources
|
||||||
|
|
||||||
|
#### 🚀 Automation Workflow
|
||||||
|
|
||||||
|
**Autonomous Development Pattern:**
|
||||||
|
1. **Context Gathering**: `@{**/*,CLAUDE.md}` for full project understanding
|
||||||
|
2. **Pattern Analysis**: Understand existing code conventions
|
||||||
|
3. **Automated Implementation**: Let codex handle the development workflow
|
||||||
|
4. **Quality Assurance**: Built-in testing and validation
|
||||||
|
|
||||||
|
### 📊 Codex vs Gemini Quick Reference
|
||||||
|
|
||||||
|
| Feature | Codex | Gemini |
|
||||||
|
|---------|--------|---------|
|
||||||
|
| File Loading | `@` patterns **required** | `--all-files` available |
|
||||||
|
| Default Mode | `--full-auto` automation | Interactive analysis |
|
||||||
|
| Primary Use | Development & implementation | Analysis & planning |
|
||||||
|
| Template Support | Full compatibility via `cat` | Native template system |
|
||||||
|
| Automation Level | Autonomous execution | Manual implementation |
|
||||||
|
| Working Directory | `--cd` flag support | Current directory |
|
||||||
|
|
||||||
|
### 🎯 Integration with Development Workflow
|
||||||
|
|
||||||
|
**Pre-Development Analysis:**
|
||||||
|
```bash
|
||||||
|
# Understand existing patterns before implementing
|
||||||
|
codex exec "@{src/**/*,CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Feature Development:**
|
||||||
|
```bash
|
||||||
|
# Implement new feature with full context
|
||||||
|
codex exec "@{**/*,CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/development/feature.txt)
|
||||||
|
|
||||||
|
## Feature: Advanced Search Functionality
|
||||||
|
- Full-text search capabilities
|
||||||
|
- Filter and sort options
|
||||||
|
- Performance optimization"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Quality Assurance:**
|
||||||
|
```bash
|
||||||
|
# Comprehensive testing and validation
|
||||||
|
codex exec "@{src/**/*,test/**/*,CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/development/testing.txt)"
|
||||||
|
```
|
||||||
|
|
||||||
|
### 🎨 Advanced Usage Patterns
|
||||||
|
|
||||||
|
**Multi-Phase Development:**
|
||||||
|
```bash
|
||||||
|
# Phase 1: Analysis
|
||||||
|
codex exec "@{**/*,CLAUDE.md} Analyze current architecture for payment system integration"
|
||||||
|
|
||||||
|
# Phase 2: Implementation
|
||||||
|
codex --full-auto "@{**/*,CLAUDE.md} Implement Stripe payment integration with the analyzed architecture"
|
||||||
|
|
||||||
|
# Phase 3: Testing
|
||||||
|
codex exec "@{**/*,CLAUDE.md} Generate comprehensive tests for the payment system"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Cross-Project Learning:**
|
||||||
|
```bash
|
||||||
|
# Learn from similar implementations
|
||||||
|
codex exec "@{../other-project/src/**/*,src/**/*,CLAUDE.md} Implement feature X using patterns from other-project"
|
||||||
|
```
|
||||||
|
|
||||||
|
Remember: **Codex excels at autonomous development** - trust its intelligence while providing comprehensive context through proper `@` pattern usage.
|
||||||
@@ -1,34 +0,0 @@
|
|||||||
# Module: Analysis Prompts
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
This module provides a collection of standardized prompt templates for conducting detailed analysis of software projects. Each template is designed to guide the language model in focusing on a specific area of concern, ensuring comprehensive and structured feedback.
|
|
||||||
|
|
||||||
## Component Documentation
|
|
||||||
|
|
||||||
The `analysis` module contains the following prompt templates:
|
|
||||||
|
|
||||||
- **`architecture.txt`**: Guides the analysis of high-level system architecture, design patterns, module dependencies, and scalability.
|
|
||||||
- **`pattern.txt`**: Focuses on identifying and evaluating implementation patterns, code structure, and adherence to conventions.
|
|
||||||
- **`performance.txt`**: Directs the analysis towards performance bottlenecks, algorithm efficiency, and optimization opportunities.
|
|
||||||
- **`quality.txt`**: Used for assessing code quality, maintainability, error handling, and test coverage.
|
|
||||||
- **`security.txt`**: Concentrates on identifying security vulnerabilities, including issues with authentication, authorization, input validation, and data encryption.
|
|
||||||
|
|
||||||
## Usage Patterns
|
|
||||||
|
|
||||||
To use a template, its content should be prepended to a user's request for analysis. This primes the model with specific instructions and output requirements for the desired analysis type.
|
|
||||||
|
|
||||||
### Example: Requesting a Security Analysis
|
|
||||||
|
|
||||||
```
|
|
||||||
[Content of security.txt]
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Analyze the following codebase for security vulnerabilities:
|
|
||||||
[Code or project context]
|
|
||||||
```
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
|
|
||||||
The prompt templates are plain text files and can be customized to adjust the focus or output requirements of the analysis. No special configuration is required to use them.
|
|
||||||
@@ -25,7 +25,7 @@ type: technical-guideline
|
|||||||
- **Key Arguments**:
|
- **Key Arguments**:
|
||||||
- `--all-files`: Includes all files in the current working directory.
|
- `--all-files`: Includes all files in the current working directory.
|
||||||
- `-p`: The prompt string, which must contain file reference patterns and the analysis query.
|
- `-p`: The prompt string, which must contain file reference patterns and the analysis query.
|
||||||
- `{template}`: Template injection using `$(cat ~/.claude/workflows/gemini-templates/prompts/[category]/[template].txt)` for standardized analysis
|
- `{template}`: Template injection using `$(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt)` for standardized analysis
|
||||||
- `@{pattern}`: A special syntax for referencing files and directories.
|
- `@{pattern}`: A special syntax for referencing files and directories.
|
||||||
|
|
||||||
- **Template Usage**:
|
- **Template Usage**:
|
||||||
@@ -34,14 +34,14 @@ type: technical-guideline
|
|||||||
gemini -p "@{src/**/*} @{CLAUDE.md} Analyze code patterns and conventions"
|
gemini -p "@{src/**/*} @{CLAUDE.md} Analyze code patterns and conventions"
|
||||||
|
|
||||||
# With template (recommended)
|
# With template (recommended)
|
||||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)"
|
||||||
|
|
||||||
# Multi-template composition
|
# Multi-template composition
|
||||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat <<'EOF'
|
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat <<'EOF'
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/architecture.txt)
|
||||||
|
|
||||||
Additional Security Focus:
|
Additional Security Focus:
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/security.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/security.txt)
|
||||||
EOF
|
EOF
|
||||||
)"
|
)"
|
||||||
```
|
```
|
||||||
@@ -68,10 +68,10 @@ type: technical-guideline
|
|||||||
|
|
||||||
### TPL (Templates)
|
### TPL (Templates)
|
||||||
|
|
||||||
#### 🗂️ Template Directory Structure
|
#### 🗂️ Shared Template Directory Structure
|
||||||
This structure must be located at `~/.claude/workflows/gemini-templates/`.
|
Templates are shared between gemini and codex. This structure can be located at either `~/.claude/workflows/cli-templates/` (global) or `./.claude/workflows/cli-templates/` (project-specific).
|
||||||
|
|
||||||
~/.claude/workflows/gemini-templates/
|
~/.claude/workflows/cli-templates/
|
||||||
├── prompts/
|
├── prompts/
|
||||||
│ ├── analysis/ # Code analysis templates
|
│ ├── analysis/ # Code analysis templates
|
||||||
│ │ ├── pattern.txt # ✨ Implementation patterns & conventions
|
│ │ ├── pattern.txt # ✨ Implementation patterns & conventions
|
||||||
@@ -127,7 +127,7 @@ These are recommended command templates for common scenarios.
|
|||||||
- **Template-Enhanced (Recommended)**
|
- **Template-Enhanced (Recommended)**
|
||||||
```bash
|
```bash
|
||||||
# Using a predefined template for consistent, high-quality analysis
|
# Using a predefined template for consistent, high-quality analysis
|
||||||
gemini --all-files -p "@{target_patterns} @{CLAUDE.md,**/*CLAUDE.md} $(cat ~/.claude/workflows/gemini-templates/prompts/[category]/[template].txt)
|
gemini --all-files -p "@{target_patterns} @{CLAUDE.md,**/*CLAUDE.md} $(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt)
|
||||||
|
|
||||||
## Analysis:
|
## Analysis:
|
||||||
1. [Point 1]
|
1. [Point 1]
|
||||||
@@ -142,10 +142,10 @@ These are recommended command templates for common scenarios.
|
|||||||
- **Multi-Template Composition**
|
- **Multi-Template Composition**
|
||||||
```bash
|
```bash
|
||||||
gemini -p "@{src/**/*} @{CLAUDE.md}
|
gemini -p "@{src/**/*} @{CLAUDE.md}
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)
|
||||||
|
|
||||||
Additional Security Focus:
|
Additional Security Focus:
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/security.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/security.txt)
|
||||||
|
|
||||||
## Analysis:
|
## Analysis:
|
||||||
1. [Point 1]
|
1. [Point 1]
|
||||||
|
|||||||
@@ -403,7 +403,7 @@ When task creation encounters insufficient implementation details, the system in
|
|||||||
#### Gemini Analysis Command Template
|
#### Gemini Analysis Command Template
|
||||||
```bash
|
```bash
|
||||||
gemini --all-files -p "@{scope-patterns} @{CLAUDE.md}
|
gemini --all-files -p "@{scope-patterns} @{CLAUDE.md}
|
||||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)
|
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)
|
||||||
|
|
||||||
## Task-Specific Analysis:
|
## Task-Specific Analysis:
|
||||||
Task: [task title and description]
|
Task: [task title and description]
|
||||||
|
|||||||
@@ -70,9 +70,10 @@ This document defines project-specific coding standards and development principl
|
|||||||
- Stop after 3 failed attempts and reassess
|
- Stop after 3 failed attempts and reassess
|
||||||
|
|
||||||
|
|
||||||
### Gemini Context Protocol
|
### CLI Tool Context Protocols
|
||||||
For all Gemini CLI usage, command syntax, and integration guidelines:
|
For all CLI tool usage, command syntax, and integration guidelines:
|
||||||
@~/.claude/workflows/gemini-unified.md
|
- **Gemini (Analysis)**: @~/.claude/workflows/gemini-unified.md
|
||||||
|
- **Codex (Development)**: @~/.claude/workflows/codex-unified.md
|
||||||
|
|
||||||
|
|
||||||
#### **Content Uniqueness Rules**
|
#### **Content Uniqueness Rules**
|
||||||
|
|||||||
@@ -0,0 +1,9 @@
|
|||||||
|
codex exec "..." 非交互式“自动化模式” codex exec "explain utils.ts"
|
||||||
|
|
||||||
|
codex --full-auto "create the fanciest todo-list app"
|
||||||
|
|
||||||
|
用于文件搜索@
|
||||||
|
键入会触发对工作区根目录的模糊文件名搜索。使用向上/向下在结果中进行选择,并使用 Tab 键或 Enter 键将 替换为所选路径。您可以使用 Esc 取消搜索。@@
|
||||||
|
|
||||||
|
--cd/-C flag
|
||||||
|
Sometimes it is not convenient to to the directory you want Codex to use as the "working root" before running Codex. Fortunately, supports a option so you can specify whatever folder you want. You can confirm that Codex is honoring by double-checking the workdir it reports in the TUI at the start of a new session.cdcodex--cd--cd
|
||||||
Reference in New Issue
Block a user