mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-10 02:24:35 +08:00
feat(ccw): migrate backend to TypeScript
- Convert 40 JS files to TypeScript (CLI, tools, core, MCP server) - Add Zod for runtime parameter validation - Add type definitions in src/types/ - Keep src/templates/ as JavaScript (dashboard frontend) - Update bin entries to use dist/ - Add tsconfig.json with strict mode - Add backward-compatible exports for tests - All 39 tests passing Breaking changes: None (backward compatible) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
122
.claude/workflows/cli-templates/prompts/rules/rule-api.txt
Normal file
122
.claude/workflows/cli-templates/prompts/rules/rule-api.txt
Normal file
@@ -0,0 +1,122 @@
|
||||
# Rule Template: API Rules (Backend/Fullstack Only)
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {FILE_EXT}: File extension pattern
|
||||
- {API_FRAMEWORK}: API framework (Express, FastAPI, etc)
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths:
|
||||
- "**/api/**/*.{FILE_EXT}"
|
||||
- "**/routes/**/*.{FILE_EXT}"
|
||||
- "**/endpoints/**/*.{FILE_EXT}"
|
||||
- "**/controllers/**/*.{FILE_EXT}"
|
||||
- "**/handlers/**/*.{FILE_EXT}"
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} API Rules
|
||||
|
||||
## Endpoint Design
|
||||
|
||||
[REST/GraphQL conventions from Exa research]
|
||||
|
||||
### URL Structure
|
||||
- Resource naming (plural nouns)
|
||||
- Nesting depth limits
|
||||
- Query parameter conventions
|
||||
- Version prefixing
|
||||
|
||||
### HTTP Methods
|
||||
- GET: Read operations
|
||||
- POST: Create operations
|
||||
- PUT/PATCH: Update operations
|
||||
- DELETE: Remove operations
|
||||
|
||||
### Status Codes
|
||||
- 2xx: Success responses
|
||||
- 4xx: Client errors
|
||||
- 5xx: Server errors
|
||||
|
||||
## Request Validation
|
||||
|
||||
[Input validation patterns]
|
||||
|
||||
### Schema Validation
|
||||
```{lang}
|
||||
// Example validation schema
|
||||
```
|
||||
|
||||
### Required Fields
|
||||
- Validation approach
|
||||
- Error messages format
|
||||
- Sanitization rules
|
||||
|
||||
## Response Format
|
||||
|
||||
[Standard response structures]
|
||||
|
||||
### Success Response
|
||||
```json
|
||||
{
|
||||
"data": {},
|
||||
"meta": {}
|
||||
}
|
||||
```
|
||||
|
||||
### Pagination
|
||||
```json
|
||||
{
|
||||
"data": [],
|
||||
"pagination": {
|
||||
"page": 1,
|
||||
"limit": 20,
|
||||
"total": 100
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Error Responses
|
||||
|
||||
[Error handling for APIs]
|
||||
|
||||
### Error Format
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "ERROR_CODE",
|
||||
"message": "Human readable message",
|
||||
"details": {}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Common Error Codes
|
||||
- VALIDATION_ERROR
|
||||
- NOT_FOUND
|
||||
- UNAUTHORIZED
|
||||
- FORBIDDEN
|
||||
|
||||
## Authentication & Authorization
|
||||
|
||||
[Auth patterns]
|
||||
- Token handling
|
||||
- Permission checks
|
||||
- Rate limiting
|
||||
|
||||
## Documentation
|
||||
|
||||
[API documentation standards]
|
||||
- OpenAPI/Swagger
|
||||
- Inline documentation
|
||||
- Example requests/responses
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Focus on API-specific patterns
|
||||
- Include request/response examples
|
||||
- Cover security considerations
|
||||
- Reference framework conventions
|
||||
@@ -0,0 +1,122 @@
|
||||
# Rule Template: Component Rules (Frontend/Fullstack Only)
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {FILE_EXT}: File extension pattern
|
||||
- {UI_FRAMEWORK}: UI framework (React, Vue, etc)
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths:
|
||||
- "**/components/**/*.{FILE_EXT}"
|
||||
- "**/ui/**/*.{FILE_EXT}"
|
||||
- "**/views/**/*.{FILE_EXT}"
|
||||
- "**/pages/**/*.{FILE_EXT}"
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} Component Rules
|
||||
|
||||
## Component Structure
|
||||
|
||||
[Organization patterns from Exa research]
|
||||
|
||||
### File Organization
|
||||
```
|
||||
components/
|
||||
├── common/ # Shared components
|
||||
├── features/ # Feature-specific
|
||||
├── layout/ # Layout components
|
||||
└── ui/ # Base UI elements
|
||||
```
|
||||
|
||||
### Component Template
|
||||
```{lang}
|
||||
// Standard component structure
|
||||
```
|
||||
|
||||
### Naming Conventions
|
||||
- PascalCase for components
|
||||
- Descriptive names
|
||||
- Prefix conventions (if any)
|
||||
|
||||
## Props & State
|
||||
|
||||
[State management guidelines]
|
||||
|
||||
### Props Definition
|
||||
```{lang}
|
||||
// Props type/interface example
|
||||
```
|
||||
|
||||
### Props Best Practices
|
||||
- Required vs optional
|
||||
- Default values
|
||||
- Prop validation
|
||||
- Prop naming
|
||||
|
||||
### Local State
|
||||
- When to use local state
|
||||
- State initialization
|
||||
- State updates
|
||||
|
||||
### Shared State
|
||||
- State management approach
|
||||
- Context usage
|
||||
- Store patterns
|
||||
|
||||
## Styling
|
||||
|
||||
[CSS/styling conventions]
|
||||
|
||||
### Approach
|
||||
- [CSS Modules/Styled Components/Tailwind/etc]
|
||||
|
||||
### Style Organization
|
||||
```{lang}
|
||||
// Style example
|
||||
```
|
||||
|
||||
### Naming Conventions
|
||||
- Class naming (BEM, etc)
|
||||
- CSS variable usage
|
||||
- Theme integration
|
||||
|
||||
## Accessibility
|
||||
|
||||
[A11y requirements]
|
||||
|
||||
### Essential Requirements
|
||||
- Semantic HTML
|
||||
- ARIA labels
|
||||
- Keyboard navigation
|
||||
- Focus management
|
||||
|
||||
### Testing A11y
|
||||
- Automated checks
|
||||
- Manual testing
|
||||
- Screen reader testing
|
||||
|
||||
## Performance
|
||||
|
||||
[Performance guidelines]
|
||||
|
||||
### Optimization Patterns
|
||||
- Memoization
|
||||
- Lazy loading
|
||||
- Code splitting
|
||||
- Virtual lists
|
||||
|
||||
### Avoiding Re-renders
|
||||
- When to memoize
|
||||
- Callback optimization
|
||||
- State structure
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Focus on component-specific patterns
|
||||
- Include framework-specific examples
|
||||
- Cover accessibility requirements
|
||||
- Address performance considerations
|
||||
@@ -0,0 +1,89 @@
|
||||
# Rule Template: Configuration Rules
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {CONFIG_FILES}: List of config file patterns
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths:
|
||||
- "*.config.*"
|
||||
- ".*rc"
|
||||
- ".*rc.{js,json,yaml,yml}"
|
||||
- "package.json"
|
||||
- "tsconfig*.json"
|
||||
- "pyproject.toml"
|
||||
- "Cargo.toml"
|
||||
- "go.mod"
|
||||
- ".env*"
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} Configuration Rules
|
||||
|
||||
## Project Setup
|
||||
|
||||
[Configuration guidelines from Exa research]
|
||||
|
||||
### Essential Config Files
|
||||
- [List primary config files]
|
||||
- [Purpose of each]
|
||||
|
||||
### Recommended Structure
|
||||
```
|
||||
project/
|
||||
├── [config files]
|
||||
├── src/
|
||||
└── tests/
|
||||
```
|
||||
|
||||
## Tooling
|
||||
|
||||
[Linters, formatters, bundlers]
|
||||
|
||||
### Linting
|
||||
- Tool: [ESLint/Pylint/etc]
|
||||
- Config file: [.eslintrc/pyproject.toml/etc]
|
||||
- Key rules to enable
|
||||
|
||||
### Formatting
|
||||
- Tool: [Prettier/Black/etc]
|
||||
- Integration with editor
|
||||
- Pre-commit hooks
|
||||
|
||||
### Build Tools
|
||||
- Bundler: [Webpack/Vite/etc]
|
||||
- Build configuration
|
||||
- Optimization settings
|
||||
|
||||
## Environment
|
||||
|
||||
[Environment management]
|
||||
|
||||
### Environment Variables
|
||||
- Naming conventions
|
||||
- Required vs optional
|
||||
- Secret handling
|
||||
- .env file structure
|
||||
|
||||
### Development vs Production
|
||||
- Environment-specific configs
|
||||
- Feature flags
|
||||
- Debug settings
|
||||
|
||||
## Dependencies
|
||||
|
||||
[Dependency management]
|
||||
- Lock file usage
|
||||
- Version pinning strategy
|
||||
- Security updates
|
||||
- Peer dependencies
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Focus on config file best practices
|
||||
- Include security considerations
|
||||
- Cover development workflow setup
|
||||
- Mention CI/CD integration where relevant
|
||||
60
.claude/workflows/cli-templates/prompts/rules/rule-core.txt
Normal file
60
.claude/workflows/cli-templates/prompts/rules/rule-core.txt
Normal file
@@ -0,0 +1,60 @@
|
||||
# Rule Template: Core Principles
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {FILE_EXT}: File extension pattern
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths: **/*.{FILE_EXT}
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} Core Principles
|
||||
|
||||
## Philosophy
|
||||
|
||||
[Synthesize core philosophy from Exa research]
|
||||
- Key paradigms and mental models
|
||||
- Design philosophy
|
||||
- Community conventions
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
[Language-specific naming rules]
|
||||
- Variables and functions
|
||||
- Classes and types
|
||||
- Files and directories
|
||||
- Constants and enums
|
||||
|
||||
## Code Organization
|
||||
|
||||
[Structure and module guidelines]
|
||||
- File structure patterns
|
||||
- Module boundaries
|
||||
- Import organization
|
||||
- Dependency management
|
||||
|
||||
## Type Safety
|
||||
|
||||
[Type system best practices - if applicable]
|
||||
- Type annotation guidelines
|
||||
- Generic usage patterns
|
||||
- Type inference vs explicit types
|
||||
- Null/undefined handling
|
||||
|
||||
## Documentation
|
||||
|
||||
[Documentation standards]
|
||||
- Comment style
|
||||
- JSDoc/docstring format
|
||||
- README conventions
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Focus on universal principles that apply to ALL files
|
||||
- Keep rules actionable and specific
|
||||
- Include rationale for each rule
|
||||
- Reference official style guides where applicable
|
||||
@@ -0,0 +1,70 @@
|
||||
# Rule Template: Implementation Patterns
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {FILE_EXT}: File extension pattern
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths: src/**/*.{FILE_EXT}
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} Implementation Patterns
|
||||
|
||||
## Common Patterns
|
||||
|
||||
[With code examples from Exa research]
|
||||
|
||||
### Pattern 1: [Name]
|
||||
```{lang}
|
||||
// Example code
|
||||
```
|
||||
**When to use**: [Context]
|
||||
**Benefits**: [Why this pattern]
|
||||
|
||||
### Pattern 2: [Name]
|
||||
...
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
[Common mistakes with examples]
|
||||
|
||||
### Anti-Pattern 1: [Name]
|
||||
```{lang}
|
||||
// Bad example
|
||||
```
|
||||
**Problem**: [Why it's bad]
|
||||
**Solution**: [Better approach]
|
||||
|
||||
## Error Handling
|
||||
|
||||
[Error handling conventions]
|
||||
- Error types and hierarchy
|
||||
- Try-catch patterns
|
||||
- Error propagation
|
||||
- Logging practices
|
||||
|
||||
## Async Patterns
|
||||
|
||||
[Asynchronous code conventions - if applicable]
|
||||
- Promise handling
|
||||
- Async/await usage
|
||||
- Concurrency patterns
|
||||
- Error handling in async code
|
||||
|
||||
## State Management
|
||||
|
||||
[State handling patterns]
|
||||
- Local state patterns
|
||||
- Shared state approaches
|
||||
- Immutability practices
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Focus on source code implementation
|
||||
- Provide concrete code examples
|
||||
- Show both good and bad patterns
|
||||
- Include context for when to apply each pattern
|
||||
@@ -0,0 +1,81 @@
|
||||
# Rule Template: Testing Rules
|
||||
|
||||
## Variables
|
||||
- {TECH_STACK_NAME}: Tech stack display name
|
||||
- {FILE_EXT}: File extension pattern
|
||||
- {TEST_FRAMEWORK}: Primary testing framework
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
paths:
|
||||
- "**/*.{test,spec}.{FILE_EXT}"
|
||||
- "tests/**/*.{FILE_EXT}"
|
||||
- "__tests__/**/*.{FILE_EXT}"
|
||||
- "**/test_*.{FILE_EXT}"
|
||||
- "**/*_test.{FILE_EXT}"
|
||||
---
|
||||
|
||||
# {TECH_STACK_NAME} Testing Rules
|
||||
|
||||
## Testing Framework
|
||||
|
||||
[Recommended frameworks from Exa research]
|
||||
- Primary: {TEST_FRAMEWORK}
|
||||
- Assertion library
|
||||
- Mocking library
|
||||
- Coverage tool
|
||||
|
||||
## Test Structure
|
||||
|
||||
[Organization patterns]
|
||||
|
||||
### File Naming
|
||||
- Unit tests: `*.test.{ext}` or `*.spec.{ext}`
|
||||
- Integration tests: `*.integration.test.{ext}`
|
||||
- E2E tests: `*.e2e.test.{ext}`
|
||||
|
||||
### Test Organization
|
||||
```{lang}
|
||||
describe('[Component/Module]', () => {
|
||||
describe('[method/feature]', () => {
|
||||
it('should [expected behavior]', () => {
|
||||
// Arrange
|
||||
// Act
|
||||
// Assert
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## Mocking & Fixtures
|
||||
|
||||
[Best practices]
|
||||
- Mock creation patterns
|
||||
- Fixture organization
|
||||
- Test data factories
|
||||
- Cleanup strategies
|
||||
|
||||
## Assertions
|
||||
|
||||
[Assertion patterns]
|
||||
- Common assertions
|
||||
- Custom matchers
|
||||
- Async assertions
|
||||
- Error assertions
|
||||
|
||||
## Coverage Requirements
|
||||
|
||||
[Coverage guidelines]
|
||||
- Minimum coverage thresholds
|
||||
- What to cover vs skip
|
||||
- Coverage report interpretation
|
||||
```
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
- Include framework-specific patterns
|
||||
- Show test structure examples
|
||||
- Cover both unit and integration testing
|
||||
- Include async testing patterns
|
||||
@@ -0,0 +1,89 @@
|
||||
# Tech Stack Rules Generation Agent Prompt
|
||||
|
||||
## Context Variables
|
||||
- {TECH_STACK_NAME}: Normalized tech stack name (e.g., "typescript-react")
|
||||
- {PRIMARY_LANG}: Primary language (e.g., "typescript")
|
||||
- {FILE_EXT}: File extension pattern (e.g., "{ts,tsx}")
|
||||
- {FRAMEWORK_TYPE}: frontend | backend | fullstack | library
|
||||
- {COMPONENTS}: Array of tech components
|
||||
- {OUTPUT_DIR}: .claude/rules/tech/{TECH_STACK_NAME}/
|
||||
|
||||
## Agent Instructions
|
||||
|
||||
Generate path-conditional rules for Claude Code automatic loading.
|
||||
|
||||
### Step 1: Execute Exa Research
|
||||
|
||||
Run 4-6 parallel queries based on tech stack:
|
||||
|
||||
**Base Queries** (always execute):
|
||||
```
|
||||
mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} best practices principles 2025", tokensNum: 8000)
|
||||
mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} implementation patterns examples", tokensNum: 7000)
|
||||
mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} testing strategies conventions", tokensNum: 5000)
|
||||
mcp__exa__web_search_exa(query: "{PRIMARY_LANG} configuration setup 2025", numResults: 5)
|
||||
```
|
||||
|
||||
**Component Queries** (for each framework in COMPONENTS):
|
||||
```
|
||||
mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} {component} integration patterns", tokensNum: 5000)
|
||||
```
|
||||
|
||||
### Step 2: Read Rule Templates
|
||||
|
||||
Read each template file before generating content:
|
||||
```
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-core.txt)
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-patterns.txt)
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-testing.txt)
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-config.txt)
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-api.txt) # Only if backend/fullstack
|
||||
Read(~/.claude/workflows/cli-templates/prompts/rules/rule-components.txt) # Only if frontend/fullstack
|
||||
```
|
||||
|
||||
### Step 3: Generate Rule Files
|
||||
|
||||
Create directory and write files:
|
||||
```bash
|
||||
mkdir -p "{OUTPUT_DIR}"
|
||||
```
|
||||
|
||||
**Always Generate**:
|
||||
- core.md (from rule-core.txt template)
|
||||
- patterns.md (from rule-patterns.txt template)
|
||||
- testing.md (from rule-testing.txt template)
|
||||
- config.md (from rule-config.txt template)
|
||||
|
||||
**Conditional**:
|
||||
- api.md: Only if FRAMEWORK_TYPE == 'backend' or 'fullstack'
|
||||
- components.md: Only if FRAMEWORK_TYPE == 'frontend' or 'fullstack'
|
||||
|
||||
### Step 4: Write Metadata
|
||||
|
||||
```json
|
||||
{
|
||||
"tech_stack": "{TECH_STACK_NAME}",
|
||||
"primary_lang": "{PRIMARY_LANG}",
|
||||
"file_ext": "{FILE_EXT}",
|
||||
"framework_type": "{FRAMEWORK_TYPE}",
|
||||
"components": ["{COMPONENTS}"],
|
||||
"generated_at": "{ISO_TIMESTAMP}",
|
||||
"source": "exa-research",
|
||||
"files_generated": ["core.md", "patterns.md", "testing.md", "config.md", ...]
|
||||
}
|
||||
```
|
||||
|
||||
### Step 5: Report Completion
|
||||
|
||||
Provide summary:
|
||||
- Files created with their path patterns
|
||||
- Exa queries executed (count)
|
||||
- Sources consulted (count)
|
||||
|
||||
## Critical Requirements
|
||||
|
||||
1. Every .md file MUST start with `paths` YAML frontmatter
|
||||
2. Use {FILE_EXT} consistently across all rule files
|
||||
3. Synthesize Exa research into actionable rules
|
||||
4. Include code examples from Exa sources
|
||||
5. Keep each file focused on its specific domain
|
||||
@@ -21,26 +21,11 @@ type: search-guideline
|
||||
**grep**: Built-in pattern matching (fallback when rg unavailable)
|
||||
**get_modules_by_depth.sh**: Program architecture analysis (MANDATORY before planning)
|
||||
|
||||
## 📋 Tool Selection Matrix
|
||||
|
||||
| Need | Tool | Use Case |
|
||||
|------|------|----------|
|
||||
| **Workflow history** | Skill(workflow-progress) | WFS sessions lessons/conflicts - `/memory:workflow-skill-memory` |
|
||||
| **Tech stack docs** | Skill({tech-name}) | Stack APIs/guides - `/memory:tech-research` |
|
||||
| **Project docs** | Skill({project-name}) | Project modules/architecture - `/memory:skill-memory` |
|
||||
| **Semantic discovery** | codebase-retrieval | Find files relevant to task/feature context |
|
||||
| **Pattern matching** | rg | Search code content with regex |
|
||||
| **File name lookup** | find | Locate files by name patterns |
|
||||
| **Architecture** | get_modules_by_depth.sh | Understand program structure |
|
||||
|
||||
## 🔧 Quick Command Reference
|
||||
|
||||
```bash
|
||||
# SKILL Packages (FIRST PRIORITY - fastest context loading)
|
||||
Skill(command: "workflow-progress") # Workflow: WFS sessions history, lessons, conflicts
|
||||
Skill(command: "react-dev") # Tech: React APIs, patterns, best practices
|
||||
Skill(command: "claude_dms3") # Project: Project modules, architecture, examples
|
||||
|
||||
# Semantic File Discovery (codebase-retrieval)
|
||||
cd [directory] && gemini -p "
|
||||
PURPOSE: Discover files relevant to task/feature
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Intelligent Tools Selection Strategy
|
||||
|
||||
## 📋 Table of Contents
|
||||
## Table of Contents
|
||||
1. [Quick Start](#-quick-start)
|
||||
2. [Tool Specifications](#-tool-specifications)
|
||||
3. [Command Templates](#-command-templates)
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Quick Start
|
||||
## Quick Start
|
||||
|
||||
### Universal Prompt Template
|
||||
|
||||
@@ -29,85 +29,76 @@ RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt) | [
|
||||
- **Analysis/Documentation** → Gemini (preferred) or Qwen (fallback)
|
||||
- **Implementation/Testing** → Codex
|
||||
|
||||
### Quick Command Syntax
|
||||
### CCW Unified CLI Syntax
|
||||
|
||||
```bash
|
||||
# Gemini/Qwen
|
||||
cd [dir] && gemini -p "[prompt]" [--approval-mode yolo]
|
||||
# Basic execution
|
||||
ccw cli exec "<prompt>" --tool <gemini|qwen|codex> --mode <analysis|write|auto>
|
||||
|
||||
# Codex
|
||||
codex -C [dir] --full-auto exec "[prompt]" [--skip-git-repo-check -s danger-full-access]
|
||||
# With working directory
|
||||
ccw cli exec "<prompt>" --tool gemini --cd <path>
|
||||
|
||||
# With additional directories
|
||||
ccw cli exec "<prompt>" --tool gemini --includeDirs ../shared,../types
|
||||
|
||||
# Full example
|
||||
ccw cli exec "<prompt>" --tool codex --mode auto --cd ./project --includeDirs ./lib
|
||||
```
|
||||
|
||||
### CLI Subcommands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `ccw cli status` | Check CLI tools availability |
|
||||
| `ccw cli exec "<prompt>"` | Execute a CLI tool |
|
||||
| `ccw cli history` | Show execution history |
|
||||
| `ccw cli detail <id>` | Show execution detail |
|
||||
|
||||
### Model Selection
|
||||
|
||||
**Available Models** (user selects via `-m` after prompt):
|
||||
**Available Models** (override via `--model`):
|
||||
- Gemini: `gemini-2.5-pro`, `gemini-2.5-flash`
|
||||
- Qwen: `coder-model`, `vision-model`
|
||||
- Codex: `gpt-5.1`, `gpt-5.1-codex`, `gpt-5.1-codex-mini`
|
||||
|
||||
**Usage**: `-m <model>` placed AFTER `-p "prompt"` (e.g., `gemini -p "..." -m gemini-2.5-flash`)
|
||||
|
||||
### Quick Decision Matrix
|
||||
|
||||
| Scenario | Tool | MODE | Template |
|
||||
|----------|------|------|----------|
|
||||
| Execution Tracing | Gemini → Qwen | analysis | `analysis/01-trace-code-execution.txt` |
|
||||
| Bug Diagnosis | Gemini → Qwen | analysis | `analysis/01-diagnose-bug-root-cause.txt` |
|
||||
| Architecture Planning | Gemini → Qwen | analysis | `planning/01-plan-architecture-design.txt` |
|
||||
| Code Pattern Analysis | Gemini → Qwen | analysis | `analysis/02-analyze-code-patterns.txt` |
|
||||
| Architecture Review | Gemini → Qwen | analysis | `analysis/02-review-architecture.txt` |
|
||||
| Document Analysis | Gemini → Qwen | analysis | `analysis/02-analyze-technical-document.txt` |
|
||||
| Feature Implementation | Codex | auto | `development/02-implement-feature.txt` |
|
||||
| Component Development | Codex | auto | `development/02-implement-component-ui.txt` |
|
||||
| Test Generation | Codex | write | `development/02-generate-tests.txt` |
|
||||
**Best Practice**: Omit `--model` for optimal auto-selection
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Use tools early and often** - Tools are faster and more thorough
|
||||
- **When in doubt, use both** - Parallel usage provides comprehensive coverage
|
||||
- **Default to tools** - Use for most coding tasks, no matter how small
|
||||
- **Minimize context noise** - Use `cd` + `--include-directories` to focus on relevant files
|
||||
- **⚠️ Choose templates by need** - Select templates based on task requirements:
|
||||
- `00-*` for universal fallback when no specific template matches
|
||||
- `01-*` for general exploratory/diagnostic work
|
||||
- `02-*` for common implementation/analysis tasks
|
||||
- `03-*` for specialized domains
|
||||
- **⚠️ Always specify templates** - Include appropriate template in RULES field via `$(cat ~/.claude/workflows/cli-templates/prompts/.../...txt)`
|
||||
- **⚠️ Universal templates as fallback** - Use universal templates when no specific template matches your needs:
|
||||
- `universal/00-universal-rigorous-style.txt` for precision-critical tasks
|
||||
- `universal/00-universal-creative-style.txt` for exploratory/innovative tasks
|
||||
- **⚠️ Write protection** - Require EXPLICIT MODE=write or MODE=auto specification
|
||||
- **Unified CLI** - Always use `ccw cli exec` for consistent parameter handling
|
||||
- **Choose templates by need** - See [Template System](#template-system) for naming conventions and selection guide
|
||||
- **Write protection** - Require EXPLICIT MODE=write or MODE=auto specification
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Tool Specifications
|
||||
## Tool Specifications
|
||||
|
||||
### MODE Options
|
||||
|
||||
**analysis** (default for Gemini/Qwen)
|
||||
**analysis** (default)
|
||||
- Read-only operations, no file modifications
|
||||
- Analysis output returned as text response
|
||||
- Use for: code review, architecture analysis, pattern discovery
|
||||
- Permission: Default, no special parameters needed
|
||||
- CCW: `ccw cli exec "<prompt>" --mode analysis`
|
||||
|
||||
**write** (Gemini/Qwen/Codex)
|
||||
**write**
|
||||
- File creation/modification/deletion allowed
|
||||
- Requires explicit MODE=write specification
|
||||
- Requires explicit `--mode write` specification
|
||||
- Use for: documentation generation, code creation, file modifications
|
||||
- Permission:
|
||||
- Gemini/Qwen: `--approval-mode yolo`
|
||||
- Codex: `--skip-git-repo-check -s danger-full-access`
|
||||
- CCW: `ccw cli exec "<prompt>" --mode write`
|
||||
|
||||
**auto** (Codex only)
|
||||
- Full autonomous development operations
|
||||
- Requires explicit MODE=auto specification
|
||||
- Requires explicit `--mode auto` specification
|
||||
- Use for: feature implementation, bug fixes, autonomous development
|
||||
- Permission: `--skip-git-repo-check -s danger-full-access`
|
||||
- CCW: `ccw cli exec "<prompt>" --tool codex --mode auto`
|
||||
|
||||
### Gemini & Qwen
|
||||
|
||||
**Commands**: `gemini` (primary) | `qwen` (fallback)
|
||||
**Via CCW**: `ccw cli exec "<prompt>" --tool gemini` or `--tool qwen`
|
||||
|
||||
**Strengths**: Large context window, pattern recognition
|
||||
|
||||
@@ -122,7 +113,7 @@ codex -C [dir] --full-auto exec "[prompt]" [--skip-git-repo-check -s danger-full
|
||||
|
||||
### Codex
|
||||
|
||||
**Command**: `codex --full-auto exec`
|
||||
**Via CCW**: `ccw cli exec "<prompt>" --tool codex --mode auto`
|
||||
|
||||
**Strengths**: Autonomous development, mathematical reasoning
|
||||
|
||||
@@ -130,26 +121,26 @@ codex -C [dir] --full-auto exec "[prompt]" [--skip-git-repo-check -s danger-full
|
||||
|
||||
**Default MODE**: No default, must be explicitly specified
|
||||
|
||||
**Session Management**:
|
||||
**Session Management** (via native codex):
|
||||
- `codex resume` - Resume previous session (picker)
|
||||
- `codex resume --last` - Resume most recent session
|
||||
- `codex -i <image_file>` - Attach image to prompt
|
||||
|
||||
**Multi-task Pattern**:
|
||||
- **First task**: MUST use full Standard Prompt Template with `exec` to establish complete context
|
||||
- **Subsequent tasks**: Can use brief prompt with `exec "..." resume --last` (inherits context from session)
|
||||
### CCW Unified Parameter Mapping
|
||||
|
||||
**Prompt Requirements**:
|
||||
- **Without `resume --last`**: ALWAYS use full Standard Prompt Template
|
||||
- **With `resume --last`**: Brief description sufficient (previous template context inherited)
|
||||
CCW automatically maps parameters to tool-specific syntax:
|
||||
|
||||
**Auto-Resume Rules**:
|
||||
- **Use `resume --last`**: Related tasks, extending previous work, multi-step workflow
|
||||
- **Don't use**: First task, new independent work, different module
|
||||
| CCW Parameter | Gemini/Qwen | Codex |
|
||||
|---------------|-------------|-------|
|
||||
| `--cd <path>` | `cd <path> &&` (prepend) | `-C <path>` |
|
||||
| `--includeDirs <dirs>` | `--include-directories <dirs>` | `--add-dir <dir>` (per dir) |
|
||||
| `--mode write` | `--approval-mode yolo` | `--skip-git-repo-check -s danger-full-access` |
|
||||
| `--mode auto` | N/A | `--skip-git-repo-check -s danger-full-access` |
|
||||
| `--model <m>` | `-m <m>` | `-m <m>` |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Command Templates
|
||||
## Command Templates
|
||||
|
||||
### Universal Template Structure
|
||||
|
||||
@@ -177,7 +168,7 @@ Every command MUST follow this structure:
|
||||
- **File Patterns**: Use @ syntax for file references (default: `@**/*` for all files)
|
||||
- `@**/*` - All files in current directory tree
|
||||
- `@src/**/*.ts` - TypeScript files in src directory
|
||||
- `@../shared/**/*` - Files from sibling directory (requires `--include-directories`)
|
||||
- `@../shared/**/*` - Files from sibling directory (requires `--includeDirs`)
|
||||
- **Memory Context**: Reference previous session findings and context
|
||||
- Related tasks: `Building on previous analysis from [session/commit]`
|
||||
- Tech stack: `Using patterns from [tech-stack-name] documentation`
|
||||
@@ -215,157 +206,132 @@ EXPECTED: [deliverable format, quality criteria, output structure, testing requi
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/[category]/[0X-template-name].txt) | [additional constraints] | [MODE]=[READ-ONLY|CREATE/MODIFY/DELETE|FULL operations]
|
||||
```
|
||||
|
||||
**Template Selection Guide**:
|
||||
- Choose template based on your specific task, not by sequence number
|
||||
- `01-*` templates: General-purpose, broad applicability
|
||||
- `02-*` templates: Common specialized scenarios
|
||||
- `03-*` templates: Domain-specific needs
|
||||
### CCW CLI Execution
|
||||
|
||||
### Tool-Specific Configuration
|
||||
Use the **[Standard Prompt Template](#standard-prompt-template)** for all tools. CCW provides unified command syntax.
|
||||
|
||||
Use the **[Standard Prompt Template](#standard-prompt-template)** for all tools. This section only covers tool-specific command syntax.
|
||||
#### Basic Command Format
|
||||
|
||||
#### Gemini & Qwen
|
||||
|
||||
**Command Format**: `cd [directory] && [tool] -p "[Standard Prompt Template]" [options]`
|
||||
|
||||
**Syntax Elements**:
|
||||
- **Directory**: `cd [directory] &&` (navigate to target directory)
|
||||
- **Tool**: `gemini` (primary) | `qwen` (fallback)
|
||||
- **Prompt**: `-p "[Standard Prompt Template]"` (prompt BEFORE options)
|
||||
- **Model**: `-m [model-name]` (optional, NOT recommended - tools auto-select best model)
|
||||
- Gemini: `gemini-2.5-pro` (default) | `gemini-2.5-flash`
|
||||
- Qwen: `coder-model` (default) | `vision-model`
|
||||
- **Best practice**: Omit `-m` parameter for optimal model selection
|
||||
- **Position**: If used, place AFTER `-p "prompt"`
|
||||
- **Write Permission**: `--approval-mode yolo` (ONLY for MODE=write, placed AFTER prompt)
|
||||
|
||||
**Command Examples**:
|
||||
```bash
|
||||
# Analysis Mode (default, read-only)
|
||||
cd [directory] && gemini -p "[Standard Prompt Template]"
|
||||
|
||||
# Write Mode (requires MODE=write in template + --approval-mode yolo)
|
||||
cd [directory] && gemini -p "[Standard Prompt Template with MODE: write]" --approval-mode yolo
|
||||
|
||||
# Fallback to Qwen
|
||||
cd [directory] && qwen -p "[Standard Prompt Template]"
|
||||
|
||||
# Multi-directory support
|
||||
cd [directory] && gemini -p "[Standard Prompt Template]" --include-directories ../shared,../types
|
||||
ccw cli exec "<Standard Prompt Template>" [options]
|
||||
```
|
||||
|
||||
#### Codex
|
||||
#### Common Options
|
||||
|
||||
**Command Format**: `codex -C [directory] --full-auto exec "[Standard Prompt Template]" [options]`
|
||||
| Option | Description | Default |
|
||||
|--------|-------------|---------|
|
||||
| `--tool <tool>` | CLI tool: gemini, qwen, codex | gemini |
|
||||
| `--mode <mode>` | Mode: analysis, write, auto | analysis |
|
||||
| `--model <model>` | Model override | auto-select |
|
||||
| `--cd <path>` | Working directory | current dir |
|
||||
| `--includeDirs <dirs>` | Additional directories (comma-separated) | none |
|
||||
| `--timeout <ms>` | Timeout in milliseconds | 300000 |
|
||||
| `--no-stream` | Disable streaming output | false |
|
||||
|
||||
**Syntax Elements**:
|
||||
- **Directory**: `-C [directory]` (target directory parameter)
|
||||
- **Execution Mode**: `--full-auto exec` (required for autonomous execution)
|
||||
- **Prompt**: `exec "[Standard Prompt Template]"` (prompt BEFORE options)
|
||||
- **Model**: `-m [model-name]` (optional, NOT recommended - Codex auto-selects best model)
|
||||
- Available: `gpt-5.1` | `gpt-5.1-codex` | `gpt-5.1-codex-mini`
|
||||
- **Best practice**: Omit `-m` parameter for optimal model selection
|
||||
- **Write Permission**: `--skip-git-repo-check -s danger-full-access`
|
||||
- **⚠️ CRITICAL**: MUST be placed at **command END** (AFTER prompt and all other parameters)
|
||||
- **ONLY use for**: MODE=auto or MODE=write
|
||||
- **NEVER place before prompt** - command will fail
|
||||
- **Session Resume**: `resume --last` (placed AFTER prompt, BEFORE permission flags)
|
||||
#### Command Examples
|
||||
|
||||
**Command Examples**:
|
||||
```bash
|
||||
# Auto Mode (requires MODE=auto in template + permission flags)
|
||||
codex -C [directory] --full-auto exec "[Standard Prompt Template with MODE: auto]" --skip-git-repo-check -s danger-full-access
|
||||
# Analysis Mode (default, read-only) - Gemini
|
||||
ccw cli exec "
|
||||
PURPOSE: Analyze authentication with shared utilities context
|
||||
TASK: Review auth implementation and its dependencies
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* @../shared/**/*
|
||||
EXPECTED: Complete analysis with cross-directory dependencies
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | analysis=READ-ONLY
|
||||
" --tool gemini --cd src/auth --includeDirs ../shared,../types
|
||||
|
||||
# Write Mode (requires MODE=write in template + permission flags)
|
||||
codex -C [directory] --full-auto exec "[Standard Prompt Template with MODE: write]" --skip-git-repo-check -s danger-full-access
|
||||
# Write Mode - Gemini with file modifications
|
||||
ccw cli exec "
|
||||
PURPOSE: Generate documentation for API module
|
||||
TASK: • Create API docs • Add usage examples • Update README
|
||||
MODE: write
|
||||
CONTEXT: @src/api/**/*
|
||||
EXPECTED: Complete API documentation
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt) | write=CREATE/MODIFY/DELETE
|
||||
" --tool gemini --mode write --cd src
|
||||
|
||||
# Session continuity
|
||||
# First task - MUST use full Standard Prompt Template to establish context
|
||||
codex -C project --full-auto exec "[Standard Prompt Template with MODE: auto]" --skip-git-repo-check -s danger-full-access
|
||||
|
||||
# Subsequent tasks - Can use brief prompt ONLY when using 'resume --last'
|
||||
# (inherits full context from previous session, no need to repeat template)
|
||||
codex --full-auto exec "Add JWT refresh token validation" resume --last --skip-git-repo-check -s danger-full-access
|
||||
|
||||
# With image attachment
|
||||
codex -C [directory] -i design.png --full-auto exec "[Standard Prompt Template]" --skip-git-repo-check -s danger-full-access
|
||||
```
|
||||
|
||||
**Complete Example (Codex with full template)**:
|
||||
```bash
|
||||
# First task - establish session with full template
|
||||
codex -C project --full-auto exec "
|
||||
# Auto Mode - Codex for implementation
|
||||
ccw cli exec "
|
||||
PURPOSE: Implement authentication module
|
||||
TASK: • Create auth service • Add user validation • Setup JWT tokens
|
||||
MODE: auto
|
||||
CONTEXT: @**/* | Memory: Following security patterns from project standards
|
||||
EXPECTED: Complete auth module with tests
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt) | Follow existing patterns | auto=FULL operations
|
||||
" --skip-git-repo-check -s danger-full-access
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt) | auto=FULL operations
|
||||
" --tool codex --mode auto --cd project
|
||||
|
||||
# Subsequent tasks - brief description with resume
|
||||
codex --full-auto exec "Add JWT refresh token validation" resume --last --skip-git-repo-check -s danger-full-access
|
||||
# Fallback to Qwen
|
||||
ccw cli exec "
|
||||
PURPOSE: Analyze code patterns
|
||||
TASK: Review implementation patterns
|
||||
MODE: analysis
|
||||
CONTEXT: @**/*
|
||||
EXPECTED: Pattern analysis report
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | analysis=READ-ONLY
|
||||
" --tool qwen
|
||||
```
|
||||
|
||||
#### Tool Fallback Strategy
|
||||
|
||||
```bash
|
||||
# Primary: Gemini
|
||||
ccw cli exec "<prompt>" --tool gemini
|
||||
|
||||
# Fallback: Qwen (if Gemini fails or unavailable)
|
||||
ccw cli exec "<prompt>" --tool qwen
|
||||
|
||||
# Check tool availability
|
||||
ccw cli status
|
||||
```
|
||||
|
||||
### Directory Context Configuration
|
||||
|
||||
**Tool Directory Navigation**:
|
||||
- **Gemini & Qwen**: `cd path/to/project && gemini -p "prompt"`
|
||||
- **Codex**: `codex -C path/to/project --full-auto exec "task"`
|
||||
- **Path types**: Supports both relative (`../project`) and absolute (`/full/path`)
|
||||
**CCW Directory Options**:
|
||||
- `--cd <path>`: Set working directory for execution
|
||||
- `--includeDirs <dir1,dir2>`: Include additional directories
|
||||
|
||||
#### Critical Directory Scope Rules
|
||||
|
||||
**Once `cd` to a directory**:
|
||||
- @ references ONLY apply to current directory and subdirectories
|
||||
- `@**/*` = All files within current directory tree
|
||||
- `@*.ts` = TypeScript files in current directory tree
|
||||
**When using `--cd` to set working directory**:
|
||||
- @ references ONLY apply to that directory and subdirectories
|
||||
- `@**/*` = All files within working directory tree
|
||||
- `@*.ts` = TypeScript files in working directory tree
|
||||
- `@src/**/*` = Files within src subdirectory
|
||||
- CANNOT reference parent/sibling directories via @ alone
|
||||
|
||||
**To reference files outside current directory (TWO-STEP REQUIREMENT)**:
|
||||
1. Add `--include-directories` parameter to make external directories ACCESSIBLE
|
||||
**To reference files outside working directory (TWO-STEP REQUIREMENT)**:
|
||||
1. Add `--includeDirs` parameter to make external directories ACCESSIBLE
|
||||
2. Explicitly reference external files in CONTEXT field with @ patterns
|
||||
3. ⚠️ BOTH steps are MANDATORY
|
||||
3. Both steps are MANDATORY
|
||||
|
||||
Example: `cd src/auth && gemini -p "CONTEXT: @**/* @../shared/**/*" --include-directories ../shared`
|
||||
|
||||
**Rule**: If CONTEXT contains `@../dir/**/*`, command MUST include `--include-directories ../dir`
|
||||
|
||||
#### Multi-Directory Support (Gemini & Qwen)
|
||||
|
||||
**Parameter**: `--include-directories <dir1,dir2,...>`
|
||||
- Includes additional directories beyond current `cd` directory
|
||||
- Can be specified multiple times or comma-separated
|
||||
- Maximum 5 directories
|
||||
- REQUIRED when working in subdirectory but needing parent/sibling context
|
||||
|
||||
**Syntax**:
|
||||
Example:
|
||||
```bash
|
||||
# Comma-separated format
|
||||
gemini -p "prompt" --include-directories /path/to/project1,/path/to/project2
|
||||
ccw cli exec "CONTEXT: @**/* @../shared/**/*" --tool gemini --cd src/auth --includeDirs ../shared
|
||||
```
|
||||
|
||||
# Multiple flags format
|
||||
gemini -p "prompt" --include-directories /path/to/project1 --include-directories /path/to/project2
|
||||
**Rule**: If CONTEXT contains `@../dir/**/*`, command MUST include `--includeDirs ../dir`
|
||||
|
||||
# Recommended: cd + --include-directories
|
||||
cd src/auth && gemini -p "
|
||||
#### Multi-Directory Examples
|
||||
|
||||
```bash
|
||||
# Single additional directory
|
||||
ccw cli exec "<prompt>" --tool gemini --cd src/auth --includeDirs ../shared
|
||||
|
||||
# Multiple additional directories
|
||||
ccw cli exec "<prompt>" --tool gemini --cd src/auth --includeDirs ../shared,../types,../utils
|
||||
|
||||
# With full prompt template
|
||||
ccw cli exec "
|
||||
PURPOSE: Analyze authentication with shared utilities context
|
||||
TASK: Review auth implementation and its dependencies
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* @../shared/**/* @../types/**/*
|
||||
EXPECTED: Complete analysis with cross-directory dependencies
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | Focus on integration patterns | analysis=READ-ONLY
|
||||
" --include-directories ../shared,../types
|
||||
" --tool gemini --cd src/auth --includeDirs ../shared,../types
|
||||
```
|
||||
|
||||
**Best Practices**:
|
||||
- Use `cd` to navigate to primary focus directory
|
||||
- Use `--include-directories` for additional context
|
||||
- ⚠️ CONTEXT must explicitly list external files AND command must include `--include-directories`
|
||||
- Pattern matching rule: `@../dir/**/*` in CONTEXT → `--include-directories ../dir` in command (MANDATORY)
|
||||
|
||||
### CONTEXT Field Configuration
|
||||
|
||||
CONTEXT field consists of: **File Patterns** + **Memory Context**
|
||||
@@ -434,7 +400,7 @@ mcp__code-index__search_code_advanced(pattern="interface.*Props", file_pattern="
|
||||
CONTEXT: @src/components/Auth.tsx @src/types/auth.d.ts @src/hooks/useAuth.ts | Memory: Previous refactoring identified type inconsistencies, following React hooks patterns
|
||||
|
||||
# Step 3: Execute CLI with precise references
|
||||
cd src && gemini -p "
|
||||
ccw cli exec "
|
||||
PURPOSE: Analyze authentication components for type safety improvements
|
||||
TASK:
|
||||
• Review auth component patterns and props interfaces
|
||||
@@ -444,14 +410,14 @@ MODE: analysis
|
||||
CONTEXT: @components/Auth.tsx @types/auth.d.ts @hooks/useAuth.ts | Memory: Previous refactoring identified type inconsistencies, following React hooks patterns, related implementation in @hooks/useAuth.ts (commit abc123)
|
||||
EXPECTED: Comprehensive analysis report with type safety recommendations, code examples, and references to previous findings
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | Focus on type safety and component composition | analysis=READ-ONLY
|
||||
"
|
||||
" --tool gemini --cd src
|
||||
```
|
||||
|
||||
### RULES Field Configuration
|
||||
|
||||
**Basic Format**: `RULES: $(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt) | [constraints]`
|
||||
|
||||
**⚠️ Command Substitution Rules**:
|
||||
**Command Substitution Rules**:
|
||||
- **Template reference only, never read**: Use `$(cat ...)` directly, do NOT read template content first
|
||||
- **NEVER use escape characters**: `\$`, `\"`, `\'` will break command substitution
|
||||
- **In prompt context**: Path needs NO quotes (tilde expands correctly)
|
||||
@@ -460,16 +426,13 @@ RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-
|
||||
- **Why**: Shell executes `$(...)` in subshell where path is safe
|
||||
|
||||
**Examples**:
|
||||
- Universal rigorous: `$(cat ~/.claude/workflows/cli-templates/prompts/universal/00-universal-rigorous-style.txt) | Critical production refactoring`
|
||||
- Universal creative: `$(cat ~/.claude/workflows/cli-templates/prompts/universal/00-universal-creative-style.txt) | Explore alternative architecture approaches`
|
||||
- General template: `$(cat ~/.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt) | Focus on authentication module`
|
||||
- Specialized template: `$(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | React hooks only`
|
||||
- Multiple: `$(cat template1.txt) $(cat template2.txt) | Enterprise standards`
|
||||
- No template: `Focus on security patterns, include dependency analysis`
|
||||
|
||||
### Template System
|
||||
|
||||
**Base**: `~/.claude/workflows/cli-templates/`
|
||||
**Base**: `~/.claude/workflows/cli-templates/
|
||||
|
||||
**Naming Convention**:
|
||||
- `00-*` - **Universal fallback templates** (use when no specific template matches)
|
||||
@@ -479,65 +442,21 @@ RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-
|
||||
|
||||
**Note**: Number prefix indicates category and frequency, not required usage order. Choose based on task needs.
|
||||
|
||||
**Universal Templates (Fallback)**:
|
||||
**Universal Templates**:
|
||||
|
||||
When no specific template matches your task requirements, use one of these universal templates based on the desired execution style:
|
||||
|
||||
1. **Rigorous Style** (`universal/00-universal-rigorous-style.txt`)
|
||||
- **Use for**: Precision-critical tasks requiring systematic methodology
|
||||
- **Characteristics**:
|
||||
- Strict adherence to standards and specifications
|
||||
- Comprehensive validation and edge case handling
|
||||
- Defensive programming and error prevention
|
||||
- Full documentation and traceability
|
||||
- **Best for**: Production code, critical systems, refactoring, compliance tasks
|
||||
- **Thinking mode**: Systematic, methodical, standards-driven
|
||||
|
||||
2. **Creative Style** (`universal/00-universal-creative-style.txt`)
|
||||
- **Use for**: Exploratory tasks requiring innovative solutions
|
||||
- **Characteristics**:
|
||||
- Multi-perspective problem exploration
|
||||
- Pattern synthesis from different domains
|
||||
- Alternative approach generation
|
||||
- Elegant simplicity pursuit
|
||||
- **Best for**: New feature design, architecture exploration, optimization, problem-solving
|
||||
- **Thinking mode**: Exploratory, synthesis-driven, innovation-focused
|
||||
|
||||
**Selection Guide**:
|
||||
- **Rigorous**: When correctness, reliability, and compliance are paramount
|
||||
- **Creative**: When innovation, flexibility, and elegant solutions are needed
|
||||
- **Specific template**: When task matches predefined category (analysis, development, planning, etc.)
|
||||
|
||||
**Available Templates**:
|
||||
```
|
||||
prompts/
|
||||
├── universal/ # ← Universal fallback templates
|
||||
│ ├── 00-universal-rigorous-style.txt # Precision & standards-driven
|
||||
│ └── 00-universal-creative-style.txt # Innovation & exploration-focused
|
||||
├── analysis/
|
||||
│ ├── 01-trace-code-execution.txt
|
||||
│ ├── 01-diagnose-bug-root-cause.txt
|
||||
│ ├── 02-analyze-code-patterns.txt
|
||||
│ ├── 02-analyze-technical-document.txt
|
||||
│ ├── 02-review-architecture.txt
|
||||
│ ├── 02-review-code-quality.txt
|
||||
│ ├── 03-analyze-performance.txt
|
||||
│ ├── 03-assess-security-risks.txt
|
||||
│ └── 03-review-quality-standards.txt
|
||||
├── development/
|
||||
│ ├── 02-implement-feature.txt
|
||||
│ ├── 02-refactor-codebase.txt
|
||||
│ ├── 02-generate-tests.txt
|
||||
│ ├── 02-implement-component-ui.txt
|
||||
│ └── 03-debug-runtime-issues.txt
|
||||
└── planning/
|
||||
├── 01-plan-architecture-design.txt
|
||||
├── 02-breakdown-task-steps.txt
|
||||
├── 02-design-component-spec.txt
|
||||
├── 03-evaluate-concept-feasibility.txt
|
||||
└── 03-plan-migration-strategy.txt
|
||||
```
|
||||
|
||||
**Task-Template Matrix**:
|
||||
|
||||
| Task Type | Tool | Template |
|
||||
@@ -567,10 +486,9 @@ prompts/
|
||||
| Test Generation | Codex | `development/02-generate-tests.txt` |
|
||||
| Component Implementation | Codex | `development/02-implement-component-ui.txt` |
|
||||
| Debugging | Codex | `development/03-debug-runtime-issues.txt` |
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Execution Configuration
|
||||
## Execution Configuration
|
||||
|
||||
### Dynamic Timeout Allocation
|
||||
|
||||
@@ -584,31 +502,45 @@ prompts/
|
||||
|
||||
**Codex Multiplier**: 3x of allocated time (minimum 15min / 900000ms)
|
||||
|
||||
**Application**: All bash() wrapped commands including Gemini, Qwen and Codex executions
|
||||
**CCW Timeout Usage**:
|
||||
```bash
|
||||
ccw cli exec "<prompt>" --tool gemini --timeout 600000 # 10 minutes
|
||||
ccw cli exec "<prompt>" --tool codex --timeout 1800000 # 30 minutes
|
||||
```
|
||||
|
||||
**Auto-detection**: Analyze PURPOSE and TASK fields to determine timeout
|
||||
|
||||
### Permission Framework
|
||||
|
||||
**⚠️ Single-Use Explicit Authorization**: Each CLI execution requires explicit user command instruction - one command authorizes ONE execution only. Analysis does NOT authorize write operations. Previous authorization does NOT carry over. Each operation needs NEW explicit user directive.
|
||||
**Single-Use Explicit Authorization**: Each CLI execution requires explicit user command instruction - one command authorizes ONE execution only. Analysis does NOT authorize write operations. Previous authorization does NOT carry over. Each operation needs NEW explicit user directive.
|
||||
|
||||
**Mode Hierarchy**:
|
||||
- **analysis** (default): Read-only, safe for auto-execution
|
||||
- **write**: Requires explicit MODE=write specification
|
||||
- **auto**: Requires explicit MODE=auto specification
|
||||
- **write**: Requires explicit `--mode write` specification
|
||||
- **auto**: Requires explicit `--mode auto` specification
|
||||
- **Exception**: User provides clear instructions like "modify", "create", "implement"
|
||||
|
||||
**Tool-Specific Permissions**:
|
||||
- **Gemini/Qwen**: Use `--approval-mode yolo` ONLY when MODE=write (placed AFTER prompt)
|
||||
- **Codex**: Use `--skip-git-repo-check -s danger-full-access` ONLY when MODE=auto or MODE=write (placed at command END)
|
||||
- **Default**: All tools default to analysis/read-only mode
|
||||
**CCW Mode Permissions**:
|
||||
```bash
|
||||
# Analysis (default, no special permissions)
|
||||
ccw cli exec "<prompt>" --tool gemini
|
||||
|
||||
# Write mode (enables file modifications)
|
||||
ccw cli exec "<prompt>" --tool gemini --mode write
|
||||
|
||||
# Auto mode (full autonomous operations, Codex only)
|
||||
ccw cli exec "<prompt>" --tool codex --mode auto
|
||||
```
|
||||
|
||||
**Default**: All tools default to analysis/read-only mode
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Best Practices
|
||||
## Best Practices
|
||||
|
||||
### Workflow Principles
|
||||
|
||||
- **Use CCW unified interface** - `ccw cli exec` for all tool executions
|
||||
- **Start with templates** - Use predefined templates for consistency
|
||||
- **Be specific** - Clear PURPOSE, TASK, and EXPECTED fields with detailed descriptions
|
||||
- **Include constraints** - File patterns, scope, requirements in RULES
|
||||
@@ -623,18 +555,18 @@ prompts/
|
||||
- Memory: Previous sessions, tech stack patterns, cross-references
|
||||
- **Document context** - Always reference CLAUDE.md and relevant documentation
|
||||
- **Default to full context** - Use `@**/*` unless specific files needed
|
||||
- **⚠️ No escape characters** - NEVER use `\$`, `\"`, `\'` in CLI commands
|
||||
- **No escape characters** - NEVER use `\$`, `\"`, `\'` in CLI commands
|
||||
|
||||
### Context Optimization Strategy
|
||||
|
||||
**Directory Navigation**: Use `cd [directory] &&` pattern to reduce irrelevant context
|
||||
**Directory Navigation**: Use `--cd [directory]` to focus on specific directory
|
||||
|
||||
**When to change directory**:
|
||||
- Specific directory mentioned → Use `cd directory &&`
|
||||
**When to set working directory**:
|
||||
- Specific directory mentioned → Use `--cd directory`
|
||||
- Focused analysis needed → Target specific directory
|
||||
- Multi-directory scope → Use `cd` + `--include-directories`
|
||||
- Multi-directory scope → Use `--cd` + `--includeDirs`
|
||||
|
||||
**When to use `--include-directories`**:
|
||||
**When to use `--includeDirs`**:
|
||||
- Working in subdirectory but need parent/sibling context
|
||||
- Cross-directory dependency analysis required
|
||||
- Multiple related modules need simultaneous access
|
||||
@@ -642,21 +574,22 @@ prompts/
|
||||
|
||||
### Workflow Integration
|
||||
|
||||
When planning any coding task, **ALWAYS** integrate CLI tools:
|
||||
When planning any coding task, **ALWAYS** integrate CLI tools via CCW:
|
||||
|
||||
1. **Understanding Phase**: Use Gemini for analysis (Qwen as fallback)
|
||||
2. **Architecture Phase**: Use Gemini for design and analysis (Qwen as fallback)
|
||||
3. **Implementation Phase**: Use Codex for development
|
||||
4. **Quality Phase**: Use Codex for testing and validation
|
||||
1. **Understanding Phase**: `ccw cli exec "<prompt>" --tool gemini`
|
||||
2. **Architecture Phase**: `ccw cli exec "<prompt>" --tool gemini`
|
||||
3. **Implementation Phase**: `ccw cli exec "<prompt>" --tool codex --mode auto`
|
||||
4. **Quality Phase**: `ccw cli exec "<prompt>" --tool codex --mode write`
|
||||
|
||||
### Planning Checklist
|
||||
|
||||
For every development task:
|
||||
- [ ] **Purpose defined** - Clear goal and intent
|
||||
- [ ] **Mode selected** - Execution mode and permission level determined
|
||||
- [ ] **Mode selected** - Execution mode (`--mode analysis|write|auto`)
|
||||
- [ ] **Context gathered** - File references and session memory documented (default `@**/*`)
|
||||
- [ ] **Directory navigation** - Determine if `cd` or `cd + --include-directories` needed
|
||||
- [ ] **Gemini analysis** completed for understanding
|
||||
- [ ] **Template applied** - Use Standard Prompt Template (universal for all tools)
|
||||
- [ ] **Directory navigation** - Determine if `--cd` or `--cd + --includeDirs` needed
|
||||
- [ ] **Tool selected** - `--tool gemini|qwen|codex` based on task type
|
||||
- [ ] **Template applied** - Use Standard Prompt Template
|
||||
- [ ] **Constraints specified** - File patterns, scope, requirements
|
||||
- [ ] **Implementation approach** - Tool selection and workflow
|
||||
- [ ] **Timeout configured** - `--timeout` based on task complexity
|
||||
|
||||
|
||||
@@ -12,7 +12,6 @@
|
||||
|
||||
## ⚡ CCW MCP Tools
|
||||
|
||||
**优先使用 MCP 工具** (无需 Shell 转义，直接 JSON 参数)
|
||||
|
||||
### edit_file
|
||||
|
||||
|
||||
Reference in New Issue
Block a user