pflow-refactor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Workflow

工作流程

Scope. Infer the target and desired depth from the conversation. Ask only about a decision that cannot be resolved from available context.
Inspect. Read applicable project rules, architecture docs, implementation, tests, consumers, and relevant history. Consult current framework or language guidance when it materially affects the design. Ignore unrelated code.
Principles. Read
```
.agents/skills/pflow-refactor/references/clean-code.md
```
and
```
.agents/skills/pflow-refactor/references/solid.md
```
. Use their smells to spot problems and their fixes to justify the To Be — cite the specific principle, not a generic appeal to cleanliness.
Analyze As Is. Establish evidence: responsibilities, ownership, dependencies, mutation and event boundaries, invariants, public API, tests, duplication, naming, change frequency, and concrete size or coupling indicators. Distinguish facts from inferences.
Design To Be. Propose the smallest architecture that addresses observed problems. Prefer composition and existing extension points. Preserve behavior, reduce coupling, define ownership and atomic change boundaries, and explain naming.
Challenge. Reject speculative abstractions and premature optimization. Add managers, repositories, interfaces, base classes, event buses, or generic mechanisms only when current evidence requires them.
Report. Lead with the conclusion, then present
```
As Is
```
,
```
To Be
```
, rationale and trade-offs, a safe migration sequence, risks, and explicit non-goals. Use exact paths and symbols where available. Mark unresolved decisions instead of inventing requirements.

范围界定：从对话中推断目标和所需深度。仅询问无法从现有上下文解决的决策问题。
检查分析：阅读适用的项目规则、架构文档、实现代码、测试用例、消费者代码及相关历史记录。当框架或语言指南对设计有实质性影响时，参考当前的指南内容。忽略无关代码。
原则遵循：阅读
```
.agents/skills/pflow-refactor/references/clean-code.md
```
和
```
.agents/skills/pflow-refactor/references/solid.md
```
文件。利用其中提到的代码坏味道识别问题，并依据对应的修复方案来论证目标方案——需引用具体原则，而非笼统地呼吁代码整洁。
现状分析：确立证据：职责、归属、依赖关系、变更与事件边界、不变量、公共API、测试、重复代码、命名、变更频率，以及具体的规模或耦合指标。区分事实与推论。
目标设计：提出能解决已发现问题的最小化架构。优先采用组合模式和现有扩展点。保留原有行为，降低耦合，明确归属和原子变更边界，并解释命名规则。
方案验证：拒绝推测性抽象和过早优化。仅当现有证据表明必要时，才添加管理器、仓库、接口、基类、事件总线或通用机制。
报告输出：先给出结论，再依次呈现
```
现状
```
、
```
目标
```
、理由与权衡、安全迁移序列、风险以及明确的非目标。尽可能使用精确的路径和符号。标记未解决的决策，而非凭空创造需求。

Boundaries

边界限制

Do not edit files, implement, commit, or turn the research into a task plan unless explicitly requested separately.
Do not recommend a rewrite when incremental migration can preserve behavior.
Do not extract abstractions solely to reduce line count or superficial duplication.
Do not optimize without measurements.

除非单独明确要求，否则不得编辑文件、实现代码、提交变更或将研究转化为任务计划。
当增量迁移可保留原有行为时，不得建议重写。
不得仅为减少代码行数或表面重复而提取抽象。
不得在无测量数据的情况下进行优化。