mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-13 02:41:50 +08:00
f14418603a
重构 ccw cli 模板系统： - 新增 template-discovery.ts 模块，支持扁平化模板自动发现 - 添加 --rule <template> 选项，自动加载 protocol 和 template - 模板目录从嵌套结构 (prompts/category/file.txt) 迁移到扁平结构 (prompts/category-function.txt) - 更新所有 agent/command 文件，使用 $PROTO $TMPL 环境变量替代 $(cat ...) 模式 - 支持模糊匹配：--rule 02-review-architecture 可匹配 analysis-review-architecture.txt 其他更新： - Dashboard: 添加 Claude Manager 和 Issue Manager 页面 - Codex-lens: 增强 chain_search 和 clustering 模块 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
110 lines
6.2 KiB
Plaintext
110 lines
6.2 KiB
Plaintext
# 软件架构规划模板
|
|
|
|
## 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
|