home / skills / cacr92 / wereply / refactoring

refactoring skill

/.trae/skills/refactoring

This skill helps you refactor Python code by applying small, verifiable steps that improve clarity and maintain functionality.

npx playbooks add skill cacr92/wereply --skill refactoring

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.0 KB
---
name: refactoring
description: 当用户要求重构、清理代码、降低复杂度、消除重复或改善可维护性时使用。
---

# Refactoring Skill

## 适用范围
- 不改变功能的结构优化
- 复杂逻辑拆分与命名优化
- 重复逻辑抽取与简化

## 关键规则(Critical Rules)
- 行为不变,先保功能
- 小步提交,随时可回滚
- 每步都有验证(测试或可复现路径)
- 涉及表格 UI 时,保持紧凑行高规范(默认 th/td padding 6px 10px、line-height 1.2;表格内 Tag 紧凑化)

## 重构流程
1. 明确当前行为与问题点
2. 设计最小改动方案
3. 小步修改并验证
4. 复核命名与边界条件

## 常见切入点
- 过长函数:拆分为可复用小函数
- 重复逻辑:抽取到单一位置
- 复杂条件:使用早返回或拆分分支
- 魔法值:提取为具名常量

## 检查清单
- [ ] 行为一致且可验证
- [ ] 改动范围最小
- [ ] 命名更清晰、重复更少
- [ ] 表格行高与内边距保持紧凑统一

Overview

This skill helps safely refactor the WeChat chat auto-reply assistant codebase to improve clarity, reduce duplication, and lower complexity without changing behavior. It guides small, verifiable changes and enforces naming, boundary handling, and compact table UI conventions. Use it to make the project more maintainable while preserving existing functionality.

How this skill works

The skill inspects functions, modules, and UI components in the Python assistant to locate long functions, duplicated logic, magic values, and complex conditionals. It proposes minimal-change refactor plans, performs small-step edits, and includes verification steps (unit tests or reproducible manual checks). It also enforces compact table styling when refactoring code that renders table-like UI.

When to use it

  • When a function exceeds a reasonable length or has multiple responsibilities
  • When the codebase contains duplicated logic across modules
  • When conditional logic is nested or hard to follow
  • When magic values are sprinkled through the code instead of named constants
  • When UI table rendering needs consistent compact styling

Best practices

  • Preserve behavior first: write or run tests before refactoring
  • Make minimal, incremental commits so changes are easy to review and revert
  • Verify each change with tests or a reproducible manual path
  • Extract repeated logic to a single function or helper module
  • Replace magic values with well-named constants and clarify intent
  • When touching table UI, keep th/td padding to 6px 10px and line-height to 1.2; compact tags inside cells

Example use cases

  • Split a long message-processing function into parse_input, route_message, and format_reply helpers
  • Extract duplicate API call logic into a shared client wrapper with retries and error handling
  • Replace nested if/else chains with early returns and a small dispatcher
  • Introduce constants for timeout, retry count, and default reply to avoid scattered literals
  • Refactor the admin dashboard table renderer to use compact cell padding and consistent tag styles

FAQ

Will refactoring change user-visible behavior?

No. The primary rule is behavior preservation. Every refactor step must include verification via tests or an explicit manual scenario to prove equivalence.

How large should each change be?

Prefer small, self-contained commits that implement a single refactor step. Each step must be reversible and accompanied by validation to minimize risk.