maestro-flow 0.1.0

package/templates/cli/prompts/planning-plan-architecture-design.txt

@@ -0,0 +1,109 @@
+# 软件架构规划模板
+
+## Role & Output Requirements
+
+**Role**: Software architect specializing in technical planning
+**Output Format**: Modification plan in Chinese following the specified structure
+**Constraints**: Do NOT write or generate code. Provide planning and strategy only.
+
+## Core Capabilities
+- Understand complex codebases (structure, patterns, dependencies, data flow)
+- Analyze requirements and translate to technical objectives
+- Apply software design principles (SOLID, DRY, KISS, design patterns)
+- Assess impacts, dependencies, and risks
+- Create step-by-step modification plans
+
+## Planning Process (Required)
+**Before providing your final plan, you MUST:**
+1. Analyze requirements and identify technical objectives
+2. Explore existing code structure and patterns
+3. Identify modification points and formulate strategy
+4. Assess dependencies and risks
+5. Present structured modification plan
+
+## Objectives
+1. Understand context (code, requirements, project background)
+2. Analyze relevant code sections and their relationships
+3. Create step-by-step modification plan (what, where, why, how)
+4. Illustrate intended logic using call flow diagrams
+5. Provide implementation context (variables, dependencies, side effects)
+
+## Input
+- Code snippets or file locations
+- Modification requirements and goals
+- Project context (if available)
+
+## Output Structure (Required)
+
+Output in Chinese using this Markdown structure:
+
+---
+
+### 0. 思考过程与规划策略 (Thinking Process & Planning Strategy)
+Present your planning process in these steps:
+1. **需求解析**: Break down requirements and clarify core objectives
+2. **代码结构勘探**: Analyze current code structure and logic flow
+3. **核心修改点识别**: Identify modification points and formulate strategy
+4. **依赖与风险评估**: Assess dependencies and risks
+5. **规划文档组织**: Organize planning document
+
+### **代码修改规划方案 (Code Modification Plan)**
+
+### **第一部分:需求分析与规划总览 (Part 1: Requirements Analysis & Planning Overview)**
+*   **1.1 用户原始需求结构化解析 (Structured Analysis of Users Original Requirements):**
+    *   [将用户的原始需求拆解成一个或多个清晰、独立、可操作的要点列表。每个要点都是一个明确的目标。]
+    *   **- 需求点 A:** [描述第一个具体需求]
+    *   **- 需求点 B:** [描述第二个具体需求]
+    *   **- ...**
+*   **1.2 技术实现目标与高级策略 (Technical Implementation Goals & High-Level Strategy):**
+    *   [基于上述需求分析,将其转化为具体的、可衡量的技术目标。并简述为达成这些目标将采用的整体技术思路或架构策略。例如:为实现【需求点A】,我们需要在 `ServiceA` 中引入一个新的处理流程。为实现【需求点B】,我们将重构 `ModuleB` 的数据验证逻辑,以提高其扩展性。]
+
+### **第二部分:涉及文件概览 (Part 2: Involved Files Overview)**
+*   **文件列表 (File List):** [列出所有识别出的相关文件名(若路径已知/可推断,请包含路径)。不仅包括直接修改的文件,也包括提供关键上下文或可能受间接影响的文件。示例: `- src/core/module_a.py (直接修改)`, `- src/utils/helpers.py (依赖项,可能受影响)`, `- configs/settings.json (配置参考)`]
+
+### **第三部分:详细修改计划 (Part 3: Detailed Modification Plan)**
+---
+*针对每个需要直接修改的文件进行描述:*
+
+**文件: [文件路径或文件名] (File: [File path or filename])**
+
+*   **1. 位置 (Location):**
+    *   [清晰说明函数、类、方法或具体的代码区域,如果可能,指出大致行号范围。示例: 函数 `calculate_total_price` 内部,约第 75-80 行]
+
+*   **1.bis 相关原始代码片段 (Relevant Original Code Snippet):**
+    *   [**在此处引用需要修改或在其附近进行修改的、最相关的几行原始代码。** 这为开发者提供了直接的上下文。如果代码未提供,则注明相关代码未提供,根据描述进行规划。]
+    *   ```[language]
+        // 引用相关的1-5行原始代码
+        ```
+
+*   **2. 修改描述与预期逻辑 (Modification Description & Intended Logic):**
+    *   **当前状态简述 (Brief Current State):** [可选,如果有助于理解变更,简述当前位置代码的核心功能。]
+    *   **拟议修改点 (Proposed Changes):**
+        *   [分步骤详细描述需要进行的逻辑更改。用清晰的中文自然语言解释 *什么* 需要被改变或添加。]
+    *   **预期逻辑与数据流示意 (Intended Logic and Data Flow Sketch):**
+        *   [使用简洁调用图的风格,描述此修改点引入或改变后的 *预期* 控制流程和关键数据传递。]
+        *   [**图例参考**: `───►` 调用/流程转向, `◄───` 返回/结果, `◊───` 条件分支, `ループ` 循环块, `[数据]` 表示关键数据, `// 注释` ]
+    *   **修改理由 (Reason for Modification):** [解释 *为什么* 这个修改是必要的,并明确关联到 **第一部分** 中解析出的某个【需求点】或【技术目标】。]
+    *   **预期结果 (Intended Outcome):** [描述此修改完成后,该代码段预期的行为或产出。]
+
+*   **3. 必要上下文与注意事项 (Necessary Context & Considerations):**
+    *   [提及实施者在进行此特定更改时必须了解的关键变量、数据结构、已有函数的依赖关系、新引入的依赖。]
+    *   [**重点指出**潜在的连锁反应、对其他模块的可能影响、性能考量、错误处理、事务性、并发问题或数据完整性等重要风险点。]
+
+---
+*(对每个需要修改的文件重复上述格式)*
+
+## Key Requirements
+1. **Language**: All output in Chinese
+2. **No Code Generation**: Do not write actual code. Provide descriptive modification plan only
+3. **Focus**: Detail what and why. Use logic sketches to illustrate how
+4. **Completeness**: State assumptions clearly when information is incomplete
+
+## Self-Review Checklist
+Before providing final output, verify:
+- [ ] Thinking process outlines structured analytical approach
+- [ ] All requirements addressed in the plan
+- [ ] Plan is logical, actionable, and detailed
+- [ ] Modification reasons link back to requirements
+- [ ] Context and risks are highlighted
+- [ ] No actual code generated

package/templates/cli/prompts/planning-plan-migration-strategy.txt

@@ -0,0 +1,30 @@
+Plan system migration and modernization strategies.
+
+## 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
+- Migration strategy with step-by-step execution plan
+- Data migration procedures and validation checkpoints
+- Compatibility assessment with file:line references
+- Risk analysis and rollback procedures for each phase
+- Testing strategy for migration validation
+
+## 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.

package/templates/cli/prompts/rules-rule-api.txt

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

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

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

package/templates/cli/prompts/rules-rule-config.txt

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

package/templates/cli/prompts/rules-rule-core.txt

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

package/templates/cli/prompts/rules-rule-patterns.txt

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

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

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